Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Multimetr FlukeMultimetr Fluke
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[Bascom][C]Atmega oraz radiowe moduły RFM01, RFM02, RFM12

ja_dzik 11 Sie 2013 12:25 233003 706
  • #631
    enro
    Poziom 10  
    Witam. Potrzebuję pomocy z RFM12B. Próbuję je uruchomić w dość specyficzny sposób:
    Nadajnik razem z atmegą8, co ok 100ms wysyłany jest ciąg znaków, linia nIRQ generuje sygnały w takt transmisji, pobór prądu ~23mA. Kod inicjalizacji:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Odbiornik jest także podłączony do atmegi8, jednak w tym przypadku nie steruje ona bezpośrednio rmf, tylko działa jako konwerter usb-spi(cdc-spi). Komendy inicjalizacji wysyłam przez własny program, sprawdziłem analizatorem stanów logicznych i wszystko wygląda w porządku. Kod inicjalizacji:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Odbiornik pobiera ~12mA, jednak linia nIRQ pozostaje cały czas w stanie wysokim. Po uruchomieniu odbiornik zwraca status 0x01xx, przy czym końcówka xx to przeważnie ff,fe. Wygląda na to że odbiornik "widzi nadajnik", ale żednych danych nie odbiera. Kiedy zresetuje FIFO status wygląda tak: 0x03xx.

    Czy ktoś ma jakiś pomysł co robię nie tak?
  • Multimetr FlukeMultimetr Fluke
  • #632
    white88
    Poziom 12  
    Pytanie,
    czy dla RF12 dla 868Mhz pobór prądu wyszedł komuś znacznie większy niż w nocie?
    Dla RF na 434Mhz wychodzi mi ok. bo nadawanie 20,79 mA oraz odbiór 10,40mA badane przetwornikiem halla + ADC 10 bit. Natomiast dla 868Mhz wypluło mi ok. 40mA nadawanie i podobnie odbiór? Chyba że jakiś błąd się wkradł...
  • Multimetr FlukeMultimetr Fluke
  • #633
    excray
    Poziom 40  
    W temacie problemów z RFM01/02 chciałbym dodać jedną uwagę której w tym temacie nie widzę. RFM01 ma w moim przypadku problem z poprawną inicjacją. Jeśli układ nie dostanie komendy 0xC080 gdzieś na początku w kodzie:
    Kod: c
    Zaloguj się, aby zobaczyć kod
    to później źle się inicjuje.
    Pierwszej linijki nie należy modyfikować ani zmieniać. W przeciwnym przypadku po zaniku zasilania RFM nie będzie się chciał poprawnie zainicjować pomimo dobrze dobranych parametrów.
  • #635
    2rs232
    Poziom 17  
    Do zabezpieczania elektroniki używam z powodzeniem lakieru Plastik 70 Kontakt Chemie. W jednym z urządzeń po 2 latach pracy na zewnątrz budynku elektronika wygląda jak "nowa".
  • #636
    FastProject
    Poziom 28  
    2rs232 napisał:
    Do zabezpieczania elektroniki używam z powodzeniem lakieru Plastik 70 Kontakt Chemie. W jednym z urządzeń po 2 latach pracy na zewnątrz budynku elektronika wygląda jak "nowa".


    Ok, ale czy z jakąkolwiek radiówką? W niech są małe pojemności i rezystancje, które mogą wpłynąć na odbiór i zasięg takiego modułu.
  • #637
    2rs232
    Poziom 17  
    FastProject napisał:
    2rs232 napisał:
    Do zabezpieczania elektroniki używam z powodzeniem lakieru Plastik 70 Kontakt Chemie. W jednym z urządzeń po 2 latach pracy na zewnątrz budynku elektronika wygląda jak "nowa".

    Ok, ale czy z jakąkolwiek radiówką? W niech są małe pojemności i rezystancje, które mogą wpłynąć na odbiór i zasięg takiego modułu.

    Lakierowałem nadajnik RFM02/868.
  • #638
    darkonel
    Poziom 19  
    Witam,
    dość długo walczyłem z modułami RFM12. Nie znalazłem nigdzie działającego kodu w asm (cały Internet przekopałem). Na szczęście się z nimi uporałem. Komunikacja działa aż miło. Kluczem okazało się połączenie linii nIRQ nadajnika z mikrokontrolerem, który odczytywał stan tej linii (stan niski oznacza gotowość do przyjęcia kolejnego słowa nadawanego przez SPI). Korzystam z pasma 433 MHz oraz ze sprzętowego SPI.
  • #639
    2rs232
    Poziom 17  
    Poprawność komunikacji SPI między modułem a procesorem, możesz przetestować włączając/wyłączając w RFM12 generowanie sygnału zegarowego na linii CLK i sprawdzać oscyloskopem jej stan.
  • #640
    darkonel
    Poziom 19  
    Zastanawia mnie dlaczego przy obsłudze modułu RFM12 przyjęło się, że inicjalizację wykonuje się wszystkimi dostępnymi komendami (a nawet nie opisaną w dokumentacji 0xCC17)? Wydaje mi się, że powinno się inicjalizować jedynie to, co chcemy ustawić dostosowując moduł do naszych potrzeb.
    Przykładowo, moja inicjalizacja nadajnika wygląda tak:
    Kod: asm
    Zaloguj się, aby zobaczyć kod

    Może jest coś, o czym jeszcze nie wiem i rzeczywiście musi się wykonać pełną inicjalizację, ale w moim przypadku życie pokazało, ze jednak nie.
    Bądź co bądź, moduły te są ok, jednak najwięcej problemów stwarza ich oprogramowanie. Klucz do sukcesu to:
    - poprawna inicjalizacja (szczególnie częstotliwość i FIFO)
    - prawidłowa obsługa programowa ze sprawdzaniem bitu zajętości
    To wszystko. Mój nadajnik działa aż miło (odbiornik z resztą też).
    [/code]
  • #641
    piotrva
    Moderator na urlopie...
    1. Co do inicjalizacji wszystkich parametrów - owszem, po POR trzeba zmienić tylko to, co nas interesuje, ale z praktyki wiem, że czasem podczas pracy i np. nieoczekiwanego resetu procesora itp. inne rejestry są przez przypadek zmieniane - wtedy trzeba ustawić wszystko.
    2.
    darkonel napisał:
    (a nawet nie opisaną w dokumentacji 0xCC17)

    Tu się nie zgodzę. moduł RFM12B ma taką komendę: 12. PLL Setting Command. Za to przy tej okazji warto zwrócić uwagę na tę literkę B. Mimo iż moduły RFM12 i RFM12B są do siebie niemalże bliźniaczo podobne to występuj,ą między nimi pewne drobne różnice, o których warto wiedzieć i zawsze musimy sprawdzić czy używamy RFM12 czy RFM12B
  • #642
    darkonel
    Poziom 19  
    piotrva napisał:
    Tu się nie zgodzę. moduł RFM12B ma taką komendę: 12. PLL Setting Command. Za to przy tej okazji warto zwrócić uwagę na tę literkę B. Mimo iż moduły RFM12 i RFM12B są do siebie niemalże bliźniaczo podobne to występuj,ą między nimi pewne drobne różnice, o których warto wiedzieć i zawsze musimy sprawdzić czy używamy RFM12 czy RFM12B


    Czyli Kolega się jednak zgadza. Przypominam, że cały czas mam na myśli moduł RFM12S (wersja SMD bez B), a w tym module mamy:

    1 Configuration Setting Command
    2 Power Management Command
    3 Frequency Setting Command
    4 Data Rate Command
    5 Receiver Control Command
    6 Data Filter Command
    7 FIFO and Reset Mode Command
    8 Receiver FIFO Read Command
    9 AFC Command
    10 TX Configuration Control Command
    11 Transmitter Register Write Command
    12 Wake-Up Timer Command
    13 Low Duty-Cycle Command
    14 Low Battery Detector and Microcontroller Clock Divider Command
    15 Status Read Command

    Wbrew powszechnie krążącej opinii, jednak są różnice pomiędzy tymi modułami.
    Co do inicjalizacji, lepiej przepuścić wszystkie komendy i mieć spokój. W razie czego - reset i po kłopocie. Nie ukrywam, że zaciekawiła mnie ta potencjalna zmiana wartości rejestrów modułu podczas resetów µC. Ja się z tym nie spotkałem, no ale "przezorny zawsze ubezpieczony".
  • #643
    excray
    Poziom 40  
    darkonel napisał:
    Nie znalazłem nigdzie działającego kodu w asm (cały Internet przekopałem).

    Jest mnóstwo przykładów w C a na ich podstawie przecież łatwo napisać kod w asm. Albo wręcz przepisać po kompilacji z pliku *.lss
    darkonel napisał:
    Kluczem okazało się połączenie linii nIRQ nadajnika z mikrokontrolerem

    Twój sposób u mnie okazał się bardzo niestabilny więc uważaj. Bardziej niezawodne i prostsze okazało się u mnie sprawdzanie linii MISO(SDO) po wysłaniu paczki:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    darkonel napisał:
    Zastanawia mnie dlaczego przy obsłudze modułu RFM12 przyjęło się, że inicjalizację wykonuje się wszystkimi dostępnymi komendami (a nawet nie opisaną w dokumentacji 0xCC17)?

    Jest opisana w dokumentacji. Tyle że dokumentacja jest niechlujna. Do konfiguracji RFM12 używam ze 3-ch DSów gdzie w każdym jest coś czego nie ma w innych.
  • #644
    darkonel
    Poziom 19  
    excray napisał:
    darkonel napisał:
    Nie znalazłem nigdzie działającego kodu w asm (cały Internet przekopałem).

    Jest mnóstwo przykładów w C a na ich podstawie przecież łatwo napisać kod w asm. Albo wręcz przepisać po kompilacji z pliku *.lss
    darkonel napisał:
    Kluczem okazało się połączenie linii nIRQ nadajnika z mikrokontrolerem

    Twój sposób u mnie okazał się bardzo niestabilny więc uważaj. Bardziej niezawodne i prostsze okazało się u mnie sprawdzanie linii MISO(SDO) po wysłaniu paczki:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    darkonel napisał:
    Zastanawia mnie dlaczego przy obsłudze modułu RFM12 przyjęło się, że inicjalizację wykonuje się wszystkimi dostępnymi komendami (a nawet nie opisaną w dokumentacji 0xCC17)?

    Jest opisana w dokumentacji. Tyle że dokumentacja jest niechlujna. Do konfiguracji RFM12 używam ze 3-ch DSów gdzie w każdym jest coś czego nie ma w innych.



    1. Właśnie tak zrobiłem. Wziąłem w końcu działający kod w C, przeanalizowałem lss-a i doszedłem co powinno być a czego być nie powinno.

    2. Nie napisałem przecież, że zrezygnowałem ze sprawdzania stanu MISO po wysłaniu paczki. Takie działanie to podstawa. Ale (właśnie o to "ale" chodzi) niestety to nie wszystko. Z samym sprawdzaniem MISO u mnie nadajnik jednak nie działał. Podczas przesyłania danych do bufora TX konieczne okazało się sprawdzenie stanu nIRQ (własnie tego dopatrzyłem się po działaniach wg pkt. 1)

    3. Ja korzystałem jedynie z dokumentacji HopeRF. Szkoda, że tak fajne moduły są tak fatalnie opisane.

    No cóż, przynajmniej wzbogaciłem swoje doświadczenie związane z RFM12.
  • #645
    excray
    Poziom 40  
    darkonel napisał:
    Nie napisałem przecież, że zrezygnowałem ze sprawdzania stanu MISO po wysłaniu paczki. Takie działanie to podstawa. Ale (właśnie o to "ale" chodzi) niestety to nie wszystko. Z samym sprawdzaniem MISO u mnie nadajnik jednak nie działał. Podczas przesyłania danych do bufora TX konieczne okazało się sprawdzenie stanu nIRQ

    To dziwne bo u mnie jest zupełnie odwrotnie. Sprawdzanie stanu IRQ działa tylko przez jakiś czas a później z powodu bliżej nieokreślonych przyczyn przestaje a sprawdzanie MISO działa bezbłędnie. Dziwne te układy.
  • #646
    darkonel
    Poziom 19  
    excray napisał:
    darkonel napisał:
    Nie napisałem przecież, że zrezygnowałem ze sprawdzania stanu MISO po wysłaniu paczki. Takie działanie to podstawa. Ale (właśnie o to "ale" chodzi) niestety to nie wszystko. Z samym sprawdzaniem MISO u mnie nadajnik jednak nie działał. Podczas przesyłania danych do bufora TX konieczne okazało się sprawdzenie stanu nIRQ

    To dziwne bo u mnie jest zupełnie odwrotnie. Sprawdzanie stanu IRQ działa tylko przez jakiś czas a później z powodu bliżej nieokreślonych przyczyn przestaje a sprawdzanie MISO działa bezbłędnie. Dziwne te układy.


    Faktycznie, bardzo dziwne te układy. Niestety aby uruchomić coś na nich trzeba mieć dużo cierpliwości.

    Aha, jeszcze mi się coś przypomniało. Otóż podczas sprzętowej obsługi SPI, po zastosowaniu dwóch metod sprawdzania zajętości na raz odbiornik działał. Jednak po przeładowaniu softu już nie działał. Dopiero po kilku dniach kopania co jest nie tak, odkryłem dziwną zależność: Po odłączeniu odbiornika od zasilania i rozładowaniu kondensatora filtrującego zasilanie, układ zaczynał działać. Ponowne przeładowanie softu zatrzymywało działanie odbiornika aż do całkowitego wyzerowania Vcc. W efekcie wstawiłem 3 nopy tuż za procedurą sprzętowej obsługi SPI i jak ręką odjął. Teraz odbiornik działa stabilnie, już chyba tydzień i bez żadnych niespodzianek.
  • #647
    daniel92k
    Poziom 2  
    Witam, jestem szczęśliwym posiadaczem modułu RFM12b i mam pewien problem. Udało mi się uruchomić komunikacje, wszystko śmiga, a problem przestawia się następująco:
    Mikrokontroler, który działa jako nadajnik, musi obsługiwać również wyświetlacz. Niestety zasilanie LCD-5V, a zasilanie RFM12b-3.3V. W tym miejscu pojawia się moje pytanie, czy jeżeli zasilę mikrokontroler z 5V a RFM12b(działający jako nadajnik) z 3.3V to czy dadzą rade się komunikować i nie uszkodzę modułu radiowego? Czy trzeba zastosować coś do tłumaczenia poziomów? Bo na podstawie datasheeta (Link) nie potrafię tego rozszyfrować...

    Mam nadzieje że ktoś też miał podobny problem i pomoże, pozdrawiam.
  • #648
    nanoTECHNO
    Poziom 14  
    Witaj

    Podaj na mikrokontroler również 3.3V. Na wyświetlacz daj 5V. W takiej konfiguracji użytkuje układy już długi czas. Możesz również zasilić LCD z 3.3V ale musisz znaleźć wersje LCD który ma miejsce na przylutowanie 8 nóżkowego układu ICL7660 do wygenerowania ujemnego napięcia kontrastu. Dodatkowo należy dostawić 2 kondensatory smd i 2 oporniki. Wyświetlaczem dającym się tak przerobić jest np. RC1602B-GHW-CSX.
    Pozdrawiam
  • #650
    imagia
    Poziom 10  
    Pytanie laika;

    mowa o RFM12B:
    Mam 50 TX i jest 1 RX, te 50 nadaje w ten sposób że wszystkie wyrabiają się w 1 sek. i cykl się powtarza przy czym muszę odebrać pakiet od każdego "zawsze".
    Zatem czy muszę robić to w kolejności czy mogą zgłaszać się dowolnie.

    gdy ustawimy RX FIFO Buffer - czy dobrze rozumiem że ustawią się w kolejce?
    jeśli tak to jak długa ona może być?

    a jeśli nie to jak byście to rozwiązali :)

    z góry dzięki za odp.
  • #651
    atom1477
    Poziom 43  
    RX FIFO Buffer w żadnym wypadku nie ustawi odebranych danych z kilku modułów w kolejce.
    On owszem kolejkuje ale bajty a nie całe ramki. Choć to jeszcze mało ważne.
    Dużo ważniejsze że te kolejkowane bajty pochodzą z odbiornika. Odbiornik nie jest w stanie odebrać paru danych na raz.
    Musiał by mieć FIFO w sobie i kolejkować już na etapie odbierania.
    A odbiornik w RFM12B jest niestety niezależny od FIFO więc tego nie zrobi.
    To tak jak stół bilardowy i bile.
    Dopóki otwór będzie zwykły a FIFO umieszczone dalej to nie skolejkuje już bil.
    Bo jak jednocześnie strzelisz dwoma bilami to żadna nie wpadnie to otworu (zderzą się przed otworem i obie skręcą). Ewentualnie wpadnie jedna.
    Dopiero otwór musiał by być FIFem sam w sobie (np. być lejkiem) żeby zbierać bile wrzucane na raz.
    I tak samo w RFM12B. Fizycznie możliwość odebrania 2 bajtów na raz nawet by istniała, ale jest bardzo trudna i w sumie nigdy się tak chyba nie robi.
    A już na pewno RFM12B nie ma takiej możliwości.
    Może on odbierać tylko po 1 bajcie na raz (tzn. w danym momencie czasu).
    A FIFO jest dopiero dalej i służy już do czegoś innego niż kolejkowania.
    Bo jedynie do buforowania. Kolejka jest tylko przy okazji bo się po prostu nie da zbuforować bez jednoczesnego skolejkowania.
    Tak więc nie ma wyjścia i musowo nadawać po kolei. A żeby to zrobić to ten RX musiał by po prostu wysyłać zapytania do każdego z TXów.
    Ewentualnie wysłać jedno zapytanie a TXy by odpowiadały każdy w innym czasie od otrzymania tego jednego wspólnego zapytania.
  • #652
    imagia
    Poziom 10  
    atom1477: dzięki za odp.

    Właśnie tego się obawiałem.

    który kolejny na 868 miał by kolejkowanie ramek? ale to i tak chyba by nie załatwiło nakładanie się ramek "idealnych" w czasie.

    a może jest jakiś inny moduł który radzi sobie z taką sytuacją ?
  • #654
    excray
    Poziom 40  
    Albo programowego powtarzania przesyłu w przypadku braku ACK. Albo skorzystać z modułów 2,4GHz które mają takie "powtarzanie do skutku" i ACK w automacie.
  • #655
    atom1477
    Poziom 43  
    Są algorytmy które pozwalają nadawać tak aby każdy z modułów był odbierany. Tzn. ustala się sekwencje nadawania oraz jej szybkość. Oczywiście różną dla każdego nadajnika.
    Ale to zadziała dla kilku nadajników, a nie 50.
    excray: tam nigdzie nie ma sygnału ACK, więc powtarzania nawet nie ma jak zrobić (mądrego powtarzania).
    A powtarzanie nadawania przez każdy z 50 modułów w ciemno to wiadomo do czego doprowadzi :D
    Chyba że coś źle zrozumiałem. Ja to zrozumiałem tak że mimo że są wykorzystywane moduły RFM12B (czyli dwukierunkowe), to są używane tylko jako nadajniki (te 50) a jeden (ten 50-ypierwszy :D) tylko jako odbiornik. Tzn. póki co, bo ja to proponuję oczywiście zmienić.
  • #656
    piotrva
    Moderator na urlopie...
    na RFM12B można zrobić ACK programowo przecież (mimo to np. NRF24L01 mają dużo fajniejsze funkcje wbudowane).
    Ja taką komunikację zrobiłbym na zasadzie:
    1. Master nadaje na adres (czyli programowo definiowany np. bajt identyfikujący urządzenia) broadcast zapytanie, potem przełącza się w nasłuch
    2. Każdy układ ma swój timeslot (czyli np. po broadcast czeka 10ms * numer układu a transmisja trwa np. 5ms) w którym nadaje odpowiedź.
  • #658
    excray
    Poziom 40  
    atom1477 napisał:
    excray: tam nigdzie nie ma sygnału ACK

    piotrva napisał:
    na RFM12B można zrobić ACK programowo przecież
  • #659
    atom1477
    Poziom 43  
    A czy jedno z drugim się wyklucza?
    Dobra, to jak krowie na miedzy:
    Tam nie ma sygnału ACK bo nie jest zrobiony. Niektóre RFMy pracują tylko jako nadajniki a niektóre (no, jeden ostatni w sumie tylko) tylko jako odbiornik. Albo miały tak pracować w pierwotnym zamyśle. Gdzie tam więc jest jakiś sygnał ACK? Nie ma go.
    Co nie znaczy że nie może go tam być jak się zrobi. O to mi chodziło.
  • #660
    excray
    Poziom 40  
    Kolego atom1477 widzę że nie zrozumiałeś mojego posta więc spieszę wyaśnić więc:
    excray napisał:
    Albo programowego powtarzania przesyłu w przypadku braku ACK. Albo skorzystać z modułów 2,4GHz które mają takie "powtarzanie do skutku" i ACK w automacie.

    Proponuję możliwość programowego potwierdzenia i ponowienia nadania w przypadku nie otrzymania potwierdzenia odbioru czyli coś co moduły nRF24L01 lub RFM73 mają wykonane sprzętowo albo właśnie zaopatrzenie się w powyższe moduły.
    atom1477 napisał:
    Tam nie ma sygnału ACK bo nie jest zrobiony

    ACK = acknowledge - tutaj potwierdzenie odbioru