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.

do góry

On 06/05/2025 17:43, jp wrote:
> Jeśli graficzne to może Xclient a na PC Xserver, ale nie wiem
> jakie minimum by musiało być zaimplementować na uC.

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ć:
1) R/W, R, W
2) Nazwa
3) Opis
4) Typ (string, int, char, float, enum ...)
5) Zakres wartości
6) Preferowany tryb sterowania (pole, suwak, gałka, wskaźnik...)

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.

do góry

W dniu 6.05.2025 o 10:07, heby pisze:

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

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

--
Mirek

do góry

On 06/05/2025 20:37, Mirek wrote:
>> Na razie widzę, że są rozwiazania pchające jsona przez uart do uC. Ale
>> to i tak wymaga rękodziela.
> Ale w czym problem?

W ilości pracy.

> Parsować nie ma czym na uC?

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.

do góry