Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Arduino - Wysyłanie wielu zmiennych po UART

pyton 02 Sie 2017 14:05 855 17
  • #1 02 Sie 2017 14:05
    pyton
    Poziom 21  

    Witam

    Chcialbym zrobić tak: Chce po UART nawiązać komunikację między 2 urządzeniami np:
    Czujniki > Arduino1 > UART > Arduino2 > LCD

    O ile z przesłaniem komendy za Arduino1 do Arduino2 nie ma problemu... to nie wiem jak przesłać zmienne..

    Przykładowo mam 10 czujników część daje na wyjściu stan cyfrowy 0 lub 1 reszta wartość analogową.

    Nie wiem w jaki sposób wysłać wszystkie dane po UART i w jaki sposób je odebrać by były czytelne która wartość pochodzi od którego czujnika.

    Wydaje mi się że każdemu czujnikowi powinienem przyporządkować "nazwę" wysłać z Arduino1 po UART i w po prostu ją wycinać przy zapisie do zmiennej w Arduino2, później wysyłać na LCD?

    Jeśli coś w tym jest to prosił bym o jakiegoś linka lub miejsce gdzie znajdę informacje o przycinaniu takiego ciągu znaków, lub jak kolwiek tego poszukać?


    Ciąg danych może wyglądać np:

    t1:32,25 h1:75,75 t2:45,55 h2:40,00 t3:80,88 h3:0 h4:1

    czyli: temp1 wilg1 temp2 wilg2 temp3 wilg3(stan niski) wilg4(stan wysoki)

    Chciałbym po prostu przesłać na odległość same dane z czujników i wyświetlić na innym LCD.

    Pozdrawiam

  • #2 02 Sie 2017 14:19
    dondu
    Moderator Mikrokontrolery Projektowanie

    Kombinujesz dobrze. Własny protokół opracuj tak jak Ci wygodnie.

    Równie dobrze zamiast wartości opartych o znaki ascii możesz przesyłać bajty bez znaczników t1, h1, itd. czyli opracować własną bajtową ramkę danych, gdzie będziesz wiedział, co każdy kolejny bajt oznacza. Do takiej ramki można także na początku dodać jakiś charakterystyczny stały przedrostek (bajt lub kilka) po którym będziesz rozpoznawał początek ramki, a na końcu bajt jakiejś sumy kontrolnej.

    W takiej ramce dodatkowo można zmniejszyć ilość przesyłanych bajtów używając poszczególnych bitów do tych informacji, które są tylko 1 lub 0.


    Zamiast przesyłać 8 bajtów np. t1:32,25
    prześlij dwa bajty o wartościach 32 i 25
    a ponieważ będą to dwa pierwsze bajty po przedrostku, to będziesz wiedział, że to odpowiednio wartość całkowita oraz wartość po przecinku czujnika t1.

    Kolejne bajty będą dotyczyć czujnika h1, ... itd.

  • #3 02 Sie 2017 15:48
    Marek_Skalski
    Poziom 33  

    Możesz też użyć protokołu szeregowego, jaki funkcjonuje w bramach Domoticz. Przykładowy opis jest tutaj: https://www.mysensors.org/download/serial_api_20
    Po jakimś czasie może będziesz chciał rejestrować pomiary na komputerze albo tablecie i wtedy będziesz miał wszystko gotowe i zgodne.

  • #4 04 Sie 2017 07:36
    ditomek
    Poziom 19  

    Proponuję format który sam z powodzeniem od wielu lat stosuje u siebie.
    Są to bajty oddzielone jakimś znakiem specjalnym - u mnie jest to dwukropek.
    dla wygody przy uruchomieniu początek komunikatu można uzupełnić o jakiś inny znak używany tylko raz.
    koniec komunikatu to standardowy dla arduino \n
    binarki sklejaj w bajty lub wordy jak ci wygodnie.
    Pamiętaj ze pomiary analogowe z miejscami po przecinku można przesyłac bez tegoż przecinka a wstawiać go do wartości po stronie odbiornika.
    Ja po odebraniu takiego ciągu znaków otrzymane liczby umieszczam w tablicy odbiorczej. indeksy tablicy odpowiadają miejscu w jakim znajdowała się liczba.
    Nie przesyłaj niepotrzebnie dodatkowych informacji co jest co bo to tylko spowalnia transmisję.

    Jak już będziesz miał to opanowane możesz rozpocząć minimalizować ilość wysyłanych danych np przez przejście na kod szesnastkowy, możesz spróbować generować sumy kontrolne i ostatecznie transmitować dane binarnie.

  • #5 04 Sie 2017 07:49
    JacekCz
    Poziom 32  

    ditomek napisał:
    Proponuję format który sam z powodzeniem od wielu lat stosuje u siebie.
    Są to bajty oddzielone jakimś znakiem specjalnym - u mnie jest to dwukropek.
    dla wygody przy uruchomieniu początek komunikatu można uzupełnić o jakiś inny znak używany tylko raz.
    koniec komunikatu to standardowy dla arduino \n


    Protokołów ni to binarny, ni to tekstowy jest fatalnym projektem. Co, gdy bajt będzie miał znakowy sens dwukropka?
    Porada szkodliwa.

    ditomek napisał:

    binarki sklejaj w bajty lub wordy jak ci wygodnie.


    Możesz powiedzieć co miałeś na myśli?


    ditomek napisał:

    Pamiętaj ze pomiary analogowe z miejscami po przecinku można przesyłac bez tegoż przecinka a wstawiać go do wartości po stronie odbiornika.
    Ja po odebraniu takiego ciągu znaków otrzymane liczby umieszczam w tablicy odbiorczej. indeksy tablicy odpowiadają miejscu w jakim znajdowała się liczba.
    Nie przesyłaj niepotrzebnie dodatkowych informacji co jest co bo to tylko spowalnia transmisję.

    Jak już będziesz miał to opanowane możesz rozpocząć minimalizować ilość wysyłanych danych np przez przejście na kod szesnastkowy, możesz spróbować generować sumy kontrolne i ostatecznie transmitować dane binarnie.


    Nie da się zrozumieć co chcesz powiedzieć. Najpierw piszesz "przesyłaj bajty", potem "dla oszczędzenia miejsca konwertuj do szesnastkowego" co podwaja objętość. To jest jakiś bełkot.

    Dodam dla ułatwienia że jakbyś odróżniał cyfry od liczb, a już bajty od znaków to by postęp.

  • #6 04 Sie 2017 08:50
    ditomek
    Poziom 19  

    Chodzi o coś takiego:
    :255:255:255:
    Jak widać między dwukropkami sa bajty tyle ze wysłane jako tekst.
    W momencie kiedy taki protokół dopiero co uruchamiasz to taka prezentacja jest najwygodniejsza.
    Potem można 255 przesłać jako FF - oszczędzasz jeden znak w przypadku liczb trzycyfrowych.
    Podobnie jeśli zamiast pojedynczych bajtów chcesz wysyłać liczby dwu bajtowe jak wordy itp.
    Zamiast :65535:65535: po serialu wysyłasz :FFFF:FFFF:
    Może teraz będę bardziej zrozumiały :-)

  • #7 04 Sie 2017 09:13
    tmf
    Moderator Mikrokontrolery Projektowanie

    ditomek napisał:
    Chodzi o coś takiego:
    :255:255:255:
    Jak widać między dwukropkami sa bajty tyle ze wysłane jako tekst.
    W momencie kiedy taki protokół dopiero co uruchamiasz to taka prezentacja jest najwygodniejsza.
    Potem można 255 przesłać jako FF - oszczędzasz jeden znak w przypadku liczb trzycyfrowych.
    Podobnie jeśli zamiast pojedynczych bajtów chcesz wysyłać liczby dwu bajtowe jak wordy itp.
    Zamiast :65535:65535: po serialu wysyłasz :FFFF:FFFF:
    Może teraz będę bardziej zrozumiały :-)


    Nie jest tak pięknie. O ile jeśli całość przesyłasz jako tekst to ten dwukropek ma jakiś sens (tyle, że nie odróżnisz początku ramki), o tyle nie da się tego przerobić na postać binarną. To o czym wspominał kol. JacekCz - co jeśli binarna reprezentacja danej będzie miała kod ASCII dwukropka?

  • #8 04 Sie 2017 09:18
    JacekCz
    Poziom 32  

    ditomek napisał:
    Chodzi o coś takiego:
    :255:255:255:
    Jak widać między dwukropkami sa bajty tyle ze wysłane jako tekst.
    W momencie kiedy taki protokół dopiero co uruchamiasz to taka prezentacja jest najwygodniejsza.
    Potem można 255 przesłać jako FF - oszczędzasz jeden znak w przypadku liczb trzycyfrowych.
    Podobnie jeśli zamiast pojedynczych bajtów chcesz wysyłać liczby dwu bajtowe jak wordy itp.
    Zamiast :65535:65535: po serialu wysyłasz :FFFF:FFFF:
    Może teraz będę bardziej zrozumiały :-)


    Prowizorka. Do krzywej szopy przybijmy deskami budę. A że buda ma spóchniałe deski podeprzyjmy ją drągiem.

    Kombinujesz jakiś horrendalny protokół, a dlatego kombinujesz, że nie zadałeś sobie elementarnych pytań jaki naprawdę jest (tekstowy czy binarny), jaki jest "kontrakt" między nadajnikiem a odbiornikiem, na przykład zastosowanie dedykowane/uniwersalne, odbiorcą jest maszyna czy człowiek itd...
    Po drugie po raz kolejny "ja wynajdę lepsze, bardziej okrągłe koło niż inny wynaleźli". Po trzecie słowa są ważne, jak się nieprecyzyjnie mówi, to się zawsze nieprecyzyjnie robi (implikacja tylko w jedną stronę)

    Po latach do krzywej praktyki dorabiamy ideologię, taka jest nasza natura.

  • #9 04 Sie 2017 09:28
    arturt134
    Poziom 26  

    Generalnie każdy dobrze opisany protokół spełni swoje zadanie. Dla własnego urządzenia najlepiej taki protokół stworzyć od początku (wbrew pozorom nie zajmie to dużo czasu), ponieważ można wtedy uwzględnić specyfikę danego urządzenia (np. częstotliwość przesyłania danych, ilość danych), specyfikę kanału transmisji (przepustowość, pewność dostarczenia danych, opóźnienia) jak również własne preferencje. Może to być protokół oparty o przesyłanie znaków ASCII, ale może być oparty na przesyłaniu wartości binarnych (osobiście preferuję to drugie rozwiązanie)

    Ważne jest aby:
    - początek ramki danych łatwy do wykrycia przez odbiornik (może to być stały bajt startu, 4 bajtowa przerwa na linii itp.)
    - rozmiar ramki łatwy do określenia - albo w sposób jawny (np. przesyłany zaraz po bajcie startu), albo poprzez zdefiniowanie końca ramki (bajt stopu, 4 bajtowa przerwa na linii itp.), ewentualnie poprzez oba te sposoby na raz.
    - prawidłowość danych w ramce łatwa do sprawdzenia (suma kontrolna, według standardowego algorytmu CRC lub choćby sama suma wszystkich bajtów modulo 256)
    - dokładnie opisane znaczenie bajtów danych przesyłanych w ramce (położenie, rozmiar, zakres prawidłowych wartości)

  • #10 04 Sie 2017 09:38
    grko
    Poziom 32  

    arturt134 napisał:
    Generalnie każdy dobrze opisany protokół spełni swoje zadanie. Dla własnego urządzenia najlepiej taki protokół stworzyć od początku (wbrew pozorom nie zajmie to dużo czasu), ponieważ można wtedy uwzględnić specyfikę danego urządzenia (np. częstotliwość przesyłania danych, ilość danych), specyfikę kanału transmisji (przepustowość, pewność dostarczenia danych, opóźnienia) jak również własne preferencje. Może to być protokół oparty o przesyłanie znaków ASCII, ale może być oparty na przesyłaniu wartości binarnych (osobiście preferuję to drugie rozwiązanie)


    Tworzenie własnego protokołu to bardzo zły pomysł w 98% przypadkach. Jest tyle binarnych/tekstowych istniejących protokołów, że nie warto tworzyć kolejnego. Własny protokół na ogół oznacza problemy z błędami w imlementacji, brakiem gotowych narzędzi, problemy z integracją etc. Nie polecam.

  • #11 04 Sie 2017 09:50
    arturt134
    Poziom 26  

    Własny protokół na ogół utrudnia życie konkurencji.... Oczywiście, czasami urządzenia muszą obsługiwać protokoły standardowe (np. Modbus), bo takie są wymagania rynku, ale i tak wszystkie polecenia serwisowe są przesyłane w protokołach niestandardowych i niejawnych. Poza tym, jakoś nie mogę sobie wyobrazić implementacji Modbusa do przesłania 4 bajtów danych między dwoma urządzeniami projektowanymi przeze mnie i niewspółpracującymi z innymi urządzeniami innych producentów. To po prostu użycie armaty do zabicia muchy.

    W poprzednim poście starałem się sprecyzować czym powinien charakteryzować się dobry protokół transmisji. Zamiast pisać własny można wziąć gotowy, być może mój opis pomoże w wyborze tego najlepszego.

  • #12 04 Sie 2017 10:08
    ditomek
    Poziom 19  

    @JacekCz czemu służy Twój post. Chcesz ze mnie się pośmiać czy pomóc koledze rozwiązać problem.
    Mam wrażenie ze bardziej interesuje Cie to pierwsze i nie rozumie tylko dlaczego.
    To co umieściłem w poście to tylko fragment tego co od lat używam z powodzeniem w moich projektach. Drażni cię to że to działa?
    Pełny format jest podobny do modbusa (także używam podziału na funkcje, bloków danych i kontroli błędów) w zasadzie jedyna różnica to znaki oddzielające pola i sam sposób liczenia sumy kontrolnej. A ze projekt jest mój nie mam ograniczeń jakie nakłada format.
    Pewnie mogłem sięgną po gotowa bibliotekę modbusa ale wtedy niczego bym się nie nauczył.
    Poza tym Mój protokół jest bardziej przyjazny bo nie korzystam z szesnastkowego kodowania liczb i w dowolnym emulatorze terminala widać jak na dłoni co jest grane.
    W trakcie uruchamiania jest to naprawdę pomocne.
    Bardzo wygodnie obrabia się te dane w pythonie bo są tam gotowe funkcje do explodowania danych i umieszczania ich w tablicy.
    W zasadzie potrzebne sa tylko trzy linijki kodu.
    Ale pewnie byłoby lepiej gdybym zgapił coś od innych albo sięgną po gotowca...standardowe myślenie arduinowca.
    @tmf dwukropek oddziela pola, między dwukropkiem jest 1 do 3 znaków "0-9" wchodzących w skład jednej liczby - dokładnie bajta
    Nie ma możliwości ze dwukropek stanie się liczba bo przesyłam znaki ascii. Początek ramki jest od znaku"=", koniec na niesmiertelnym \n
    Nie rozumiem twoich obaw.

  • #13 04 Sie 2017 11:35
    JacekCz
    Poziom 32  

    grko napisał:

    Tworzenie własnego protokołu to bardzo zły pomysł w 98% przypadkach. Jest tyle binarnych/tekstowych istniejących protokołów, że nie warto tworzyć kolejnego. Własny protokół na ogół oznacza problemy z błędami w imlementacji, brakiem gotowych narzędzi, problemy z integracją etc. Nie polecam.


    Dokładnie
    Akurat w tej chwili o wiersz obok jest wątek o MQTT na uK, kibicuję temu i nawet się ambitnie wczytywałem, nie umiałem pomóc. Autorzy nowej implementacji "zapomnieli" jawnie podać że jest limit ilości zmiennych.

    ditomek napisał:
    @JacekCz czemu służy Twój post. Chcesz ze mnie się pośmiać czy pomóc koledze rozwiązać problem.
    Mam wrażenie ze bardziej interesuje Cie to pierwsze i nie rozumie tylko dlaczego.
    To co umieściłem w poście to tylko fragment tego co od lat używam z powodzeniem w moich projektach. Drażni cię to że to działa?


    PIERWSZE przy jakimkolwiek wiarygodnym protokole to ścisła i pełna specyfikacja.
    Specyfikacja nie obraź się, ale amatorska, to strzał w kolano jesli chcesz do protokołu przekonać.
    edit: plus problemy zgłoszone przez kolegów.


    Co do wiary "u mnie działa". Działa w rękach autora - to chyba wiemy - jeszcze o wiele za mało, co więcej w rękach tego samego autora jak wróci do projektu po długim czasie, w zmienionych intuicyjnie warunkach (zwłaszcza bez dokumentacji albo z nieścisłą dokumentacją). Ta sama osoba siadająca do kodu sprzed X lat to w zasadzie jak drugi niezalezny programista, ze wszystkimi wynikającymi problemami.

    ditomek napisał:

    Ale pewnie byłoby lepiej gdybym zgapił coś od innych albo sięgną po gotowca...standardowe myślenie arduinowca.


    Właście to jest istota dojrzałego czy profesjonalnego oprogramowania, użyć uznanej biblioteki TO NIE WSTYD. jest w tym pewien (pożyteczny) trud, bo trzeba w to wejść, uczuć się od lepszych (z czasem również zdarzy się mieć o tym krytyczne zdanie) itd...

    Akurat nie jestem arduinowcem i styl robienia tam "bibliotek" to jakas katastrofa.

    Mam swoją socjologiczną obserwację. W świecie PHP / JS jest punktem do chwały pisanie po swojemu jeszcze raz, czegoś co wielokrotnie ma sprawdzone implementacje. Wiele można się domyślać o psychologii, może jest za słaby aby zrozumieć punkty rozszerzeń biblioteki, API itd... czuje się niedowartościowany itd...
    W świecie Javy taki programista byłby zabity śmiechem, tam zupełnie inny styl.
    jak już o socjologii mowa: w świecie arduino się pisze "posiadam takie kody" które się wkleja bez zrozumienia.

    W konkluzji: psychologia "pisz po swojemu" występuje tylko w niektórych segmentach IT

  • #14 04 Sie 2017 11:46
    tmf
    Moderator Mikrokontrolery Projektowanie

    ditomek napisał:

    @tmf dwukropek oddziela pola, między dwukropkiem jest 1 do 3 znaków "0-9" wchodzących w skład jednej liczby - dokładnie bajta
    Nie ma możliwości ze dwukropek stanie się liczba bo przesyłam znaki ascii. Początek ramki jest od znaku"=", koniec na niesmiertelnym \n
    Nie rozumiem twoich obaw.


    Mieszasz. Jeśli protokół jest całkowicie oparty na ASCII to nie ma problemu. Pisałeś, że można te dane przesyłać binarnie - otóż w twoim rozwiązaniu nie można, bez specjalnych zabiegów. Obecnie mamy gotowce praktycznie na każdą okazję i jedyne co trzeba zrobić to wybrać odpowiedni, istniejący protokół, który najlepiej spełnia nasze oczekiwania. Wynajdowanie koła od nowa nic nie wnosi.

    Dodano po 5 [minuty]:

    arturt134 napisał:
    Własny protokół na ogół utrudnia życie konkurencji.... Oczywiście, czasami urządzenia muszą obsługiwać protokoły standardowe (np. Modbus), bo takie są wymagania rynku, ale i tak wszystkie polecenia serwisowe są przesyłane w protokołach niestandardowych i niejawnych.


    Zwolennik "Security through obscurity"? To już wielokrtotnie zostało wyśmiane. Sensowny protokół rozkminisz raz dwa, wprowadzanie udziwnień bardziej przeszkodzi autorowi projektu niż osobie, która będzie chciała go rozkminić. Potrzebujesz utrudnić życie konkurencji - od tego masz protokoły z szyfrowaniem danych, autentykacją itd. Gotowe rozwiązania mają przynajmniej zrobione analizy bezpieczeństwa. W rozwiązaniu autorskim najczęściej jest tak, że autor wierzy w bezpieczeństwo swojego rozwiązania, nie posiadając na to żadnych dowodów.

  • #15 04 Sie 2017 11:47
    dondu
    Moderator Mikrokontrolery Projektowanie

    Nie ma jednej jedynie słusznej drogi.

    Każdy przypadek jest inny i nie można twierdzić, że ma być taki, czy inny protokół. O tym fakcie decyduje projektant, bo tylko on ma pełnię informacji dot. projektu w tym ograniczeń jakie musi pokonać. Dlatego w jednym przypadku podejmie decyzję użycia gotowych protokołów, a w innym stworzy własny.

    Argument, że brak gotowych narzędzi, podczas gdy programista biegle włada językiem C (lub innym uniwersalnym) jest nietrafiony, ponieważ jest on w stanie szybciutko napisać własne narzędzie. Podobnie z błędami implementacji.

    Dlatego skończmy już dyskusję w tym zakresie skupiając się na podpowiadaniu autorowi, który jak na razie nie odzywa się.
    Poza tym autor jest początkującym i warto pomóc mu stworzyć własny protokół, by poszerzył swoje umiejętności, co w przyszłości pozwoli mu świadomie wybierać optymalne rozwiązanie do każdego kolejnego projektu.

  • #16 04 Sie 2017 12:20
    ditomek
    Poziom 19  

    @tmf nie mieszam, napisałem do autora że po opanowaniu sztuki przesyłania komunikatów ascii może przejść na przesył binarny.
    Przeczytaj mój post jeszcze raz a jestem pewny że teraz będzie wszystko jasne.
    Faktycznie, może użyłem za dużo skrótów myślowych i teraz muszę wszystko tłumaczyć...
    dla mnie EOT

  • #17 08 Sie 2017 20:27
    pyton
    Poziom 21  

    Dziękuje bardzo za podpowiedzi - chwilowo muszę odpuścić temat... jak znajdę chwilkę to do niego powrócę i pewnie jak coś nie zadziała to zapytam:)
    Dziękuje bardzo jeszcze raz.

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME