ATNEL tech-forum https://forum.atnel.pl/ |
|
MK MULTI UART i wysłanie jako jeden string https://forum.atnel.pl/topic24474.html |
Strona 1 z 1 |
Autor: | Wilu88 [ 2 maja 2023, o 15:29 ] |
Tytuł: | MK MULTI UART i wysłanie jako jeden string |
Witam Po długiej przerwie wracam do programowania swojego sterowniczka. Program ma za zadanie komunikować się po BT z telefonem w celach konfiguracji sterownika. Postanowiłem zakupić bibliotekę MK MULTI UART 2.0 bo wydaje się idealna do tego. Jednak mierzę się z pewnym problemem, otóż gdy chce przesłać do telefonu ciąg kilku parametrów oddzielonych przecinkiem mam z tym problem. Wygenerowałem sobie taką funkcję odbierająca komendę AT i w rezultacie wysyłającą parametry sterownika język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
Jednak zauważyłem że gdy mam tych kilka komend uart_put to po stronie telefonu czasem mam pocięty ten ciąg, albo przychodzi tylko końcówka. Jak najlepiej to ogarnąć by wysłać to jedną komendą uart_put tak by wszystkie zmienne liczbowe i tekstowe spakować do jednego stringa? Pewnie dla was błahy problem ale po tak długiej przerwie od programowania to zaciemnienie mnie ogarnęło |
Autor: | mirekk36 [ 2 maja 2023, o 16:18 ] |
Tytuł: | Re: MK MULTI UART i wysłanie jako jeden string |
Po pierwsze to weź sobie to sprawdź po kablu w drugim terminalu - a nie rzucasz się od razu na jakieś połączenia radiowe i jak coś nie idzie - to nawet nie wiesz co z czym połączyć, gdzie błąd itp Toż to NAJPROSTSZE z możliwych rozwiązań - wysyłać z AVR do terminala przez przejściówkę USB/RS232 i obserwować co i jak przychodzi ... będziesz miał od razu porównanie A po trzecie to weź że użyj funkcji sprintf() zamiast KLEIĆ takiego stringa w locie. I na dodatek jak widzę nie jest to string bo nie ma zakończenia typu CR albo CRLF |
Autor: | Wilu88 [ 2 maja 2023, o 16:23 ] |
Tytuł: | Re: MK MULTI UART i wysłanie jako jeden string |
Mirku połączenie działa bez problemu, problem polega tylko na tym że raz na kilka prób w terminalu na telefonie odbieram cały ciąg, a czasem przychodzi on podzielony. Dlatego chciałem zrezygnować z kilku uart_put na rzecz jednego bo podejrzewam że tu jest problem. |
Autor: | mirekk36 [ 2 maja 2023, o 22:05 ] |
Tytuł: | Re: MK MULTI UART i wysłanie jako jeden string |
problem jest w tym, że nie stosujesz przesyłania stringów ASCII zakończonych enterem tylko w twoim wykonaniu to praktycznie binarka i nie składasz po drugiej stronie prawidłowo ramki. A to nie dziwota, że pakiety przychodzą w kawałkach - a tym bardziej jeśli sam robisz to za pomocą wysyłania wieloma komendami. Pisałem wyżej jak sobie można łatwo z tym poradzić - sprintf() no ale też ENTER na końcu i sprawdzanie w telefonie właśnie odbioru stringa z CR na końcu |
Autor: | Wilu88 [ 4 maja 2023, o 20:41 ] |
Tytuł: | Re: MK MULTI UART i wysłanie jako jeden string |
Dodam jeszcze że jak wyłączę ECHO i np wkleję sobię uart_puts gdzieś w pętli głównej to za każdym razem na telefonie odbieram pierwszy znak, potem enter i resztę ciągu. |
Autor: | ord [ 5 maja 2023, o 07:01 ] |
Tytuł: | Re: MK MULTI UART i wysłanie jako jeden string |
Przede wszystkim musisz sobie uzmysłowić, że dla sterownika medium transmisyjnego Twoje dane są ciągiem nieustrukturalizowanych bajtów. Nie możesz oczekiwać, że driver sam popakuje Ci je w pakiety. Musisz nałożyć na to jakiś "protokół" który pozwoli wyodrębnić ze strumienia porcje danych stanowiących jakąś całość.W tym przypadku początek danych jest oznaczony ciągiem "AT+" a koniec znakiem '\n' (czy tam ciągiem "\r\n", whatever). Na tej podstawie możesz zrobić prostą maszynę stanów, która skompletuje komendę. Przy tym podejściu uniezależniasz się od dziwactw bibliotek i fluktuacji podaży danych wynikających z różnic temp nadawania i odbierania czy zatorów spowodowanych np. zakłóceniami w medium. |
Autor: | mirekk36 [ 5 maja 2023, o 07:56 ] |
Tytuł: | Re: MK MULTI UART i wysłanie jako jeden string |
Zachodzę w głowę jak można dopatrywać się różnic pomiędzy język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. i język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. nie wysilając się na chociażby użycie byle pierwszego lepszego analizatora stanów logicznych (o którym często mówię i pokazuję) wystarczy w 100% nawet ten za 30zł z allegro z oprogramowaniem za darmo od Saleae i możesz się podłączyć pod linię TX jednego czy innego procka i zobaczyć jak FIZYCZNIE - na ŻYWO wychodzą te dane z procka przez UART skoro to właśnie tu upatrujesz różnicy .... sorki ale to NONSENS obserwować to od strony jakiegoś tam softu w telefonie, który nie wiem co robi i szukać przyczyny w nadawaniu z procka ... ba ty nawet myślisz że to biblioteka źle coś nadaje - kompletny NONSENS (nie obraź się) .... i to do kwadratu. Tym bardziej, że sam piszesz że po kablu wszystko działa - to naprawdę do dzisiaj nie zastanowiło ciebie to i nie zaciekawiło jak taka ramka wygląda "na drucie" czyli fizycznie - jak lecą poszczególne bajty/bity, jakie są odstępy między bajtami ????? Toż już wiele dni temu byś sam sobie odpowiedział na to pytanie widząc, że nie ma żadnej różnicy w nadawaniu - tylko ciekawy jestem jaki byś wtedy wniosek wyciągnął ... ale nie wierz mi - że oba sposoby nadawania są identyczne jak się wysyła jeden string, nie wierz mi proszę cię - błagam cię - weź ANALIZATOR STANÓW LOGICZNYCH i naucz się korzystać z takich narzędzi bo to PODSTAWA PODSTAW a na dodatek przyjemność i szybkie diagnozowanie wielu rzeczy .... ileż można o tym mówić, pisać i pokazywać ... poważnie. Przecież ten wątek ciągnie się już od 2 maja i do dzisiaj jeszcze tego nie zrobiłeś ? Rozwiązałbyś swój problem z analizatorem już w godzinę po napisaniu pierwszego postu i to sam. Bo ileż mogę pisać, że to o czym piszesz to po pierwsze składanie kilku stringów i żebyś wysyłał jednego - ok zrobiłeś w końcu po paru dniach wysyłanie jednego stringa - nawet do testów - brawo język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. dałeś na końcu enter "\r" - super ... czyli w końcu robisz normalną transmisję ASCII czyli stringi zakończone enterem ... to teraz masz porządną ramkę i ciurkiem wysłane bajty całego stringa i nie ma żadnych przerw pomiędzy bajtami - tylko nie chcę tu więcej już słyszeć pytań czy aby moja biblioteka wysyła to jakoś inaczej albo gorzej niż andruino bo to niestety zaczyna być irytujące - zamiast tego jak pisałem wyżej WEŹ ANALIZATOR STANÓW LOGICZNUCH i porównaj że te ramki na pinie TX procka ok? A teraz przechodząc do tych obrazków z jakiegoś dziwolągowatego programu które pokazałeś - to najbardziej zastanawia mnie co na tym obrazku robi coś takiego: Cytuj: A T+CT?CT, 1,10,15,50 szczególnie to co zaznaczyłem na czerwono ... to w końcu co ty wysyłasz ? taki string? język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. czy może taki? język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. No i na sam koniec przypomnę po raz kolejny bo już o tym pisałem wyżej ale i ord pisał o tym - że nie wiadomo i ty chyba sam nie wiesz co odbiera ramki na telefonie i jak je składa? To jakaś twoja aplikacja? czy obca ? Bo sam podgląd odebranych danych może wydawać się porwany - ale jeśli miałbyś nastawiony odbiór na ODBIERANIE STRINGÓW ASCII - rozumiesz czy nie rozumiesz co to znaczy? Ok przypomnę to znaczy, że taka aplikacja która ma taką opcję MUSI czy tego chcesz czy nie CZEKAĆ KURCZĘ na znak ENTER - żeby dopiero wtedy przekazać dalej ODEBRANY NAWET W KAWAŁKACH cały string. Podsumowując kompletnie nie wiemy co ty tam wyprawiasz po stronie telefonu i o co chodzi, a ty tymczasem dopatrujesz się różnic w wysyłaniu stringów z andruino vs z mojej biblioteki .... bez analizatora stanów logicznych w rękach |
Autor: | Wilu88 [ 5 maja 2023, o 17:14 ] |
Tytuł: | Re: MK MULTI UART i wysłanie jako jeden string |
mirekk36 napisał(a): Zachodzę w głowę jak można dopatrywać się różnic pomiędzy język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. i język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. nie wysilając się na chociażby użycie byle pierwszego lepszego analizatora stanów logicznych (o którym często mówię i pokazuję) wystarczy w 100% nawet ten za 30zł z allegro z oprogramowaniem za darmo od Saleae i możesz się podłączyć pod linię TX jednego czy innego procka i zobaczyć jak FIZYCZNIE - na ŻYWO wychodzą te dane z procka przez UART skoro to właśnie tu upatrujesz różnicy .... sorki ale to NONSENS obserwować to od strony jakiegoś tam softu w telefonie, który nie wiem co robi i szukać przyczyny w nadawaniu z procka ... ba ty nawet myślisz że to biblioteka źle coś nadaje - kompletny NONSENS (nie obraź się) .... i to do kwadratu. Tym bardziej, że sam piszesz że po kablu wszystko działa - to naprawdę do dzisiaj nie zastanowiło ciebie to i nie zaciekawiło jak taka ramka wygląda "na drucie" czyli fizycznie - jak lecą poszczególne bajty/bity, jakie są odstępy między bajtami ????? Toż już wiele dni temu byś sam sobie odpowiedział na to pytanie widząc, że nie ma żadnej różnicy w nadawaniu - tylko ciekawy jestem jaki byś wtedy wniosek wyciągnął ... ale nie wierz mi - że oba sposoby nadawania są identyczne jak się wysyła jeden string, nie wierz mi proszę cię - błagam cię - weź ANALIZATOR STANÓW LOGICZNYCH i naucz się korzystać z takich narzędzi bo to PODSTAWA PODSTAW a na dodatek przyjemność i szybkie diagnozowanie wielu rzeczy .... ileż można o tym mówić, pisać i pokazywać ... poważnie. Przecież ten wątek ciągnie się już od 2 maja i do dzisiaj jeszcze tego nie zrobiłeś ? Rozwiązałbyś swój problem z analizatorem już w godzinę po napisaniu pierwszego postu i to sam. Bo ileż mogę pisać, że to o czym piszesz to po pierwsze składanie kilku stringów i żebyś wysyłał jednego - ok zrobiłeś w końcu po paru dniach wysyłanie jednego stringa - nawet do testów - brawo język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. dałeś na końcu enter "\r" - super ... czyli w końcu robisz normalną transmisję ASCII czyli stringi zakończone enterem ... to teraz masz porządną ramkę i ciurkiem wysłane bajty całego stringa i nie ma żadnych przerw pomiędzy bajtami - tylko nie chcę tu więcej już słyszeć pytań czy aby moja biblioteka wysyła to jakoś inaczej albo gorzej niż andruino bo to niestety zaczyna być irytujące - zamiast tego jak pisałem wyżej WEŹ ANALIZATOR STANÓW LOGICZNUCH i porównaj że te ramki na pinie TX procka ok? A teraz przechodząc do tych obrazków z jakiegoś dziwolągowatego programu które pokazałeś - to najbardziej zastanawia mnie co na tym obrazku robi coś takiego: Cytuj: A T+CT?CT, 1,10,15,50 szczególnie to co zaznaczyłem na czerwono ... to w końcu co ty wysyłasz ? taki string? język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. czy może taki? język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. No i na sam koniec przypomnę po raz kolejny bo już o tym pisałem wyżej ale i ord pisał o tym - że nie wiadomo i ty chyba sam nie wiesz co odbiera ramki na telefonie i jak je składa? To jakaś twoja aplikacja? czy obca ? Bo sam podgląd odebranych danych może wydawać się porwany - ale jeśli miałbyś nastawiony odbiór na ODBIERANIE STRINGÓW ASCII - rozumiesz czy nie rozumiesz co to znaczy? Ok przypomnę to znaczy, że taka aplikacja która ma taką opcję MUSI czy tego chcesz czy nie CZEKAĆ KURCZĘ na znak ENTER - żeby dopiero wtedy przekazać dalej ODEBRANY NAWET W KAWAŁKACH cały string. Podsumowując kompletnie nie wiemy co ty tam wyprawiasz po stronie telefonu i o co chodzi, a ty tymczasem dopatrujesz się różnic w wysyłaniu stringów z andruino vs z mojej biblioteki .... bez analizatora stanów logicznych w rękach Mirku podsumowując mój wywód. To walczę z tym od 2 maja robiąc różne testy, to ze nie użyłem analizatora wynika z tego że transmisja z uC jest OK. Bo ten sam program na jakiejś starej apce napisanej B4A odbiera string idealnie i go nie przerywa. Natomiast od jakiegoś czasu uczę się Android Studio w języku Kotlin i tam odbierane wygląda trochę inaczej. Stąd moje pytanie czy czy w twojej bibliotece a tej z arduino może być jakaś różnica, jakiś punkt zaczepienia który może na to wpływać że kod z Arduino na ESP32 nie dzieli się przy odbiorze a ten napisany przeze mnie w C ma takie problemy. To żaden zarzut w twoja stronę że coś jest nie tak z twoją biblioteką, próbuje tylko znaleźć jakiś punkt. Twoja biblioteka na innej apce (która pewnie wykorzystuje inny język może też B4A i pewnie inny mechanizm odbioru) działa bez problemu i jestem w stanie wysłać 200 znaków. Co do dziwolągu który zauważyłeś to po prostu przy tych wszystkich eksperymentach okazało się że miałem ECHO włączone akurat w tym momencie i tylko tyle. Dziękuję CI bardzo za poświęcony czas na odpowiedź |
Strona 1 z 1 | Strefa czasowa: UTC + 1 |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |