OpenElDisp

[oko]

ElDisp jest genialnym rozwiązaniem, jeśli chodzi o koncepcję i sprzęt. Niestety, na poziomie oprogramowania ma sporo wad i mankamentów:

-pozycja jest zapisywana w sztywnym interwale 5 s., co powoduje ogromne problemy gdy zasięg się rwie. Wtedy jest wielka szansa utracenia ostatniej ważnej próbki. Tym bardziej, że jeśli nawet zostanie ona wyświetlona, to zniknie zastąpiona komunikatem o utracie linku i braku telemetrii

-strzałka pokazująca kierunek do bazy działa z bardzo dużym opóźnieniem i mało precyzyjnie (ma tylko 8 pozycji)

-nie obsługuje Mavlinka

-wymaga windows do konfiguracji

-no i nie jest open source :) a to źle, bo nie można modyfikować i się uczyć, jak to działa.

Postanowiłem zatem napisać otwarty zamiennik działający na tym sprzęcie. Ma być on z założenia bardziej "hakerski". Ma też pełnić funkcję edukacyjną, przynajmniej dla mnie :) Tu już sporo się udało, bo zrobiłem wiwisekcję ElDispa i sporo się nauczyłem, ale jeszcze więcej mam pytań.

Najbardziej mnie zastanawia, dlaczego port szeregowy i port I2C są zamienione miejscami względem standardowego przypisania wyjść procesora? Dlaczego tak się robi? No chyba nie ze względu na prowadzenie ścieżek? Sporo to komplikuje. Do komunikacji z pamięcią po I2C można użyć biblioteki SoftwareI2C, która pozwala zmienić przypisanie wyprowadzeń. Z portem szeregowym też zapewne tak można, ale pozostaje kwestia bootloadera. Na szczęście jest dostępne (choć nie opisane) kompletne złącze ISP, więc nie jest mi niezbędne wgrywanie oprogramowania po porcie szeregowym. Ale jeśli miałoby być możliwe, to zapewne potrzebny jest specjalizowany bootloader? Taki, któremu można powiedzieć, że "port szeregowy masz na PC5 i PC4". Czy są dostępne takie konfigurowalne bootloadery?

Sterowanie wyświetlaczem jest opisane tu, a wyświetlacz LPH7366 z 9 wyprowadzeniami tu.

[miś]

Widzę żę wziąłeś się za eLDisp'a 1.
Rozwieję część Twoich wątpliwości.
Po pierwsze sprzętowe I2C jest równolegle połączone z UART'em. Po co ? A no w fazie tworzenia projektu była opcja aby taki wyświetlacz był sterowany po i2c. No ale padła, bo nie znalazłem sensu sterowania po I2C, więc nigdy to nie zostało zrealizowane, ale połączenia na PCB zostały.
Dla tego też do pamięci eeprom zastosowany został programowy interfejs I2C (a pamięć jako taka wylądowała w projekcie jak już wszystko było prawie gotowe, więc została podłączona tam gdzie było bliżej

Co do bootloadera, to typowy FastBoot, i do ładowania możesz użyć mojego FbootLoadera (oryginalnie przeznaczonego do mojego OSD).
BTW właśnie FastBoot potrafi używać dowolnych pinów wykorzystując softwarowy uart.

[oko]

Wielkie dzięki za rady, nie jest to takie proste dla początkującego. Póki co udało się zbrickować elDispa, ale komunikacja przez ISP działa, więc to zapewne kwestia bootloadera. Zamówiłem arduino nano z atmegą 168 do prób, tam będzie łatwiej bo odłączone są peryferia. Teraz muszę się zająć innymi sprawami w oczekiwaniu na to nano, ale dzień z elDispem to nie był stracony czas :)

EDIT: on żyje! Blink działa na nóżce 32, ale nie na 13 (mimo że chyba ta też nie jest podłączona), no ciekawe ciekawe...

EDIT2: ale kolejny problem: niby pisze przez port szeregowy na terminal (to już coś), ale pojawiają się krzaki. Mimo ustawienia prędkości transmisji i jawnego podania parametrów SERIAL_8N1. Dlaczego tak? Czy to bootloader coś zmienia, czy hardware?

[miś]

Pewnie źle ustawiłeś prędkość UART'a. W eLDispie jest kwarc 8MHz, a nie 16MHz jak w arduino.

[oko]

Dzięki wielkie, faktycznie tak jest! Po co się w takim razie przy kompilacji bootloadera podaje częstotliwość procesora? Pewnie właśnie po to, by to dostosować, a ja coś pomieszałem z tymi bootloaderami...

Teraz muszę sprawdzić, czy port ISP jest wrażliwy na taką zmianę częstotliwości.

[miś]

W tym akurat FastBoocie po nic A w zasadzie tylko po to aby czekał zadane 0.33 sekundy na komendę "Connect". Ten bootloader ma autobaud i potrafi ładować na dowolnej szybkości, byle by tylko dało się takową uzyskać dla danego kwarcu. Przy 8MHz działa do 57600baud. Ale jak w programie na PC ustawisz 9600 to też załaduje, bo bootloader rozpozna że gadają do niego na 9600.

[oko]

Sporo się udało:

-wgrać nowy bootloader i teraz szybkości portów są OK
-rozmawiać z pamięcią po I2C
-ożywić LEDy
-wykryć naciśnięcia przycisków
-wgrać hex-a z oryginalnym elDispem i zobaczyć stare dobre "MisiuSoft" na wyświetlaczu

Jedyne, co się kompletnie nie udaje, to uruchomić wyświetlacz. Był i jest pusty. Ale żyje, jak to pokazuje wgranie oryginału. Wyświetlacz LPH7366 a jego sterownik to PCD8544. Coś źle z nim gadam albo źle przypisałem wyjścia procesora. W sieci są różne wersje sekwencji sterujących - ma ktoś doświadczenia?

Tak czy inaczej, chyba zrobię też wersję na elDispa v2, powinno być łatwiej z tym OLEDem. A może nie?

EDIT: pomyliłem się śledząc przelotki i ścieżki - teraz działa i wyświetlacz!

[oko]

Dodałem obsługę przycisków i parsowanie komunikatów. Wyświetlam otrzymane wartości na ekranie. Najbardziej mnie martwią duże opóźnienia przy transmitowaniu kursu (zakładając że parametr c=XXX to kurs, ale chyba tak), od pół sekundy do dwóch-trzech sekund. To w praktyce uniemożliwia sensowne wykorzystanie tej telemetrii do wracania na jej podstawie do bazy. Dlaczego tak się dzieje? Czy wolno przychodzą ramki, czy też rzadko są modyfikowane, a może trzeba ustawić inne parametry generowania mavlinka w ArduPilocie?

Dla porównania zrobię też parser mavlinka w OpenElDispie.

EDIT: i jeszcze fajnie by było, gdyby się dało określić preferencje co do telemetrii. Pasmo jest ograniczone i każdy by chciał je wykorzystać wg swoich preferencji. Dla mnie dane o kursie są znacznie ważniejsze niż np pozycja, nie mówiąc już o temperaturze odbiornika albo napięciu (to można uaktualniać co kilka sekund). Poniekąd tak jest w ArduPilocie, gdzie jest chyba z 10 parametrów określających jakie dane są wysyłane z jaką częstotliwością.

Czy ElDisp v2 jest na procesorze 328? Niestety pierwsza wersja jest na 168, a na nim nie chce mi działać biblioteka FastSerial, wiesza się i tyle.