Cześć wszystkim

Od kilku dni testuję bibliotekę Kolegi Nefarious19 z postu topic11377.html do nrf24l01, rozwijając przy tym swój mały projekcik stacji pogodowej. Mam taki kod:


Funkcje dotyczące TWI odnoszą się do podłączonego tam czujnika HTU21D. Liczę sobie temperaturę, zamieniam float na stringa, puszczam atmosferą do drugiego procesora i dalej do PC. Nie podoba mi się to co zrobiłem Do takiego siermiężnego liczenia floatów wolę wykorzystać komputer.
I tu pojawia się mój problem: z czujnika przychodzą trzy bajty informacji, dwa dotyczące temperatury/wilgotności, i suma kontrolna do sprawdzenia CRC. Po wykonaniu pomiaru chciałbym wysłać te bajty jeden po drugim i po każdym z bajtów chciałbym dostać potwierdzenie otrzymania od odbiornika przy PC. Jak należy poprawnie to wykonać? Postawienie jeden za drugim nrfSendDataToAir nie sprawdza się, wychodzą głupoty. Ponadto, zdarza się, że transmisja się zawiesza i nie ma reguły kiedy. Czasem po 10 minutach, czasem po 30 sekundach. Podejrzewam, że trzeba czyścić/sprawdzać któreś flagi, tylko które?
Proszę uprzejmie o pomoc i pozdrawiam.

------------------------ [ Dodano po: 17 minutach ]

Zapomniałem dodać, a to wg mnie bardzo ważne - program jako taki się nie zawiesza! Sprawdziłem na oscyloskopie czy są wysyłane rozkazy do czujnika i okazuje się, że tak. Znaczy to, że program sobie kręci pętle jak trzeba, tylko coś z NRF-ami się dzieje i nie mam pomysłu co.

Nie wnikając w bibliotekę, dla NRF musisz wykonać takie coś:
W rejestrze SETUP_RETR ustawiasz maksymalną ilość retransmisji oraz opóźnienie. WAŻNE: Zobacz w dokumentacji zależność tego czasu od ilości danych i prędkości transmisji.
Zalecam ustawić 15 retransmisji i 500us, włączone auto ACK.
Po wysłaniu danej czekasz na pojawienie się przerwania, potem sprawdzasz (rejestr STATUS ), czy przerwanie pochodzi od TX_DS -czyli zakończono pomyślnie transmisje czy od MAX_RT czyli przekroczono ilość retransmisji. Jeśli to drugie, wiadomo, że coś jest nie tak, zerujemy flagę.



W bibliotece z linku w pierwszym poście jest:


Jak widać nie informujemy użytkownika o tym, że wystąpił błąd transmisji, jedynie kasujemy flagę.
Trzeba dodać sobie kolejną zmienną np. MAX_RET_flag w pliku *.c



W pliku *.h


I zmienić procedurę obsługi przerwania:

I po wysłaniu sprawdzać, czy flaga nie została ustawiona. Jeśli tak- wiadomo że błąd transmisji. Można spróbować ręcznie wysłać dane jeszcze raz.

Nie wykluczam, ze trzeba dokonać więcej zmian, musisz się przyjrzeć bibliotece, lecz mam nadzieję, że na podstawie tego co napisałem, zrozumiesz o co chodzi.

_________________
Amatorska stacje meteorologiczna

Dziękuję za wyczerpującą odpowiedź, mam porządny punkt zaczepienia
U siebie mam tak w tym momencie:


Więc czas - w porównaniu z wartościami podanymi przez Ciebie - dużo większy, a ilość powtórzeń dużo mniejsza.

Napisałeś tak:

Czy poprawnie jest to zrealizować w taki sposób (?):



------------------------ [ Dodano po: 8 minutach ]

O ile widzę, to w przypadku, gdy jest wykryty błąd w transmisji to nie dość, że nie informujemy użytkownika o tym, co się stało, to transmisja może się nie powtórzyć? A gdyby tak po błędzie transmisji zrobić reset nrfa? Najczęściej to pomagało, ale chciałbym to zrobić programowo i nie wyłączając procesora. Czy wystarczy machnąć tranzystorem sterującym zasilaniem?

Ilość retransmisji się zgadza,

Znaczy 15 retransmisji, czyli maksymalna ilość. Czas nie do końca potrzebny taki duży.







No nie do końca. Musisz poczekać na zakończenie transmisji, nieważne z jakim skutkiem. Korzystając z tego, że w przypadku przekroczonej ilości retransmisji zerujemy też flagę TX, najprostszy, lecz blokujący sposób wygląda tak:

Przynajmniej ja bym to tak widział...
Pozdrawiam

_________________
Amatorska stacje meteorologiczna

Ano widzisz! Sam wpadłem na tego while'a z TX_flag, ale nie zauważyłem różnicy w działaniu. Może się poprawi z tą dodatkową flagą MAX_RET_flag.
Spróbuję machnąć tranzystorem zasilania nRFa po błędzie i potem odnowić transmisję. Dodam sobie jeszcze diodę, którą zapalę przy pojawieniu się tej flagi. Będę dawał znać jak efekty.

Zbędne działanie, przynajmniej dla poprawnie działającego układu. Z czego to zasilasz? Daj blisko NRF-a kondensatory 100n i 10uF.

_________________
Amatorska stacje meteorologiczna

Zasilanie - wg mnie - mam zrobione porządnie. Akumulator 18650 3.7V -> przetwornica Pololu step-up 5V -> stabilizator LDO na 3.3V, wszędzie kondensatory filtrujące. Do tego na samych pinach nRF'a mam przylutowane między GND i VCC 10uF tantal i 100nF ceramik.

------------------------ [ Dodano po: 2 minutach ]

A po niepoprawnej transmisji wszystkie bufory z danymi, co to nie udało ich się wysłać, zostają zerowane?

Zależy. Sam układ NRF24l01 w przypadku przekroczonej ilości retransmisji nie zeruje buforu FIFO, tak więc łatwo można ponowić transmisję danych.
Natomiast w bibliotece jest:


To samo robimy w funkcji nRF_SendDataToAir co wydaje się już zbędne.
Gdy nie wykonamy nRF_Clear_TX(); możliwa jest ponowna próba wysłania tych samych danych, wystarczy impuls na CE.
Natomiast MAX_RT musimy wyzerować, aby dalsza komunikacja była możliwa.

_________________
Amatorska stacje meteorologiczna

Czyli zakomentarzować nRF_Clear_TX(); i podać impuls na CE?

Pod warunkiem, że masz na myśli czyszczenie te w procedurze obsługi przerwania (patrz kod z mojego ostatniego postu). Nie możesz też przestawić NRF na odbieranie, czyli zakomentuj linijkę nRF_RX_Power_Up();. Pamiętaj tylko, że w razie ponownego niepowodzenia, ręcznie przestawić NRF-a na odbiór danych. Impuls na CE musi mieć minimum 10us. Do tego trzeba się bardziej przyjrzeć funkcją nRF_RX_Power_Up(); i nRF_TX_Power_Up(); a teraz jestem w pracy.

_________________
Amatorska stacje meteorologiczna

Uszczegółowię trochę kilka problemów.

Układ wygląda tak: nadajnik to xmega 128a3 + nrf, do nadajnika podpięty czujnik HTU21D, magistrala I2C. Powietrzem chcę przesłać dane z HTU.
Odbiornik to Atmega32A + nrf, to co odbierze leci UARTem do Putty.

Pojawił się natomiast trochę inny problem - odpaliłem program na dłużej, chodzi sobie i wysyła te dane przez jakiś czas, odbiornik wysyła na UART stringi i trwa to kilka-kilkanaście minut. Po tym czasie transmisja po prostu ustaje, UART już nic nie wysyła. Widzę to przede wszystkim po diodzie na FTDI, bo przestaje mrugać. Dopisałem proste polecenie, taki debugger - w nadajniku, w pętli głównej cały czas świeci się dioda. Wyłączana jest na czas transmisji. Gaśnie na bardzo krótko, ale zauważalnie. I nawet jak ustanie transmisja z odbiornika dalej na UART to mruga sobie dalej, czyli nadajnik pracuje poprawnie. Poza tym widzę na oscyloskopie, że komendy do czujnika cały czas są wysyłane i dane pomiarowe są zwracane.

Jeszcze raz podaję kody plików main.c nadajnika i odbiornika:
Nadajnik (xmega + nrf):


Odbiornik (atmega32 + nrf + UART):


Dodaję w załącznikach dwa logi wraz z zawartością terminali.
W pierwszym przypadku działał kilkanaście minut, potem puścił kilka krzaków i odbiornik przestał wysyłać do PC (RX i TX w stanie wysokim), przy czym nadajnik działał dalej (debugger w postaci diody mrugał, a na oscyloskopie były komendy do czujnika). Błąd na końcu loga spowodowany jest tym, że wyłączyłem zasilanie FTDI.

W drugim przypadku nadajnik jak i odbiornik działali krótko i transmisja po prostu ustała.

Dodam, że w momencie wysypanie się transmisji w event logu Putty nie ma żadnego błędu! Błąd się pojawia dopiero jak wyłączę FTDI, ale to akurat normalne.

Problem nr 3 - mam taki fragment w nadajniku:

Jak widać, wysyłam byte1. Jego wartość powinna być ok. 200. A na terminalu widzę czasami takie cuda:

ODEBRANO BAJTOW: 1 452

Przy czym ten problem nie pojawia się jak wysyłam byte0! Czujnik jest sprawny, bo jak nie wysyłam konwertowanych bajtów na stringi, tylko przeliczoną temperaturę (zakomentarzowany kod) to temperatura zawsze się zgadza (aż złapie zwiechę).

Takie zawieszanie się nrf'a też miałem, gdy był on na granicy zasięgu(około 60 - 70% gubionych pakietów). Pomagała ponowna inicjalizacja. Nie wiem z czego to wynika.

Dodaj flagę MAX_RET_flag w nadajniku(w sposób jaki wcześniej pisałem) i napisz warunek, że jeśli wystąpi błąd, zasygnalizowało diodą. Zobaczysz, czy w momencie problemu dioda się zaświeca. jaką ustawiłeś prędkość transmisji? Daj na razie 250kbps. SPI sprzętowe czy programowe? Korzystasz z przerwań, czy po prostu odpytujesz układ?
U mnie NRF-y działają bez problemu 24/7 w stacji meteo, wysyłają co 5sek baz żadnego resetowania -a już na pewno nie sprzętowego i tak to musi działać.

Masz zamiar wykorzystywać transmisję dwukierunkową, czy jednokierunkową, bo wtedy można uprościć kod.

_________________
Amatorska stacje meteorologiczna

Docelowo transmisja będzie dwukierunkowa. Moja stacja meteo ma być mobilna (na prostej podstawie robota z silnikami) więc będę musiał wysyłać dane dot. kierunku i zbierać dane z czujnika/czujników.

Wczoraj to zrobiłem i się nie zaświeciło w momencie zawieszenia. Ale zaraz zrobię to jeszcze raz, bo trochę zmieniałem kod a i w UARTcie dodałem taką linijkę przy funkcji wysyłającej znak:


Pytasz o prędkość transmisji UARTa czy nRFa?

SPI sprzętowe, do tego wykorzystanie przerwania IRQ. UART w odbiorniku też sprzętowy.

Zdaję sobie sprawę, że musi to działać non-stop i nie spocznę póki u mnie to nie będzie tak działało

Oczywiście prędkość transmisji NRF-ów. Jeśli korzystasz z Mirkowego MKUART z buforem cyklicznym i przerwaniami, to dodana linijka nie ma sensu. To przerwanie "informuje", że bufor jest pusty.

_________________
Amatorska stacje meteorologiczna

nrfy miałem ustawione na 2Mb. Zmieniłem na 250kb za Twoją radą.
Wyposażyłem program w dwa diodowe debuggery po stronie nadajnika, oto pętla while:


Dodałem flagę MAX_RET_flag i jak tylko się zaświeci powiadomi mnie o tym dioda. Jako, że flagę trzeba szybko wyzerować to postanowiłem nie gasić diody, i tak jestem w fazie testów. Oprócz tego mam drugi debugger informujący o kręceniu się pętli while. Mam timer programowy co 1s. Jeśli jestem poza warunkiem if(timer1000ms) to świeci mi dioda. Jak program wchodzi w tego ifa to gasi diodę. No i jak wchodzi to mam króciutkie, ale zawuażalne mignięcie. Poza tym na FTDI mam diody podpięte pod RX/TX więc widzę kiedy coś idzie do PC.

Na razie program sobie wysyła byte0 i czekam na zapalenie zielonej diody.

Czy w Twojej stacji używałeś jeszcze jakichś ciekawych sposobów na obsługę błędów transmisji i wieszanie się nrfa?

------------------------ [ Dodano po: 5 minutach ]

Jak na razie nic nie jest gubione, ale zdarzają się kwiatki typu:

ODEBRANO BAJTOW: 3 666

Trochę przerażające jest to, że jak już coś się takiego pojawia to tylko te 666 za każdym razem

Czy takie kwiatki (wszak 666 nie jest liczbą 8-bitową, a tylko takie są wysyłane z HTU21) mogą być związane z konwersją inta do stringa? Takie zdarzenia są wysoce niepożądane, tym bardziej, że do PC chcę przesyłać surowe dane, a liczeniem zmiennoprzecinkowym zajmie się już PC.

------------------------ [ Dodano po: 12 minutach ]

Zauważyłem taką rzecz - jak byte0 miał wartość dziesiętną 106 to kwiatkiem w transmisji był 666, tj. powyżej. Ale jak czujnik przesłał 107 to kwiatkiem w transmisji jest teraz 777. Stawiam, że coś ze stringiem nie tak, ale nie bardzo wiem jak poprawić. Oto zmienne jakie używam:+


No i przypisanie ze struktury obsługującej czujnik, konwersja i wysyłka:


Czy może być tak, że z poprzednich transmisji zostają jakieś śmieci i to one powodują takie zaburzenia w konwersji na string?

Wpisz dla testów na sztywno jakiś string, który ma zostać wysyłany, może to być linijka:


Obserwuj transmisję jakiś czas w terminalu czy występują jakieś błędy.

_________________
Amatorska stacje meteorologiczna

Ok, już przełączam. Jak na razie 35min chodziło z tym co wyżej, sporadycznie jakieś głupoty typu 666, 777.

A co jakbym chciał przesłać czyste dane liczbowe, np. właśnie wspomniany byte0? Kiedy próbowałem tak:

to przy kompilacji dostałem warna:

Nie rozumiem dlaczego different size, skoro wskaźnik jak i byte0 są uint8_t. Jak poprawnie przesyłać coś innego niż stringi?

------------------------ [ Dodano po: 6 minutach ]

Z kolei jak podałem w miejscu byte0 liczbę typu uint16_t to kompilacja bez warninga. Znaczy, że dla poprawnego wykonania funkcji powinienem mieć zmienną większą niż 8-bitową?

Zobacz co się dzieje w funkcji nRF_SendDataToAir

Poza tym jako argument jest wskaźnik na zmienną, nie zmienna.

Utwórz tablicę dla 3 bajtów :

Trzy pierwsze elementy wypełnij swoimi danymi, w czwarty (bufor[3]) wpisz zero (symulacja końca stringu).
I wyślij podając jako argument adres pierwszego elementu:


Pamiętaj tylko, żeby przełączyć terminal na odbieranie bin, dec lub hex (zależy jaki terminal) a nie ascii, bo zobaczysz pojedyncze znaki

_________________
Amatorska stacje meteorologiczna

Skoro mam podać adres pierwszego elementu bufora to nie powinno to wyglądać tak (?):


Nie jestem pewny, więc pytam

------------------------ [ Dodano po: 1 minucie ]

A i ze sztywnym stringiem leci już godzinę (bez 7miu minut) i nawet jednej ramki nie zgubił. Znaczy to, że biblioteka i nrfy w porządku, czy tak?
Dioda od MAX_RET_flag też się nie zapaliła.

------------------------ [ Dodano po: 3 minutach ]

No i właśnie zacięła się transmisja, a dioda od MAX_RET_flag się nie świeci. Zgasła na dobre druga dioda, tak jakby program nadajnika zatrzymał się w if(timer1000ms).

Jeśli już to

Jednakże warto zapamiętać, że nazwa tablicy bez numeru elementu zwraca adres pierwszego elementu tablicy. Jeśli posiadasz książkę BB radzę powrócić do tematu tablic

Skoro wysyłając stałe dane nie ma błędów, wiesz żeby przyczyny szukać wyżej w kodzie.

_________________
Amatorska stacje meteorologiczna

Dosłownie minutę po tym jak napisałem, że nie ma błędów to program się zaciął, dioda od MAX_RET_flag nie świeciła się, natomiast zgasła druga dioda, czyli program utknął w if(timer1000ms).

Zapomniałem o tym fakcie nt. tablic, chyba raz to gdzieś mi się obiło o oczy jak zaczynałem cokolwiek czytać o programowaniu

------------------------ [ Dodano po: 5 minutach ]

Odnośnie przesyłania liczb - w odbiorniku, żeby wysłać gołe liczby na UART to muszę zmienić:

na coś w rodzaju:
?
Czy nie zmieniam nic, zostaje char i traktuje go jako zmienną 8-bitową, pamiętając o tym, żeby na terminalu zmienić na dec?