Cześć,

sytuacja jest dla mnie trochę dziwna, a nie mam za dużego doświadczenia z AVRami. Dlatego proszę o zerknięcie, bo może da się wyciągnąć jakieś sensowne wnioski.

Próbuję zaadoptować przykład 26 (Simple test) z Greenbooka, aby sprawdzić połączenie dwóch modułów RFM73.
Posiadam dwie Atmegi328P (DIP28) na stykówce.
1. Obie tak samo podpięte do zasilania i do modułów RFM73.
2. Obie pracują na wewnętrznym oscylatorze 8MHz (fusy: H:0xD9 L:0xE2 E:0x07 - czyli z fabrycznego ustawienia zmienione jest tylko CKDIV8).
3. Moje zmiany biblioteki w rfm7x.h:
- używam nóżek od 15 do 19

i nóżki nr 4

4. Moje zmiany biblioteki w rfm7x.c:
- w tym mikrokontrolerze inaczej inicjalizuje się przerwania i dodatkowo na PD2 jest INT0, więc zmieniam

5. Moje zmiany w main.c:
- mam leda podpiętego do innego pinu

- timer inaczej inicjalizowany w tej Atmedze:

- inna też nazwa wektora przerwań:


PROBLEM:
Po podłączeniu zasilania widać, że oba zestawy przechodzą pomyślnie funkcję 'is_rfm7x_connected()' o czym dają znać diody. Jednak jedna z tych Atmeg chwilę po wejściu do głównej pętli while(1) resetuje się. Widzę po tym, że znowu zaczyna mrugać diodka informująca o tym, że jest poprawne połączenie (is_rfm7x_connected() zwraca 1).

Wprowadziłem na początku pętli while(1) pętelkę for z trochę innym mruganiem, żeby odróżnić od tego informującego o poprawnym połączeniu. W ten sposób widzę, że program nawet nie dochodzi na tym jednym procku do włączenia zdarzenia odbiorczego:

bo już w trakcie tego mrugania diodką powraca do wykonywania funkcji main() od początku.

Próbowałem szukać przyczyny i jedyne co to zauważyłem, że jak odłączam pin IRQ modułu RFM73 od pinu PD2 Atmegi to problem znika. A później zauważyłem też, że nawet gdy nie ma zasilania 3V3 na nóżce VDD modułu to i tak następuje reset Atmegi, gdy te piny przerwania są połączone. Tylko ich rozłączenie pomaga.

Oczywiście druga Atmega z tym samym programem i tak samo podpięta zachowuje się poprawnie.

Pomożecie?

A próbowałeś zamienić moduły między prockami ? Może moduł jest uszkodzony ?

Faktycznie, nie próbowałem <facepalm>. Jutro zobaczę co z tego wyjdzie.

A zasilanie?
Źródło ( wydajność prądowa), blokowanie itp.

Po zamianie modułów reset występuje na drugim procku, na tym samym module. Wygląda na to, że coś z nim nie tak.

Zasilam Atmegi z jednego USBasp. 3V3 na oba RFM73 podałem z osobnej płytki Arduino zasilanej z zewnętrznego zasilacza. Wydaje mi się, że to powinno wystarczyć jeśli chodzi o wydajność prądową.
Co masz na myśli pisząc "blokowanie" odnośnie zasilania? Bo nie bardzo rozumiem.

blokowanie (popularnie) zasilania kondensatorami.

Acha, czyli filtracja po mojemu 100n i 10u mam na VCC i AVCC.

Zamówiłem już nowy RFM73.

Ma ktoś chęci przejrzeć moją adaptację kodu w C? Bo nie czuję się w tym mocny i nie jestem pewny czy na wszystko zwróciłem uwagę.

Wydajność 3.3V z arduino to 50mA (tragicznie mało). Teoretycznie RFM73 przy nadawaniu pobiera max. 23mA a przy odbiorze 22mA
co daje 45mA na 2 moduły, ale tak nie powinno się robić. Daj jakieś lepsze zasilanie 3.3V.

To z nowym modułem podepnę zasilacz laboratoryjny. Tak czy siak tutaj program nawet nie dochodził do momentu transmisji w którąkolwiek stronę. Próbowałem też z podłączoną jedną Atmegą i modułem, efekt był taki sam.

Ok. Podpiąłem zasilacz na 5V i 3V3 z wydajnością 1A na każdym kanale. No i teraz sytuacja jest taka, że oba zachowują się dokładnie tak samo, ale niestety nie poprawnie, bo oba mikrokontrolery startują od początku. Sprawdziłem na oscyloskopie i wyszło na to, że moment restartu następuje w momencie przerwania na linii IRQ z modułu (pojawia się tam niski stan). Za bardzo nie rozumiem o co może chodzić, może macie jakieś pomysły?

Znalazłem winowajcę (w kodzie, bo oczywiście winowajcą jestem ja z powodu braku ogarnięcia tematu ):

W stosunku do wersji biblioteki z GB zmieniłem numer zewnętrznego przerwania z INT2 na INT0 (moja Atmega w obudowie DIP28 nie ma pinu z INT2). Nie zmieniłem jednak w bibliotece wektora przerwań "ISR( INT2_vect )" na "ISR( INT0_vect )". Brak obsługi tego wektora, mimo inicjalizacji przerwania, powodował w momencie jego wystąpienia reset procka. Pewnie jest takie zachowanie gdzieś opisane, ale nie widziałem tego. Na trop trafiłem tutaj: http://electronics.stackexchange.com/questions/120567/avr-bootloader-interrupt-issue w pierwszym komentarzu pod pierwszym postem.

Dzięki za zaangażowanie. Mam nadzieję, że to już wszystkie niezbędne modyfikacje biblioteki, kodu programu.

Pozdrawiam!

A czy masz poprawnie obsługiwane przerwanie INT0 (bo było INT2)?

ISR( INT0_vect ).....

w pliku rfm7x.c


ps.

nie zdążyłem wysłać- a wszystko przez ten obiad.