Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Sziasztok!
Kérdezni szeretném hogy véleményetek szerint ez így működőképes? Igazándiból csak a movf indf,rcreg ben nem vagyok biztos...
Csatold a programod!
Valahogy nekem mindíg összevissza jelenik meg a kód, de biztos csak én vagyok a béna és nem tudom használni az oldalt..Ezért csatolom .txt ben.
Hát ez így nem lesz jó már látom...Talán így
Idézet: „Valahogy nekem mindíg összevissza jelenik meg a kód, de biztos csak én vagyok a béna és nem tudom használni az oldalt..Ezért csatolom .txt ben.” De miert TXT-ben? Miert kell atnevezni az ASM-et TXT-re mielott csatolod?
Nem átnevezem, csak ilyenkor megynyitok egy jegyzettömböt és az ASM ből kimásolom a kérdéses részt. De csatolom az teljes programot is ASM ben. Ez csak egy piszkozat, a fejléc szövegezése a működésével kapcsolatban erre az átírt programra már nem aktuális.
Megtaláltam a hibát, csak nem értem, hogy miért hibázik.
para = (ADRESH<<8)+ADRESL; ezt nem jól csinálja meg, míg az előtte lévő részben jól , ha külön-külön kiolvasom az ADRESH és ADRESL értékét úgy nincs gond.>>
Valószínűleg az a gond, hogy ADRESH 8 bites regiszter, s a fordító nem csinál automatikus típuskonverziót, hanem a balraléptetéssel "kisöpri" belőle a biteket...
Idézet: „A nyákon most 1,92 V-ot ad” Ha már kezedben volt a voltméró, az 5 V-ot (a szenzor tápfeszültségét) is megmérhetted volna! Arra egyébként ügyelj, hogy az ADC referenciája és a szenzor táfeszültsége azonos legyen, s akkor legalább a tápfeszültség változásának hatása kiesik. Az adatlapon levő képleteket meg majd átkell szőrözni, mert egyik helyen 0.958V-nak olvastam az offszet értékét, máshol meg 0.8V-nak. Utóbbival számolva az 1,92 V 36.5 %-ot ad, ami jó egyezés a "majdnem 40 %"-kal. A magasabbrendű görbével illesztett karakterisztika paramétereiről meg a hőfok kompenzációról még nem is szóltunk... Remélem, azok is szerepelnek a teendők listáján! 
Nekem már elsőre gyanús volt, hogy hogyan lesz ez értelmezve.
Az viszont fura, hogy elsőre jó, aztán meg nem? Szerintem egyáltalán nem jó így, mert szerintem is kisöpör belőle mindent, és telerakja valamivel, még az is lehet, hogy a carry épp aktuális értékeivel, vagy nullákkal.
Azt nem csinálhatja, hogy "valami" belekerül jobbról, mert ez a művelet definiálva van a c-ben (left shift, nullákkal feltöltve). Az meglehet, hogy nem megfelelő hosszúságú adaton hajtja végre a balra tolást, de ezen meg tudni kellene segíteni egy casting-gal, pl.:
para = ( ( (int16)ADRESH ) << 8 ) + ADRESL ; Persze "int16" helyére olyan típust kellene írni, ami az adott c implementációban 16 bites egészt jelent. A sok zárójel közül is lehet, hogy vannak elhagyhatók, de én inkább kiírom mindet, hogy egyértelmű legyen a végrehajtás sorrendje.>>
Szerintem is a casting lehet egy megoldás, bár annak is jónak kéne lenni, hogy
para = ADRESH*256+ADRESL Ha a fordító elég fineszes, akkor shiftelésre fordítja a szorzást. Van egy sejtésem, hogy ez nem minden esetben lenne így! Idézet: „Nekem már elsőre gyanús volt, hogy hogyan lesz ez értelmezve.” Az a baj, hogy ilyenkor a fordító "jóindulatára" van bízva a dolog értelmezése. A CCS C fordító például nemes egyszerűséggel "kioptimalizálta" az (ADRESH<<8) tagot, mondván: úgyis nulla lenne, akkor minek kiszámolni... Más bitszámú eltolásnál csak 8 biten végzi el a műveleteket, így a kicsorgó bitek elvesznek. Az alábbi sor viszont jól fordul le:
Én is néztem ezt régebben Hi-Tech-el hogy hogyan oldja meg. Ha jól emlékszem volt annyi esze, hogy az para = ADRESH*256+ADRESL esetében simán bemásolta a felső byte helyére a 256-os szorzatot, az alsó byte-ra meg az ADRESL -t. Tehát nem shiftelt, meg szorzott, hanem csak a megfelelő 8 bites memória részekre másolta az adatokat.
Idézet: „Én is néztem ezt régebben Hi-Tech-el hogy hogyan oldja meg. Ha jól emlékszem volt annyi esze, hogy az para = ADRESH*256+ADRESL esetében simán bemásolta a felső byte helyére a 256-os szorzatot, az alsó byte-ra meg az ADRESL -t. Tehát nem shiftelt, meg szorzott, hanem csak a megfelelő 8 bites memória részekre másolta az adatokat.” Igen, ezt minden normalis kod optimalizalonak tudnia kell. Az egyetlen bokkeno, hogy ezekben az ingyenes "hobby valtozatokban" vagy teljsen kikapcsoljak az optimalizalast vagy csak reszlegesen, es akkor kezdodnek a gondok a kodmeretekkel meg a futasi idovel. Ezt az egyet nagyon jol csinalja az AVR, hogy ingyen van hozza a GCC aminel nincs sem kod sem pedig optimalizacios korlat.
Hali!
Óra feledékenyeknek kapcsolást szeretném megépíteni, de saját tervezésű nyákon. A nyák elkészült, minden be van forrasztva. De valami oknál fogva nem megy. Már 3x átnéztem a forrasztásokat, a nyák összeköttetéseket meg az adatlapokat. A diódák, tranzisztorok, IC-k szerintem jó irányban vannak. A táp és föld mindenhol megvan és az értéke is stimmel. Ami látványosan rossz: melegszik a PIC16F628A, mint a villanyrezsó... Megmértem a 4MHz-es kristályt szkóppal is. Valami randa 100Hzes jel volt a lábain. Szerintetek hol rontottam el, de nagyon? (A nyákról csak este tudok infot feltenni.)
Egyre jobb.
A PIC és a meghajtó IC egy-egy foglalatban van. Egy 12Vos adapterről kapják a naftát, amiből egy stab ic 5V-t csinál. Első körben a feszültségeket az IC-k nélkül néztem. Ha bent vannak az IC-k, a következő feszeültség lesznek: 5V -> 2.5V 12V -> 5V Ezt már végképp nem vágom, hogy mitől lehet.
Úgy értettem, hogy a kontrollerre van fordítva adva a táp, hogy össze van cserélve a két táplába. A 7805 kimenetére kellene egy 100nF-os kerámiakondenzátor közvetlenül a lábaira, illetve ugyanilyen kellene a PIC két táplába közé is, szintén a lehető legközelebb hozzá. Lehet, hogy gerjed a 7805. Melyik IC behelyezésekor alakulnak így a feszültségek?
Szerintem ha küldesz egy nyáktervet mert azt mondod, hogy az saját, akkor tuti meg lesz a hiba!
A feszeket az ic lábakon nézem.
Most bent volt mind a kettő, de megnézem őket külön-külön is.
Lehet. De most nem tudom közzétenni a nyák-ot, mert nincs nálam a ter.
 A feszültségek csak a PIC miatt változnak. Lehet, hogy valahol rövidre zártam?
Biztos nem cserélted fel a tápokat véletlen a PICen amikor áttervezted? Nem keverted össze a Vdd/Vcc és Vss/Gnd elnevezéseket? Én rendre mindig eljátszom ezt figyelmetlenségből és akkor szokott nagyon melegedni a PIC.
Az a baj, hogy az ember a saját hibáit nehezen veszi észre...
PCB terv lentebb.
Sehol nem látok szűrőkondit, amitől szerintem az egész gerjed.
Én úgy látom a táp nincs fordítva a panelen, az IC foglalatokat jó oldalra ültetted be? Mert ugye be lehet forrasztani a TOP és a BUT oldalról is. Ha nem jó a beültetés akkor már fordítva van benne a PIC is...
Előbb írtam egyet, aztán töröltem, mert észrevettem, hogy a jobb felső sarokban jelölve van, hogy zöld sávok a TOP oldalon vannak. Hacsak tényleg nem cserélte fel az egészet(azaz az IC-ket nem a zöld, hanem piros túloldalról ültette be), akkor ennek jónak kéne lenni(eltekintve attól, hogy jelenleg nem minden részletét néztem meg, mert csak haladjunk fokozatosan.).
Sziaszok!
Lenne néhány kérdésem a projektemmel kapcsolatban: egy LED-et akarok villogtatni meghatározott frekvenciákon, 50-50% ki és bekapcsolással. Ha megérintem a PIC-et a 10.-11. lábak környékén (nem a lábat, csak az IC tetejét), a frekvencia megváltozik, vagy ha sleepben van, akkor felvillan a LED, néha pedig egyszerűen elindul az egész, ráadásul a LED nagyon magas frekvencián, halványabban villog. nem tudok valamit csinálni, hogy stabilabb legyen? az MCLR lábat 10KOhm-val összekötöttem +5volttal, ami sokat javított, de még mindig instabil az egész. Használok megszakításokat, de tesztelgetés közben úgy vettem észre, hogy nem csinál semmit a gomb(frekvenciát kellene növelnie vagy csökkentenie). a megszakítási rutin szerintem biztosan jó, többször is átnéztem már adatlap szerint, és több tutorialt is átrágtam. a gomb úgy van bekötve, hogy +5 voltot ad az egyik megszakítási lábra, és van egy 10KOhm-os ellenállás, ami ezt a lábat köti össze 0-volttal, ha ez az ellenállás nincs, akkor már ha megmozdulok, már másképp viselkedik az egész. |
Bejelentkezés
Hirdetés |
