Szia!
Az adó-vevő adatlapjának 18. oldalán van az ábra, hogy miként kell felépíteni az adatforgalmat. De szerintem kevésbé szívatnád meg magad, ha olyan adó-vevőt választanál ami SPI interfészt használ a kommunikációhoz. Az pofon egyszerű az általad választott PIC-ben is van SPI modul.

Szia!
Ha még nem vetted meg, akkor javasolnék olyan adó vevőt, ahol nem kell saját kódolást kiagyalni, csak betolni az adatot , ráadásul a vevő inteligens és csak akkor kezdi venni az adatot, amikor neki szól.
Esetleg nézz be az RFM12bs topicba. ( Ez a modul adó és vevő is egyben)
Assembly programozásban az adott modulhoz tudok segítséget adni.
üdv.: Foxi

Szia!
Azért tetszett meg ez az adó-vevő pár, mert mindenképpen a PIC12F1840-el szeretném a rendszert felépíteni, és az adatlap szerint ez az egység csak egy lábat használ. Nem mellékesen nagyon olcsó. Ami nem stimmel nekem, hogy az ábrán jelzett PIC adatlapja szerint ahová kötve van az nem kommunikációs láb. Valamint az sem tiszta, hogy ha ennyi kell a rádióhoz, akkor minek bele SDA, meg CLK.

Ha elolvasod az adatlapot, vagy legalább a 11. oldalt, akkor kiderül, hogy az SDA és CLK lábak az RF modul programozásához kell. Ezt pedig csak akkor kell használni, ha a default beállításoktól eltérőt szeretnél beállítani (12-13. oldal).

Valóban csak 1 lábat használ a kommunikációhoz. Az órajelet a modul saját kvarca adja, ami ha jól látom 26 MHz-es. Ehhez kell igazítanod az adatküldést. Pl. egy soft resetet úgy kell csinálni, hogy 16 órajel ciklus alatt kell kiadnod a 0xBD01 értéket azon az egy lábon.

Ne haragudj a tudatlan kérdéseimért, de adó-vevő terén leragadtam azon primitív szerkezeteknél, ahol addig van jel a vevő kimenetén, amíg az adón nyomom a gombot. Igazából ennél is úgy képzeltem el, hogy a PIC kiad magából valami azonosítót, azután azokat az információkat, amiket továbbítani szeretnék, a vevö ezt adja a másik PIC- nek, az meg a programom azerint feldolgozza. Vagy ez nem ilyen egyszerű?

Szia!
Hát sajnos nem egyszerű. A vevő állandóan vesz valamit, ha mást nem zavarjeleket. nézzük az átküldendő adatokat. Egy szám 8 bitből áll, azonban a vevő nem birkózik meg az adattal, ha egymás után több 0 bit van. Ezért az átküldendő adatokat kódolni kell. Elég elterjedt a manchester kódolás.(Lásd Wikipédia) .Aztán amikor az adó adni kezd, nem biztos, hogy mindjárt veszi az első bitet is,tehát kéne valamilyen szinkronizáló jel ,majd az adathalmaz, a végén egy ellenörző összeget is ki kell adni. A vevő veszi az adatokat, előállítja a saját ellenörző összegét és a legvégén összehasonítja a vett ellenőrző összeggel. Ha stimmelnek, az adat felhasználható, egyébként el kell dobni.
kb. ezt kell leprogramoznod.
üdv.: Foxi

Szia!

Ez így tényleg eléggé macerás. Főleg, hogy vezetékesen már próbáltam egy vezetéken adatot küldeni, de valamiért sehogy sem került szinkronba a két PIC órajele.
A kódolás ezen segítene?

Nem, a kodolas abban segit, hogy eldonthesd, a jo adat ment-e at, amit te szerettel volna.
Miert kell egy vezetek? Soros vonali kuldes nem jo? Mindket PIC TX es RX vonalakkal rendelkezik, ezeket osszekotve hardware-bol megy, ha a soros beallitasok jok.

Ha oda-vissza akarsz kommunikalni 1 vezeteken, akkor a 1-Wire technologianak kellene utananezned, pl. a DS1821 homero igy mukodik. Ez egy hosszu impulzust hasznal szinkronizalasra es idoalapu a kodolasa.

Csak egyirányba akarok adatot küldeni, mindössze néhány byte-ot, és rádióval.

A Manchester kódolás lényege, hogy az adat és a szinkronizáló információ egy jelben továbbítható. Mágneses adattárolásra fejlesztetté ki. Szalaghoz, dobhoz, lemezhez, stb, ahol csak egy fej áll rendelkezésre.

Ezt még úgy-ahogy értem. A kód létrehozásában sem látok problémát. Csak arról nincs elképzelésem, miként fogadjam és felytsem vissza.

Szia!
Nos ha assembly programozás, akkor egy bit kivitele:
Az adatlap szerint 0.1 -40kbps sebesség lehetséges. Legyen hasra 9.6k 1/9,6*1024= 0,101ms azaz kb 100us egy bit ideje. ezt osszuk négy felé =50us . A 0 bit felépítése 150us magas és 50us alacsony az 1 bit 50us magas és 150us alacsony szint. Ezzel a megoldással már ki lehet küldeni a biteket.
Adás megkezdésekor kiküldesz 3db 0x55 számot, ezután egy 0xAA t azután az adatokat, és végül az ellenörző számot.
A vétel:
Megérkezik egy bit , ha ez 1 akkor várunk a 0 bitre. 0 bitnél elkezdjük körbeforgatni a vevőpuffert, minden beérkező bitnél forgatunk egyet rajta és megvizsgáljuk, hogy a puffer értéke 0xAA lett-e ha nem forgatunk tovább. Ha 0xAA akkor a szinkron megvan utána jönnek az adatok stb....
Bár én ilyet sosem használtam, valami ilyesmit készítenék.

kimaradt, hogy minden második beérkező bit után vizsgálunk 0xAA -ra.

Vételkor az adatláb felfutó élére megszakítás generálódik, és 100us múlva ott van a bit ami vagy 0 vagy 1.
A továbbiakban is szinkronizálhat a bejövő jel,vagy kvarc esetén pontos időzítés néhány byte átvitele esetén.

Én most azzal kezdtem el kisérletezni, hogy először kiadok egy magas jelszintet 1ms hosszan. Utána 0,5ms szünet. Majd 0,2ms magas, 0,5ms szünet. Ezt a vevőoldal úgy értelmezi, hogy az első jel kivált egy megszakítást. A megszakításon belűl egy számláló beméri az első jel hosszát. Ez az érték lessz a sablon a magas jelszinthez. Az ezután beérkező jel már adat. Minden beérkező jelet a sablonhoz hasonlít. Az ennek a jelnek a 2/3-át meghaladó jelet 1-nek fogadja el, ami ennél rövidebb, az a 0. Így elvileg nem zavar be az esetleges órajel eltérés.
Mi a véleményed?

Feltaláltam a tyúksz**ban az ütőeret. Gyakorlatilag amivel elketdtem kisérletezni, az a bbalazs álltal javasolt 1-Wire technológia. Miután utánaolvastam, és aszerint állítottam be az időzítéseket, sikerrel küldtem át adatot. Most még egy dologgal vagyok megakadva.
Bár az adat (jelen esetben mindössze 1 byte) 300qsec alatt átmegy, a frissítési gyakoriságot nem bírom 30Hz fölé emelni. Az fölött egyszerűen nem megy át adat. De már az első sem.
Mit rontok el?

300qsec? Gondolom az 300usec lenne.
Forráskód nélkül nehéz bármit is segíteni.

Milyen PIC-et, mekkora frekvenciaval hajtasz?
Probaltal-e PLL-el orajelet emelni? Be van-e kapcsolva valamilyen elooszto a szamlalokhoz, timerekhez?

Szia!

PIC18F14K22 4MHz órajelen. Időközben találtam egy hibát, Timer0 8 bites üzemmód helyett 16 bitesen van. Kijavítom, meg nézem, úgy mit csinál, utána feltöltöm a programrészleteket.

Na most fejelem meg a falat!
Végre minden jónak tűnik. Gyors, pontos átvitel, 2 másodpercig, utána a vevő elektronika lefagy. De legalábbis az LCD-ről eltűnik minden.
Jelenleg a tesztáramkör áll adóoldalon egy potiból, egy PIC-ből, és egy ledes 3 karakteres kijelzőből, ami a poti értékét mutatja. Ezt az értéket küldöm át. Vevőoldalon meg egy PIC és egy 2x16 LCD van. Egy darab 3 számjegyű számot jelenít meg.
Ez lenne az adásért feleős program:


Ez pedig a vételé:
Timer0 beállítása 8 bit 1:2 előosztó
Timer1 beállítása 8 bit 1:1 előosztó

A vevő rutinban a 3 és főképen a 35. sor okozhatja a hibát. A kontroller maga (hardware) tiltja a megszakítást, ha már egyet elfogadott. A 35. sor azt okozhatja, hogy a visszatérési cím rajta marad a stack -en. A 8 szintű stack elég hamar betelhet.

Szia!
Bár azt nem tudom, mi az a "stack", de abban teljesen biztos vagyok, hogy igazad van!
Ugyanis megszüntettem a megszakítást, a program egy pontjárol ugrok el adatot lekérni.
Ott előszőr várok a szinkronjelre, majd ha az megvan, fogadom az adatot. Plussz megfejeltem az egészet egy WDT-vel, hogy ha nem jön jel, kerüljön a cucc alaphelyzetbe. Erre vonatkozna a következő kérdésem:
A túl gyakori reset, amit a WDT válthat ki, ha nem jön adás, nem árt a PIC-nek?
Amúgy így néz ki a módosítás. Most jó minden.

A stack tárolja a visszatérési címeket. Annak az utasításnak a címét, amit a call -lal hívott ill. a megszakítás kiszolgáló rutin lefutása után végre kell hajtani.

Köszönöm az infót!
Most már csak a másik kérdésemre szeretnék választ kapni, a reszettel kapcsolatban.

A sok reset (watchdog, brown-out és egyéb) nem árt a kontrollernek. Ha valamilyen értéket a belső EEPRom -jába elment, akkor kell az írhatósági számra figyelni.

Nagyon köszönöm mindenkinek a segítsséget!

A 18F-esekben mar joval nagyobb a verem. Akkor lehet gond, ha rekurzio tortenik.
A megszakitasban nem szabad annyit varni (sot, egyaltalan nem szabad varni), hanem amilyen gyorsan csak lehet, visszaadni a vezerlest a foprogramnak.
A 18-as csalad K sorozatanal figyelni kell a regiszterekre, mert van, amelyik kimaszik a tartomanybol ezert assemblyben a BSR-t allitani kell hozza, utana meg vissza a tobbihez.

Nem az a lényeg, hogy mekkora a verem, hanem az, hogy a kontroller áramkörei (HW) gondoskodnak arról, hogy ne fogadjanak el egy (ugyanolyan szintű) megszakítást. aminek a kiszolgálása épen zajlik. (Magasabb szintűt elfogadhatják.) Minden mikroprocesszorban gondot okoz, hogy a megszakításból való visszatérés alatt se fogadjon el kérést, de különböző gyártók és típusok más-más megoldást valósítanak meg. Van ahol a megszakítás engedélyezése 1 utasítást (a rutin végén levő return) késleltetik (I8080), van ahol a hardware végzi a sátus szó visszaállítását (benne van a megszakítás engedélyező bit) és van ahol külön utasítás van rá. (Z80: reti, retn, PIC: retfie). Bízzuk a kontrollerre a tiltást.

Az rendben van, hogy nem fogadnak el, de azonnal utana viszont lehet, igy ha a megszakitas hosszan vacakol es kozben beut a kovetkezo megszakitas, akkor a foprogi nem kap idot.
Ezert javasoltam reszben az orajel emelest, a kod ismerete nelkul.