Mirki mam pytanie odnośnie protokołow komunikacji, bo im więcej o tym czytam tym mniej to rozumiem. TPC/IP Załóżmy, że mamy architekturę klient-server, połączenie po TCP. Aby to była taka "message-based" komunikacja to definiujemy sobie to np. w ten sposób:| Header(proto version, message type, itp...)| Data | Checksum |Z perspektywy aplikacji korzystamy ze struktur, które są serializowane np. binarnie, czy do jsona i wysyłane przez socket w takiej kolejności jak to definiuje protokół. Jak widzicie mówię tutaj o protokole hmm aplikacyjnym? Nie samego medium transportowego.USBBazując na powyższym przykładzie, czy mogę sobie zrobić komunikacje między hostem i targetem po usb, gdzie protokół byłby dokładnie taki sam (header, date, chcsum), tylko inne medium transportowe?SPI - jak wyżej - podkreślam mówię o protokole z perspektywy aplikacji - nie samego peryferiumI2C - jak wyżejDo czego zmierzam - czy protokół aplikacyjny ma / może być niezależny od medium transportowego i teoretycznie zmiana połączenia między urządzeniami (np. z ethernet na usb), wymagałaby tylko zmiany konfiguracji wykorzystywanego MEDIUM a nie protokołu?Modbus - dlaczego jak czytam gdzies o modbusie to znajdę tylko informacje o wykorzystaniu w kontekście RS232/RS485 oraz TCP/IP? O ile z tego co patrzyłem z grubsza modbus definiuje timingi przy wysłyaniu ramek, to czy to w ogóle ma sens w przypadku TCP/IP - przypuszczam, ze nie więc w tym przypadku MODBUS definiuje tylko układ danych w bitstreamie.Dlaczego nie ma nic o Modbus over USB/SPI/I2C? Przeciez to tylko format ramki definiujący protokól aplikacyjny a nie warstwy transportowej/peryferium.Przecież jak najardziej mogę sobie wysłać po USB czy I2C coś w stylu: START | Address | FunctionCode | Data | CRC | END.Strasznie mi się to wszystko miesza w głowie i nie rozumiem już do końca co z czym można wykorzystać. Będę wdzięczny za wszelkie podpowidzi.#embedded taguje też #elektronika bo koledzy z tego tagu też piszą soft.