Wątek: Kokpity, panele - dla budowniczych symulatorów

[vito_zm]

Witam,mam nowy pc i jestem trochę zajęty.Jeszcze nie uruchomiłem projektu Damosa,ale to zrobię .Patrząc na schematy zauważyłem,że przy naszej koncepcji możemy realizować małe projekty wymieniając uP w matce MB oraz dobierając odpowiednią córkę DB.
Przy projektach złożonych gdy potrzebujemy wszystkie rodzaje peryferiali to musimy zastosować kilka MB z odpowiednimi DB.Czy możesz Damos to potwierdzić?
Uruchomiłem program Codeking co widać na zdjęciu,ale mam zablokowany dostęp do danych.Może robię coś nie tak?

[codeking]

Z listy w polu "Profil" (combobox) trzeba wybrać jeden z profili i kliknąć na "Uruchom" (uaktywni się gdy będzie wybrany jakiś profil).

[damos]

Witam,mam nowy pc i jestem trochę zajęty.Jeszcze nie uruchomiłem projektu Damosa,ale to zrobię .Patrząc na schematy zauważyłem,że przy naszej koncepcji możemy realizować małe projekty wymieniając uP w matce MB oraz dobierając odpowiednią córkę DB.
Przy projektach złożonych gdy potrzebujemy wszystkie rodzaje peryferiali to musimy zastosować kilka MB z odpowiednimi DB.Czy możesz Damos to potwierdzić?

Dokładnie tak (z tym, ze nie trzeba wymieniać uP - wystarczy go przeprogramować). Już o tym pisałem - taka idea jest też pokazana na diagramie. To rozwiązanie ma kilka zalet, o których też już pisałem

[mickey81]

Hmm, to może by pomyśleć o płytce PCB zawierającej tylko ATmegę i elementy dyskretne oraz 'zasilacz' i ewentualnie złącze do programowania. To byłaby taka uniwersalna matka, a do niej można by dopinać córki. Takie rozwiązanie byłoby bezpieczniejsze niż 'przekładanie' scalaka.

[zajac]

Zdecydowania tak + duże złącze do córek / może kątowe, żeby je od razu łączyć i musiały by mieć tę samą szerokość, ale to nie problem / już się do tego przymierzam.

pozdrawiam Zając

[damos]

Hmm, to może by pomyśleć o płytce PCB zawierającej tylko ATmegę i elementy dyskretne oraz 'zasilacz' i ewentualnie złącze do programowania. To byłaby taka uniwersalna matka, a do niej można by dopinać córki.

  Dokładnie tak to zostało zaprojektowane:

Moja koncepcja jest taka:
(zrobiłem prosty diagram do prezentacji tej idei)
http://www.damos.k11.pl/LO/diagram/index.htm

[...] każda płyta "matka" (MB) jest podłączona bezpośrednio do USB a do niej są podłączane płyty "Córki"  (DB).
Płyt-matek jest wiele, ale każda jest taka sama (to samo PCB, kod uP inny).
Każda płyta-matka zawiera minimum potrzebne do obsługi USB (procesor, gniazdo USB, kwarc, rezystorki) i złącze do podłączenia peryferiów.

Już to sobie z Zającem omawialiśmy

edit:
@vito_zm - w nocnym amoku ( )zapomniałem dopisać, że diody podłączasz do wszystkich  "odnóży" w IC2 i IC3 (od 5 do 20). Pokazane na schemacie to jedynie przykład mający pokazać polaryzacje diod. Każdy driver (IC2, IC3) obsługuje 16 diod świecących.

[vito_zm]

Już o tym pisałem - taka idea jest też pokazana na diagramie. To rozwiązanie ma kilka zalet, o których też już pisałem

Jak zwykle masz rację.Problemy z nowym PC trochę mnie przytępiają.Przy okazji chciałem sprawdzić diagram i nie można go otworzyć.
Oczywiście programować można na MB nie wymaga to aż tak dużo elementów.
Sprawdziłem jak rozprowadzają zasilanie w OC.Głównym źródłem zasilania jest zasilacz zewnętrzny podłączony do MB (nazywanej Master).Z MB pobierają zasilanie DB (córki).W wersji z LPT masy PC oraz zasilacza są połączone.
W wersji z pakietem USB Expansion zasilacz zewnętrzny jest połączony równolegle do zasilania USB,na pin 1(USB) +5v na pin 4(USB) GND.Pakiet ten łączy się z 4 pakietami MB (Master) przez DB25.
Reasumując źródło zasilania zewnętrznego jest dostarczone do płyt MB (Master może ich być 4).Płyty te są źródłem dla DB.
Z jakiegoś powodu USB Expansion ma także możliwość podłączenia zasilacza.
Codeking już coś się dzieje w Twoim programie,muszę tylko to przeanalizować.

[damos]

Przy okazji chciałem sprawdzić diagram i nie można go otworzyć.

A co dokładnie się dzieje i jaki URL ?  Ja go z powodzeniem otwieram na kompie w firmie: http://www.damos.k11.pl/LO/diagram/index.htm . Może ustawienia bezpieczeństwa blokują ci aktywna zawartość strony ? Tam jest JavaScript.

[vito_zm]

Mam odmowę dostępu co widać na załączonym obrazku.

[damos]

To musi być sprawa konfiguracji twojego kompa. Może Norton blokuje widząc JavaScript? Na serwerze nie ma nic, co by blokowało komukolwiek dostęp do tego materiału. Jak odpalam w firmie z IE - to McAfee właśnie traktuje JavaScript jako treść niebezpieczną i połowicznie blokuje dostęp. Wydaje mi się jednak, że to błędne działanie antywira - w końcu całość strony była wygenerowana z Enterprise Architekta ...
Najszybsze rozwiązanie po wygenerowanie tego jako zwykłego obrazka: http://www.damos.k11.pl/LO/diagram/diagram_jako_image.png
To MUSI się otworzyć

[vito_zm]

Mam diagram.Damos czy dobrze rozumuję.Stack to 2 scalaki (16 wyjść).Wszystkie stacki mają wspólny zegar,wyjścia są połączone z wejściami tworząc bardzo długi rejest szeregowy.Możesz mieć np.24 wyjść strobów LE.Cały rejestr musi być zapisany,ale odczytujesz tylko ten do którego wyślesz strob LE.
Jest to ciekawe rozwiązanie z paru względów.Dla mnie najważniejsze to oszczędność kabli oraz elementów.Moje gratulacje.

[damos]

Mam diagram.Damos czy dobrze rozumuję.Stack to 2 scalaki (16 wyjść)

Prawie, ale nie do końca Stack to szereg takich scalaków, od 1 do 30 (w pierwszej wersji jeden stack może zawierać 480-cio bitowy rejestr, jest to uproszczenie wynikające z maksymalnej wielkości bufora przy transferach kontrolnych USB - 64 bajty. Można to później zmienic, ale nie jestem pewien, czy będzie taka potrzeba ). Każdy scalak ma 16 wyjść, więc 2 scalaki to już 32 wyjścia

.Wszystkie stacki mają wspólny zegar

  tak. Zarówno zegar jak i wejście są wspólne.

wyjścia są połączone z wejściami tworząc bardzo długi rejest szeregowy.

Dokładnie tak. Kolejne "scalaki" są podłączane do siebie w zakresie jednego stacka.

Możesz mieć np.24 wyjść strobów LE. Cały rejestr musi być zapisany,ale odczytujesz tylko ten do którego wyślesz strob LE.

Tak właśnie to działa (zmienił bym tylko zwrot "odczytujesz tylko ten" na "zapamiętujesz stan rejestru w tym", bo faktycznie to te rejestry sa Read-Only ) Wyjść strobów mam 28...

[vito_zm]

Przejrzałem jeszcze raz koncepcję sterowania DB dla wersji LED i mam do Ciebie Damos pytanie.W tej koncepcji jest 28 linii odczytujących 2 rejestry wyjściowe,czyli mamy max.56 bajtów do dyspozycji.Czyli jest to rejest szeregowo-równoległy o długości 448 bitów podzielony na pamięci 16 bitowe.Zapis następuje do 2 rejestrów wyjściowych określoną linią LE strobu w odpowiednim momencie czasowym.
Jeśli chcemy zapisać ostatnie 2 bajty to musimy przesłać cały ciąg danych czyli 448 bitów.Jeśli chcemy zapisać pierwsze 2 bajty to możemy przesłać krótki ciąg danych czyli 2 bajty
Jeśli mamy zapas czasu na zapis oraz procedura zapisu wszystkich 448 bitów nie jest skąplikowana to można jedną linią LE zapisać wszystkie rejestry jednocześnie.W tym przypadku odświeżamy z RAM uP stare wartości w rejestrach wyjściowych i zapisujemy nowe.Wadą tej koncepcji jest to,że musimy czekać z odczytem tak długo,aż zostanie wysłany cały ciąg 448 bitów.Czy jest to realne z punktu widzenia programisty,czy może popełniam jakiś błąd?

[damos]

Przejrzałem jeszcze raz koncepcję sterowania DB dla wersji LED i mam do Ciebie Damos pytanie.W tej koncepcji jest 28 linii odczytujących 2 rejestry wyjściowe,czyli mamy max.56 bajtów do dyspozycji.

Nie do końca.
Mamy 28 osobnych rejestrów z wejściem szeregowym i wyjściem równoległym. Taki jeden rejestr to właśnie "stack", ponieważ składa się ze stosu połączonych mniejszych układów.
Każdy "stack" ma maksymalną pojemność 60 bajtów, czyli 480 bitów. Nie ma minimalnej długości. 28 takich stacków daje nam w sumie 13 440 bitów (można wysterować tyle diod LED  lub 1680 wyświetlaczy 7-seg lub 280 zestawów każdy po 6 wyświetlaczy 7-seg  :karpik - i to za pomocą jednej ATmegi16...)

Zapis odbywa się za pomocą 3 linii:
- pierwsza to CLK - czyli zegar
- druga to SDI - czyli Serial Data In
- trzecia to LE - czyli Latch Enable
Mamy więc 28 linii (odbiorników) odczytujących JEDEN sygnał wejściowy (wspólny dla nich) - linię SDI bit po bicie, zgodnie z sygnałem zegarowym generowanym przez uP (CLK).

Czyli jest to rejest szeregowo-równoległy o długości 448 bitów podzielony na pamięci 16 bitowe.

Nie do końca. Jest to 28 osobnych rejestrów . Każdy o zmiennej długości (maksymalnie 480 bitów). Każdy z osobnym wyjściem równoległym.

Zapis następuje do 2 rejestrów wyjściowych określoną linią LE strobu w odpowiednim momencie czasowym.

Podawanie danych następuje do wszystkich rejestrów w tym samym czasie. Zapis - tylko jednego rejestru, za pomocą wybranej linii LE.

Jeśli chcemy zapisać ostatnie 2 bajty to musimy przesłać cały ciąg danych czyli 448 bitów.

Długość ciągu danych zależy od zdefiniowanej długości rejestru. Ogólnie - zawsze podaję tyle bitów, ile ma dany rejestr.

Jeśli chcemy zapisać pierwsze 2 bajty to możemy przesłać krótki ciąg danych czyli 2 bajty

Jest to ryzykowne. Przy zapisie za pomocą LE zmieniane są wszystkie bity w rejestrze. Tak więc powinniśmy zawsze podać tyle bitów, jak długi jest rejestr. W przypadku rejestru 480 bitowego - trzeba podać tyle bitów. Jeśli podłączyliśmy odbiorniki tylko do pierwszych 2 bitów - możemy podać tylko 2 bity i wywołać zapis. Pozostałe bity poprostu nie będą widoczne na żadnym odbiorniku i można je ignorować. Należy jednak pamiętać, że każdy rejestr może mieć inną długość.

Jeśli mamy zapas czasu na zapis oraz procedura zapisu wszystkich 448 bitów nie jest skomplikowana to można jedną linią LE zapisać wszystkie rejestry jednocześnie.

Nie. Każda linia LE jest osobna dla wszystkich rejestrów. W każdym rejestrze wywołujemy zapis osobno.

Wadą tej koncepcji jest to,że musimy czekać z odczytem zapisem tak długo,aż zostanie wysłany cały ciąg 448 1-480 bitów.Czy jest to realne z punktu widzenia programisty,czy może popełniam jakiś błąd?

Jest właśnie tak. Podajemy wszystkie bity (etap "write" ) a następnie a następnie zatrzaskujemy w rejestrze (etap "store"). Czasowo na uP wygląda to tak:
zapis rejestru 72 bitowego: 100.82 us (dla 1 linii to 9918 fps, dla wszystkich 28 to 354 fps)
zapis rejestru 480 bitowego: 339.7 us (dla 1 linii to 2943 fps, dla wszystkich 28 to 105 fps)

Tak więc szybkość samego uP wystarczy. Problemem będzie przepustowość USB dla HID low speed, USB ControlMessage oraz software'owej implementacji USB ma uP.
Maksymalna teoretyczna prędkość USB ctrlMessage dla low speed to 64 Kbps To daje mniej niż 4 fps przy 13 tys. diod Faktyczna szybkośc tej implementacji USB na ATmega16 jest mniejsza - jeszcze jej nie mierzyłem dokładnie. MJoy ma USB o prędkości poniżej 10Kbps...

Rozwiązaniem problemów szybkości jest sprzętowe USB. Pracuję nad tym w wolnych chwilach. Jeśli powstanie to będzie w 100% kompatybilne z softem na PC, który zrobię dla obecnego systemu. Jedynie wepniesz inny hardware do USB (zastępując kilka obecnych MB jedną MB mkII) i nie będziesz musiał NIC więcej zmieniać. Mimo zmiany/dodania hardware'u moduł widoczny na diagramie (http://www.damos.k11.pl/LO/diagram/diagram_jako_image.png) jako "ControllerService" zachowa dokładnie ten sam interface i aplikacje zewnętrzne nawet nie będą o tym wiedzieć.

Przypominam, że polecenia zapalenia/zgaszenia konkretnych diod wysyłasz do kontrolera a już on zajmuje się optymalną strategią update'owania tego na USB.

jeśli coś nadal nie jest jasne - proszę o pytania

[vito_zm]

Po tym wyjaśnieniu widzę dopiero możliwości tego projektu.Mój błąd polegał na tym,że przez stack rozumiałem te 2 rejestry na schemacie a całość jako 28 x2 czyli 56 bajtów.Teraz widzę,że moje pytania nie miały sensu,ponieważ projekt ma takie możliwości,że trudno sobie wyobrazić jego praktyczne zastosowanie.Właściwie to system jako całość z softem jest dobrym materiałem na patent (kiedyś to było modne,nie wiem jak to teraz wygląda).Jestem pełen podziwu dla Twojej wyobraźni.
Jeszcze raz gratuluję,przepraszam za pytania,ale to mój stary nawyk,gdy coś mam zrobić staram się  zrozumieć działanie układu
pozdrawiam,vito_zm