Cześć!
Paruję 2x Atmega16A za pomocą w/w modułów radiowych, z czego jeden pełni funkcję pośrednika między terminalem (putty) a robotem (druga Atmega16A). Korzystam z bibliotek Mirka pod RFM70D przerobionych aby działały na 73D oraz przerwanie z INT2 na INT0. Oba moduły na sprzętowym SPI, bez zbędnego kombinowania.
Generalnie całe sterowanie robotem ma się odbywać: Putty -> USART -> ATMEGA-> RFM -> RFM -> ATMEGA.
I to bardzo ładnie się udaję do momentu odebrania przez moduł w robocie ramki. Ramka jest przetwarzana i analizowana jest jej zawartość oraz podejmowane odpowiednie działanie. Procesor współpracujący z terminalem co 30 sekund bezczynności (braku nadawania czegokolwiek, czy to komend, czy sygnałów sterujących) wysyła sygnał synchronizujący na który robot ma 500ms na odpowiedź. Na tym przykładzie postaram się opisać mój problem. Generalnie wszystkie sygnały to liczby naturalne, które robot potrafi zinterpretować.
Sęk w tym, iż robot odbierze "rozkaz zgłoszenia się że żyje" ale wysłanie powodzi się tylko dokładnie raz za pierwszym razem. Kolejne zapytania dochodzą (dioda odbiorcza miga) ale odpowiedź nie zostaje wysłana. Podejrzewałem, że w funkcji wysyłającej jest błąd, ale przecież dokładnie takiej samej używam przy wysyłaniu od terminala. Jeśli chodzi o kod, podłączenie standardowe jak mówiłem, nic nie zmieniałem, oprócz przerwania:
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
Fragment kodu w robocie:
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
Jeśli chodzi o sam moduł to oczywiście próbowałem zrobić najprostszą transmisję, typu:
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
Działa bezbłędnie. Jak i również odbieranie "z buta" w pętli while wszystkich ramek, ale skoro mamy zdarzenia to nie o to w tym chodzi
Jeśli macie jakiś pomysł, słucham uważnie.
Pozdrawiam!