Hapcan Programmer 2 - dev

[pawel]

działa jak piszesz

ps. 1. przy buttonie na szynę din 3.1.0.x pokazuje temperaturę mnie ta zima męczy to mam słońce tak to się dopiero pisze nie czepiam się!
2. nadal raz widzi ramki z sieci raz nie, ale na też przyjdzie czas
puki co elegancko, szybkość skanowania modułów jest imponująca, czasem zdarza się że przy pierwszym skanowaniu parę modułów jest 'unkwown'

[Bartek]

1. Gdzie ta temperatura się pojawia, przy skanowaniu czy tak o sobie? 3.1.0 nie powinien wysyłać ramek z temperaturą. Może to jakiś inny moduł wysyła?

2. Jeszcze na to nie patrzyłem, a samo skanowanie narazie jest zrobione najprościej w stylu zapytaj i zapomnij . Docelowo programer będzie na koniec uzupełniał dane jeśli będą niekompletne. Obecnemu programerowi też się u mnie zdarza nie zaczytać czasami np. opisu modułu.

[engee974]

Hello everybody,
I would like to help but... could you write in english ?

Thanks,
Nicolas

[Bartek]

I don't know whether others would but I can write important notes in english too. First off all, which areas You can help? There are programmers, testers or just people with good visions and ideas welcome .

---

P.S. Zmieniłem nicka na forum z PelzaK na Bartek, na wypadek gdyby ktoś się poczuł zmieszany .

[engee974]

Thanks !

I'm a programmer and could also test.
I don't know C# but can learn it.

I will check the git and get the sources.

[Bartek]

It is now on very early state of developing so I'm currently prototyping and checks possibilities . I'm using C# occasionally in my current daily work so I'm learning too - especially using the frameworks is a huge task. C# language itself is pretty easy.

I need to figure out few concepts before full plugins development for all devices can be started.

[Bartek]

Jacku, czy moduły poprawnie zachowają się jeśli wejdzie się w tryb programowania i z niego wyjdzie bez wykonywania innych czynności?

Wysyłam dwie ramki, wejście i wyjście z trybu programowania spodziewając się resetu urządzenia ale coś nie bardzo chcą wyjść z trybu programowania.

Edit: Dobra już wiem, po prostu za szybko wołałem wyjście, zanim urządzenie zdołało wejść w tryb programowania. Ale czyżby FIFO tutaj nie działało? Pewnie ramka z wyjściem z trybu jest odrzucana jesli urządzenie nie jest w trybie programowania (?).

[Jacek]

Wydaje mi się, że tak. Przed chwilą jeszcze sprawdziłem...

W trybie programowania nie ma FIFO. Moduł może odebrać tylko jedną widomość i urządzenie nadrzędne musi czekać na odpowiedź modułu

[Bartek]

Podobnego screena z opisem algorytmu sobie chwilę wcześniej rozrysowałem analizując co i jak . Użyję jednak pytania o Hardware Type (0x103) zamiast o status w oczekiwaniu na restart, ze względu na podział rozpoznawania wiadomości na pluginy (status obsługują pluginy dedykowane do urządzeń, wiadomości bootloadera plugin obsługujący bootloader).

[Jacek]

Widziałeś ten rysunek?

[Bartek]

Oczywiście. Pdf z dokumentacją to podstawa . Przerobiłem ją już wielokrotnie, np. przy implementacji Hapcanuino, teraz nieco od innej strony skupiając się na programowaniu pamięci. Dopiero teraz zrozumiałem dlaczego struktura EEPROMa jest taka a nie inna (posiada luki np. w okolicy identyfikatorów node i group). Samo programowanie pamięci wymaga nieco więcej uwagi, no bo można uszkodzić firmware . A jak się testuje "na produkcji", czyli na działających modułach w mieszkaniu to tym bardziej trzeba być ostrożnym . Ale spoko, nie pierwszy raz programuję w takich warunkach .

[Bartek]

Jacku, czy wersja bootloadera zwracana przez moduł gdy wejdzie w tryb programowania jest wykorzystywana np przy programowaniu pamięci EEPROM? Przykładowo początkowe bajty EEPROMa mają inną strukturę dla modułów, które obsługują szybki odczyt pamięci od tych, które nie obsługują więc czy te moduły mają różną wersję bootloadera i po niej rozpoznają znaczenie bajtów w EEPROMie?

Implementuję właśnie programowanie pamięci EEPROM i zastanawiam się, czy są wykorzystywane różne struktury danych w zależności od wersji bootloadera czy od wersji firmware?

[Jacek]

Od dłuższego czasu bootloader jest w wersji 3.4. Obie wersje firmware (ta z szybkim odczytywaniem pamięci i bez) używają tego samego bootloadera.
Różnica jest w samym firmware. Ten z szybkim odczytem pamięci zaraz po uruchomieniu uruchamia procedurę sprawdzania ostatniej komórki pamięci (https://github.com/hapcan/UNIV_3.2.4.x/ ... v4.inc#L65) i zapisuje ją w eeprom pod adresem 0xF00002 (ostatnia komórka eeprom) i 0xF00005 (ostatnia komórka pamięci flash).
Następnie to HAPCAN Programator sprawdza wersję firmware i wtedy wie czy może wykorzystać komórki 0xF00002 i 0xF00005 do szybkiego odczytu pamięci.

Z Twojego punktu widzenia ta funkcja może być w bootloaderze. Mi zależało na implementacji funkcji niezależnie od wersji bootloadera w procesorze.

[Bartek]

Taki mały raporcik. Działa już jedna zakładka Settings > ID and Desctiription, gdzie można zmienić ID i nazwę modułu. Testowałem 3 różne podejścia do sposobu programowania modułu, więc trochę to trwało. Cała trudność polega na tym, że komunikacja jest asynchroniczna, czyli sam algorytm programujący działa stanowo i jest niezależny od wątku odbierającego wiadomości. Na wypadek gdyby ktoś chciał kompilować, to trzeba przestawić pętlę skanującą aby leciała od początku - na potrzeby testów u mnie sprawdzam na jednym module RGB, który leży w grupie 208 więc skanowanie odbywa się w wyższych grupach tylko.

Podświetlenie modułu na żółto oznacza, że moduł jest w trybie programowania. Po zaprogramowaniu urządzenie jest pingowane co sekundę przez ramkę HardwareTypeRequestToNode aby sprawdzić czy się zrestartowało poprawnie.

[kompio]

Podczas uruchomienia mam błąd :