Witam wszystkich! Sytuacja wygląda następująco ... próbuje sobie zrobić "prosty" układ centralki alarmowej. Idea przedstawiona na rysunku poniżej:
Komunikacja w układzie "Nadajnika" ---> Wspólne Programowe SPI dla Mifare (pin CS podciągnięty do plus przez rezystor 10k i podłączony do PD7)i RFM69C (pin CS podciągnięty do plus przez rezystor 10k i podłączony do PB0).
W tym momencie sytuacja wygląda dynamicznie
i wygląda na to jakby szwankowała komunikacja z Mifare i RFM69 i sterowaniem tymi CS, chociaż każdy z tym układów steruje swoim wyprowadzeniem CS w czasie komunikacji więc nie powinno być konfliktów
Próbowałem dołożyć do bibliotek (zarówno Mifare jak i RFM69) wyłączanie drugiego układu w czasie gdy ten coś tworzy na SPI, ale nic to nie pomogło.
Zauważyłem taką zależność, że wszystko jest dobrze gdy RFM69 komunikują się "od razu" i niema powtórnego wysyłania danych bo nie zostały odebrane ... Jak nastąpi taka sytuacja to jest kaplica tzn Mifare pada i przestaje odczytywać karty ( sprawdzałem przy użyciu timera programowego i zmiennej jako TOGGLE czy procesor w tym stanie działa i zmienna się zmienia na LCD), więc wygląda jakby padała komunikacja po SPI programowym.
Poniżej zamieszczam schemat jak to jest fizycznie podłączone w obu przypadkach:
Co do bibliotek do do RFM69 to biblioteka z GreenBooka a jeśli chodzi o Mifare to biblioteka znaleziona gdzieś w internecie ale działa bo karty odczytuje tak jak tego potrzebuje, pytanie czy przez tą wspólną magistralę SPI się nie gryzą wzajemnie
Jeśli chodzi o moją radosną twórczość programistyczną to na ten moment wygląda to mniej więcej tak:
NADAJNIK ---> main.c
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
CENTRALKA ----> main.c
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
Na koniec dodam jeszcze, że obie atmegi taktowane kwarcem 11,0592 Mhz i w obu rfm włączone używanie przerwania INT1. Wcześniej jedna była taktowana 11,0592 a druga wewnętrznym 8Mhz i wyłączone były przerwania od GPIO0 i efekt był taki sam. Więc problem leży gdzieś indziej ... tylko gdzie