Próbuję właśnie uruchomić nową bibliotekę RFM69 z Green Booka w jednym ze swoich projektów. Z uwagi na specyfikę sprzętu musiałem wprowadzić pewne modyfikacje. Po pierwsze inny jest MCU - Atmega 328P, po drugie zamieniłem programowe SPI na sprzętowe.
Trafiłem jednak na bardzo dziwny problem - kod zawiesza się w bardzo dziwnym miejscu, w którym na pierwszy rzut oka nie ma niczego, na czym mógłby się zawiesić...

Metodą prób i błędów doszedłem do tego, że za zawieszenie odpowiada funkcja rfm69_init(). Żeby ustalić dokładne miejsce, wewnątrz kodu tej funkcji pododawałem wywołania uart_puts(), wysyłające kolejne "znaczniki". Oczywiście zgodnie z przyjętą tutaj zasadą, wrzucam jedynie omawiany fragment kodu:



Układ po zrestartowaniu wysyła jedynie znacznik "A", dalsze już nie docierają. Opcja USE_IRQ jest ustawiona na 1, IRQ_NR to także 1. Dalszy blok kodu, umieszczony wewnątrz instrukcji warunkowej preprocesora powinien się więc wykonać. Nawet gdyby tutaj tkwił jakiś problem, to program powinien zaraz przejść do dalszej części i wysłać literkę "E". Nie ma tutaj przecież żadnej pętli, która mogłaby przejąć wykonywanie programu...

Poniżej zamieszczam inne modyfikacje, które wprowadziłem:

Ja zapytam inaczej - czy próbował kolega najpierw odpalić to tak jak w GB ? czyli na programowym SPI ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Z rozpędu pozmieniałem wszystko pod mój układ, miałem zamiar sprawdzić czy/jak to działa na programowym SPI, jednak najpierw chciałem skonsultować moje modyfikacje. Może jest tam jakiś błąd, którego ja nie mogę się dopatrzeć. Docelowo wolałbym jednak używać sprzętowego SPI.
Swoją drogą program przestał się zacinać, kiedy ustawiłem USE_IRQ na 0...

Mam jeszcze jedno pytanie:
Skąd można by wyłuskać adres modułu, który wysłał nam wiadomość? W przykładzie z książki mamy dwa, ustawione "na sztywno" adresy modułów, które przerzucają między sobą komunikat. Ja chciałbym zrobić coś wedle następującego schematu:

1) Odbieramy komunikat od dowolnego modułu, odczytujemy go do zmiennej tablicowej, a w osobnej zmiennej zapisujemy adres nadawcy.
2) Przekazujemy odebrany komunikat do procedury parsującej, która sprawdza czy mamy do czynienia ze znanym poleceniem. Jeśli tak - jest ono dalej przetwarzane i przygotowywana jest odpowiedź, zapisywana w osobnej tablicy.
3) Jeśli tablica z odpowiedzią zawiera jakąś treść, jest ona wysyłana pod zapisany wcześniej adres naszego "korespondenta".
4) Wszystkie tablice są czyszczone, choćby przez wpisanie 0 do pierwszego elementu.

Można by w ten sposób stworzyć mechanizm pozwalający na automatyczne udostępnianie jakiejś treści (np. czasu) dowolnemu urządzeniu w sieci, które o nią poprosi. Trochę podobnie do komunikacji UDP za pomocą ENC28J60.

BTW czy net_id ma coś wspólnego z opcją sprzętowego szyfrowania komunikacji? Ta opcja jest wykorzystywana w bibliotece z Green Booka, czy ze względu na prostotę nie została w niej zaimplementowana?

opcja szyfrowania w ogóle nie została zaimplementowana ... ale chyba przy takim omówieniu modułu i tworzenia biblioteki to ... implementacja tego we własnym zakresie chyba nie powinna już nastręczać trudności, gdy ktoś się uprze na to szyfrowanie.

Natomiast adres nadawcy można przecież nadawać w pierwszym bajcie ramki i już ..

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Te moduły "lubią" zewnętrzny pullup na lini CS...

_________________
Czekamy na RedBook'a!

Rozumiem. Chciałem się tylko upewnić. Może spróbuję je dodać samodzielnie, chociaż nie sądzę, żeby ktoś w mojej okolicy próbował robić spoofing komunikacji za pomocą tych modułów.



Tak, wiem. Zwyczajnie nie chciałem go nadmiarowo przesyłać jeszcze raz, jeśli byłoby to już realizowane sprzętowo i potem ten jeden bajt dałoby się wyciągnąć z jakiegoś rejestru modułu. Rozumiem, że nic takiego nie ma miejsca i mogę jedynie przesyłać adres nadawcy razem z danymi?



To zawsze robię tak czy inaczej, w każdym układzie wykorzystującym magistralę SPI.

Hmm... Jeszcze jedno pytanie przyszło mi do głowy.
Czy biblioteka jest także kompatybilna z modułem RFM69HCW? Czy też obsługuje jedynie wersję CW?

Pewnie że jest kompatybilna - tylko trzeba sobie dodać samemu sterowanie dodatkowymi rejestrami odpowiedzialnymi za zwiększanie mocy nadajnika

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

A czy moduł w wersji HCW ruszy również z niezmodyfikowaną biblioteką, oczywiście operując z mniejszą mocą?
Pytam, ponieważ właśnie przeprowadzam pierwsze eksperymenty z tym modułem. Jakiś czas temu skleciłem urządzenie, które wyposażyłem w RFM69HCW, ale nie uruchomiłem tej części jego funkcjonalności. Miałem samemu próbować przeportować bibliotekę z Arduino, ale ostatecznie zająłem się innymi projektami i czekałem na nowego Green Booka.
W tej chwili nie mam pod ręką drugiego modułu, żeby sprawdzić komunikację (przyjdzie na dniach), ale zabrałem się za pierwsze testy i prawdę mówiąc nie jestem do końca pewien wyników. Próbowałem zobaczyć, czy jakaś transmisja radiowa będzie widziana przez RTL-SDR, ale niczego nie mogę wychwycić.

W tej chwili przywróciłem programowe SPI.
Czy istnieje jakiś sposób na sprawdzenie, czy w ogóle występuje komunikacja pomiędzy modułem a MCU?

Połączenia na płytce zostały sprawdzone wielokrotnie i wyglądają prawidłowo.

pewnie że jest - przecież masz tam do tego specjalną funkcję i pokazywałem nawet ją w poradniku wideo

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Hmm... O którym wideoporadniku mówimy? Chyba coś mi umknęło.

Nie - przepraszam - jest taka funkcja ale do RFM73 - sorki

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Tak właśnie mi się wydawało, że widziałem to w filmiku dla siedemdziesiątki trójki.
Czy w RFM69 mogę na szybko przeprowadzić jakiś test komunikacji przez SPI?

Napisz funkcyjkę do dczytu jakichś stałych domyślnych wartości rejestrów

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Na przykład taką


PS.
Pokaż jeszcze jak masz moduł podłączony...
Jeśli masz podłączony pin RST to musi on być w stanie wysokiej impedancji (nie podciągnięty), czyli pin atmegi jako wejście i bez pullupa.

Obsługę załatwiają takie makra:

_________________
Czekamy na RedBook'a!

Hmm... Faktycznie mam pin RST podłączony do linii MCU (ustawionej na wyjście w stanie wysokim) + rezystor podciągający do VCC.
Czyżby w takim układzie moduł znajdował się w stanie ciągłego resetu?

Faktycznie, okazuje się, że winę ponosiło nieprawidłowe podłączenie pinu RST.
Tak swoją drogą jak powinien być podłączony pin IRQ? Podciągnięcie go rezystorem do VCC jest prawidłowym rozwiązaniem?