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).

Értem már, ez nagyon jó, köszi.

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.

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.

Ü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.

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.

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'

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.

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

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.

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.

#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!