Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Altalaban nem ugy szokott a dolog kinezni, hogy az AD egyszeruen nem mukodik es kesz. Ezt a microchip sem engedheti meg maganak.
Az errataban leirjak, hogy bizonyos feltetelek egyuttallasa eseten vannak (lehetnek) gondok vele. Vagyis AN1-en mukodott, a tobbin nem. En azert utananeztem volna, mi lehet a gond... Azert kerdeztem, hogy egy masik, ugyanilyen PIC-ben is ez volt-e a helyzet. Attol, hogy a trabantod nem indul, mert pl. nincs benne benzin, atulsz egy skodaba es az megy, nem a trabi volt a hibas.
Nem igazán üzemszerű ,de ha az icprognak némely processzorhoz van disasembler-e .ezt ctrl-c vel ki tudod másolni,egy asm kiterjesztésű filébe beilleszteni...
Régen mintha az MPLAB-bal is sikerült volna ,de mostanában csak a visszafordításig jutottam ,asm-et nem tudtam belőle csinálni.(import file ,utána program ablak.)
A program a két mikrovezérlőn ugyan az volt, csak pár konfigurációs változás van a kettőjük közt. Ez is csak azért, mert a PIC18F25K80 újabb és pár dolgot rajta máshogyan, más regiszterek más bitjeivel kell beállítani. Vagy pl a 25K80-on a CCP3-at használtam, a 2423-on pedig a CCP1-et, mert neki kevesebb CCP modulja van. Szóval ilyen kis különbségek vannak csak a programban.
De onnantól szerintem egyértelmű a hiba, hogyha az A/D átalakító GO/DONE bitjének nullába állása után 65534-et találok az ADRES-ben (12 bites A/D-nél).
Szia!
Ahogy proba is írta, MPLAB-ban visszalehet fejteni. Csinálsz egy új projectet, azzal a PIC-kel, amelyben van a HEX file, aztán a File--> Import menüvel beimportálod a visszafejtendő hex fájlt. Ezután a View-->Program Memory menüvel előjön egy ablak, amiben már asm utasítások vannak, címekkel. Viszont szerepelnek a "Line", "Address"... oszlopok is. Ahhoz, hogy csak az asm utasítások legyenek, rákattintasz bal klikkel az "Address" feliratra, és kiveszed a pipát belőlük. Aztán ha csak a "Disassembly" oszlop marad, az utasításoknál az első sorban szintén bal klikkelsz, és az "Output To File"-re kattintasz. Itt tudod kiexportálni. Aztán márcsak meg kell nézni, hogy melyik cím melyik regiszterhez tartozik. 
Nem ír vélelenül a programod indirekt címzéssel a 0xFC4, BANKED móddal a 15. lap 0xC4 címére? Illetve nem fordulhat elő, hogy nem a 15. bankból, az access bankból olvasol ki értéket az ADRES regiszterek helyett?
Egyszer a 18F -en megviccelt az alábbi hibás sor:
A movwf -nek nincs rendeltetési mezője, helyette a f a BANKED / ACCESS kódnak fordult...
Hűű, nem tudom. Így van a táblám:
Idézet: „Illetve nem fordulhat elő, hogy nem a 15. bankból, az access bankból olvasol ki értéket az ADRES regiszterek helyett?” Nem tudom, a watch ablakban az "Add SFR"-nél a legördülő listán kiválasztottam az "ADRES"-t. De szerintem teljesen mindegy mert a két analóg bemenet esetén ugyan az a mintavételező szubrutin fut le és ugyan azzal a mutatóval, ugyan arra a táblára ír. Mégis az egyik analóg bemenet esetén néha a hülyeségeket csinál, a másik esetében nem.
Nem tusz debugg-olni és a hibás értékek kiolvasása közben megfigyelni a bankokat, indirekt címeket?
Ha tényleg az A/D a rossz, akkor nem lehet kiszűrni az ilyen durván kiugró értékeket? Mindig nagyobb bitszámú érték keletkezik, amikor hibás az érték, mint 12? Vagy 12biten belül is vannak hibás értékek időnként?
Egyszer az viccelt meg, hogy a port alternatív funkcióját nem kapcsoltam ki.
Csatold mar a teljes kodot, igy csak talalgat mindenki -- lehet egesz mashol van a bibi...
Amugy azt javasolnam, hogy a TAB karaktereket csereldd le space-ekre, mert az csak problemat okoz (pl most is ahogy beilleszted a kodod egybe mossa a szavakat). Idézet: „Nem tusz debugg-olni és a hibás értékek kiolvasása közben megfigyelni a bankokat, indirekt címeket?” Feleslegesnek tartom, mert a két analóg bemenet közti mintavételezésben a különbség kizárólag az, hogy egyszer az ADCON0-ban az AN0-át állítom be, a másik esetben pedig az AN1-et. Utána totál ugyan az történik. Mégis az AN0 esetében hibás értékeket kapok, AN1-nél pedig nem. Ha a bankok, indirekt címzések rosszak is lennének, akkor minkét esetben hibás értékeket kapnék. Idézet: „Ha tényleg az A/D a rossz, akkor nem lehet kiszűrni az ilyen durván kiugró értékeket? Mindig nagyobb bitszámú érték keletkezik, amikor hibás az érték, mint 12? Vagy 12biten belül is vannak hibás értékek időnként?” Hát... eddig nagyjából azt tapasztaltam hogy vagy jó az érték, vagy 6553x. De azóta kicseréltem már a mikrovezérlőt, így nem tudom újra reprodukálni a hibát. (Csak ha visszacserélném a SOIC-28-as tokot, de ezt nem szeretném. Örülök hogy a PIC18F2423 jó.)
A mintaeldobálós-átlagolós-kerekítős rutinomat nem szeretném közkinccsé tenni. Amikor megírtam, nagyon-nagyon alaposan ellenőriztem hogy helyesen működik-e, rengeteget teszteltem és azóta ez dolgozik minden analóg jellel operáló áramkörömben, kivétel nélkül hibátlanul. Ezért erősen kétlem hogy hiba lenne benne. De mondom, még ha esetleg lenne is, annak mindkét analóg bemenet esetén jelentkeznie kellene, mert ugyan azt a szubrutint hívom meg.
Idézet: „Amugy azt javasolnam, hogy a TAB karaktereket csereldd le space-ekre, mert az csak problemat okoz (pl most is ahogy beilleszted a kodod egybe mossa a szavakat)” Itt tényleg hülyén néz ki de az MPLAB-ban így olvasható jól és nyilván ez a fontosabb. Amúgy itt is jó lehetne, csak szólni kell Topinak.
Készülnek már PIC32 kontrollerek SOIC28, SDIP28 tokban is.
Nekem meg szokott maradni a tabulátor: kijelölés és code -dá alakítá után a code=c -t átjavítom code=asm -re...
A múltkor eszembe jutott ez a mintaeldobálós rutin dolog. Biztos rengeteg munka, sok fejlesztés van benne, és messzemenőkig letesztelted a pontosságot is. Felmerül a kérdés viszont statisztikai oldalról, hogy mi alapján dobálod el te azokat az adatokat. Csak arra akarok utalni, hogy egy egyszerű átlagolás is megtenné, nem? Ha ezzel gyökeresen más eredményeket kapnál, akkor annál a műszernél nincs minden rendben.
Idézet: „Felmerül a kérdés viszont statisztikai oldalról, hogy mi alapján dobálod el te azokat az adatokat.” Az értékük alapján. A rutinom vesz 80db mintát, melyet elment egy 80*2 bájtos táblába. Utána megkeresi a 80db minta közül a legnagyobbat, majd kitörli. Utána még egyszer végignézi a 80db mintát és ismét kitörli a legnagyobbat amit talál. Ezt összesen nyolcszor végzi el egymás után, majd megkeresi a legkisebb mintát és azt is kitörli. Ezt szintén nyolcszor teszi meg, tehát összesen 16db mintát dob el a 80-ból, marad 64db. Ezt a 64 mintát összeadja és az összeget elossza 64-el (az osztás előtt kerekít is). Idézet: „Csak arra akarok utalni, hogy egy egyszerű átlagolás is megtenné, nem?” Nem, vagyis nem lenne ennyire jó. Eredetileg ezt az algoritmust a panelmérőm számára írtam. Ez a panelmérő könnyen kerülhet olyan helyzetbe, hogy valamelyik mérőbemenetén egy tüske lesz. Mondjuk azért mert kapcsolóüzemű tápba lett beépítve a panelmérő, vagy egy hirtelen áramtüske feszültséget indukál a PIC analóg bemenetén, stb... Vagy egyszerűen csak maga a mérendő jel tartalmaz valami kis tüskét, tranzienst. Na ezeket a tranzienseket az algoritmusom gyönyörűen leszűri. Hangsúlyozom, hogy ez a rutin természetesen csak DC esetén jó és csak ennél van értelme. Tegyük fel például, hogy tökéletes DC a mérendő jel, tehát legyen mondjuk a 80db minta mindegyike decimálisan 2000. Ebben az esetben az egyszerű matematikai átlag és a mintaeldobálós rutin eredménye is 2000 lesz. De tegyük fel hogy ráül egy tüske, ami mondjuk úgy jelentkezik hogy 5db minta nem 2000 hanem 3800 lesz. Ekkor a matematikai középérték (egyszerű átlag) 2112 lesz, az eldobálós program viszont az 5db kiugró mintát nem veszi számításba és így ugyan úgy 2000 lesz az eredmény. És igen, nem csak az öt kiugrót dobja el hanem még 3db 2000-es mintát is és még 8db 2000-est amit legkisebbnek ítél. De ez nem gond, hiszen amennyit eldob, annyival kevesebbel oszt ugyebár a végén. Persze így kicsit csalunk, mert nem a tényleges jel középértékét kapjuk, na de a tényleges jel parazita összetevőt tartalmaz amit miért lenne baj hogy eltüntetünk... Még egyszer mondom, ha nem DC-t mérünk akkor ez az algoritmus kifejezetten rossz. De arra meg van egy másik rutinom ami 8192db mintából számol matematikai középértéket, effektív értéket és csúcsértéket. 
A végén felére rövidítettem a hozzászólásom, így viszont a tiéd lett kétszer akkora.
Az algoritmusra emlékeztem, nem egy trúvájról van szó. Nem szaporítom a szót, nekem csupán az nem tetszik, hogy belemagyarázzuk a mérési eredményekbe, hogy hibásak, ezzel mintegy meghamisítva a végeredményt az elhagyásukkal. Hiába jön ki jó érték. Mindazonáltal lehet, hogy ez a méréstechnikában elfogadott/megtűrt módszer, ezt nem tudom. "Máshol" nagy dilemma egy-egy mérési pont elhagyása, lám itt pedig módszeresen történik ez. Idézet: „A mintaeldobálós-átlagolós-kerekítős rutinomat nem szeretném közkinccsé tenni.” Ez ertheto. Akkor probaldd meg a feladatot lebontani, es ha jol ertem a gondod nem ezzel a hyper-super-dupo rutinnal van, hanem magaval az ADC beolvasassal. Tehat csainalj egy tesztet ami csak olvasgat es akkor all meg csak ha butasagot olvas (vagy gyujt ki egy LED-et, kuldi el az erteket soros vonalon stb stb stb). Az mindig egy jo dolog, ha megprobalod a komplex feladatot apro dolgokra, modulokra bontani es modul teszteket csinalsz. Ha a modul jol mukodik a mudul tesztek soran akkor valoszinuleg a modulokat ossze illesztgetve a vegleges helyen is jol fog mukodni...
Szia! Nézz utána a statisztikai számításoknak. A mérési pontok eloszlása, szórás, t-próbák stb. Megfelelő tulajdonságokkal rendelkező mérési sorozat alkalmas arra, hogy "kidobj" nem odaillő, ritkán előforduló, értékeket. Én is így szoktam mérni A/D-vel, csak nem ilyen sok mérési ponton, hanem 10mérés. min-max kidob, osztva 8-al. Vagy 6mérés, kidob kettő és 4-el oszt. Azért érdemes a 2 hatványaira redukálni a pontokat, mert egyszerű shifttel(>>) lehet osztani.
Sziasztok!
Szeretnék összekötni UARTon egy 18f14k50-et (5V) és egy 24hj128gp202 -t (3V3). A kérdésem az lenne, hogy az adatlap szerint RB5 és RB6 láb 5V toleráns, szóval ha ezekre mappelem az UARTot, akkor minden további nélkül összeköthető? Van valami amire azért érdemes odafigyelni? Ez az egy volt chipcadéknél raktáron és nem akarom kinyírni...
Hát most hogy így mondod...
Adatlap szerint RX ST bemenetű, ami 0,8*VDD billenési szintű, szóval 4V tól van a magas. Ez így akkor nagyon nem lesz jó, viszont a rendszer többi része is 5V os szóval jól beszivattam magam.:S
Hello!
A TTL kompatibilis lábak tudnak Open Drain-esként működni. Ezt az ODCx regiszterekben tudod beállítani.
Köszi, ennek utánanézek.
Közben rákötöttem a PK2-t és még 2,5V al is ment a kommunikáció, szóval ezek után nem tudom mennyire lehet hinni az adatlapnak 
A Pk2 -ben nem az uart kivezetéseinek felhasználásával történik a soros kommunikáció...
Hali !
A te algoritmusod eltárolja a mért adatokat, és a végén dobja el a két szélsőt ? Csak azért kérdezem, mert olyan rutinon gondolkodom, ami nem igényel sok ramot a mintáknak. Ki is találtam egy olyat aminek elég 3, függetlenül a minták számától. Viszont ez csak 2 mintát tud eldobni. Tovább lehetne fejleszteni 4 mintásra is, de akkor már 5 ideiglenes tároló kellene. Nincs erre esetleg egy jól bevált C rutinja valakinek ?
Ez az ötlet sem rossz, erre és is gondoltam hogy így oldom meg. Végül is én azért nem csinálom, mert 160 bájt (2*80) nem sok, egy használatlan bankba szépen elfér és a mutatók miatt még bankváltással sem kell törődni. Illetve amit én anno fontosabbnak véltem, hogy ha csak eltárolgatom a mintákat akkor az egyes mintavételek közt a lehető legkisebb idő telik el. Ellenben ha nem tárolok akkor minden mintavétel után számolgatnia kell a PIC-nek és így ritkább a mintavétel. Nem mondom hogy ez bármit számítana, csak leírtam.
Sajnos a legmemóriaspórolósabb (de hosszú szó) megoldásnál is legalább annyi mintát el kell tárolni amennyit aztán el akarsz dobni, plusz egy ami az épp vizsgált. Ennél egyszerűbben nem hiszem hogy meg lehet oldani.
Persze, eltárolom. Olyan PIC-et választok általában, aminél nem gond az a pár rekesz. De menet közben is ki lehet kalkulálni, ahogy írod. Ízlés dolga, én általában haladni akarok, nem mindig megyek bele bonyolultabb megoldásba, ha nem muszály. De nem lebeszélni akarlak! Jó az, ha az ember használja a fejét!
|
Bejelentkezés
Hirdetés |
