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

[damos]

spox, damy radę. Ja tez mam inny - kompatybilny (podobno)

[vito_zm]

Witam,
kiedy Ty śpisz Damos?

W niektórych kontrolerach masz ograniczoną ilość czasu pomiędzy kolejnymi transferami danych.

Poczytałem trochę na temat kontrolera HD44780 i nie znalazłem informacji na ten temat wynika z tego,że nie ma ograniczeń.Wspominacie o innych kontrolerach.Znalazłem opis procedur dla KS0108 może komuś się przyda http://radzio.dxp.pl/ks0108/
Uświadomiłem sobie przy okazji czytania opisu HD44780 z problemów jakie będą przy odczycie RAM dla DED Falcona.Co do odczytu PFL to nie powinno być problemu (tak myślę).PFL daje tylko komunikaty czyli przy zmianie komunikatu można przesłać nowy komunikat.DED jest interaktywny czyli możemy wpisywać w określone miejsce w określonej lini dane (znaki).W związku z czym program musi przesłać dane do określonego miejsca w danej lini,ale jest to problem na przyszłość gdy powstawną konkretne aplikacje.

[Fiero_185th VFS]

Po obejrzeniu tego filmiku; http://www.mikesteven.pwp.blueyonder.co.uk/blackshark/blackshark_touchbuddy_2.avi
doszedłem do wniosku że budowa kokpitu stricte pod F16 jest jest pomysłem krótkowzrocznym.
No chyba że ktoś ma tyle funduszy i miejsca że jest w stanie zrobić kilka kokpitów lub też chce latać F16 i niczym innym.

[damos]

Vitam ! Mam już komunikację między PC a ATmega16 po USB. Teraz "tylko" dorzucić obsługę wyświetlaczy, jakiś interface po stronie PC i gotowe...

[vito_zm]

Gratulacje Damos,jesteś jak zwykle niezawodny.

Teraz "tylko" dorzucić obsługę wyświetlaczy

Codeking i Gerrah już to zrobili.Codeking z poziomu uP Gerrah pc.Myślę,że jest moment na przejście na  ATmega16 ze względu na USB.Z tego co wiem to można procedurę obsługi wyświetlacza napisać w C++,zrobić kompilację oraz połączyć z programem Damosa.Trzeba też ustalić jaki stosujemy wyświetlacz ile linii oraz znaków (oparty na kontrolerze HD44780).Nie jestem pewien czy przy ustalaniu konkretnego wyświetlacza nie pojawią się problemy z uniwersalnością jego zastosowania.Mam na myśli np.PFL gdzie potrzeba tylko2 linie oraz FS gdzie być może potrzeba więcej linii.Pytanie jest następujące,czy wybór konkretnej aplikacji (falcon,FS)jest z poziomu menu PC czy są to oddzielne programy a raczej procedury

jakiś interface po stronie PC ...

W tym punkcie można chyba stworzyć jakiś wspólny protokół komunikacyjny pc USB nie zależnie od aplikacji.Nie mam pojęcia jak pobierać dane dla FS.Co do falcona to Gerrah już to robi,tzn.zna adresy gdzie są dane.
Ja próbuję od pewnego czasu uzyskać informację na ten temat a konkretnie o tzw.Share memory z viperpits,ale bezskutecznie.Pytam w dalszym ciągu.
Teraz wszystko w rękach programistów.Może warto poprosić innych np.Some1 o pomoc.Z mojej strony deklaruję pomoc na poziomie hardware,ale to niewiele.Mogę zrobić prototyp i go testować jeśli to pomoże.

[Gerrah]

Wielkością wyświetlacza nie zawracałbym sobie głowy, to nie ma większego znaczenia. Bardziej przejmowałbym się czy ma być wykorzystywany interfejs 4 bit czy 8 bit.

Vito_zm, co do pamięci współdzielonej to później dokładniej przyjrzę się tamtej bibliotece co podałeś. Co prawda z DED i PFL w tej chwili nie ma problemu, ale chciałbym móc wyciągnąć resztę danych.

[vito_zm]

Wydaje się,że w 8 bitowym wariancie można w przyszłości multipleksować linią E kilka wyświetlaczy.Linia RW może być ustawiona na stałe na zapis tak jak jest w wariancie 4 bit.
ps
Gerrah witam na forum viperpits

[damos]

Z tego co wiem to można procedurę obsługi wyświetlacza napisać w C++,zrobić kompilację oraz połączyć z programem Damosa.

Gdyby to było takie proste... Teraz muszę dodać support dla wyświetlaczy w uP. Będzie to wymagało przerobienia sterowników do HD44780. Kodu sterującego HD44780 jest całą masa. Problem polega na tym, że pojawiły się nowe ograniczenia odnośnie obsługi USB Kontroler (uP) musi robić tzw. polling (czyli cykliczne odpytywanie) USB z pewnym maksymalnym interwałem czasowym. To będzie wymagało wywoływania obsługi USB z wnętrza kodu obsługującego wyświetlacze. To będzie roboty na minimum 24godziny kodowania.

Trzeba też ustalić jaki stosujemy wyświetlacz ile linii oraz znaków (oparty na kontrolerze HD44780).

To będzie mogło być konfigurowalne.

Nie jestem pewien czy przy ustalaniu konkretnego wyświetlacza nie pojawią się problemy z uniwersalnością jego zastosowania.Mam na myśli np.PFL gdzie potrzeba tylko2 linie oraz FS gdzie być może potrzeba więcej linii.

Na razie tylko HD44780. Dla innych wyświetlaczy trzeba będzie zmienić firmware (oprogramowanie uP).

Pytanie jest następujące,czy wybór konkretnej aplikacji (falcon,FS)jest z poziomu menu PC czy są to oddzielne programy a raczej procedury

Po stronie PC jest moduł, który udaje virtualny wyświetlacz. Dowolna inna aplikacja ustawia na nim tekst a on juz zajmie się przesłaniem tego do fizycznego wyświetlacza. Nasze rozwiązanie nie będzie zależeć od konkretnego symulatora.

  W tym punkcie można chyba stworzyć jakiś wspólny protokół komunikacyjny pc USB nie zależnie od aplikacji.

Nie. Można zrobić protokół komunikacji z aplikacją, a inne moduły nawet nie mogą mieć pojęcia, że sprzęt jest podłączony przez USB. Ze względu na ograniczenia sprzętu protokół USB zależy tylko i wyłącznie od możliwości sprzętu.

Nie mam pojęcia jak pobierać dane dla FS.Co do falcona to Gerrah już to robi,tzn.zna adresy gdzie są dane.

A to jest inny problem.

Z mojej strony deklaruję pomoc na poziomie hardware,ale to niewiele.Mogę zrobić prototyp i go testować jeśli to pomoże.

Z pewnością będzie to pomocne.

[vito_zm]

To będzie wymagało wywoływania obsługi USB z wnętrza kodu obsługującego wyświetlacze. To będzie roboty na minimum 24godziny kodowania.

Jako laik zadam trywialne pytanie,czy nie lepiej zastosować wyspecjalizowany układ realizujący USB zamiast tworzyć jego emulację w uP.Czy to rozwiązanie uprościłoby w znaczący sposób programowanie?
Druga sprawa to łączenie programów pisanych przez kilku programistów.Z tego co pamiętam z mojej pracy zawodowej to pisaliśmy procedury w języku PL a później w Paskalu i tworzyliśmy biblioteki.Każdy kto programował swój uP z nich korzystał.Ten sposób programowania był dosyć efektywny.O tym myślałem  aby każdy programista napisał swój moduł lub procedurę,nie jestem pewien czy w naszym przypadku jest to możliwe.

[damos]

Jako laik zadam trywialne pytanie,czy nie lepiej zastosować wyspecjalizowany układ realizujący USB zamiast tworzyć jego emulację w uP.Czy to rozwiązanie uprościłoby w znaczący sposób programowanie?

I tak i nie Po pierwsze - jestem(śmy) ograniczony do Atmeli. W rodzinie Atmela praktycznie tylko dwa układy zasługują na uwagę: AT90USB oraz AT32UC3(B). Pierwszy jest dwa razy droższy od Atmega16, ma sprzętowe USB z którym i tak trzeba się narobić i do tego tą sama szybkość co Atmega16 a obudowę trudniejszą do lutowania (tylko SMD: TQFP48).  Drugi to 32-bitowa kość nowej generacji, obsługiwana innym kompilatorem, z innym API. Posiada USB i jest kilkukrotnie szybsza od ATmegi, ale też dwukrotnie droższa. Ma sprzętowe USB, może pracować nawet jako host USB. Obudowa jeszcze bardziej hardcore'owa: TQFP64 lub TQFP100 Gabarytowo zaś jest mniejsza od wszystkich za wyjątkiem ATiny Oczywistym wyborem jest w miarę tania kość z dużymi możliwościami. Powinno dać się na niej (jednej) zrobić wyświetlacze, enkodery, sterowniki diod, dodatkowe klawisze etc.
http://www.atmel.com/dyn/resources/prod_documents/doc32059.pdf
http://www.atmel.com/dyn/resources/prod_documents/doc32000.pdf
Ale to jest dłuższa robota. Nad ATmega usiadłem na kilka godzin i jest efekt. Na AT32UC3B potrzebuję kilku tygodni. Ponad 1000 stron dokumentacji

Druga sprawa to łączenie programów pisanych przez kilku programistów.Z tego co pamiętam z mojej pracy zawodowej to pisaliśmy procedury w języku PL a później w Paskalu i tworzyliśmy biblioteki.Każdy kto programował swój uP z nich korzystał.Ten sposób programowania był dosyć efektywny.

U nas tylko jedna osoba programuje uP Ja mogę przyjąć biblioteki dla AVRGCC.

[vito_zm]

Czyli sprawa jest wyjaśniona.Jeśli coś chcemy robić to na tym na czym się znamy.Teraz pytanie ogólne czy jesteśmy w stanie określić moduły programowe lub raczej procedury tak aby po uzgodnieniu danych wejściowych i wyjściowych (tak to się chyba nazywa w programowaniu obiektowym) można było je pisać.Chodzi o to,żeby odciążyć Damosa.Zdaję sobie sprawę,że programowanie pod konkretny uP wymaga jego znajomości,ale z tego co wiem z tym nie powinno być problemu.   

[Gerrah]

Mi, jakby co, należy wskazać co i w czym a ja już postaram się aby zostało to jak najszybciej i w miarę bezbugowo zrealizowane

Szkoda, że na USB się kompletnie nie znam Każdorazowo po wpisaniu w google "usb documentation" dostaję dreszczy i pot mi się skrapla na czole

[vito_zm]

Każdorazowo po wpisaniu w google "usb documentation" dostaję dreszczy i pot mi się skrapla na czole

Myślę,że z tym nie będzie problemu ponieważ Damos to już rozwiązał.Ponieważ jest on zawodowym programistą i ma największe z nas doświadczenie w programowaniu i nie tylko to on zadecyduje o dalszej współpracy i podziale zadań.

[bip3r]

Panowie, jak tak sobie śledzę ten wątek i czytam co tu piszecie w niezrozumiałym dla mnie języku , to mam wizję, że jak już się Wam uda doprowadzić ten projekt do końca, to szkoda by Wasz trud i wiedzę marnować na "jednorazowy" użytek.
Jak będą efekty (np. w postaci możliwości wyświetlania MFD z Falcona [takie śmiałe marzenie ] ) to powinniście poważnie zastanowić się nad ścisłą współpracą, z założeniem firmy, produkcją i dystrybucją tego rozwiązania, co jak sądzę znalazłoby zbyt nie tylko wśród chłopaków z 13-ej, ale w całym światku Falcona.

Z taką wizją w główce, pozdrawiam, trzymam za Was kciuki, życzę powodzenia w realizacji i nie wcinam się już w temat

[vito_zm]

Jak będą efekty (np. w postaci możliwości wyświetlania MFD z Falcona [takie śmiałe marzenie

To już jest zrobione i dostępne za free.Za tydzień dostanę nowy pc to rozpocznę testy z MFD.Napiszę o tym dokładnie w swoim wątku.