Witam,
ja właśnie uporałem się z pierwszą częścią takiego zagadnienia o jakie pytasz
... tzn mam ATTiny2313 i komunikacja z PC, za niedługo dojdą kolejne "klocki" ... u mnie ATTiny2313 mierzy temp na 3 czujnikach DS18B20, steruje 2 przekaźnikami na 220V, ma 2 wejścia z optoizolatorami do załączania różnych sygnałów i wykorzytuję komparator do badania czy jest już zmierzch/noc czy dzień (taki sterownik-ogrodu i piwnicy)
. Na PCcie mogę odczytywać już ładnie stan przekaźników (i ustawiać je manualnie), czas załączenia , temperatury .. tu screenshot
a odnośnie protokołu to zaplanowałem i zrobiłem to tak:
ustaliłem, że dane będą wymieniane w postaci "RAMEK danych"
budowa ramki:
1. MSG_Size - rozmiar ramki w bajtach
2. Adresat - adres (1..255) układu do którego wysyłamy dane
3. Nadawca - adres (1..255) tego układu który nadaje (każdy moduł ma zapisany na stałe adres - PC ma umownie zawsze 255)
4. Command - komenda, polecenie - kod od 0-255
5. DataStart - bajt mówiący o starcie danych (jakaś wybrana wartość)
6.
... bajty danych
n.
n+1. suma kontrolna całej ramki (suma XOR wszystkich bajtów)
dalej:
w uC na przerwaniach mam zrobiony odbiornik i nadajnik, który wykorzytuje cykliczny o zdeklarowanej wielkości w pamięci SRAM bufor, dzięki czemu wysłanie danych w programie to tylko wpisywanie odpowiednią procedurką znaków do bufora (a przerwanie UDRIE samo już dalej wysyła) - podobnie z odbieraniem danych (przerwanie Rx odbiera i wpisuje do bufora a odpowiednia procedurka odczytuje kolejne znaki z buforka - działa super i i nie obciąża procka
....
oczywiście dorobione są procedurki które aby coś wysłać - formują RAMKĘ jak wyżej i wpisują tylko po kolei jej bajty do bufora, podobnie jest procedura, która sprawdza czy dotarła cała ramka i jest bez błędów oraz co ważne czy w polu adresat jest adres tego układu do którego dotarła (jeśli nie to ramka jest ignorowana) czyli uC cały czas słucha co się dzieje w sieci
dokładnie podobne zasady zrobiłem tylko że w Delphi na PCcie. Jak narazie wszystko działa ślicznie !
natomiast rozbudowując o dodatkowe moduły sieć RS485 planuję, że będzie to działało tak:
jest sobie 1 master i on cyklicznie odpytuje kolejne moduły i wczytuje co potrzeba, jednak - każdy z modułów jeśli chciałby być również podrzędnym masterem - będzie mógł zgłosić to głównemu MASTEROWI, który przydzieli mu odpowiedni czas na działanie jako master w sieci a sam będzie cicho lub będzie działał jako slave przez ten czas. Jeśli ten nowy master skończy przed czasem swoją robotę to powiadomi o tym głównego a ten dalej zacznie odpytywać kolejne moduły itd itd...
jeśli moduł, który przejął mastera się zawiesi - to jak pisałem po upłynięciu maksymalnego czasu otrzymanego od głównego Mastera - to właśnie on się znowu sam uaktywni.
dodatkowo, każdy z modułów który przejmuje rolę mastera wyposażę w procedurę, że gdy wyczuje kolizję w sieci (tzn nie będzie otrzymywał odpowiedzi od kolejnych modułów do których się zwraca to przechodzi automatycznie w stan slave
... drugie rozwiązanie o którym myślę to działanie sieci (jak podpowiedział mi tu na elektrodzie jeden z kolegów) ArcNet - czyli moduły przesyłają sobie dane w ramkach ale w ramce jest jeszcze tzw ŻETON(TOKEN) który każdy po kolei każdy otrzymuje i jest masterem - a po wykonaniu swojej roboty przekazuje żeton kolejnemu układowi w magistrali - też fajne (tylko jeszcze nie wymyśliłem tu dobrej metody co robić gdy "zdechnie" moduł który własnie otrzymał TOKEN)
tak generalnie to bardzo ciekawe zagadnienie i programowanie tego sprawia mi jak narazie dużą przyjemność
... dobrze że robię to w asemblerze bo na styk zmieściłem się z tym w ATTiny2313 z jego pamięcią szczególnie RAM 128b
pozdrówka
. Bo standardem w PC jest RS232 , Co do protokołu zacznij od czegoś prostego typu:
no i wymaga nie mało zasobów,
