Fórum témák
» Több friss téma |
Megszokhattam volna már, hogy ha valami értelmetlen működést produkál, többnyire én vagyok a hülye.
Ez helyett: MOVLW B'00000110' MOVWF T2CON ez volt beírva: MOVLB B'00000110' MOVWF T2CON
En ezert mar nagyon regen keszitettem egy sima MOV makrot, ami
mov macro hova, mit movlw mit movf hova endm ennyit csinal osszesen. Azert MACROassembler a fordito. Nagyon sok munkat megkonnyit, pontosan tudod, hogy mit fordit, nem kotelezo hasznalni sem, ha valami kulonleges modot akarsz (pl. ugyanazt az erteket harom kulonbozo helyre akarod beirni, akkor a rendes asm utasitasokat hasznalod, nem pazarlod a helyet). Ja, es a kovetkezo hiba majd az lesz, hogy nem tudod, hogy erteket vagy cimet toltesz be  ha valami nevre hivatkozol. Az assembly szepsegei. A hozzászólás módosítva: Feb 25, 2016
Idézet: „movf hova” Helyett inkább movwf hova !
Kipróbáltam.
Ez marha jó! Köszönöm!
Még így, együtt is működnek:
Oh, teljesen igazad van!
Meg szerencse, hogy sonajkniz jol ertette.
Ezekkel a bankváltásos makrokkal észnél kell lenni. Szerintem inkább:
MOVLW MIT MOVFF WREG, HOVA
A MOVFF egyik regisztert másolja a másikba és bankfüggetlen (cserébe két utasítás ciklusig tart). Tehát a MIT beteszem a W-be, majd kiírom a HOVÁ-ba ( a WREG a W regiszter neve, ha megnézed a memória kiosztását FE8h).
A változókat az ember megpróbálja olyan bankokba csoportosítani, ahol egyszerre kellenek, hogy minél kevesebbet kelljen váltani, ezét figyelni kell az ilyen makrokat mikor használja az ember, mivel mindig a 0 bankra vált. A hozzászólás módosítva: Feb 25, 2016
Sziasztok!
Az lenne a kérdésem, lehetséges olyasmi egy PIC esetében, hogy 16MHz-n egy kimenet ki-, vagy bekapcsolása néha nem hajtódik végre? A jelenség a következő: Van két encoderes léptetőmotor. Az encoderek gyárilag vannak beépítve a motorokba. Ergo, azonos elfordulásra, azonos jelmennyiségű jel jön az encoderekből. A két encoder jelét egy PIC12F1840-es dolgozza fel és továbbítja egy végtelenül leegyszerűsített egyetlen jelként két vezetéken. A probléma az, hogy ha pl: encoderenként kellene kapjak 1000 jelet, akkor az egyiken 940, a másikon 1060 jel keletkezik. Ami arra utal, hogy ami az egyikből hiányzik, azt a másik kapja meg. Az eltérés ahoz kevés, hogy programhiba okozhassa. Ha a feltevésem helytálló, hogyan védhető ez ki? Mellékelem a küldő rutinokat.
Az enkóderek kimenete Grey kódolású. A rajzon nem az van.
Mivel nem látjuk a enkóder bemeneti részét, bennem inkább az merült fel, hogy a motor fordulatszám és az enkóder osztása alapján biztos, hogy elég gyors lesz így a program?
A rajzon a program alapján létrehozott kód van. Ezt továbbítja a PIC12-es. Egy ezres felbontású encoderről összesen 4000 jel vehető le. De nekem csak 500-ra van szükségem. Azaz csak minden második teljes lépés után küld tovább jelet.
ktamas66! Elég necces, mert a két encoder jelsebessége a feldolgozáskori utasításokkal csaknem 2,5 millió utasításciklus másodpercenként. Mindez megszakításban. De mivel a program maga csak egy GOTO $-0 utasításból áll, azaz innen megy megszakításba, és ide is tér vissza, így a 16MHz-be belefér.
De ha ezek a késleltetések a megszakításban vannak, az nem okozhatja az enkóder jeleinek hibás felismerését (bár nem tudom, az hogyan történik)?
Bocsánat, az előbb a teljes lefutást szoroztam a teljes impulzusszámmal. Csak 1800000 utasítássor.
A két encoder A és B ága egyaránt IOC bemenetre fut. A megszakítás kezdetén megnézem, melyik bemenet jelzett. Azután azt vizsgálom, magas vagy alacsony jelzés jött-e. Azután megnézem, hogy a párja magas, vagy alacsony. Ez alapján dönt a program, hogy az adott encoder felfelé, vagy lefelé számoljon. Ez a leghosszabb részen, a számolással együtt is csak 26 utasítássor. A számláló felfelé számoláskor minden 8. lépésnél nulláz, visszafelé pedig ha elérte a 0-át, 7-et ír a számlálóba. minden lépésfordításnál küldi el az adatot, ami 88 utasításhosszt vesz igénybe. Mivel két encoder van, így kétszeres az adatmennyiség. A motorok percenkénti fordulata 200.
Könnyű lenne azt mondani, hogy értem
. Én minden esetre végiggondolnám a az IT kezelését. A konkurens IT-k kezelésének egyik problémája a "Interrupt Latency". Ez azt jelenti, hogy mivel az IT nem azonnal hajtódik végre (alapban 3-4 instrukciós ciklus, de mivel a főprogramodban a GOTO 2 ciklusos, akár 5-is lehet), lehetséges, hogy mire a programod az IT-ben megvizsgálja melyik jel okozta az IT-t, más egy másik jel is be lehet billenve, így esetleg helytelen eredmény születhet.
Erre gondoltam én is. Azért is matekoztam vele annyit. De egy ciklusidőn belül max. a másik encodertől jöhet be jel, az meg nem probléma, ha egy körrel később hajtódik végre. Ugyanazon encodertől érkező két jel között elég nagy a szünet. 300 utasításciklus lemehet közte. Abba pedig belefér az előző jel feldolgozása, plusz a másik encodertől időközben bejött jel feldolgozása, még ha mindkettő épp adattovábbítási ciklusba volt is, akkor is rövidebb 300 sornál. Tehát elvileg nem maradhat le a jelről. Mint ahogy nem is marad le, mert ha encoderenként 1000 jelnek kell lennie, a végeredményben ott a 2000 jel, csak nem a helyén. Ezért kérdeztem, hogy előfordulhat-e olyan, hogy nem vált egy kimenet, vagy hogy egy bemenet érzékelése a vevő oldalon hibázik?
Idézet: „A két encoder A és B ága egyaránt IOC bemenetre fut.” Optikai vagy mechanikus az encoder? Ha mechanikus, az érintkezői prellegnek.
Szia!
Régebben én is készítettem enkóder jelfeldolgozó programot. Szerintem nem jó írány a megszakításos kezelés. Én más utat jártam, abból kiindulva, hogy az enkóder A és B jele négy különböző állapotban lehet, és ezek követési rendje részben kötött. Így az aktuális állapotnak megfelelő programrészlethez ugrottam. Ez a jittereket is normálisan lekezelte. Ez az irányok figyelembevételével 8 kis programrészletet igényelt. Ha a bemeneti állapotok változása abnormális volt (pl.: AB 00 állapot nem válthat AB 11 állapotra), akkor hibát jelzett. Az állapotok beolvasást egyrészt Schmitt-triggeres-re kialakított komparátorokkal, illetve 4-szeres digitális szűréssel igyekeztem biztonságossá tenni. Ha igazak a régi jegyzeteim, akkor ez egy PIC16F636-on 50kHz-es élváltásokat még éppen észrevett, azaz az impulzusok frekvenciája max. kb. 10kHz lehetett. A feldolgozása 4x-es, külön kimeneten az előre, külön kimeneten a hátra impulzusok. Ez csak 1db jeladó feldolgozását tudta, ha 2db kell, akkor elvileg 64 hasonló programrészlet kellene. Sajnos régen még olyan "okos" voltam, hogy kevés kommentet írtam, de azért csatolom az asm fájl, hátha segít.
Igazán kedves vagy, de mint írtam, nem az encoderek jelfeldolgozásával van a gond.
Eredetileg egy PIC csinált mindent. A billentyűzeten bevitt célt a kijelzőn megjelenítette, az encoderek helyzetéhez képest azonosította, elindította a motorokat, a célnál megállt, és kiírta, hogy "Méreten" Hibátlanul működött. De a főnökömnek ez így nem felelt meg. Ő a következőt akarta látni a kijelzőn:" Cél: 436,4 mm" , " Pos: 320,0 mm" és azt kérte, a számok pörögjenek a haladásnak megfelelően, hogy látványos legyen. Na ezt már nem bírta a PIC tüdővel. Ehez már külső órajel kellett volna, legalább 40MHz-vel. Ekkor viszont a kijelzőkezelés lesz macerás. Mivel, mint írtam, nem volt szükségem a teljes jelmennyiségre, ezért ketté vettem a feldolgozást. Így valahol az adatátadásban kell legyen a hiba. Ha a hiba mértéke nagy lenne, valószínűleg már megtaláltam volna. Pont az a baj, hogy az eltérés túl kicsi ahhoz, hogy egyértelműen ki lehessen jelenteni, a szoftverrel van a baj. Ráadásul szimmetrikus. Azaz amennyivel az egyik kevesebbet számol, annyival számol a másik többet.
A leírtakhoz hasonló probléma a fogadó részben is lehet.
Ebben?
Hol? Ennél még egy ledvillogtatás is bonyolultabb.
Első ránézésre nem tűnik rossznak, lehet valami hazárd jelenséged van. Én megnövelném a kezdő impulzusok közötti időt (lehet kevés az 1 NOP), akár a időzítés rovására. De az is lehet, hogy pont fordítva van (nem tudom a másik PIC-nek milyen az órajele), mire a 8. sorig eljut letelik a másik PIC időzítése, vagy csak nagyon a határon van, és néha hibázik. Nem tudom ott a NOP-nak mi a szerepe, a W-t automatikusan menti az IT, a kiváltó ok törlése is mehet későbbre.
Kaptam olyan infót, hogy a tris regiszter hajlamos elmászkálni. még nem próbáltam ki, de ha így van, az magyarázat lehet. Illetve, még az jutott eszembe, nem lehet áramköri probléma?
A mellékelt képen körberajzoltam a két PIC összeköttetését. Nem itt van probléma? Esetleg kellene közé ellenállás?
Bocsánat, hogy belekotyogok, de egy megszakításban bármilyen várakozás illetlenségnek tűnik, természetes következménye az adatvesztés.
Ha a TRIS elállítódik mi teszi helyre a következő impulzusnál. A gyanú az első impulzus kezelésére terelődik, főleg ha a le/fel számolásnál már nincs probléma. Vagy egyenlőre csak egy irányba mozog, és úgy véti a hibát?
A hozzászólás módosítva: Ápr 7, 2016
Szia! Ez a 1060 - 940 jel nekem azt mondja, hogy az enkóderek jelfeldolgozásával van gond. (Pl. közel egyidőben jön jel az 1. és 2. enkóderből és ekkor a másik enkóderhez tartozó számlálót lépteted.) A jelvezetékek "tiszta" jeleket adnak a PIC bemenetére? Egy kis RC tag segíthet.
Az encoderek optocsatolókon át kapcsolódnak a PIC-hez. Készítettem egy más fajta átviteli rutint. Ez adott időnként küldi az adatokat, hasonló megoldással, mint az I2C. Ebben az esetben nem keletkezett eltérés, viszont a fogadó oldalon négyszer több megszakítás generálódott. Mivel ezek a megszakítások akkor is mennek, ha épp nem lenne rájuk szükség, többször felborult már a program. Amit leginkább nem értek, mitől átvitelbiztosabb a sok jel. Mint a kevés.
|
Bejelentkezés
Hirdetés |
