Az encoder A és B jelét ugyanazzal a rutinnal kezelted? (2048-as encoderről PIC16F690-el 8MHz-es órajellel hajtottam, miközben 0,1 másodpercenként kérdezte le a master I2C-n. Én is ki tudtam akasztani, de csak úgy, hogy kézzel jól megpörgettem a tengelyt. Ja és 1 encoder 1 PIC összeállítással a megszakításban csak az encoder kezelés volt!)

Nálam kicsit nagyobb a jelsűrűség. Két encodert kezel le a PIC12-es 16MHz-n. Amikor a folyamatos adatátvitelre tettem 150usecenként küldte az adatot 4 biten. Azaz 90 usec szünet után 4 meszakitás kb 15 usec ütemben. Az erederi verzióban, ahol a működés stabil, viszont hibás az adat, kb 70 usecenként küld, de gyakorlatilag csak egy biten. Tehát korántsem terheli úgy a fogadóoldalt, viszont mégis hibázik.

Számlálást a PIC12...-es végzi? (A feltett programrészletedből ezt nem látom.) Én legalább 3 byte-os számlálóba írnám az aktuális értéket és azt küldeném át...

A PIC 12-es egy előszámlálást végez, mert nincs szükség a teljes felbontásra. A teljes számlálást nem bízhatom rá, plussz adatküldés, mert a motorokat is vele kellene akkor működtetni. Ehez egyrészt kevés a lábszám, de ennél nagyobb problémát jelentene, hogy legalább 32 MHz-n kellene járatni, viszont 8MHz-n tudom megfelelően szabályozni a PWM jelet.

Megnéztem még egyszer a megszakítási rutinodat. Nekem túl egyszerűnek tűnik, hogy csak a PORTB,1-től teszed függővé, hogy melyik encoder lépett. Szerintem a változást kell figyelembe venni. Bármelyik encoder okozta a is megszakítást, mindkettőnél meg kell vizsgálni, hogy volt-e változás. Bár meglehetősen zavaró, hogy 1000 inpulzusra pont 940 ill. 1060 a számított érték. (lehet, hogy ez csak szimulátoron ennyi?)

Megszakítást csak a portb0 vált ki.
Ekkor kérdezi le portb1 állapotát. Így választja ki, melyik encoder jelzett. Amikor portb0-án megszűnik a jel, újra megnézi portb1-et. Ha 0, kivonás, ha1 hozzáadás.
Az eltérés mértéke nem mindíg ennyi, csak ez körüli. Viszont mindig szimmetrikus. Az értékek a készre szerelt eszköztől jöttek. Szimulátorral nem teszteltem. Kissé macerás.

Ha a fogadó PIC tényleg csak 8MHz órajellel jár, akkor inkább valószínű, hogy a lefutó élről marad le néha. Próbáld minél előbbre hozni a feltételvizsgálatot.

Ez a negszakítási rutin a PIC12F1840-ben van? Annak csak PORTA-ja van és minden láb kiválthat megszakítást - most futottam át a pdf-et, remélem jól értelmeztem.

Nem. A PIC 12 fogadja a két encodertt és küldi a feldolgozott jelet tovább. A fogadó egy PIC18F26K22-es.

Elvileg, ahogy számoltam, nem szabadna neki, de egy próbát mindenképpen megér. Ilyen szemszögből átnézve a rutint, van realitása. Kösz a tippet.

Kedves fórumtársak!

Szeretném megköszönni mindenkinek a segítségét!
Végre meglett a hiba. ktamas66 járt a legközelebb az igazsághoz, bár nem a lefutóélről, hanem az encoder azonosításáról maradt le néha. Ezekkel az időzítésekkel most már jól működik.

Ám ez felvet egy újabb kérdést. Miért tud a megszakítás esetenként akár 10 utasításciklust is késni?
Igaz, az adás 16MHz órajel mellett történik, a vétel pedig csak 8MHz-n, de attol még ennek a rutinnak az adás indulásának pillanatától eredetileg 12 utasításhossznyi ideje volt arra, hogy beazonosítsa az encodert. Elvi számítás alapján a 10.-nél kellett volna mérnie, amit 90%-ban meg is tett.

Ahogy növeltem az adási időt, úgy csökkent egyre lejjebb a hibaszázalék, de teljesen csak a vevő 21 utasításciklusnyi várakoztatása fölött szűnt meg. Mi okozhatja a megszakítás ilyen jelentős, esetenkénti szóródását?

A réginél én úgy emlékszem azt számoltam, hogy a késleltetés 24 ciklus, a vevőben a legrosszabb esetben az interrupt latency 5 ciklus + a hatodik utasításra vizsgálod a portot, ez 11 ciklus és mivel az órajelek nem szinkronozottak még egy elkóricálhat. Tehát a fogadóban a 12 ciklus pont megegyezik az adó 24 ciklusával az órajelek miatt. A legegyszerűbb megoldás szerintem betenni az első utasításba egy MOVFF PORTB, VIZSGALANDO utasítást, legfeljebb ha másik megszakítás jött, akkor felesleges. Ezt később már vizsgálgathatod. Így az adó részben lecsökkentheted a késleltetést 5-6 ciklusra, csak le ne maradjon a program a második impulzusról.

Ez egész tetszetős megoldás. Legközelebb alkalmazni fogom. Viszont ez sem biztos, hogy ki tudná küszöbőlni azt a nagy szóródást, amit tapasztaltam. Mivel amikor hibázott, nem egy-két órajel volt csupán az eltérés.

Szerintem nem olyan rettenetes ez, lehet az órajelek pontatlanságából összejön. Én is írtam olyan programot, ahol azt gondoltam, hogy az adott esemény csak a véletlenek szerencsétlen összejátszásával jöhet létre, a valóságban pedig 2-5 percenként stabilan megjelent.

Sziasztok!
MPLAB V8.86-os szimulátoron a következőt tapasztaltam. Megszakításban ez van:
btfss INTCON,RBIF
goto Ki_ISR
; bcf INTCON,INTF
bcf INTCON,RBIF
Az RBIF bitet minden második futásnál törli csak!
Az INTF bitet az első megszakításnál 1-be löki, ez törölhető és többször nem állítja be.
Egyik jelenséget sem értem. MPLAB hiba lenne?

Melyik PIC?
Miért nem a 8.92 verziót használod?

16F886 van beállítva. (most ez a verzió van telepítve) 8.92 megbízhatóbb?

Ennyi infóból azt mondanám, hogy bankváltás gondja van szerintem, de biztosat csak a teljes forrásból lehet mondani.

Másod be ide a megszakítási rutint.

Itt a teljes megszakítási rutin:
('nedugi' figyeltem a bankváltásra. Egyébként minden bankban benne van az INTCON)

Nem bogarásztam teljesen végig az adatlapot, de ha ez IOC akar lenni én előbb olvasnám a portot, hogy újraírja a latchet és csak utána törölném az RBIF-et, nehogy kétszer jöjjön ugyanaz az IT..

Mégiscsak a bankváltásnál csöpög be az eső:
A fenti kódban a 11. sorra érve nem tudható a kiválasztott bank száma. Kellene ide (vagy előbbre, de a 3. sor után) egy bankváltás, hogy tisztább legyen a kép.
A bankváltás halogatható a 19. sor előttig, de oda már mindenképen a 0. bank kiválasztása kell. Hova is foglaltál helyet a TEMP, T1L, T1M, T1H, T2L, T2M, T2H változóknak?

Nincs benne bankváltás, az alapbeállítások után végig a 0-ás bankban van. Az MPLAB alsó sorában mindig lehet látni az aktuális bank számot is, ha váltana.

Ennél a PIC-nél IOCB(0-7) van csak és ez az engedélyezés. Átraktam a PORT olvasása utánra az RBIF törlését és így jó lett. Neked van igazad! (Lehet, hogy az MPLAB egyformán kezeli a különböző PIC-ket? 16F886-ban nincs LAT....pdf szerint.)

A port olvasása tárolja el azt a értéket, amihez képest a változást figyeli. Ha nem olvasod be, mindig a régi álláshoz képest nézi az eltérést, így újra megkapod az IT-t, amíg a port láb vissza nem áll a régi értékre.

Biztosan így van, de ezt most már a valóságban is tesztelni fogom, mert az első változatnál a számlálás sem volt jó a szimulátorban. Köszönöm a segítséget.

Sziasztok!

Hosszan szenvedtem egy DS1821-esel.
Végre sikerült működésre bírnom, csak azt nem tudom eldönteni, hogy az adott hőmérő, vagy az adatlap hibás.
Ezt írja az adatlap: (mellékletben a parancskészlet.)

Nekem ebből az jött le, hogy az [EE] parancs kiadása után, ki kell adni az [AC] parancsot, kiolvasni, megvizsgálni a 7. bitet. Ezt a bitvizsgálatot addig ismételni, míg a 7. bit 1-re vált. Ezután lehet kiadni az [AA] parancsot, és kiolvasni a hőfokot.
Csakhogy!
Az [EE] parancs kiadásától kezdődően semmilyen parancsot nem fogad el többet, és olvasni sem lehet. Ha várok egy másodpercet, resetelem, majd kiadom az [AA] parancsot, gond nélkül kiadja az előbb lemért hőmérsékleti értéket. Illetve minden egyéb parancsra is reagál.
Szerintetek mi a hibás? Az adatlap, a szenzor, vagy az értelmezésem?

Teljesen jol mukodik
Amikor elkuldod 1shot-ba, akkor mer es aztan egybol alszik. Ha olvasni akarod elotte fel kell keltened.
Pont ezt csinaltad.

Akkor viszont az adatlap ír hülyeséget, hogy vizsgáljam a status 7. bitjét.

Megprobalom eloturni a kodot, hogy anno en hogy oldottam meg.