Aktywne Wpisy
huopisko +576
nie wiem kto zrobił to cudowne zdjęcie, ale cały dzień lata po twitterze
piękny kontrast pomiędzy zagłodzonym państwowym szpitalem, z którego odpada tynk, a drogimi samochodami lekarzy zaparkowanymi tuż pod nim
to powinno dostać jakąś nagrodę pokroju World Press Photo of the Year
#medycyna #nfz #lekarz #lekarz100k #konowalposting #polska
piękny kontrast pomiędzy zagłodzonym państwowym szpitalem, z którego odpada tynk, a drogimi samochodami lekarzy zaparkowanymi tuż pod nim
to powinno dostać jakąś nagrodę pokroju World Press Photo of the Year
#medycyna #nfz #lekarz #lekarz100k #konowalposting #polska
źródło: 1000005878
Pobierz
bArrek +80
Taka koleżanka z pracy lubi gdy się jej przyspermi tzn ja tego nie robiłem ale jak ktoś rzuci taki spermiarski tekst to się uśmiecha widać że się jej podoba a jeszcze jakiś czas temu była dziwna sytuacja trochę gdy weszła do mnie do pokoju i od razu wychyliła się za drzwi na korytarz jednocześnie wypinając w moją stronę i złapała się za pośladki tzn no w spodniach była i wgl i nie
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.
USB
Bazują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 peryferium
I2C - jak wyżej
Do 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.
─────────────────────
· Akcje: Odpowiedz anonimowo · Więcej szczegółów
· Zaakceptował: razzor91
· Autor wpisu pozostał anonimowy dzięki Mirko Anonim
Modbus to protokół, jeżeli sobie zrobisz implementację będzie chodzić na dowolnym medium. Tylko najpopularniejsze rs485.
@mirko_anonim: bo modbus jest używany do łączenia urządzeń w przemyśle - odległości większe niż 10cm i możliwość występowania silnych zakłóceń.
─────────────────────
· Akcje: Odpowiedz anonimowo · Więcej szczegółów
· Zaakceptował: digitallord
@fabek: standard definujący protokół
@mirko_anonim: USB jest niepotrzebną komplikacją a SPI i I2C służą do łączenia układów scalonych w obrębie jednej płytki