o

Cześć.

Dłubię sobie małe urządzenie. Konkretnie sterowalny generator DSS, ale to nie jedyne. Zakładam, że będzie on miał izolowane wejście USB, działające w trybie uart.

Chciałbym go z PC, najlepiej z Pythona, obsłużyć. C++ nie pogardzę.

Mogę coś sam wymyśleć.

ALe może ktoś trafił na jakąś biblitekę + protokół komunikacyjny, który mogę łatwo zaimplementować na uC w urządzeniu i automatycznie dostać działającą komunikację? Jak by potrafiło się "samo" tworzyć GUI do tego, na podstawie discovery urządzenia, to było by naprawdę świetnie.

Mam taki własny protokół, który rozwijałem ze 20 lat temu, który własnie to potrafi, tzn po podpięciu dodolnego urządzenia zgłasza się i PC odczytuje rejestry, funkcje itd a nastepnie automatycznie tworzy interaktywny panel sterujący. Mogę go użyć (Java), ale to nie jest standardowe. Ale może jest coś podobnego, uzywanego powszechnie? Nie chcę mojego kwadratowego koła używać, jeśli jest coś bardziej standardowego.

Na razie widzę, że są rozwiazania pchające jsona przez uart do uC. Ale to i tak wymaga rękodziela.

W skrócie: szukam blbiteki pozwalajacej wykonać 90% komunikacji z mikrokontrolerem i opcjonalnym bajerem typu autodiscovery + GUI.

Nienie ;)

Wyobraź sobie, że masz urządzenie modbus. Coś prostego.

Takie urządzenia (modbusowe) są skrajnie tępe. Nie da da się, poza wykryciem "ma jakieś rejestry" niczego więcej osiągnąć, bez osobnej dokumentacji.

Ja moim protokołem, który używałem 20 lat temu, mogłem każdy rejestr opisać:

Te dane były w urządzeniu, można było o każdą odpytać.

... oraz nie tylko wyenumerować wszystkie rejestry, ale również wszystkie urzadzenia na magistrali RS485 dynamicznie, podczas komunikacji z pozostałymi urządzeniami, równolegle.

Proto nie był rozwinięciem modbusa, tylko czymś zupełnie innym.

W efekcie czego na PC istniał sobie program w Javie. Program ten po odpaleniu i podaniu COMa do komunikacji szukał urządzeń. Jak znalazł nowe, to enumerował wszystkie rejestry i samoczynnie tworzył panel kontrolny tego urządzenia. To było dynamiczne, mogłeś wpinać i wypinać urządzenia z RS485 i każde zgłaszało się samo i dostawałeś generyczne GUI typu suwagi, gałki itd. Program w Javie nie wiedział co to jest, ale wiedział jak to obsługiwać, z opisu rejestrów pobieranego z urządzenia.

Dodatkowo eksponowało to wszystkie rejestry do Javascriptu, na którym pisany był główny algorytm sterujący wieloma takimi urządzeniami.

Czyli: spodziewam się, że tworze jakieś urządzenie "w arduino" w którym mam do kontroli ze dwa int-y i jaką flagę statusową. Zamiast wymyślać nowy protokół dla takiego urządzenia, to chciałbym mieć jakiś generyczny, w którym proces enumeracji, detekcji urządzeń jest w pełni automatyczny, eksponując mi to wszystko na PC w postaci API Pythona, oraz, jako bonus, mogę sobie stworzyć z tego np. Widget w Qt z kontrolkami sterującymi tym urządzeniem.

To powoduje, że odpada 90% pracy związanej od mojego programu w Pythone, do mojego firmware w kontrolerze. Moje urządzenie ma dwa inty o fazie "foo" i "bar", wiec w API Pythona dostaje mapę "foo" do ktorej mogę przypisać inta i on wyląduje w kodzie firmware.

Przykłądem takiego czegoś jest SCPI, ale to jest projektowane przez programistę Cobola i średnio się nadaje do małych projektów ;)

Jest też VISA, ale nic o tym nie wiem.

W dniu 6.05.2025 o 10:07, heby pisze:

Ale w czym problem? Parsować nie ma czym na uC?

W ilości pracy.

Najlepiej mieć proto z jak najmniejsza ilością parsowania. Czyli przewidziany do pracy z uc. Np. Protobuf się słabo nadaje, jeśli masz pamięć RAM liczoną w setkach bajtów. Nadaje się do wszystkiego innego, ale nie do firmware. I rozwiązuje 5% zagadnienia.

Oraz, jesli już coś robić, to korzystać z gotowych klocków.