szymanskim - na wszystkich modułach ustawiasz ten sam adres (adres rury odbiorczej - losie jak to brzmi ), twoim zadaniem jest implementacja programowej adresacji - czyli jak odpytujesz poszczególne czujniki (moduły pomiarowe) to określasz jego wirtualny adres w zapytaniu np. AT+TEMP?,MODUL_A. Takowe zapytanie trafia do WSZYSTKICH TWOICH MODUŁÓW (tzw. broadcast) i teraz musisz oprogramować odpowiednio moduł pomiarowy tj. w momencie odebrania zapytania z koncentratora moduł bada czy zapytanie go dotyczy, jeśli tak robi pomiar, wysyła dane do koncentratora i idzie lulu, jeśli nie wtedy nie robi nic (wiadomo on się obudzi) i idzie spać dalej też. I tutaj są ważne przerwania, ponieważ przerwanie odbierasz na jakimś wejściu INT i w nim wybudzasz układ na czas odbioru ramki i ewentualnego pomiaru i usypiasz po jego wykonaniu lub zignorowaniu zapytania.

Tylko że taka komunikacja to jest że tak to nazwe "pull" - to znaczy że koncentrator odpytuje czujniki = czujnik musi nasłuchiwać. Wydaje mi się że będzie prościej w moim przypadku jak koncentrator będzie nasłuchiwał a czujniki będą wysyłały dane jak się wybudzą przez Watchdoga (bo na nim mam licznik). W takiej konfiguracji czujnik właściwie przez większość czasu będzie w głębokim śnie tak samo radio.
Chyba że takie rozwiązanie z jakiś powodów nie jest rekomendowane przy NRF?

Swoją drogą na razie walcze, żeby AVR z modułem NRF dogadał się z NRFem podłączonym do Arduino.. skonfigurowanie dwóch układów (używających dwóch bibliotek) to zadanie ponad moje siły Coraz bardziej jestem przekonany, że dużo łatwiejsze będzie podpięcie do Arduino układu z AVR+NRF tak żeby to co przyjdzie na NRF było wystawione do Arduino po UART.

szymanskim - moim zdaniem odpytywanie jest o tyle bezpieczne że masz gwarancję (o ile zrobisz poprawną programową adresację modułów) że w danym momencie tylko jeden moduł się będzie odzywać. Ja też z początku przyjąłem taktykę że moduł wysłał dane pomiarowe do punktu zbiorczego, ale wtedy trzeba zrobić korytarz czasowy w którym tylko i wyłącznie jeden moduł będzie się odzywał, czyli robić odpowiednie synchronizacje wysyłki danych z modułów itd. Dlatego uważam że odpytywanie modułów pomiarowych jest wygodniejszym i bezpieczniejszym rozwiązaniem.

Tak to się zgadzam z tymi potencjalnymi kolizjami. Tyle że jak pisałem wysyłka z czujnika u mnie będzie minimalnie raz na 15min czyli przy wysylce która trwa maksymalnie 100ms (jak dobrze licze, bo nie wiem czy kolizja wystąpi na etapie initializacji mknrf_init układu czy dopiero przy mknrf_puts) to szansa na kolizje przy dwóch czujnikach to jest 1/9000 (czyli statystycznie raz na około 90 dni). Nawet jeśli się zdarzy kolizka to w najgorszym przypadku nie będzie jednego odczytu co nie jest dla mnie problemem. Jako że w układach używam wewnętrzny kwarc tak więc mam gwarancję że nawet jak wystąpi raz kolizcja to układy nie będą długo zsynchronizowane.
Zerknąłem na prądy przy różnych trybach i przy standby-I i standby-II są odpowiednio 26uA i 300uA ale przy obu jak mi się wydaje nie można nic odbierać a przy zwykłym odbiorze jest około 13mA i to w moim układzie jest niedopuszczalne.

------------------------ [ Dodano po: 24 minutach ]

Wracając do:
>szymanskim - na wszystkich modułach ustawiasz ten sam adres (adres rury odbiorczej - losie jak to brzmi ), twoim zadaniem jest implementacja programowej adresacji

Jak to się ma do pipów? Z filmów zrozumiałem, że pipe pozwolą tworzyć "wirtualne" kanały w obrębie jednego układu NRF. Czyli np. mamy 3 czujniki podłączone do jednego AVR gdzie AVR jest podłączony do NRF i każdy czujnik jest podpięty do oddzielnego pipe i wtedy mamy możliwość jakby adresowania czujników. Czy chodzi o coś innego?

Z innej beczki. Próbował ktoś uruchomić bibliotekę na Atmedze8? Wczoraj robiłem pierwsze testy i o ile na medze32 wszystko ładnie ruszyło to 8 jakaś oporna

_________________
sig off ;(

Jak ja "uwielbiam" takie pytania ... no po prostu przesada, że aż strach (bez urazy) ....

Pytanie z serii do JASNOWIDZÓW zawodowych z uprawnieniami do 20 KV niebiańskiego napięcia ...

Panie, pranie - no proszę na litość niebiańską - jak już coś piszesz to napisz choć odrobinę więcej czyli:

- co ci rzekomo nie idzie ?
- na czym wg ciebie polega oporność atmegi8 ?
- masz jakieś błędy kompilacji?
- pokazałeś jakiś zrzut ekranu ?
- sprawdziłeś numery i nazwy pinów, przerwań - ew timery sprzętowe w main.c ... (zajrzałeś do noty PDF żeby porównać np czym różni się Timer0 w m8 w stosunku do Timer0 w m32 ? który to użyty jest zresztą nie w bibliotece tylko w programie przykładowym w main.c ???

żeby można było ci cokolwiek pomóc i podpowiedzieć gdzie robisz albo okrutnego albo okrutne BABOLE ?

Na prawdę - specjalnie pokazałem przykłady na kilku różnych prockach - żeby udowodnić, że da się bibliotekę odpalić na DOWOLNYM procku AVR - podkreślam DOWOLNYM ...

Więc na przyszłość - proszę, że szanować czas innych i samemu nieco bardziej się przyłożyć do zadawania pytań na forum ...

I proszę mi tu zaraz nie pisać, że się wkurzyłem, zeźliłem że nie wiadomo co ... po prostu na spokojnie wyjaśniam - jak należy podchodzić do zdroworozsądkowego zadawania pytań na forum - jeśli się oczekuje porządnej odpowiedzi i ew rozwiązania swojego problemu - a nie używać "trybu dla jasnowidzów" ok ?

_________________
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 ]

Nie oczekiwałem odpowiedzi od jasnowidza, liczyłem raczej na krótką odpowiedź czy idzie i na co ewentualnie zwrócić uwagę, żeby nie marnować swojego czasu na szukanie błędu tam gdzie go nie ma. Baaa... nie prosiłem nawet o pomoc w rozwiązaniu problemu, zadałem tylko pytanie w poście, gdzie przewija się kilka wątków. Jeżeli uznam, że poświęciłem już zbyt dużo czasu a komunikacja nadal nie działa wtedy założę nowy wątek, opiszę problem, przedstawię schemat i dopiero wtedy będę liczył na pomoc.

Pozdrawiam

_________________
sig off ;(

No widzisz - więc jako jasnowidz, napisałem na co zwrócić uwagę bo na każdym procku AVR da radę to zrobić

_________________
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 ]

Ciągle walcze z dziwnym problemem, który objawia się gdy używam bibloteki (a bardziej ogólnie NRF).
Mam układ na płytce prototypowej oparty o Atmega 328p + moduł NRF. Sam program to okrojony testowy program dołączony do biloteki NRF antelowskiej. Działanie sprowadza się od odbioru komunikatu i wyświetleniu go na ekranie

w petli głównej mam właściwie to (do tego jeszcze :


a w funkcji odbierającej:


Jednym słowiem wiele się nie dzieje. Generalnie program działa ale np. po jakiś 24-48h (w tym czasie odbiera godzinach (w tym czasie odbiera z 20tyś pakietów) układ przestaje odbierać. Sprawdzałem i pętla główna działa a po prostu już nie wchodzi do przerywania czyli nic nie jest odbierane.
Co ciekawe jeśli użyłem WatchDoga i restartowałem procek to układ dalej nie odbierał natomiast jak fizycznie wyłączyłem i właczyłem zasilanie ukłąd zaczyna odbierać
Co trochę sugeruje jakby sam NRF się zawiesił a nie procek (możliwe, że to wynika z zakłóceń które występują na płytce prototypowej)- pytanie jaka jest metoda zresetowania NRF (oprocz odłączenia go od zasilania za pomocą tranzystora) ?

Przeprowadziłem, jeszcze testy i wygląda, że w sytuacji jak układ przestaje odbierać nie zawsze odłaczenie/przyłączenie NRF do zasilania pomaga. No jest to dziwne, czekam jeszcze na PCB - tam się okaże czy jest to problem związany z płytką prototypową czy czegoś innego.

Wrócę jeszcze do pytania szymanskim.
A czy jako selektora odbiorników nie można by użyć kanałów?
Po prostu każdy nadajnik nadaje na swoim kanale a w odbiorniku odpowiednim czasie funkcją
mknrf_set_channel( x ); ustawiamy z którego nadajnika chcemy dane czytać.

Witam. Zacząłem testować bibliotekę i napotkałem na pewien problem, a mianowicie:
w pliku mk_spi.h po ustawieniu SEND_ONLY na wartość 1 nie da się skompilować programu.

W bibliotece mk_spi masz funkcję spi_xmit_buf()

zabrakło tam dyrektywy kompilacji warunkowej, więc dodaj ją tak jak jest poniżej:

_________________
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 ]

Po dopisaniu tej dyrektywy warunkowej powstają kolejne błędy podczas kompilacji.

No to nie obraź się ale przy takim opisie problemu i błędów które ci się pokazują - a ich nie pokażesz - to raczej zwróć się o pomoc do jasnowidza. Albo opisz dokładnie o jakie błędy chodzi

_________________
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 ]

Nie mam się o co obrażać. Pomyślałem, że mając Pańską bibliotekę podam tylko informację o błędzie, a Pan spróbuje u siebie ją skompilować i będzie wiadomo o co mi chodzi. Jedyne co ustawiam to: USE_SOFT_SPI 1, oraz SEND_ONLY 1 po czym zaczynają się błędy kompilacji. Po dopisaniu dyrektywy warunkowej #if SEND_ONLY == 0 w miejscu przez Pana wskazanym powstaje kolejny błąd, a mianowicie w bibliotece mk_spi.c brakuje funkcji void spi_xmit_byte( uint8_t byte ), ( jest tylko w pliku nagłówkowym mk_spi.h ) bo jest tylko uint8_t spi_xmit_byte( uint8_t byte ). Po dopisaniu tej funkcji z dyrektywą #if SEND_ONLY == 0 w bibliotece mk_spi.c już nie powstają błedy. Nadal nie można skompilować projektu bo biblioteka mkNRF.c nie jest przygotowana do takich ustawień. Zacząłem zmieniać funkcje takie jak uint8_t mknrf_read_reg( uint8_t reg ) na void mknrf_read_reg( uint8_t reg ) i inne (wiem, że funkcje takie jak mknrf_read_reg muszą zwracać wynik, ale do celów testowych specjalnie je tak zamieniłem, by była możliwa kompilacja tylko w trybie nadawczym) po czym kompilacja się udała, ale nadajnik już nie wysyła danych.

No to panie kochany - wyjaśnij mi po co ty chcesz używać SEND_ONLY dla biblioteki NRF ??? przepraszam cię ale to tak jakbyś chciał jechać z miasta A do miasta B, tylko odkręciłbyś sobie koła a później dziwił się, że auto nie jedzie i nie możesz dojechać.

Przecież akurat zastosowanie SPI na potrzeby komunikacji NRF ... czy tego chcesz czy nie, MUSI również odbierać dane a nie tylko wysyłać. Jak ty sobie wyobrażasz komunikację procka z modułem NRF bez odczytu danych z niego? To nonsens .... I dlatego masz kupę błędów gdy włączas SEND_ONLY dla SPI, bo bibliotece koła zabierasz

_________________
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 sobie teraz pomyślałem, spoglądając po czasie - jeszcze raz na ten twój opis .... a może ty sobie pomyślałeś że to SEND_ONLY w bibliotece SPI dotyczy NRF'ów? (najgorsze jest to domyślanie się) ... Ale jeśli tak pomyślałeś to mam nadzieję, że widzisz teraz że to jest BŁĄD .... bo ustawienia w bibliotece SPI dotyczą tylko i wyłącznie działania procka w zakresie magistrali SPI i nie mają nic a nic wspólnego z NRF'ami

_________________
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 ]

Panie Mirku dzięki za wyrozumiałość i cierpliwość. Chcę zbudować pilot w oparciu o nadajnik NRF oraz ATtiny45. Dodatkowo potrzebuję jeden wolny pin z ATtiny, a NRF wymaga ich aż 5 bez IRQ. Początkowo myślałem o zrezygnowaniu ze sterowania pinem CSN w module NRF (w niebieskiej książce jest o tym napisane, jeżeli na magistrali SPI jest tylko jedno urządzenie Slave nie trzeba używać pinu CS - w tym wypadku CSN) , ale nie mogę go na stałe podłączyć do masy bo wtedy nie działa moduł NRF. Jestem początkujący i nie znam się na NRF pomyślałem o alternatywie SEND_ONLY 1 uwalniającej MISO i z tond te jak już wiem błędne pytania. Ciekaw jestem jeszcze czemu ten pin CSN nie może być na stałe podpięty do masy.

Bo pin CSN nie jest odpowiednikiem CS ... jak już to można by uznać, że tę rolę pełni pin CE w module NRF, ale po pierwsze aktywny stan to wysoki jak chodzi o nadawanie i z punktu widzenia prawidłowego działania NRF musi być "po drodze" zmieniany jego stan. A więc zapomnij o tym, żeby się go pozbyć poprzez podłączenie do GND czy VCC.

_________________
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 ]

Serdecznie dziękuję za informację .

Biblioteka w wersji do testów(wysyłanie "LED ON" i "LED OFF") działa, lecz chcąc zbudować najprostszy pilot wysyłający tekst "LED TOG" już nie działa prawidłowo.
Do testów wysyłam na UARTA komendy odebrane z NRF i okazuje się, że tekst LED TOG zostaje odebrany tylko raz.
Dołożyłem kolejny przycisk w pilocie wysyłający tekst "TEST" i okazało się, że kiedy kolejny tekst wysyłany przez pilot jest inny od poprzedniego to odbiornik je odczytuje. Dlaczego tak się dzieje, że odbiornik nie reaguje na odbieranie tych samych tekstów?

bo źle piszesz program to oczywiste

_________________
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 ]

Ok. Rozwiązanie jest takie: naciśnięcie klawisza wysyła dwa teksty. Najpierw przykładowo "TEST", a następnie "LED_TOG" i tak teraz już to działa w odbiorniku. Z kolejnego nadajnika wysyłam temperaturę to już "TEST" nie musi być bo po co odbierać wciąż tą samą temperaturę (przykładowo "TEMP=0,23,6" ) jak można odświeżyć zawartość na wyświetlaczu dopiero po jej zmianie. Skoro odbiornik nie odbiera tych samych tekstów, to w przypadku odbierania temperatury powstały wcześniej problem jest zaletą.

Jednak jest coś w bibliotece panie Mirku. Cały czas testowałem pilot przy ustawionym USE_SOFT_SPI na 1 oraz USE_NRF_IRQ na 0.
Kiedy USE_NRF_IRQ ustawiłem na 1 w nadajniku, to mogę wysyłać już za każdym razem ten sam tekst "LED_TOG".
Ciekawe jest też to, że przy USE_NRF_IRQ ustawionym na 0 aby wysłać kolejny tekst trzeba zresetować nadajnik.
Eksperymentując dodałem przed każdym wysłaniem tekstu kolejną inicjalizację - mknrf_init( PSTR("ATNEL") ); - co spowodowało, że układ zaczął działać bez zarzutów. Zastanawiam się jednak co zmienić w bibliotece, by przy USE_NRF_IRQ ustawionym na 0 nie trzeba było przed każdym wysłaniem tekstu inicjalizować moduł NRF.

Nie mam tej biblioteki pod ręką ale pewnie musisz sprawdzać w pollingu czy coś przyszło, odebrać to i ew. wyczyścić bufor odbiorczy?

Może najpierw pokaż co ty w swoim kodzie wyprawiasz - a później pisz, że coś nie tak z biblioteką

_________________
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 ]

Żadnych drastycznych zmian od oryginalnego kodu.
Kiedy w nadajniku ustawię #define USE_SOFT_SPI 1, a #define USE_NRF_IRQ 1 - to odbieranie komendy "LED TOG" działa
Kiedy w nadajniku ustawię #define USE_SOFT_SPI 1, a #define USE_NRF_IRQ 0 - to odbieranie komendy "LED TOG" już nie działa (tylko jednorazowo zadziała)

sprawdzę jutro w firmie

_________________
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 ]

I jak Panie Mirku, sprawdzał Pan te ustawienia #define USE_SOFT_SPI 1, a #define USE_NRF_IRQ 0 ?