Przejrzałem posty jeszcze raz, bo Damos już raz mi udowodnił, że mam problemy ze wzrokiem
Tam od razu "udowodnił" i "problemy"
Trzeba też rozważyć optymalizację kodu pod względem obciążalności procesora PC? Sam
symulator jest dość obciążającym procesem, a reszta? Masz jakiś pomysł?
hmm na razie mam to:
W planie są dwie wersje softu do sterowania. [...] dla najszybszej reakcji (kiedy będzie odpalony na osobnym kompie). Drugi dla jak najmniejszego zużycia CPU (żeby nie zabierać CPU symulatorowi
ale nie znalazłem nic, co by mi rozjaśniło wątpliwości. Otóż wyjaśnij proszę, czy będzie to jakaś duża aplikacja sterująca całością projektu, czyli MB i wszystkimi DB równocześnie?
Autorowi zawsze
wydaje się, że wszystko jest jasne, nawet kiedy nie jest
Już śpieszę z wyjaśnieniami:
Zgodnie z założeniami:
[...]uniwersalne[...] PCB, które będzie takie samo dla wszystkich modułów i będzie zawierać ATMega16 wraz z supportem dla USB. Do niej podłączało by się peryferia typu wyświetlacze LCD, LED, diody itd... [...] Była by to solidna podstawa do budowania różnych urządzeń. Wszystkie one były by na PC obsługiwane jednym, spójnym interfacem.
Hardware i bazowa aplikacja do sterowania nim będą kompletnie niezależne od jakiegokolwiek symulatora. Będziesz mógł używać ich z dowolnego FS'a a nawet zrobić sobie na tym sterowanie oświetleniem w domu przez internet
Mówię zupełnie serio. Główny kontroler będzie pracować jako serwer sieciowy - wystawiasz go więc na publicznym IP. [...] Łączysz się z serwerem przez [...]net
Moja koncepcja jest taka:
(zrobiłem prosty diagram do prezentacji tej idei)
http://www.damos.k11.pl/LO/diagram/index.htm
Jest tam ogólnie pokazane, jak informacje z symulatora są pobierane i wysyłane dalej za pomocą TCP do kontrolera [...]. Kontroler może być na tej samej maszynie - to nie problem. Powinien być serwisem windows lub osobną aplikacją. Dla jasności został umiejscowiony na innej.
Punkt styku oparty na TCP zdejmuje konieczność tworzenia bibliotek dla różnych języków i różnych systemów op.
- Program sterujący (Controller) jest
jeden i steruje wszystkimi MB. Do MB podłączone są DB, ale nimi Controller się nie przejmuje (w konfigu jedynie może miec zdefiniowane pewne parametry adresacji).
- Tak, jak jest pokazane na diagramie: MB podłączone do USB na PC, USB kontrolowane przez libusb, a z libusb korzysta jedna aplikacja: Controller.
- Controller będzie serwerem TCP i to będzie jedyna droga komunikacji z nim. Będzie mógł pracować jako Windows Service lub Linux Daemon.
- Protokół komunikacji będzie maksymalnie uproszczony i będzie obejmować:
* konfigurację (definiowanie fizycznych urządzeń takich jak wielkości konkretnych wyświetlaczy i ilości podłączonych diod)
* definiowanie virtualnych urządzeń (takich jak obszary tekstowe na różnych wyświetlaczach LCD, składanie kilku wyświetlaczy 7-seg w jeden, wieloznakowy. Wtedy wysyłasz dane do tego "virtualnego" urządzenia nie martwiąc się, gdzie powinien pojawić się jaki znak lub cyfra)
* wysyłanie poleceń do "virtualnych" urządzeń (np. clear)
* wysyłanie danych do "virtualnych" urządzeń (np. wysyłasz liczbę do virtualnego urządzenia "frequency disp 1" a jeden z wątków Controllera, odpowiedzialny za obsługę danego typu MB już sobie znajdzie, na jakie segmenty ma to trafić i zamieni ją na odpowiednią prezentację binarną właściwą dla tych wyświetlaczy, i wyśle je gdzie trzeba)
W późniejszej wersji Controller zajmie się również:
- symulowaniem mrugania lampek itd.
- przyjmowaniem prośby o wysyłanie zdarzeń danego typu (jak np. kliknięcia klawisza, obrót/zmiana położenia przełącznika, obrót enkodera itd)
- wysyłaniem zdarzeń (eventów) zarejestrowanym klientom (jak np. kliknięcia klawisza, obrót/zmiana położenia przełącznika, obrót enkodera itd)
- generowaniem zdefiniowanych key-kodów (emulacja klawiatury) w odpowiedzi na zdarzenia w urządzeniu USB.
Proces wysyłania danych do urządzeń USB będzie zależny od konfiguracji - albo natychmiast, albo nie częściej niż np. co 30 ms (jest szansa na zakumulowanie większej ilości zmian i wysłanie ich razem i zaoszczędzenie CPU)
Przyznaję, że nie robiłem testów obciążenia kompa przy masowej transmisji USB. Wydaje mi się jednak, że ze względu na "powolność" ATmegi nie powinno to stanowić problemu.
