Hello
Most nem foglalkoztam a sebesség-problémával, ugyanis egy újabb hiba jelentkezett.
Eddig csak úgy használtam a modult (8 és 16 bites módban egyaránt), hogy sync-bájtok után csak egy adat-bájtot küldtem, ezután töröltem a FIFO-t a vevőben.
Most viszont távirányítást akarok megvalósítani, ahol is 3 bájtos csomagokat szeretnék használni. Tehát a vevőnek a sync bájtok után 3 bájt hasznos adatot kell vennie (2 bájt a vezérléshez + 1 checksum), ezután törlöm a FIFO-t. Megírtam a programot, de nem működött. PicKit2 logic analyzer-jével rálestem az FFIT lábra menet közben. Kiderült, hogy miután veszi a vevő az első hasznos bájtot, egy idő után automatikusan magasra vált az FFIT láb, és ezt nem a második adat-bájt vétele okozza. Az adót úgy módosítottam, hogy a sync bájtok után csak egy bájt hasznos adatot küldjön, után semmit. A helyzet ugyanaz: miután érkezik egy adat-bájt, utána minden kb. 1,68ms-ban egy rövid időre magasra vált az FFIT láb. Mintha annak az egy bájtnak a hatására valamiféle négyszögjel-generátor kapcsolna be az FFIT lábon - viszont az az egy bájt helyesen megjön. És ugyanez a hiba jelentkezik 8 és 16 bites FIFO módban is - 8 bites módban 2x frekvenciájú ez az impulzussorozat az FFIT lábon, mint 16 bites módban.
Úgy néz ki, hogy akkor muszáj lesz 1 bájtos csomagokat használnom, és minden hasznos bájt után törölni a FIFO-t, mert akkor nincs ilyen probléma.
Üdv.

Még azt hozzá kell tennem, hogy ha a vételi oldalon csak az első vett bájttal foglalkozom, és utána már nem törődök a modullal, akkor az FFIT lábon jön a 2. felfutás és magas szinten is marad az a láb.
Üdv.

Hello
komlosi: itt a demo hex 20MHz-es kristályra.
A St. Register felső bájtja a 0-ás EEPROM címre kerül, az alsó pedig az 1-esre. Futtasd le a programot a PIC-en, majd olvasd vissza az EEPROM tartalmát.
Üdv.

Kedves m.joco!

Letöltöttem, lefuttatam, és 80h és 00h-t olvastam ki az EEPROM-ból, nem tudom ez jó eredmény-e, de már jobban hangzik az én az én 0000h-mtól.
A kvarc csak 4Mhz, de szerintem az nem lehet gond.

Üdv.:
komlosi

kiegészítés:
Azóta futtattam még és akkor pedig C000h-t olvasott ki.

Hello
Lehet, hogy probléma, ha nem 20MHz-es kvarccal járatod, mivel időzítések vannak a programban.
Lefordítottam újra 4MHz-es kvarcra. Nekem azt hiszem a legfelső 3 bit 1-es szokott lenni, meg még talán 1 valahol.
Üdv.

Sziaszok!

Nem tud valaki ccs-ben megírt jól működő forráskódot valahol? Két modulom van, mindkettőn akarok adni és venni is. Egy modellt akarok vele irányítani, laglábbis első körben.

Találtam már a guglival egy halom kódot, de azt is olvastam, hogy egy helytelen konfiggal tönkre lehet tenni a mudulokat, ez igaz?

Helló!

Így 4000hexet olvas ki. Az órajelnek minimuma szerintem nincs, tehát 20Mhz helyett 4Mhz-t használva csak nyúlnak az időzítések és az nem lehet gond. Ennek ellenére most mást vett.

kipróbáltam másik modullal az is u.a.

Üdv.:
Komlósi

Érdekes, hogy mindig mást olvas ki, a 0x4000 azt jelenti, hogy POR flag bit magas, ez rendben is van indulás után első st. register kiolvasáskor. Egyébként hogy próbálod ki? Tápod ráadod, majd kikapcsolod, és simán kiolvastatod a beégetett hex-et?
Ezek után érdemes lenne két kapcsolást összeraknod 1-1 modullal, aztán pl. az adó másodpercenként lesugározna egy csomagot, és ennek hatására a vevő egy LED-et villantana. Ha ezt megcsinálod, akkor az nIRQ láb helyett inkább az FFIT lábat kösd a PIC-re.
Üdv.

Igazából nem mindig. 1x 8000 aztán mindig C000, az új hexel pedig mindig 4000.
Letöltöm, elindítom, aztán rácsatlakozok az ICD-vel debugban és kiolvasom a az EEPROMot. Az EEPROMba írok valamit pl.:AA AA aztán megint elindítom... stb.
Csináltam úgy is hogy elveszem a tápot mielőtt elindítom, de semmin sem változtat.

Nekem nem gond, 2 kapcsolás összeállítása, van 4 modulom meg jó pár PICem. Tudsz adni hozzá demo HEX-t?

A státuszbitek jelentését honnan szedted, én sehol sem találom?

Üdv.: komlosi

Hello
Az itt található adatlap ugyan nem pont ehhez van, de megtalálod benne a St. Register-t.
A legjobb az lenne, ha raknál össze két, teljesen egyforma kapcsolást próbanyákon, úgy értem egyforma legyen a bekötésük. Tegyél mindkettőre 1-1 LED-et. Írd meg hogy mekkora kvarcot használsz, és akkor írok valami egyszerű demo programot, hogy lássuk, működnek-e a modulok
Egyébként ez a debug mód mit takar? Az értem, hogy hibakeresésre van, de ilyenkor "máshogy" fut a PIC?
Üdv.

Helló!

OK!
Elvileg a Debug módban is ugyanúgy fut a program, de bárhol meg lehet állítani, soronként futtatni és egyéb jó dolgok... Hátránya, hogy néhány byteot elvesz a RAMbol, de ez még nekem nem volt gond. Azt hogy lassabban fut-e vagy pont ugyan úgy azt nem tudom biztosra, én nem vettem észre különbséget.

Üdv.

És ami a legfontosabb... debugban ha megállítod a progit, akkor meg lehet nézni a memória és az eeprom tartalmát.

Nem tud valaki ccs-ben megírt jól működő forráskódot valahol RFM12B modulhoz?
Két modulom van, mindkettőn akarok adni és venni is. Egy modellt akarok vele irányítani, lagalábbis első körben.

Találtam már a guglival egy halom kódot, de azt is olvastam, hogy egy helytelen konfiggal tönkre lehet tenni a mudulokat, ez igaz?

Szia! - Sziasztok!

Leszedtem az általad feltöltött forráskódot, és ezzel kapcsolatban egy kérdésem lenne. Mint láttam, neked az egyik main progi csak ad, a másik csak vesz, nekem egyszerre kellene ez a két dolog.

Gyorsan összevágtam a kettőből egy kódot, szerinted vagy bárki szerint ez működőképes? Annyit csinálok, hogy inicializálás után átkapcsolgatom a modult az RFM12BRXMode(); és RFM12BTXMode(); -okkal.

Elegendő ennyi, hogy működjön az adás és vétel, vagy mást is át kell állítani ilyenkor?




Előre is köszönöm a segítséget.

Valaki?

Üdv!

m.joco-nak a "zavar-os" problémájára:

"Ennél gyengébb minőségű ISM sávú szeméttel nem hiszem, hogy bárki ...olna."

Imi.

Sziasztok!

Hogy tudom kiolvasni a konfigurációt? Elvileg ha 0x00-t küldök, akkor vissza kellene kapnom, de nem jön vissza semmi. Igazából az a bajom, hogy a vett adatot sem tudom kiolvasni, ezért próbálkozok a konfiguráció kiolvasásával. A beírás megy, mert mert a konfignak megfelelően 868,062 MHz-en hallom, ahogy jönnek a csomagok, amiket 1mp-ként küldök.

Van valakinek ötlete? Vagy működő kódja atmega8-ra?

Hello
Ők nem pont ilyen modult használnak, de ettől függetlenül valószínűleg nekem is modul beállításai vesznek el.
Üdv.

Hello!

Egy küldönös problémám lenne.
Végigolvastam a fódumot, kipróbáltam jópárat az általatok összeírt módosításokból, de semmi változás.

Annyit csinálok, hogy végtelen ciklusban 1mp-enként 1db hasznos bájtot küldök a vevőnek.
Eddig jól is működik, a vevő vesz valami és az a valami az, amit küldtem.

A baj ott, van, ha az adó résznek, ill. a vevő résznek, nem egyszerre adom rá a +-t és GND-t (vagyis nem a tápcsatit húzom ki le, hanem csak a + ill. a - kábelt)(-teljesen külön tápforrások-), akkor az esetek nagy részében nem kapom meg a vevő részen az adatot. Néha sikerül elkapnia a fonalat és rendesen a küldött adat érkezik meg, amit kivillog egy LEDen, máskor meg semmi nem történik, nem villog semmit.

Egyik modul elemről megy (3,6V), másik meg adapter és utána LM317-ről (3,6V). Próbáltam még nagy kondival simítani a tápfeszen, de semmi változás akkor sem.
Nekem már nincs nagyon ötletem, ezért kérném a tanácsotokat...

Szia!
Szerintem az RFM12B-nél nem lehet a konfigurációt visszaolvasni. Ha az RFM12B SPI-on kapott információban az első bit "0" akkor azt Status Read Command-nak fogja venni függetlenül attól, hogy a további bitek (1-15-ig) milyen értéket vesznek fel.
Vagyis ha te 0x00-át küldesz, akkor azt Status Read-nek veszi, illetve szerintem csak venné, ugyanis ebben az esetben is 16bitet kell küldeni, majd a ChipSelect-et magasra állítani.
Javaslatom az lenne, hogy próbáld venni a Status Read-re kapott választ, úgy hogy 0x0000-át küldesz ki, s egyszer úgy programozod a modult, hogy a Low Battery Detect (LBD) 0XC0xx paranccsal beállítasz egy kisebb értéket mint a tápfeszültséged, ekkor a Read Status 6. bitje (ha 1-ről kezdünk számolni) magasra kell, hogy váltson.
Majd beprogramozod a modult úgy, hogy a LBD nagyobb legyen mint a táp, s ekkor 0-ra vissza kell állnia a 6. bitnek a Status Read parancsra adott válaszban.

Hello!
Ez valóban érdekes probléma, én is csináltam ilyet de nem tapasztaltam hasonló dolgot.
Esetleg az inicializálással lehet probléma, elképzelhető, hogy amikor csak egyik tápvezeték van lehúzva, s vissza akarod csatlakoztatni egyszer hozzáér egy pillanatra majd újra elválik stb. ez esetleg megzavarhatja az inicializálást.
Iktass be a programkód elejébe (RF modul inicializálása elé) egy várakozást, első lépésként lehet drasztikus is, mondjuk 1 másodperc, így biztosra mehetsz, hogy az RF modul inicializálása közben már stabil a tápfesz.

Hi!
Kérem szépen a neved, lakcímed, tajszámod, hogy postázhassam a Nobel díjat.

Szerintem pont fején találtad a szöget. A portirányok megadása után, közvetlenül az RF init elé raktam egy 2 másodperces várakozást, és így az eddigi rövid tesztek alapján teljesen megoldódott a probléma.

Mégegyszer ezer köszönet a válaszért...
Üdv: Zolorb

Bocsánat, nem konfigurációt, hanem státuszt akartam írni. Szóval az a bajom, hogy ha elküldök 0x0000-t, akkor arra 0x0000 azaz semmi nem jön vissza. Átnéztem már a kapcsolást, ha modul nélkül kézzel magasba húzom a kontroller miso lábát akkor beolvassa a 0xffff értéket.

Aham, ok.
Egyébként a nulla érték statusra nem biztos, hogy rossz, mert ha pl rosszul van a vétel illetve az adás beállítva (s mivel még nem tudtál venni semmit, ha jól értettem ezért nem biztos, hogy valamelyik is jó, annyi biztos csak, hogy az adó ad egy frekin) és egyéb esemény sem történt a modullal, pl POR, EXR, LBD stb akkor teljesen jó a nullás válasz.
Ezért lenne jó ha kipróbálnád amit írtam, hogy megpróbálod az LBD-t beállítani, ehhez nem kell semmi extra, csak a modulnak meg kell adni a 0xC0yy paranccsal egy LBD limitet ami alacsonyabb az aktuális tápfesznél.
Ha tudod venni az LBD-t akkor a status kiolvasásával minden rendben, viszont ha nem akkor valami a kommunikációval lehet, pl időzítések.

A legkisebb beállítható LBD érték 3,75V, de nem tudok ilyen alacsony feszültséget adni rá, mert a kontrollernek minimum 4,5V kell. Kipróbáltam, hogy adás közben olvasom ki a státuszt ( elvileg a RGIT-nek 1-ben kellene lenni, mert ez jelzi, hogy mehet a következő byte), de ugyanúgy 0x0000. Időzítések elvileg jók, hardveres SPI-t használok, 1MHz órajellel. Még az lehet, hogy a kontroller felprogramozásakor volt amikor rajta felejtettem a modult és arra gyanakszok, hogy a modul SDO lábát megöltem

Valóban, a legnagyobb szint a 3,7V.
Azt ugye tudod, hogy a modul működési feszültségi tartománya 2,2 - 3,8V-ig. Nem tudom mennyire jó ha olyan magas feszültséggel járatod, az absolut maximum igaz, hogy 6V, de ez csak azt jelenti, hogy ha véletlen rákapcsolsz 6V-ot nem fog azonnal tönkremenni. Na de ettől még működnie kellene (ha jó még a modul ).
Viszont amit érdemes lenne kipróbálni, hogy lejjebb viszed az SPI sebességet, én is próbáltam 1MHz-el, s nem ment, most 200kHz-re van állítva s ezzel nincs problémám.

Hello
A működési tartomány azt jelenti, hogy abban a tartományban működik a modul. 5V-ról nem fog működni a modul, de nem is fog tönkremenni. Használj 3,3V-os feszstabot a modulhoz, és szintillesztőt a kommunikációhoz.
Üdv.

IA4420-al szerelt modulom van, az 5V-os. Az adatlapban "5-10MHz (recomended)" olvasható, abból gondoltam, hogy az 1MHz nem lesz sok, de kipróbálom 200kHz-el, ez az utolsó reményem.

Hello
Honnan tudod, hogy IA4420-al szerelt modulod van?
Én azt hittem, hogy az RFM12B-t egyfajta IC-vel szerelik.
Üdv.