Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Kilka AVR, RS485 i aplikacja na Windows - wątek 9-tego bitu adres/dane

07 Lis 2019 17:52 579 21
  • Poziom 15  
    Cześć.

    Taki problem - mam kilka płytek z prockami Atmega8, które wyposażone są też w układ do komunikacji przez RS485. Piszę też prosty program na Windows (w Visual Studio, język C#) który będzie stanowił mastera, a moduły z atmegami będą robić za Slave-y. Mam też konwerter RS232 na RS485 (swojego wykonania), który wpięty będzie w komputer. Procki Atmela mają fajną funkcję, polegającą na tym, że ich UART można skonfigurować do pracy z 9-ma bitami danych, gdzie 8 pierwszych bitów to dane, a 9-ty bit określa czy przesyłane są dane z informacjami czy "adres" urządzenia. Co za tym idzie gdy moje moduły będą odbierać ramkę danych która "nie jest do nich zaadresowana" to po prostu ją zignorują.
    Fajnie to wygląda przy komunikacji pomiędzy prockami, gorzej gdy chce się podpiąć do tego komputer z napisaną aplikacją. Z tego co się orientuję to port szeregowy w komputerze nie potrafi wysyłać więcej niż 8 bitów danych. Da się jakoś rozwiązać ten problem?
  • Pomocny post
    Poziom 19  
    Generalnie są dwie metody o podobnej zasadzie, a opierają się na bicie parzystosci, który to jest tym brakującym 9 bitem. Dalej to myślę że sam dojdziesz
  • Poziom 19  
    @dasej to jak te slave będą wiedziały co wysyłasz? A jak Ty się dowiesz co odbierasz?
  • Poziom 19  
    A skąd ten sprzęt będzie wiedział że to adres. Rozumiem że software już jest i nie będzie pisać nowego.
  • Poziom 28  
    osctest1 napisał:
    A skąd ten sprzęt będzie wiedział że to adres. Rozumiem że software już jest i nie będzie pisać nowego.

    Ustalając, np. że wartość 0xFF to początek ramki z danymi, a drugi bajt jest adresem urządzenia do którego mają trafić dane. Jeżeli wartość 0xFF będzie mogła pojawiać się jako wartość w przesyłanych danych zamienić ją na sekwencję dwóch bajtów np. 0xFF = 0xFA 0xAA, dodatkowo trzeba ustalić sekwencję dla 0xFA na np. 0xFA = 0xFA 0xBB. Komunikacja z SPS30 po uarcie odbywa się w podobny sposób.
    Kilka AVR, RS485 i aplikacja na Windows - wątek 9-tego bitu adres/dane
  • Poziom 19  
    @miszczo997 A jakie ma to znaczenie, że jakiś sobie tam czujnik używa jakiegoś tam protokołu? @dasej Albo pokazywanie innych protokołów.

    Autor pyta o 9bitów na PC-cie - na to trzeba mu odpowiedzieć. : do tego wykorzystuje się bit parzystości jako obejście ograniczeń. I tyle.

    Jest wiele urządzeń - np. maszyny vendingowe, które używają tego standardu motoroli, który się teraz jakoś bardzo mądrze nazywa (poszukać sobie w google), ale mnie jakoś z głowy uciekło.
  • Moderator Mikrokontrolery Projektowanie
    dasej napisał:
    le kombinujesz.
    Olej "9" bit. Wysyłasz ramkę gdzie jeden z bajtów ta adres slave i po temacie.

    To co proponujesz to nieziemska kombinacja. Jest proste rozwiązanie sprzętowe to się z niego korzysta. Na PC jak pisał @osctest1 wykorzystuje się do nadania 9-tego bitu bit parzystości ustawiając w zależności od potrzeb parzystość/nieparzystość.
    dasej napisał:
    Proste. @osctest1 . Tak jak pisałem jeden bajt to adres a w odpowiedzi się przedstawia tym samym adres (swoim).
    Kolejna kwesta, nie pytany nie odpowiada.

    A jeśli masz kilka slave to taka zabawa jest z wielu powodów nieciekawa. W ciągu bajtów, skąd dany slave będzie wiedział, że któryś z nich jest adresem? Jedyna pewna możliwość to stosowanie przerw w transmisji, co z kolei spowalnia transfer. Kolejna problem - slave muszą monitorować stale magistralę. W praktyce trzeba w przerwaniu odbierać całą transmisję i ją analizować. Efekt - zbędne obciążenie MCU + niemożnaość np. efektywnego wykorzystania trybów oszczędzania energii.
    miszczo997 napisał:
    eżeli wartość 0xFF będzie mogła pojawiać się jako wartość w przesyłanych danych zamienić ją na sekwencję dwóch bajtów np. 0xFF = 0xFA 0xAA, dodatkowo trzeba ustalić sekwencję dla 0xFA na np. 0xFA = 0xFA 0xBB.

    Aha, a jeśli w sekwencji transmitowanych danych może pojawić się 0xffaa, to dodać trzeci bajt, a jak i on może się pojawić to czwarty... Takie zabawy są dobre jeśli transmitujemy np. ASCII, ale przy transmisjach binarnych (efektywniejszych) nie za bardzo to zdaje egzamin.
  • Poziom 31  
    osctest1 napisał:
    Autor pyta o 9bitów na PC-cie - na to trzeba mu odpowiedzieć. : do tego wykorzystuje się bit parzystości jako obejście ograniczeń. I tyle.


    To może jakiś konkretna propozycja dla autora, jak ma to w C# zrobić.
  • Poziom 19  
    tmf napisał:
    To co proponujesz to nieziemska kombinacja.
    No nie przesadzaj. Modbus i inne 8 bitowe protokoły jednakowoż są najpowszechniejsze.
    tmf napisał:
    Takie zabawy są dobre jeśli transmitujemy np. ASCII, ale przy transmisjach binarnych (efektywniejszych) nie za bardzo to zdaje egzamin.
    generalnie w każdym rozsądnym protokole nagłówek, a czasem nawet całą ramkę traktuje się całościowo. Dopiero jak stwierdzisz że np. nagłówek jest OK, to dopiero wtedy interpretujesz jego pola takie jak adres.

    Oczywiście nie dotyczy to interfejsów sprzętowych takich jak I2C, czy CAN, gdzie adres jest częścią standardu.
  • Poziom 31  
    @tmf Znam takie rozwiązania i spokojnie obsługują ponad 100 slave na dwóch przewodach.
    Jak któryś slave ulegnie uszkodzeniu to go wymieniasz na nowy, który na obudowie ma podany swój adres komunikacyjny,
    wystarczy wpisać go do sytemu i wszystko hula dalej.
  • Moderator Mikrokontrolery Projektowanie
    dasej napisał:
    @tmf Znam takie rozwiązania i spokojnie obsługują ponad 100 slave na dwóch przewodach.
    Jak któryś slave ulegnie uszkodzeniu to go wymieniasz na nowy, który na obudowie ma podany swój adres komunikacyjny,
    wystarczy wpisać go do sytemu i wszystko hula dalej.


    Możesz sprecyzować o czym piszesz? Jakie rozwiązania masz na myśli?
  • Poziom 28  
    tmf napisał:
    Aha, a jeśli w sekwencji transmitowanych danych może pojawić się 0xffaa,

    W czym problem w takiej sekwencji? Zamieni się ją na wartość 0xFA 0xAA 0xAA. Protokół Sensiriona transmituje wyniki pomiarów w postaci floatów, gdzie dozwolone są dowolne wartości i nie ma z niczym problemu. Po prostu jeżeli pojawi się wartość oznaczająca początek ramki jako dane to cała przesyłana wiadomość zostanie powiększona o 1 bajt. W przypadku zaproponowanych przez mnie wartości pojawienie się 0xFF lub 0xFA jako dane wydłuży ramkę o 1 bajt (dla każdego wystąpienia), ale dalej będzie można jednoznacznie zinterpretować dane.

    tmf napisał:
    Kolejna problem - slave muszą monitorować stale magistralę. W praktyce trzeba w przerwaniu odbierać całą transmisję i ją analizować. Efekt - zbędne obciążenie MCU + niemożnaość np. efektywnego wykorzystania trybów oszczędzania energii.


    W sposobie który zaproponowałem slave odbiera w przerwaniu 1 bajt i w sprawdza sobie, czy jest to wartość 0xFF. Jeżeli nie, czeka na kolejny bajt i dalej sprawdza czy to 0xff, jeżeli tak, czeka na kolejny bajt i sprawdza, czy to jego adres. Jeśli adres będzie zgodny, to dopiero wtedy odbiera resztę danych do jakiegoś bufora i je analizuje.
  • Moderator Mikrokontrolery Projektowanie
    miszczo997 napisał:
    W sposobie który zaproponowałem slave odbiera w przerwaniu 1 bajt i w sprawdza sobie, czy jest to wartość 0xFF. Jeżeli nie, czeka na kolejny bajt i dalej sprawdza czy to 0xff, jeżeli tak, czeka na kolejny bajt i sprawdza, czy to jego adres. Jeśli adres będzie zgodny, to dopiero wtedy odbiera resztę danych do jakiegoś bufora i je analizuje.


    I co to zmienia? Odbiornik musi odebrać każdy bajt, żeby go przeanalizować. Nie da się więc uśpić MCU i każdy przesłany bajt generuje zbędne przerwanie. Nie wiem po co się upierać przy takich rozwiązaniach, skoro producent udostępnia tryb MPCM, który rozwiązuje problemy.
    miszczo997 napisał:
    W czym problem w takiej sekwencji? Zamieni się ją na wartość 0xFA 0xAA 0xAA.

    Czyli klasyczne eskapowanie sekwencji. Pytanie w czym to ma być lepsze niż rozwiązanie autora, oparte na sprzętowej realizacji?

    Dodano po 49 [sekundy]:

    dasej napisał:
    Np. odczyt wodomierzy.
    A przy transmisji radiowej idzie to w tysiące. Wtedy adres slave ma nawet 32bity.

    Ale co to ma wspólnego z pytaniem autora?
  • Poziom 15  
    Witam po przerwie. Widzę, że temat się rozwinął i mnie to cieszy :)
    Ogólnie to aplikacja na PC jak i programy dla mikrokontrolerów są w trakcie tworzenia więc jeśli chodzi o jakieś modyfikacje, to na tym etapie nie ma z tym problemu.
    Zależy mi na tym rozwiązaniu z 9-tym bitem, aby mikrokontrolery nie musiały zajmować się odbiorem danych gdy jest to nie potrzebne. Dziękuję za nakierowanie mnie na trop :) Myślę, że teraz już sobie z tym poradzę.
  • Poziom 24  
    tmf napisał:
    Nie wiem po co się upierać przy takich rozwiązaniach, skoro producent udostępnia tryb MPCM, który rozwiązuje problemy.

    I w uśpieniu analizuje ramkę i 9 bit?
  • Moderator Mikrokontrolery Projektowanie
    Janusz_kk napisał:
    tmf napisał:
    Nie wiem po co się upierać przy takich rozwiązaniach, skoro producent udostępnia tryb MPCM, który rozwiązuje problemy.

    I w uśpieniu analizuje ramkę i 9 bit?

    Tak, jest to realizowane sprzętowo. Dzięki temu bajty danych nie będą wybudzać MCU, a jedynie przesyłane bajty adresu. Co prawda ciągle każda ramka wybudzi MCU, ale z każdej ramki MCU będzie analizował wyłącznie bajt adresu, pozostałe ani nie wybudzą go, ani nie będą generować przerwań. W efekcie obciążenie spadnie proporcjonalnie.