Fórum témák
» Több friss téma |
Idézet: Látod, pont ezért kérdeztem... Nekem csak PIC18 és PIC24HJ típusokhoz van tananyagom. PIC16 ügyében itt nézz körül! No, meg ezen az oldalon!„Lehetőleg ha egy tananyagot tudnál küldeni” Idézet: „Na és még jó lenne egy házilag összerakható égető is” A cikkek között (PIC szekció) találsz többet is. A hozzászólás módosítva: Szept 26, 2012
Szia!
Nem csoda, hogy nagy a kavarodás a programban. A Save macro elmenti ugyan a w_save változóba a W regiszter értékét, de a Load macro rosszul állítja vissza. A swapf utasítás megcseréli az alsó és a felső 4 bitet... A Load macro helzesen:
Ha elindítottad volna a programot szimulátorban (ahogy többen ajánlottuk), egyből láttad volna a hibát. Megkönnyíti a dolgot, ha a w_save és a status_save a közös memória területen van 0x70 .. 0x7F. Elég, ha a w_save -t teszed oda.... Ld a belinkelt cikk.... A hozzászólás módosítva: Szept 26, 2012
Gyorsan megnézem mester.
 A szimulátorban leginkább időket nézek, nem vagyok benne jártas hogyan adjak szimulátor módban x sebességű megszakítójelet stb..
Most ahogy a javító kóddal próbáltam végképp összeomlik az lcd kifut a vezérlésből, egy sorosra vált és úgy is marad. Nem értem, ahogy mentem egyszer csere ok ahogy töltöm egyszer cserélem f ben. aztán cserélem w ben ? az összesen 3 csere azaz megint elforgattam nem?
A hozzászólás módosítva: Szept 26, 2012
Szia!
Bocsánat, a Save macro mindjárt vissza is cseréli. Sajnos nem vettem észre... Az általános példából kiindulva, a visszaállítás szokta csinálni, talán mert ott már ráér. Még egyszer bocsánat.
Az a helyzet, hogy a legrövdebb megszakításnál ( semmit sem csinálok csak kilépek ) is néha belefutnak egymásba. ezt onnan látom hogy a Tmr1 nélkül, védelem nélkül is stabilan az jön amit a Genius kar analog karjai küldenek, ha megy a Tmr1, akkor ez az érték ingadozik, még akkor is ha megy a védelem, ez így nemjó nyilván hogy 128 után azonnal 0 át kap a szervó. Valahogy úgy kellene ütemezni, hogy a Tmr1- be csak akkor léphessen be, ha az Rb0 most végzett, azaz biztos van ideje elintézni a dolgát.
A hozzászólás módosítva: Szept 26, 2012
Szia! Átnéztem azt a kis cikket, amit küldtél. Nem vagyok nagy angol szaki, de ha jól értem, akkor kiolvassa a memória végéből a gyárilag beállított értéket és felvési az IC lábaira. Ez jól hangzik abban az esetben ha:
- beolvassa a program (Watt féle programból nem derült ki, végig üres szektorokat láttam) - és ha még gyári az IC. Nekem van itthon 4-5 olyan 12F629-esem, amit már programoztam, tehát abból már nem derül ki, mi volt a gyári érték. A WinPIC800 program az egy db itthon lévő gyári IC-ből kiszedett egy 3428-as értéket, amit utána visszatöltöttem a program végébe, de azzal sem indult el a Vicsys féle tesztvillogó. (egyszer jönne össze valami elsőre...  )A kérdésem az lenne, hogy van-e megoldás a gyári érték visszanyerésére (hozzáteszem, még kutatok a google-n), illetve ha nincs, kiküszöbölhető-e a probléma programból? (feltételezem, ha a config szóban külső oszcillátort állítok be, és kap is egy külsőt, akkor nem érdekes, mi van a belsővel, de ezt végső esetre hagynám)
Ezt keresd meg és próbaképpen írd be.
Bővebben: Link
Szia!
Akkor mégis hogyan akarod stabilan tartani a szervo idejét? Akkor az fog csúszkálni. Sajnos több ötletem nincs.... Idézet: A 3482 hihetőbb volna. Mármint 0x3482...„A WinPIC800 program az egy db itthon lévő gyári IC-ből kiszedett egy 3428-as értéket” Idézet: Ezt hogy csináltad? Mert én azt javasoltam, hogy írd oda a program (a hex fájl) végére, és a programmal együtt írd be.„visszatöltöttem a program végébe” Idézet: Sőt, a belsőnél sem nagyon érdekes, ha a program nem hívja meg ezt az "eljárást). Legfeljebb pontatlan lesz egy picit (amúgy sem atomóra a belső RC oszcillátor...). „ha a config szóban külső oszcillátort állítok be, és kap is egy külsőt, akkor nem érdekes, mi van a belsővel”
A helyzet most a következő: a WinPIC800-al beolvastam a gyári memóriát az egyik PIC-en. Az utolsó sor 2. oszlopában volt a keresett kód, oda is írtam vissza. Természetesen nem volt jó, utána jutott eszembe, hogy mintha ennek az utolsó sor UTOLSÓ oszlopában lenne a helye. Oda beírva a Vicsys féle 1 mp-es villogást generáló tesztprogram gyönyörűen futott és annyiszor indítottam hiba nélkül, ahányszor akartam.
 (fél siker!)Sajnos a szintén tőle származó RC Car flasher már nem adja magát ilyen könnyen... A kód szerintem 3428 volt, de most már elbizonytalanodtam, így kipróbálom a 82-t is. (épp töltődik) Azt nem tudom megmondani, hogy a 2 programból meghívja-e bármelyik a belső ütemadót, erre Vicsys tud válaszolni. (bár ha jól emlékszem, a teszt programra azt írta, hogy "belső oszciról ketyeg", vagy valami ilyesmi) Egyébként - mivel még nem szereztem PicKit 2-t - a Watt féle égetőt és programot használom, abban pedig szerkeszthető a program is, így írtam a végére az oszcillátor beállítást. Úgy vélem, jó úton haladok, főleg ha sikerül a kisautó-villogót is elindítanom. Persze a többi IC gyári beállításának visszanyerése még nyitott kérdés, de egyszerre csak egy dologgal foglalkozom...
Közbe végzett a feltöltés és másodjára is érdekes a helyzet. Az RC Car flash elindul, de teljesen rendszertelenül villog. Futna a program - sőt, szerintem fut is - csak nem jól, ami érdekes, mert ugyanezen beállítással a teszt program hibátlan...
Még egy érdekesség: 3428-al is és 3482-vel is fut a másodperces villogó... (nem nagyon értek a programnyelvekhez, mi a kettő közt a különbség?) Egyébként most is itt villog mellettem...
Észrevettem, hogy volt az a probléma, hogy először nem akart a megszakításba kilépni a Tmr1, azután kilépett az értelmetlen movfw intcon sorral, most anélkül is. Lehet, hogy ez a megszakítás nincsen rendben. Mert a Tmr0 az nem okoz ilyen hibákat. És kétlem hogy ez kb 2us-os Tmr1 kilpése miatt van. Gondolkodom, de köszi , hogy segítettél, ha meglesz a baj megmondom.
Idézet: Hát persze, de amennyiben használja a program a kalibrációs értéket, akkor kismértékben különböző sebességgel.„Még egy érdekesség: 3428-al is és 3482-vel is fut a másodperces villogó...” Idézet: Mindkettő egy-egy RETLW NN utasítás, csak más értékkel térnek vissza (feltéve ha a program meghívja). Az adatlap mintapéldája így használja fel az eltárolt értéket:„mi a kettő közt a különbség?”
Jó reggelt!
Eljutottam addig, hogy a Tmr1 nem ront a bemeneti adatokon és hozzávetőleg 13ms- onként belép. (ahogy ki kellene, csak kicsit csúsztatja meg az adás) Akkor léphet be ha túlcsordult és az Rb0 kifelé halad. Ez rendben van, de a nehézsége most van, hogy hogyan maradjon halálpontosan 1-2ms között az általa "szagatott szervó szög jel? A belépett Tmr1 nem lehet elfoglalt ennyi ideig (1-2ms ) A hozzászólás módosítva: Szept 27, 2012
Megvan azthiszem. Elméletben. Minden 2. Tmr1 szakíthatja meg a programot az elsőnél kap egy flaget, ahonnan a program többi része tudja hogy kell kezelni a mostani túlcsordulást bekapcsolja a szervó kimenetet és feltölti magát a kívánt értékkel, ami a szervó jele, ez nem okoz megszakítást majd. Hanem a program többi része most úgy kezeli a tulcsordulást, hogy kikapcsolja a szervó jelet. Ez így viszonylag pontos, de megint függ attól, hogy hol a program és pár uS eltérés így is lehet. Nincs jobb ötletem.
Jó reggelt!
Tudom, hogy kérdeztem,most le is szimuláltam, de bármilyen engedélyezett megszakításnak, ha megszakítás közben egy flag-ja 1 lesz, akkor ha a GIE bitet visszaállítja a retfie, akkor azonnal belép és hogy ez mindre vonatkozik e, az Rb0-ra is? Mert logikus ez a felépítés és ezt is tapasztalom, de így felfoghatatlan, hogy mi a bajom hiszen olyan gyors a 20Mhz, hogy az adás értelmezését nem ronthatja el 400ns de még szerintem 5-10us sem. Igazán nemértem ezen az alapon gondom nem lehetne, de mégis láthatólag olykor az lcd szerint kimarad egy bit ezt onnan látom, hogy az egész képernyőn elcsúszik egy 0 vagy egy 1-es. Mi lehet a baj??
küldtem is egy üzit némi probléma felvetéssel
megkaptad?
Most néztem, eztán majd nézem.
Szia!
Idézet: „...hiszen olyan gyors a 20Mhz, hogy az adás értelmezését nem ronthatja el 400ns...” 20MHz -es órejelnél egy normál utasítás végrehajtása 200ns, egy ugrásé 400ns. A megszakításba való belépés min. 400 ns, hiszen ugrás történik, a kilépés (maga a retfie) is 400 ns. Ehhez jön még a mentés (1200ns) és a vizzaállítás (1200ns). Összesen 2uS -nél tartunk. A megszakítás kiszolgálásának idejét nem is számoltuk. Mekkora a bitidő és milyen hosszú egy távirat (bitben mérve) a rádiós átvitelnél?
Egy a 0 bit az 620us az 1 az 868us és 32 bit a hosszúság + van egy start 1,2ms.
Aztán, az rb0 amennyire a látom a logikai analizátoron (nem az igazi, lpt portos ) olyan 5us ami idő altt elvégzi. De akármelyik megszakítás sem sok. Az ábra azt mutatja, hogy igenis összefutnak és baj ez. A szervó az még a feltétlen Tmr1 megszakítással is néha bemorrog ha megy az Rb0, ami nem tetszik, pláne ha az engedélye az Rb0-tól is függ, az úgy lehetetlen értelmesen vezérelni. Mostmár fogalmam sincsen hogy mit mikor engedjek kinek, mert sehogyan sem tökéletes. De nemakarom egy másik pic-el usart-al vagy akármilyen más kommunikációval. Nemigaz, hogy egy pic képtelen rá.
Csináltam egy ilyet, hátha segít.
Nem sokat haladtam ezzel, ha belenyugszom hogy zavarja a Tmr1 az adást, akkor sem jó, sőt akkor sem ha minden byte után 4 bit hibakódot is teszek. Szóval elkezdtem kukázni, egy klinikailag halott 16f628-as tért vissza az élők sorába (hogy mennyi minden volt már , a faragasztó és a vízálló szigetelő alól mindenhonnan visszamenekült ) Egyébként már nem lehetett írni, a pickit2 felismerte de törlésnél el is vesztette. Most a régi tait égetőmmel takarítottam el a Vpp útjából a szemetet vagy nemtudom mire vélni nem első eset ez a megoldás, én csak a pickit2 gyenge pumpált Vpp-jére tudok gondolni.
Szia!
Esetleg emeld fel a startjel hosszát 2mSec időre, ezzel egyidőben indítsd a szervo idejét, és akkor már nem zavar be semmibe, még a startjel alatt vége .
Na igen csak startjel csak kb 40ms-onként van.
Hali Nem jó az ábra, mert a timer1 megszakítási ideje csak 1-2uSec az ábrán pedig leglább 2-3mSec idő látható,A tmr1 nél csak egy tüskét kéne látni 10msec.nél és megint egyet ehhez képest 1-2 mSecnél. Ez igy nem is működhet.
Jajj bocsánat az a Tmr1 műveletének eredménye. A megszakítás ennyi:
|
Bejelentkezés
Hirdetés |
