Igaz ugyan, hogy az assembly legfőbb előnye a tömörségéből adódó gyorsabb futás, de hogy még az inicializálás lefuttatása előtt nyerj két utasításciklusnyi időt, ráadásul mindössze egyszer bekapcsolásonként, annak aztán nincs nagy jelentősége. A főprogram írása során törekedj a tömörségre. Például, ha szükséged van egy linealizációs ciklusra, azt megírhatod úgy is, hogy követed az alapképlet logikáját, és mivel tizedessel nem tudsz dolgozni, így először felszorzod az osztandót mondjuk 100-al hogy egész számot kapj a későbbi számoláshoz, majd a végeredményt újra elosztod, vagy többlépcsős osztásokat csinálsz. Mindenképpen baromi hosszú lesz a kód és a lefutás.
De assemblyben meg van rá a lehetőséged, hogy kiforgasd a képletet, és ezzel a töredékére redukáld a kódot. Ez az, amit egyéb nyelveken nem, vagy csak körülményesen lehet megtenni, ami miatt alig nyersz vele valamit.

Igaz. Én ahhoz a mondáshoz tartom magam hogy: . De ez nem azt jelenti hogy menet közben nem lehet a jobb felé kacsingatni. Nem sok a 2 utasításciklus, de ha nekem csak egy kis odafigyelésbe kerül akkor ennyivel jobb lesz a dolog
Bár érzem hogy messze vagyok attól hogy szép assembly kódokat írjak. Jelen esetben:


UI: Persze neked is teljesen igazad van, annyira elenyésző hogy felesleges lenne sokszor foglalkozni vele. Én csak azt mondom, ha mondjuk valami nagyobb projektet csinálnék, már kész lenne a program, akkor ilyenekkel lehetne szépíteni

Az assembly programozás akkor jön előtérbe, ha valamit gyorsan (rövid, számítható idő alatt) kell elvégezni illetve kis hely áll rendelkezésre.
Az inicializálásra való ugrás megkerülhetetlen. A megszakítási rutinra való ugrással történő "átvezetés" kérdése sokkal bonyolultabb:
- BootLoader átvezeti a megszakítási rutint egy vagy több ugrással. Ugyan ez lehet a megoldás, ha a programot (vagy egy részét) futás közben kell módosítani.
- Túl hosszú (szerteágazó) megszakítási rutint egy külön program lapra (az a bizonyos 2k-s lap) lehet helyezni.
- Időkritikus események kezelésénél lehet, hogy az ugrás végrehajtási idejére is szükség lenne.
- Ha más "túltöltöttük" a program memóriát, minden felesleges utasítás helye jól jön, minden kis zugot ki lehet használni.

Sziasztok!

Van egy PIC32MZ2048EFH144 -es mikrovezérlőm. Ezt a típust lehet assembly nyelven programozni? Mert eddig MPLAB X IDE -hez csak C nyelvü compilert találtam.

Hogyan lehet ezt a típust assemblyben programozni?

XC32 -ben van assembler is.

Azt használom és amikor létre akarok hozni egy új .asm-et akkor azt írja ki hogy
"An Assembler file with no content."
Vagy akkor nem az MPLAB X IDE-ben hozzak létre egy új asm-et hanem az asztalon egy txt-ből és azt nyissam meg a programban?

Miért nem tudok assemblyben programot égetni rá? Mi a probléma? Hogyan kéne akkor csinálnom?

Ugyanúgy ahogy C-ben. Lefordít, beéget. Mi nem megy?

Nem ugyanúgy.
Mert C ben létre hozom a fáljt és mikor rá égetem gond nélkül meg csinálja.
Azonban mikor létre hozom a .asm fáljt már akkor írj hogy "An Assembler file with no content.".
Amikor pedig be akarom égetni hibát jelez.
"
make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf
make[1]: Entering directory 'C:/Users/magyarazathoz.X'
make -f nbproject/Makefile-default.mk dist/default/production/magyar_zathoz.X.production.hex
make[2]: Entering directory 'C:/Users/magyarazathoz.X'
make[2]: Leaving directory 'C:/Users/magyarazathoz.X'
nbproject/Makefile-default.mk:90: recipe for target '.build-conf' failed
make[2]: *** No rule to make target 'build/default/production/newAsmTemplate.o', needed by 'dist/default/production/magyar_zathoz.X.production.hex'. Stop.
make[1]: Leaving directory 'C:/Users/magyarazathoz.X'
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2

BUILD FAILED (exit value 2, total time: 376ms)
"

Nincs véletlenül egy á betű valamelyik "magyarazathoz"-ban?

Nem az a baj. De azért csináltam egy új projectet és tessék:

"
make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf
make[1]: Entering directory 'C:/Users/magyarazathoz.X'
make -f nbproject/Makefile-default.mk dist/default/production/magyarazathoz.X.production.hex
make[2]: Entering directory 'C:/Users/magyarazathoz.X'
make[2]: *** No rule to make target 'build/default/production/newAsmTemplate.o', needed by 'dist/default/production/magyarazathoz.X.production.hex'. Stop.
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
make[2]: Leaving directory 'C:/Users/magyarazathoz.X'
nbproject/Makefile-default.mk:90: recipe for target '.build-conf' failed
make[1]: Leaving directory 'C:/Users/magyarazathoz.X'
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed

BUILD FAILED (exit value 2, total time: 528ms)
"

Egyéb ötlet, hogy miért nem akar működni?

A source könytárban benne van? Bal oldalon a project fán.
Max töltsd fel ide, vagy privátban küldd és megnézem mi a helyzet vele.

Sziasztok!

Olyanba botlottam egy 10f206 nál hogy nincs return utasítás csak retlw. Viszont az mplab elfogadja a return utasítást is(nem vagyok gépközelben de megnézem majd mire fordítja). Ilyenkor mit csináljak? Nincs szükségem visszatérési értékre. Gondolom ez a pic kevés utasítása miatt van, elvégre ha nem is akarok visszaadni akkor is így bármit visszaadva csak 1 utasítás kell a 2 helyett.
Kérhetek erről egy kis felvilágosítást?

Köszönöm!

Az MPLab a return-t nem utasításként, hanem makróként kezeli PIC12F206 esetén. Így RETLW 0 kerül a fordításba.

Szia!

Arról azért ne feledkezz meg ( ha számít!), hogy ez felülírja a korábbi W értékedet !

Sziasztok!

Köszönöm a válaszaitokat, közben haza is értem, és tényleg RETLW 0 ra fordítja. Mivel nincs megszakítás ebben a kontrollerben, ezért nem túl lényeges hogy mentegessem a W értékét, szóval annyira nem vagyok bajban vele. Köszönöm a segítséget!

Sziasztok, egy újabb kérdés jött fel. Adott az alábbi programrészlet:

Itt egy bájtnyi adatot szeretnék kishiftelni, viszont minden állapot csak magas amit kiad, de nem értem hogy miért. Mit rontok el ?

UI: GP0 az adatláb, GP1 pedig a clock.

Az RRF PERC_EGGYES után mi az a ,1?
A GPIO,GP1 viszont minden feltétel esetén 1-be vált.
A STATUS,C második ellenőrzése és az alatta lévő sor viszont felesleges.

RRF-nél az eggyes hogy a fájlregiszteren keresztül forgat. A másik ellenőrzés nekem átláthatóbbá teszi, lehet átírom még. A GP1 nem baj hogy mindíg egybe vált, a GP0 nem akar semmilyen módon se 0-ra váltani.
A kódrészlet úgy működik hogy előzetesen feltöltöm a PERC_EGGYES regisztert a kívánt értékkel, és utána hívom meg ezt. A kód fut, nem akad le sehol (proteusban raktam össze) de nem vált a GP0 soha eggyesre.

Szerintem hagyd le azt az 1-est, tedd az 6-os sort a 12-es elé, a 6-os helyére írd, hogy BTFSC PERC_EGGYES,0
a 7-es, 9-es 10-es sort pedig töröld ki.

Lehetséges okok:
- TRISIO 0. bitje nem 0,
- Analóg funkció nincs kikapcsolva,
- A GPIO 0 kimenet túl van terhelve, esetleg csak dinamikusan.
A bcf, bsf read - modify - write művelet, azaz a port regiszter értékét beolvassa, 1 -re / 0 -ra állítja a megfelelő bitet és kiítja. Ha az előzőleg végrehajtott utasítás hatására a port lábon a feszültség nem emelkedik kellően (ld. adatlap) magasra, akkor azon a biten alacsony szintet fog beolvasni és már egy hibás értéken hajtja végre a műveletet.


Jobban méz ki így:

Ugyanígy, a INCF COUNTER -t is érdemes átírni INCF COUNTER,F -re.

Kezdem elveszteni a reményem. Rájöttem hogy van kiadott adat, csak nem helyes, de azt nem értem miért.
Linkelem a teljes kódot hátha valaki rájön.

Most annyit módosítottam hogy 8 bites csoportokban küldi ki az adatot. A két bit tesztet bent hagytam, nekem ez így átláthatóbb és könnyebb leprogramozni;
-ha az érték 0 ugorja át a következőt
-nem ugorta át ergó 1 - beállítom a lábat 1-re
-ha az érték 1 ugorja át a következőt
-nem ugorta át ergó 0 - beállítom a lábat 0-ra

GP0, adatláb. GP1, órajel. GP2, strobe láb.

A kód az én értelmezésemben; clock alacsony, carrybe beshiftelem az első bitet, tesztelem hogy milyen és aszerint állítom a GP0 lábat, clock magas, növelem a számlálót, megnézem hogy hol tartok, 8x csinálom meg. Ha letelt visszatérek.

Valamit nagyon elnézek, de nem értem mit

Próbáld ki azt, hogy az adatbyte 0-ás bitjét vizsgálod a carry helyett.
Mivel nem találok hibát az elgondolásodban, csak arra tudok gondolni, hogy nem tolja be valamiért a carryba az adat soron következő bitjét. Viszont a kivonásnál a carry 1-be vált.
Ha így sem működik, akkor maga az eltolás nem teljesül.

Az első bit nálad az a 0.?

- Analóg funkció nincs kikapcsolva:
A PIC10F206 -ben van egy analóg komparátor, ami alaphelyzetben be van kapcsolva. Ettől a GP0 (CIN+) és a GP1 (CN-) analóg módban van a reset után, de a komparátor kimenete nem kapcsolódik a GP2 (COUT) lábra. Ld. adatlap 8.8
A TRIS GPIO utasítás után egy bcf CMCON0, CMPON utasítás kell még.

Más:
A 10F206 a program memória legutolsó rekeszében tárolja az OSCCAL gyári beállítását. A memória törlése kitörölheti ezt az értéket.

Javaslat DIP8 tokozáshoz: A OSCCAL beállítási értékét egy új kontrollernél olvasssuk ki és az érték szerint jelüljük meg a lábait: A 0 bit szerint az 1. lábat, az 1. bit szerint a 2. lábat stb. Ránézéssel bármikor be tudjuk állítani az OSCCAl értéket.

PICkit2 -nél a hex file beolvasásakor a program memória legutolsó rekesz tartalmát a kontrollerből kiolvasottal helyettesíti. Tehát már az állomány beolvasása előtt csatlakoztassuk a kontrollert.

Ezek szerint ennél acPIC-nél a kimenetnek állított lábat is tudja blokkolni az analóg bemenet?

Sajnos ez nem olvasható ki az adatlapból, a port kimenet ábráján sincs feltüntetve.
Nézd meg a 10F220, 10F222 adatlapját is. Ott a megszokottól eltérő megoldás látható. Az analóg mód a kimenetet tiltja le. A rajz szerint a bekapcsolt analóg módú portbit szintje beolvasható a GPIO regiszter olvasásával.
Nem biztos, hogy a kimenettel van a probléma:
Tegyük fel, a BSF GPIO, GP0 beállítja a kimenetet 1 -re. A következő BSF GPIO, GP1 beolvasná a GPIO0 lábról a szintet, mivel az analóg, így feltehetőleg 0 -t olvas, átállítja a GPIO1 értékét és visszaírja a GPIO regiszterbe. Ezzel 0 -ra állítja a GPIO0 lábat.
Csak méréssel dönthető el, hogy melyik módszert alkalmazták a 10F200 - 10F206 esetén.

Kikapcsoltam a komparátort, most már a adatbyte bitjét vizsgálom (a carry-vel igazatok van, fals adatot fog visszadobálni a kivonás miatt, bár mivel minden egyes függvényhívás előtt frissítem az adatbytot ennek nem kéne bezavarnia.) Viszont továbbra sem akarja az igazat, kipróbálom még pár dolgot, aztán lehet átírom az egészet más elgondolás alapján, esetleg tanácsot kérnék tőletek hogy ti ezt hogy oldanátok meg?

Utólag elnézést kérek tőletek, ugyanis én hibáztam. CD4094-et használok , aminek a 8 bit kishiftelése után egyből a strobe lábbal beírtam az adatot és ez volt a hiba, és a fals és villodzó kiírások oka. Most egy egyszerűsített (és hosszabb) kóddal fut, és a hiba okának tudatával már kijavítva szépen azt jelzi ki ami nekem kell! Ezt én nem mondtam nektek, ezért nem is tudhattátok, de azért mindenkinek jár egy hatalmas virtuális pacsi!

Köszönöm!