Nem segít a bádogtető lejtésének emelése, ha jó nagy lyuk van rajta. Ígyis-úgyis beesik az eső.
Még egyszer: Nem a sebességet, nem a program hosszát, stb kifogásoltam, hanem azt a rossz beidegzódést, hogy a GIE (ill. a GIEH, GIEL) biteket a megszakítási rutinban állítgatjuk. Mindenképen hibát okoz, főleg abban az esetben, amit felhoztál példának.

Lássuk csak, mit csinál, ha elég gyorsan jönnek a kérések. Ha a kérés a bsf utasítás végrehajtásakor már aktív, a kontroller elfogadja. Leteszi a stack -re a retfie címét, elugrik a megszakítás belépési pontjára. Ha a kérés a bsf utasítás végrehajtásakor már aktív, a kontroller elfogadja. Leteszi a stack -re a retfie címét, elugrik a megszakítás belépési pontjára....
Egy 16F -en elég 7 -szer, egy 16F1xxx -en 15 -ször, egy 18F -en 31 -szer eljátszani és betelik a stack...

Lássuk csak, mit csinál, ha elég gyorsan jönnek a kérések. Az első kérés elfogadásakor (mielőtt még a belépési pontra ugrana) a stack -ra menti a PC értékét és letiltja a kérések elfogadását. Végrehajtja a kiszolgálást (akár milyen hoszzú is legyen). A kiszolgáló törli a kiváltó okot, de más kérést is kiszolgálhat, ha a megszakítás kérő jelzőbitje 1. A kilépés előtt legyen egy új kérés, amit a kiszolgáló nem tud már lekezelni. A retfie a GIE -t 1 -re állítja az utasítás végrehajtása során. Azaz a stackról leszedi a mentett értéket és beteszi a PC -be (minden bitjét) és engedélyezi a megszakítást. A megszakítást csak a retfie utasítás végrehajtása után fogadhatja el. Így a stack -en nem tudnak felhalmozódni a visszatérési címek.

Bővebben: Link

Szia!

Újab problémával fordulnék hozzád.
megvettem az adó-vevő párt.(Adó: RFM117-868S1, Vevő: RFM217-868S1)
Beiktattam az áramkörbe, hogy ezen vigyem a jeleket. Csakhogy hülyeségeket csinál.
Ha a PIC-ek az eredeti 4MHz-n pörögnek, amint adni kezd az adóoldal, fél másodpercenként változnak véletlenszerű számok a kijelzőn, függetlenül attól, én mit akarok küldeni. Ha folyamatos négyszögjelet küldök, akkor is. Ha leveszem a PIC-ek frekvenciáját 2MH-re, a vevő folyamatos 255-öt ír ki beadott jeltől függetlenül, ha felemelem 8MHz-re, akkor meg 66-ot. Stabil 0, vagy stabil1 esetén nem ír ki semmit. Az RF adatlapján semmit nem találok arra vonatkozóan, hogy modulálná az álltalam küldött jeleket, vagy egyébb jelet is elküldene.
Kérlek, ha tudsz valami bővebb infót az adó-vevőről, esetleg a bekötéséről, segíts!

Sajnos nincs tapasztalatom ezekkel a modulokkal kapcsolaban.

Teljesen ket malomban orlunk.
Az altalad leirtak teljesen igazak.

En ket dologra mutattam volna ra:
1. a 16F sorozathoz kepest nagyobb a verem, igen kifacsart kodot kell irni (jellemzoen magasszintu nyelv forditoja altal generalt valami ize), hogy beteljen a verem NORMAL mukodes kozben.
2. Ha a megszakitasok tul gyorsan jonnek, nem marad ido a foprogramra EGYALTALAN.

Ennyit es nem tobbet szerettem volna a te KIEGESZITESEDKENT leirni, mintegy jotanacskent sonajkriz-nek. Sapienti sat.

Szia!
Próbáld meg úgy csinálni,hogy amikor a vevő adatlába magas szintű lesz, akkor megszakítást generál és elindít egy számlálót. pl. 100us annak leteltekor megnézed szintén az adatlábat, ha még magas akkor nulla az érték, ha alacsony akkor 1. persze a nulla ekkor 150us magasból és 50us alacsonyból áll. az 1 pedig 50us magasból és 150us alacsonyból.(ezután már 200us időnként kell megnézni. )Ekkor maga az adó szinkronizálja a vevőt.
Az adatátvitel 200us /bit.
üdv.: Foxi

Köszi szépen!
Kipróbálom!

Most olvastam,hogy a vevő alapból 2,4kbit/sec átvitelre van állítva.
azaz 1 bit 1/2,4*1024=400usec.

Szia!
Közben megírtam az adó rutint 400us egy bit kivitele. 4MHz kristály esetén

Szia!
Az adó értéke azt jelenti, hogy ettől eltérő bitrátát nem sugároz ki?
A programodból nem minden világos a számomra.
Például, hogy jöttek ki ezek az értékek? Illetve nem sikerült rájönnöm, hogyan választod ki, melyiket küldöd. Nagyon megköszönném, ha kikommentelnéd!

Mivel 4MHz hristálynál 1 utasítás ciklus 1us, ebből adódik hogy 100 ciklus hoz 33 decfsz /bra páros kell.A rutin pontos időzítését ellenőrizheted az MPlab ->debugger->stopwatch ablakban és a lerakott break jelzőkkel. A komment:

Azért különböznek az idők, mert a magas szintek pontosan 100 és 300usec idők, viszont a rutin hívás is idő meg a visszatérés is és ez korrigálva van a "nulla" idejében.

Nem az adó, hanem a vevő van alapból 2,4Kbit/sec-re állítva, tehát adni is ennyivel kéne...

Szia!

Így már értem a gondolatmenetedet. Nagyon ügyess! Még annál is jobban leegyszerűsítetted, mint ahogy én szoktam.
Viszont valószínűleg más fordítót használsz mint én, mert az MPLab X a ciklust nem úgy fordítja, mint ahogy a leírásod alapján kellene.

A "movlw 99"-et " nem decimálisnak, hanem hex-nek fordítja, ami így 153.
Valamint a ciklust nem 3, csak 2 utasításciklusba rendezi.
Ezért nem stimmeltek nekem a számok.
Mégegyszer köszönet.

Pedig ott van a RADIX DEC a program elején. Így decimálisnak kellene lennie.

Ott a pont. Én automatikusan RADIX HEX-et írtam. Így tanultam.

Szia!
Nem fordíthatja máshogy, mert a decfsz utasítás 1 ciklus, a bra pedig 2.

Ezért nem akart nekem sehogy sem szinkronba kerülni az adó és a vevő oldal!
A vevő oldalon timerrel mértem a jelhosszakat, adó oldakon decfsz-goto ciklussal küldtem.
Csak én a goto-t mindig 1 ciklusnak számoltam. Most, hogy írtad, megnéztem az adatlapot.
Eddig csak azért nem szívtam ezt meg, mert nem használtam kritikus időzítésre. Újfent köszönet.

Sziasztok!
Az lenne a kérdésem, hogy a megszakítás során van-e arra mód, hogy a program visszatérési címét megváltoztassuk? Arra gondolok, hogy ha van egy olyan ciklusom, amelyik beragadhat, akkor a ciklus elején elindítanék egy timert, ami ha lejár, megszakítást indít, ahol a visszatérő címet átírnám a ciklus kilépési pontjára.

Mitől ragad be a ciklus? Inkább azt kéne megoldani valahogy.

Jelre vár. Csak nem egyre, és nem egy helyen. Ráadásul minden egyes része időkritikus, ezért nem tehetek minden pontjára számlálót.

Megszakításba akarsz ciklust tenni?

Nem.
A ciklus a program futása közben kerül meghívásra. De nem maradhat benne sokáig.
Ezért adott idő után ki kellene belőle lépni. WDT-vel már megoldottam, de nem elegáns megoldás. Ráadásul hosszú.

A ciklusban figyelt valamilyen státusz bitet, amit a it rutinban átállítasz, így kiugorhat a ciklusból.

Ez az alap:
BTFSS PORTA,0
GOTOT $-2
Ez 3 utasításciklusl. tehát a bejövő jel még így is 2 utasításciklusnyi szórással rendelkezik.
BTFSC BIT,0
GOTO KILEP
BTFSS PORTA,0
GOTO $-8
További 1-2 utasításciklust tesz a szóráshoz. Mivel ez 40x ismétlődik, az időzítés kicsúszhat a szinkronból.

Ha jól gondolom ez a vevő rész, ahol állapotot figyelsz, elvileg nem csúszhat ki a szinkronból. Ez így amíg vár 4 ciklus (a BTFSx két ciklus, mert betesz egy NOP-ot), ha közben IT jön ki tudja mennyi. Ha mondjuk IOC-vel kezeled, akkor is van 3-5 ciklus interrupt latency asszinkron jeleknél, ha nem pont IT alatt jött a jel.

Szia!
Nem kell pollingolni, ha az adó "csomagokban küldi az a 2-3 byte-ot, akkor az első felfutó adatélre megszakítást generál, erre a megszakításra továbbiakban nem figyelsz (letiltod) és elindítod valamelyik timert, most már ez fog megszakítást generálni, és megszakításonként rendre betolod az adatláb bitjeit a regiszterbe. 8 után elmented. Ha lefutott x bit, visszaállítod a start megszakítást.

Szia!
Voltaképpen működik a dolog, bár az zavaró, hogy kizárólag az adásszünetben lévő statikus zörejek miatt.
Az álltalad írt adóprogram felhasználásával működésre tudtam bírni a rádiót. Épp csak 2MHz-hez átszámoltam. Valamint a teszt PIC 18-on fut.
Ilyen lett:


Próbálkoztam csak idő alapú vétellel, hogy ne ragadhasson be a vétel, ha nem jön jel. De ez nem jött össze. Most úgy működik, hogy az adó kb 15msec-ként indít egy adatot. Szinkront + kétszer ugyanazt a byte-ot. Ez kb 1ms alatt fut le. A vevő, amikor adatot kér, beugrik ADATKERES ciklusba. Mivel ez korántsem az érkező adat eleje, hanem adat + zörej, a végösszehasonlítás nem hoz eredményt. Ezért addig ugrál a ciklus elejére, míg az összehasonlítás jó nem lessz.
Így fest:

Szia!
A vevőt milyen PIC fogadja és mi fog még menni róla? Mennyire lesz lefoglalt?
Mert ugye mást is kell csináljon.
Lassan eljutsz oda, hogy kell valamiféle szinkron az adatcsomag elé, és nemsokára lesz egy ellenőrző összeg is a végén...

Szia!
Elsőre a fiaimnak gyártott elektromos gördeszka távirányítóját akarom lecserélni.
Egy infrás helikopter távosából kioperált joystic potiját , és egy nyomógombot olvas be egy PIK12F1840-es. A vevő ugyanilyen PIC-el, PWM szabályzást és elektromos féket fog működtetni. Már készül az adó oldal.
Egy Kinder tojás kapszulájába építem be.

Nem rossz project, próbáld meg, hogy küldesz 0xaa-t 2x8 bitet ez ugye 10101010 kétszer. Ezután egy tetszőleges (0x55) számot
Amikor a vevő elkezdi venni, még nem tudja, hogy a zavar és hasznos bitek miatt, hogy hol kezdődik egy byte. A vevő pörgeti a beérkező biteket, és ha zavart vesz, az nem lesz 0xAA . Ha már egyszer vesz 0xAA-t még ekkor sincs bitszinkronban, de már biztos, hogy a te adód jelei jönnek. Továbbra is görgeted a biteket,de maximum 16 bitet de most már a 0x55-re vizsgálsz, ha beérkezett, jönnek az adatok.Így működnie kell.
Ha csak nem vagy igen elszánt, akkor tényleg javasolnám az RFM12BS modult, mert mindezt ellátja, nincs zavarjelből adódó egyéb szám, a pufferbe csak hasznos adat kerül, Automatikusan kihangolja az antennát stb. Igaz 1300pénz/db.
Cserébe nem kell molyolni, és garantált a siker. Nekem egy szélmérő adatait tárolta egy ram egy hétig, azt azt nyomta be rádión usb-re és onnan PC-re közel fél év alatt soha nem volt hiba,rádaásul oda-vissza kommunikáltak.

Hasznos tanács, de én mindíg elsőre a nehezebb utat választom, mert igaz ugyan, hogy jelentősen többet szívok, de mégtöbbet tanulok. Ha valami helyettem végzi el a munkát, az igen jó, de attól én még nem fogom tudni, mit is csinál voltaképpen. Többek között ezért nem vagyok hajlandó egyenlőre másban programozni, mint asm.-ben.