Może tutorial? Kod w C, podłączenie, konfiguracja - RF 433MHz i AVR

Witam. Ostatnio zainteresowałem się komunikacją bezprzewodową pomiędzy min. dwoma qC przez RF 433MHz, ponieważ dostałem takie coś i chciałbym tego użyć przede wszystkim w celach edukacyjnych. Powiedzmy, że jakąś fundamentalną wiedzę laik może zdobyć w internecie. W zasadzie wszystkie przykłady konfiguracji i napisania kodu programu umieszczone na blogach, forach, filmikach itd. są dla Arduino i bibliotekę VirtualWire. Nie doszukałem się niczego konkretnego z naciskiem na konkretnego dla uC np. atmega. Zaczynając od podłączenia modułu przez obsługę - połączenie się nadajnik-odbiornik, ewentualną kalibrację kończąc na przykładowym kodzie w C a tego ostatniego najbardziej brakuje.
Więc moja prośba w sumie jest taka czy ktoś mógłby przedstawić jakiś przykładowy kod w C, który może gdzieś wykorzystał. Dla odbiornika i nadajnika. Ja posiadam moduł zestaw FS100A. Wszystko wstępnie kieruję do komunikacji pomiędzy dwoma atmegami. Może polecacie jakieś biblioteki? Chciałbym żeby taki konkretny tutorial zaistniał na forum chociażby dla kolejnych początkujących.
Następna sprawa to podłączenie. Czy linie data z modułu można podłączać tylko do nóżek RX i TX którymi są np. w atmega8 PD0 i PD1?
Przyjmijmy klasyczną konfigurację sprzętową.
Nadajnik: uC + czujnik temperatury lub ruchu - odczytuje temp lub wykrywa ruch i przekazuje informację do odbiornika
Odbiornik: uC + LCD na którym jest wyświetlana wartość czyli temperatura lub wyświetla się napis "Ktoś idzie"
Jeżeli macie już wszystko gotowe pod inne zastosowania i chcecie się podzielić tym to proszę o wstawianie.
Z góry dziękuję i pozdrawiam

Witam.

Można i czymś takim się bawić. Możliwości są stosunkowo małe.
Do tego wykonałem tylko jedno podejście i wylądowało to w koszu.

Obecnie używam modułów RFM69.
To co masz to komunikacja tylko w jedną stronę.
Transceiver umożliwia komunikację typu. Ja pytam ty odpowiadasz.
Następna sprawa moduł wszystko załatwia sam, Ty tylko musisz z bufora odczytać dane lub je tam wpisać.
Przy FS100A jeden nadaje drugi słucha i to wszystko.
Jak będziesz chciał mieć kilka urządzeń to sporo się namęczysz by je poprawnie odsłużyć.

I pewnie dla tego w necie nic nie mogłeś znaleźć.
Co prawda cena jest fajna ale możliwości nijakie.

Przykład użycia RFM69 Link

Wiem że to komunikacja jednokierunkowa. Czyli trzeba podłączyć nadajnik d uC i ustawić PD1 jako wyjście, odbiornik do drugiego i PD0 jako wejście? To są wyjścia kontrolera dedykowane dla nadajnika i odbiornika czy można określić jakieś inne?

Jakie będą procesory?
a. w nadajniku
b. w odbiorniku

Przede wszystkim tych modułów nie "nakarmisz" UARTem. Dane muszą być zakodowane w pewien specyficzny sposób, którego UART nie dostarczy. Przykłady właściwego kodowania to Manchester czy wspomniany VirutalWire. Są też inne. Który pin jest wykorzystany do nadawania/odbioru zależy od konkretnego liba. Np. VirtualWire z którego zwykle korzystam pozwala skonfigurować dowolny pin, ale już implementacja kodera VW, którego zacząłem pisać na sprzętowy moduł USI wymaga już konkretnego pina.

dasej wrote:

Jakie będą procesory?
a. w nadajniku
b. w odbiorniku

Jak wspomniałem wyżej jakieś atmegi - 8, 88 etc. To w 8 na PD0 i PD1 są RX i TX, nie pamiętam jak w innych jest.

@Bluzman Myślę że @ex-or Udzielił Ci odpowiedzi.
Proponuję porzucić ten temat. Po prostu szkoda Twojego czasu na tą technologię.
To o czym pisze @eX_-or moduł RFM załatwiają same sprzętowo.

Cześć
Naukę od czegoś trzeba zacząć. Ja stosuje podobne moduły i z powodzeniem zadowalająco pracują z prostym programem na UART, wziętym z dowolnej noty technicznej uC avr.

@StaryVirus_e_Wiarus Kolega @Bluzman czeka na przykłady.
Możesz mu pomóc by zrealizował swój pomys i się czegoś nauczył.
Droga wolna.

W internecie jest wszystko. Opis UART, noty do modułów, do uC avr. Tylko chcieć samemu. Nauka nie polega na tym, że ktoś coś za autora napisze, połączy i będzie działać. Na naukę trzeba dużo czasu. To nie jest tak, że dziś mam pomysł, pierdnę i wyskoczy na elektrodzie.pl. Propozycje innych modułów, uC też nie pomogą, bo do tego potrzebna większa wiedza. Autorze - samemu , cierpliwe i będziesz bardziej zadowolony. Powodzenia.

dasej wrote:

Po prostu szkoda Twojego czasu na tą technologię.

Uważam, że niekoniecznie trzeba ją tak kategorycznie skreślać. Trasmiter ma tę zaletę, że jak nie nadaje to w ogóle nie pobiera prądu, więc do prostego bateryjnego czujnika, uważam, się nadaje.

Pisanie po próżnicy.
Wątek leci a kolega @Bluzman nadal nie uzyskał pomocy.
Podtrzymuje swoje zdanie. Zrobiłem bezprzewodowy termometr z RFM69 który pobiera 900nA.

To jest właśnie problem takich tematów na forach itd. Ja się pytam o kod źródłowy - skonfigurowanie wstępne pinów w języku C dla tego modułu i jak podłączyć a 5 osób mi udowadnia że nie warto bo inny jest lepszy. Później jest dyskusja że kolega się pytał o ten moduł i chciałby wiedzieć i ktoś odpowiada że deszcze pada a ten sprzęt to badziew. Tak umiera kolejny temat na forum na tym samym etapie a mógłby istnieć tylko jeden taki ale dobrze rozwinięty i rozwiązane wszystkie zagadnienia. Wiem że lepszy jest RFM bo czego można się spodziewać po module z technologii połączenia radiowego sprzed 40 lat za 6 zł

Już tak nie narzekaj. Co prawda ci którzy uważają że nie należ tego skazywać na
zapomnienie nic nie napisali to Ci podeślę Link Link Link Opis mini stacji meteo Link

Jedno pytanie do google
Nadal uważam że marnujesz czas.
Powodzenia.

Filmiki widziałem te od Mirka wymiatają czasem. Ostatnio nagrał jak zrobić maseczkę na usta. Zainteresowało mnie to powiadamianie o poczcie w skrzynce. Projekt stacji pogodowej odlozylem chwiliwo. Nie narzekam ale to dalej do samego sedna tematu nie wprowadza dużo nowego. Zapytam się tylko o szyfrowanie Manchesterem. Właściwie to co to za szyfrowanie jest, na czym polega co to za algorytm? szyfruje same dane przesyłane czy jakoś pasmo, kanał?

To nie jest szyfrowanie, a kodowanie. Główną zaletą jest to, że możesz z niego odtworzyć oryginalny zegar taktujący transmisję oraz fakt, że unikasz długich czasów bez zmiany stanu, co szczególnie dla transmisji radiowej jest słabe. Samo kodowanie jest proste - po prostu robisz xor zegara i transmitowanych danych. Na nowych AVR możesz to zaimplementować sprzętowo korzystając z XCL. Wbrew temu co niektórzy powyżej napisali, użyte proste nadajniki/odbiorniki nie są takie złe. Trochę więcej trzeba własnego kodu napisać (z drugiej strony inicjalizacja io obsługa maszyny stanu RFM też sporo kodu pochłania), ale właśnie są proste i to ich główna. zaleta.

dasej wrote:

Już tak nie narzekaj. Co prawda ci którzy uważają że nie należ tego skazywać na
zapomnienie nic nie napisali to Ci podeślę Link

Ten link jest do Arduino IDE, ono ma swoją platformę i jakieś "uproszczone" C czy C++ już sam nie pamiętam a te biblioteki (Manchester, VirtualWire) są do Arduino, nie dla zwykłej atmegi czy attiny z RXD i TXD. Ja chcę czysty C, nic wspólnego z jakimś Arduino.
Moduł już nie ważny bo widzę że rozmowa sprowadza się do przekonywania, który jest lepszy. Chyba UART będzie trzeba skonfigurować jakoś? Będę się powoli zabierał do tego po przerwie. Znalazłem 2 atmegi8 jednak, będą 2 identyczne qC.
Może ktoś poleci bibliotekę do tego, zastanawiam się nad tą https://github.com/andygock/avr-uart Oparta na przerwaniach. Jak z nią postępować? Nie rozumiem jeszcze wiele rzeczy w C a opisy do niej to są na pół gwizdka, bardziej dla obytych już w temacie.
Poza #include biblioteki tworzę nową funkcję pod funkcją główną programu przez dodanie void uart_init ( unsigned int baudrate) (Tutaj są opisane funkcje http://www.peterfleury.epizy.com/doxygen/avr-gcc-libraries/uart_8h.html) ? Nadajnik podpięty nóżką DATA z TXD, wysyła dane do odbiornika.

Proszę bardzo UART bez przerwania.

Bluzman wrote:

Może ktoś poleci bibliotekę do tego, zastanawiam się nad tą https://github.com/andygock/avr-uart Oparta na przerwaniach. Jak z nią postępować? Nie rozumiem jeszcze wiele rzeczy w C a opisy do niej to są na pół gwizdka, bardziej dla obytych już w temacie.

Transceivery jakich używasz po prostu modulują dane z wejścia, a odbiornik je demoduluje. Nie ma tam żadnej filozofii, więc można je traktować jako połączenie dwóch uartów drogą radiową. Tyle, że... ponieważ nie ma w tym żadnej filozofii, a droga radiowa jest podatna na zakłócenia, więc sam musisz zadbać o poprawność przesyłanych danych - detekcję startu, końca, wykrycie błędów w transmisji. Dlatego sama "biblioteka" do obsługi UART, składająca się z 3 funkcji - typu inicjalizacja, nadanie znaku, odbiór znaku, nic ci nie da. Zresztą taką "bibliotekę" w C znajdziesz chociażby w nocie katalogowej użytego procesora AVR. Ty potrzebujesz czegoś więcej - tu właśnie przydaje się modulacja Manchester, musisz dodać preambułe do nadawanych pakietów, jakieś CRC itd. Normanie to robią bardziej zaawansowane transceivery typu RFMxx. Ty musisz programowo sam o to zadbać. Oczywiście jest pewna szansa, że spięcie dwóch uartów przy pomocy prostych transceiverów da jakieś pożądane efekty i to zadziała, tyle, że pewność tego działania będzie niewielka.
Dlatego koledzy sugerowali użycie innych układów. Jeśli ne chcesz to chociaż przeczytaj ich noty, w których opisana jest budowa pakietu, detekcja itd. Będziesz miał wskazówki od czego zacząć przy własnej implementacji.

Czyli dla atmegi i attiny np. coś takiego byłoby dobre?
https://github.com/goldsborough/Mavrchester

Bluzman wrote:

Czyli dla atmegi i attiny np. coś takiego byłoby dobre?

To ci załatwia kodowanie, to teraz jeszcze preambuła, struktura ramki, integralność danych (jakieś CRC).
Ale na początek, podłącz te dwa radia do UART, nadaj coś bez kombinacji, sprawdź czy działa. Jeśli tak, to zaimplementuj kolejny etap - kodowanie. Nie rzucaj się od razu na całość bo polegniesz.

Skonfigurowałem USART na dwóch atmegach8 (TX i RX). Zastosowałem prosty kod z noty katalogowej. Do RX podłączyłem LCD. Wyświetlacz cały pokrywa się "krzakami". To samo się dzieje czy uC są połączone kablem TX->RX czy też wysyłam dane przez radio.
Konfiguracja LCD jest raczej prawidłowa bo przy wpisaniu tekstu w " " ( LCD_WriteText("mojtekst"); ) wyświetla się on prawidłowo. Podejrzewam typy zmiennych ale prosiłbym o sugestie jakieś.

RX


TX
[/code]

Zacznij od podstaw języka C. Odczytujesz jeden znak z UART po czym wartość tego znaku przekazujesz jako adres łańcucha do wypisania do funkcji LCD. Kompilator niby ostrzeżenia nie zgłasza?

Dobrze wyświetla z pewnością, już wyżej napisałem o tym

Bluzman wrote:

Konfiguracja LCD jest raczej prawidłowa bo przy wpisaniu tekstu w " " ( LCD_WriteText("mojtekst"); ) wyświetla się on prawidłowo.

szelus wrote:

Odczytujesz jeden znak z UART po czym wartość tego znaku przekazujesz jako adres łańcucha do wypisania do funkcji LCD. Kompilator niby ostrzeżenia nie zgłasza?

Nie rozumiem do końca chyba, tzn. co jeszcze trzeba dodać w funkcji LCD? Dane wysyłają się za pomocą void USART_Transmit, są odbierane w char USART_Receive kolejno w pętli do zmiennej i zmienna ta idzie do wyświetlenia - LCD_WriteText(odczyt);
Dodałem jeszcze przed wyświetleniem sprintf() to zniknęły krzaki i zaczęły się pojawiać jakieś liczby ale nie te które wysyłam. Wysyłane dane mają typ unsigned char i ładowane po odbiorze tak samo teraz. Nie pokażę w tej chwili kodu bo nie mam dostępu.
A jeżeli chodzi o ostrzeżenia kompilatora to raz coś wypluwał a drugi raz nie, jak mu się podobało chodź nie wprowadzałem zmian żadnych. Dokładniej się czepiał typu zmiennej w linijce LCD_WriteText(odczyt);

Bluzman wrote:

Nie rozumiem do końca chyba, tzn. co jeszcze trzeba dodać w funkcji LCD? Dane wysyłają się za pomocą void USART_Transmit, są odbierane w char USART_Receive kolejno w pętli do zmiennej i zmienna ta idzie do wyświetlenia - LCD_WriteText(odczyt);

To właśnie widzę, że brakuje Ci podstaw C. Umiesz programować w jakimkolwiek języku, czy zaczynasz totalnie od zera?
W kodzie, który pokazałeś, odbierasz pojedyncze znaki (to właśnie robi funkcja UART_Receive) i każdy znak z osobna próbujesz wyświetlić. Problem w tym, że funkcja LCD_WriteText przyjmuje jako argument napis, a napis w C to jest tablica znaków zakończona specjalnym znakiem o kodzie 0. Przy czym w zasadzie w C nie ma typu napisowego, za taki służy konwencjonalnie wskaźnik na znak, bo w C wskaźnik na pojedynczy element jakiegoś typu jak i tablicę takich elementów nie są rozróżnialne składniowo.

Bluzman wrote:

Dodałem jeszcze przed wyświetleniem sprintf() to zniknęły krzaki i zaczęły się pojawiać jakieś liczby ale nie te które wysyłam. Wysyłane dane mają typ unsigned char i ładowane po odbiorze tak samo teraz. Nie pokażę w tej chwili kodu bo nie mam dostępu.

Bez kodu będzie ciężko coś poradzić, bo na podstawie powyższego trudno domniemywać, że rzeczywiście napisałeś kod zgodny z zamiarem. W każdym razie w pokazanym powyżej kodzie nadajnika wysyłasz pojedynczy znak o kodzie 123, czyli znak '{'.

Bluzman wrote:

A jeżeli chodzi o ostrzeżenia kompilatora to raz coś wypluwał a drugi raz nie, jak mu się podobało chodź nie wprowadzałem zmian żadnych. Dokładniej się czepiał typu zmiennej w linijce LCD_WriteText(odczyt);

Pytanie było w zasadzie retoryczne. Kompilator musiał wypluć ostrzeżenie bo przekazywana zmienna typu char jest niekompatybilna z oczekiwanym argumentem typu char*.

Bluzman wrote:

A jeżeli chodzi o ostrzeżenia kompilatora to raz coś wypluwał a drugi raz nie, jak mu się podobało chodź nie wprowadzałem zmian żadnych. Dokładniej się czepiał typu zmiennej w linijce LCD_WriteText(odczyt);

Nie wiem jak jest u ciebie, choć myśle że podobnie, (ja korzystam z pliku make), to jeśli nie ma zmian w pliku to kompilator nie kompiluje ponownie tego pliku bo nie musi. Nie ma wtedy komunikatów z tego pliku.

Tak to powinno wyglądać:


A co do tych radiowych modułów (jeśli dobrze kojarze typ), z tego co czytałem to potrzebują one wstępnie sygnału do synchronizacji. Z tegoż względu słabo się nadają do UARTA. Były ze dwa tematy na forum o tym.
.

tmf wrote:

To ci załatwia kodowanie, to teraz jeszcze preambuła, struktura ramki, integralność danych (jakieś CRC).
Ale na początek, podłącz te dwa radia do UART, nadaj coś bez kombinacji, sprawdź czy działa. Jeśli tak, to zaimplementuj kolejny etap - kodowanie. Nie rzucaj się od razu na całość bo polegniesz.

Sprawdziłem UART, jest połączenie, wysyła pojedynczy znak - połączenie dwóch atmeg kabelkiem. Kiedy podpinam moduł radiowy do RX i TX to na LCD wyświetlają się 3 cyfry i cały czas się zmieniają. Teraz żeby było poprawnie to powinienem zastosować Manchestera?

Dodaję jeszcze kod, który zastosowałem
TX


RX

Spróbuj na wyjściu odbiornika radiowego DATA a między RX mikrokontrolera wpiąć taki filtr: