Fórum témák
» Több friss téma |
Nevezett kontrollerben a szokásosnál ügyesebb, differenciális ADC van. Minden analóg bemenet a Vcc és Vdd közötti feszültséget kaphat, nem összekeverendő a negatív bemenet a negatív feszültséggel. Ha a negatív bemeneti feszültség magasabb mint a pozitív, akkor az ADC mérés eredménye negatív lesz. Így egy méréssel össze lehet hasonlítani két feszültséget.
Pl. jobbra rendezett eredménynél az ADRESH felső négy bitje 1, ha a negtív bemeneten magasabb feszültség van, mint a pozitív bemeneten. Tulajdonképpen kettes komplemens számot kapsz eredményül. Ha normál módon akarod használni az ADC-t, akkor válaszd az AVss opciót (CHSN=000).
Sziasztok!
Kellemes Húsvéti Ünnepeket mindenkinek! Gyorsba kérdeznék valamit két locsolás között ![]() Nincs véletlenül assembly-ben olyan lehetőség mint C-ben a tömb? Szeretnék egy olyat csinálni, hogy W-be berakok egy számot 0....9-ig, utána meg egy olyan megoldás kellene, hogy ez az érték egy tömb n. eleme lenne és ezt az értéket felvenné W. Pl: W = 4, és van egy 10 elemű tömböm. Minden tömbelem egy 8 bites bináris érték, és egy olyan utasítás kellene, hogy a tömb 4. elemén található értéket vegye fel W-be. Ezután már tudok vele operálni, de ezt nem tudom hogy csináljam. Azt sem tudom hogy van-e egyáltalán ilyen lehetőség. Eddig úgy oldottam meg, hogy 0...9-ig beírok egy számot W-be és azt hasonlítom össze egy regiszter értékével. Ha = akkor az értéknek megfelelően lépek tovább. Ez így rendben működik, de marha hosszú lesz így a kód ezért gondoltam hogy ha lenne egy ilyen tömbös lehetőség akkor sokkal gyorsabb és egyszerűbb lenne minden.
Közel végtelen számú megoldás lehetséges.
Ez akadt a kezembe. meghivod a "szam" szubrutint, és elágazol a WREG értéke alapján. a GOTO után valamikor végrehajtott RETURN a "szam" hívása utáni címre tér vissza. Itt például arra kell ügyelni, hogy a programrészlet minden utasítása azonos PCH tartományba essen. A hozzászólás módosítva: Ápr 5, 2021
Több információ kellene:
Milyen adatábrázolásúak a tömb elemei? Változhat-e a tartalmuk? Hol vannak tárolva? Van lehetőség, de a fenti kérdésektől és a választott kontroller típustól függ a megoldás. Tegyük fel, hogy RAM -ban tárolt byte-os adatokról van szó hagyományos 16F kontrollerenél a tömb egy memórialapon helyezkedik el : Ismerni kell a tömb kezdőcímét (Byte_Array). W -ben van az elem indexe.
Most az FSR az indexel kiválasztott tömb elemre mutat.
utasítással kiolvashatjuk, a
utasítással módosíthatjuk értékét. A hozzászólás módosítva: Ápr 5, 2021
Üdv!
Nem írtad, hogy milyen mikrovezérlőhöz kellene, de feltételezem, hogy 18LF26K80-hoz. Ha a táblázatod a program memóriában (ROM) van, akkor kalkulált ugrással a táblázat egyik RETLW elemére ugrasz. Doksi 101. oldal. Ha az adatmemóriában, akkor indirekt címzést használsz.(FSRx és INDFx regiszterek) Doksi 119. oldal.
Szia
erre gondolsz? (kivonat a 16f628 leírásból) CALL TABLE ;W contains table offset value TABLE: ADDWF PC ;W = offset RETLW k1 ;Begin table RETLW k2 . . RETLW kn Page-váltásra vigyázz
Az indirekt címzés használata:
A W regiszterhez (ami az elem sorszámát tartalmazza) hozzáadod a táblázat kezdőcímét (16-bitesen), majd az eredményt betöltöd az FSRLx és FSRHx regiszterekbe. Az IND regiszterből pedig kiolvashatod a táblázat elemének értékét. (pl. MOVF INDFx,W) (x=0...2)
Köszi mindenkinek a sok infót, szemezgetek, átírom a progit hogy lássam a működését úgy jobban megértem.
Ha jutottam valamire még jövök. Ha elakadtam akkor is ![]()
Még egy tipp a ROM-ban tárolt tömbbel kapcsolatban:
PIC18-on a RETLW helyett inkább a TBLRD utasítást érdemes használni, mert sokoldalúbb és helytakarékosabb. Az tömb elemének kiszámolt címét beírod a TBLPTRL, TBLPTH és TBLPTU regiszterekbe, kiadod a megfelelő TBLRD utasítást, majd a TABLAT regiszterből kiolvasod az elem értékét. Az utasítás előnye, hogy a számláló automatikusan növelhető/csökkenthető (ami táblázatok, vagy több byte-os adatok olvasásához jó), ill. a programszó mindkét byte-ja felhasználható. (A programmemória byte címzésű. Egy utasítás két címet foglal el.) További infó a doksi 125. oldalán. A hozzászólás módosítva: Ápr 5, 2021
Utána olvasgatok az adatlapon, köszi. Valamit szerintem nem jól értelmezek mert eddig nem nagyon akar összejönni. Próbáltam a programmemóriába is rakni a DT-vel, de nem tudtam a megfelelő helyre ugrani. Átraktam az adatmemóriába mindent, de ott sem sikerül oda ugrani.
Megpróbálom amit írtál csak egy kicsit még nehéz, soha nem csináltam még táblázatot. Most már a sokadik próbálkozás után itt tartok:
Már kitöröltem mindent amivel eddig próbálkoztam, csak ez maradt. A NULLA_......KILENC_ regiszterek értékei a LED kijelző 8 bites bitmintáit tartalmazzák, és mellé írtam a címeit. Meghívom a TABLE rutint de már nem tudom hogyan tovább.
Az én példámban a TABLE: utáni első sor a PCL (hibás az eredeti példa) programszámlálóhoz hozzáadja a W értékét, ezzel tulajdonképpen oda ugrik, ami a kívánt sor. A RETLW pedig a CALL TABLE párja és visszaadja a kívánt számot a W-ben.
Ez az ADDWF PCL hiányzik. A RETLW csak konkrét számot tud visszaadni, amit persze deklarálhatsz máshol. RETLW 29h pl. 29h-t ad vissza a W-ben. Ha persze utána csak nop lesz, akkor ez csak a szimulátorban jó, mert azután jön a RETLW NULLA_ azt is végrehajtja és már el is szállt a holdba. A hozzászólás módosítva: Ápr 5, 2021
Hát ezt most már tényleg nem vágom. Beraktam az ADDWF PCL, 1 -et de vagy semmit nem csinál, vagy teljesen máshová ugrik. Átírtam számokra a RETLW utáni részt, az úgy jó ha lefut az első sor akkor bekerül az érték W-be és visszaugrik a CALL utáni sorra. Ez idáig oké, de egyszerűen nem akar odaugrani ahol a tömb elem indexe van.
Egy példa TBLRD utasítással (PIC Assemblerre):
Tegyél egy breakpointot az addwf-re
Nézd meg, ott mennyi van W-ben Nekem tökéletesen működik. W=0-val az első sorból ugrik vissza. w=5-tel a hatodikból. Mennie kell. Vissza is adja amit kell: Jók a definícióid (TIZES?) movlw 5 call table xx: goto xx (Macen nehéz megtalálni a dollár jelet ![]() table: addwf PCL retlw 'A' retlw 'B' retlw 'C' retlw 'D' retlw 'E' retlw 'F' retlw 'G' retlw 'H' A hozzászólás módosítva: Ápr 5, 2021
Köszi még próbálkozom, de inkább újra kezdem egy új lapon hogy lássam már egyáltalán a működését.
A lényegét már azért kezdem érteni csak még nem akar összejönni. Zsora: köszi, ez tetszik csak van egy két új dolog amit még nem ismerek. pl: mit jelent a PSECT? Nem akarok hülyeséget mondani de ez valami memóriafoglalás féle, de lehet rosszul tudom. Nem értem a PSECT code,abs sort.
Egy PIC12F675 programozása közben a következő hibaüzenetet kapom: PK2Error0027: Failed verify (Address = 0x0 - Expected Value 0x2818 - Value Read 0x0)
Ettől még használható ez a példány?
A PSECT direktíva azt mondja meg az assemblernek, hogy a következő programrészeket melyik memóriaterületre kell tenni (fordítani). Példák:
PSECT code - futtatható kód a programmemóriában PSECT code,abs - futtatható kód a programmemóriában, abszolút címen PSECT data - inicializált adatok (konstansok) a programmemóriában PSECT udata - nem inicializált adatok (változók) az adatmemóriában Nem tudom hogy te melyik assembly fordítót használod, de az MPLAB X IDE v5.valahány verziójától már nincs benne alapból az MPASM, hanem az XC8 tartalmazza a PIC Assemblert, ami némileg eltér tőle. (A v5.15-ben még az MPASM volt.) Az a gond, hogy az MPASM-ra írt programok nem működnek (változtatás nélkül) PIC Assemblerrel.
Egy példa a RETLW használatára:
Fontos, hogy a PCL módosítása előtt a PCLATH regisztert is megfelelően beállítsuk, mivel az (és a PCLATU) is betöltődik a programszámlálóba. A példában ezért a rutint fix címre tettem úgy, hogy az első RETLW laphatárra kerül (0x0100 cím). Ennek megfelelően a PCLATH értéke 0x01 (1-es lap). A PCLATU marad 0, mert ez a mikrovezérlő 64kB-os. A hozzászólás módosítva: Ápr 5, 2021
Sziasztok,
a Pickit4-el van valakinek tapasztalata? Mennyire gyors a 3-hoz és az ICD3-hoz képest? Van egy ICD3-am, de nagyon utálom szegényt a lassúsága, nehézkessége miatt. Esetleg vennék egy Pickit4-est, ha az sokkal jobb ilyen téren.
Nekem nem tünt gyorsabbnak a Pickit3-hoz képest, RealIce-hosz viszonyitva meg lassubb. ICD3-hoz nem tudtam hasonlítani, de az ICD4-hez képest korlátozotabb a debug lehetőség is.
Beprogramoztad, végigment hibátlanul, majd egy külön végrehajtott ellenőrzés (Verify) hasalt el?
Meglehet, hogy a beírt program kiolvasás védett. Nézd meg a konfigurációs regiszter tartalmát. A PGC és/vagy PGD láb kimenetre kapcsolva közvetlenül a program indulása után? Egy késleltetés kellene a kimenetre állítás előtt. Látom, PICkit2 -vel programozol. Válaszd a "Vpp first Programming Entry" módot.
Köszi az infót, mindig nagyon örülök ha tanulhatok valami újat. Köszi a példa progit is átrágom magam rajta este. Bocsi hogy tegnap már nem válaszoltam de este egy kicsit már belazultam. Ha siker van, azért jelzem
![]()
Szívesen! De... ahhoz hogy megfelelő segítséget kapj, azért nem ártana elmondanod, hogy:
- melyik mikrovezérlőre kell a program (nem mindenki olvas vissza) - melyik fejlesztőkörnyezet (fordító) melyik verzióját használod Ahhoz hogy programozni tudj, ismerned kell: - az adott mikrovezérlőt - az adott mikrovezérlő assembly utasításait - a fordítóprogramot A hozzászólás módosítva: Ápr 6, 2021
Törlés után is hibát dobott és egy sima LED villogtató sem indult el rajta, úgyhogy szerintem kuka.
OK. Igazad van, elnézést.
18F26K80 a jelenlegi áldozat, most épp ezzel harcolok, de később meg akarom írni a progit esetleg egy soklábú tesójára, vagy egy 18F25J10-re. Van más PIC-is ami nagyon szimpi, de sajna azt nem ismeri az IDE. MPLABX-el nem foglalkozom. Küzdöttem vele pár hétig-hónapig, brutál bonyolult(-nak néz ki) úgyhogy azt feladtam. MPLAB 8.92-öt használok és MPASM a fordító. Ez nagyon jó. Folyamatosan az adatlapokat böngészem, azt hittem már ismerem az adott PIC-et, de furcsa, mindig találok valami újat. Az utasításaival is ismerkedem, tesztelgetem, és tök jó mikor sikerül valami.
A TBLRD-s példát átírtam MPASM-ra. Csak MPLAB X IDE v5.15 alatt teszteltem, mert MPLAB v8-at már régóta nem használok. W-be 5-öt töltve, az 5-ös szám ASCII kódja (0x35) kerül vissza eredményül a W-be.
Ajánlom figyelmedbe a mellékelt olvasnivalót. A hozzászólás módosítva: Ápr 6, 2021
Egy korábbi hozzászólásomban azon értetlenkedtem, hogy miért változtatták meg a PIC Assemblerben a bithivatkozásokat. Miután alaposabban megnéztem az .inc állomány végén található definíciókat, leesett a tantusz:
Bitek kezelése MPASM-ban:
Bitek kezetése PIC Assemblerben:
Ez az XC8-ban (is) használt megoldásra emlékeztet. Tehát mégsem olyan agyatlan módon változtatták meg. Visszaszívtam. ![]() A hozzászólás módosítva: Ápr 8, 2021
#define CARRY STATUS, 7
Bitek kezelése MPASM-ban:
Ez így működött az MpAsm -ben is. Egy program verzióban:
Egy másik verzióban:
A közös forrásban
Működött ugyan, de nem tudtad a szimulátorban közvetlenül megnézni a LED értékét.
Szia!
Idézet: „Működött ugyan, de nem tudtad a szimulátorban közvetlenül megnézni a LED értékét.” Akkor ez most már megy a pic-as alatt ?! Pont a múltkor említettem az egyik ismerősömnek, hogy ezt nem lehet a 8.92-nél és "logikátlannak tartottam" !Örülnék neki, ha megoldották volna, mennyivel egyszerűbb lenne, mint az adott bitet "skubizni" ! Majd kipróbálom, köszi az infót! |
Bejelentkezés
Hirdetés |