25db os léptetés . l[i][0] Szintet tárolom amit oszlop fügvénybe töltöm bele.

Akkor jól csinálom mert ha igen nem müködik nekem(

Jé, ez nekem meg volt papíron, ha igaz

Bitet teszel egyenlővé byte al? Nekem nem mindig kezelte jól a fordító így próbáld átírni a *(++pa)-t erre !!(*(++pa).

Ha igy gondoltad sajnos nem jó

A pa =&l[i][0]; a 3. sorban valóban eltárolja a l[i][0] címét, de az utána következő 25 utasításban a pa++ vagy a ++pa minden egyes végrehajtása növeli a pa értékét, a 33. sorra más 25 címmel magasabb címre fog mutatni, mint a l[i][0] azaz a l[i+1][0] címére.

Állítsd be a szimulációt, hajtasd végre a programot lépésenként és vizsgáld a pa értékét. Nézd meg a memóriát is - a l[][] tömböt...

Bocsánat, nem akartalak ennyire megkavarni....

Csomagold be (végre) egyben az egész programot, deklarálás, *.h, *.c , stb, hogy végre mi is le tudjuk fordítani, meg tudjuk nézni, hogy hol hibázik....

van előtte két felkiáltó jel !!(*(++pa)) kétszer negálja a az adott értéket.
Ismét ajánlanám icserny oldalát elolvasni elég hosszan van dokumentálva, mert megint azt látom, hogy csak azt várod, hogy a sült galamb a szádba repüljön.

Semmi lexikális anyag nélkül elég sokáig fog tartani megtanulni, mindenképp kezd el olvasni az oldalt nekem az elején sokat segített mind assembly mind C terén.

Tessék a teljes progi

Estefelé ránézek..

Előre leszögezem, hogy nem értek a PIC programozáshoz, PC-re fejlesztek. De szerintem ez itt biztosan nem jó! Nincs inicializálva a pointer.
261. sorban deklarálod, és 263. sorban fel is használod, de közte a pointernek nem mondod meg, hogy hova mutasson.

Sziasztok,

Kezdő vagyok, szeretném megtanulni hogyan készítsek megszakítás rutint. Tudnátok segíteni?
MPLAB X-et használok és PIC16LF1825-re írom a programot.

Olyat szeretnék készíteni, hogy bizonyos időközönként ránézzek két bemenetre és ha mind kettő 0 akkor kezdje elölről a fő programot.
Azt hiszem ehhez kellene a Timer modult használni, de nem tudom hogyan állítsam be.
Hogy elölről kezdje a főprogramot, azt hogy valósítsam meg? Reseteljem a processzort..?
Bocsi az analfabéta kérdésekért!

Milyen nyelven?

Jaj bocsánat a lényeg lemaradt: C nyelven!

Azt a fránya angolt pedig gyakorolni kellene. Az életben temérdek sok dolog tud változni, szakmailag is nagyon más területre kerülhetsz, az egész elektronikát talán végleg magad mögött hagyod majd egy idő múlva, de egy másik megtanult nyelv egészen biztosan egy életen át elkísér(hetne). A jelek szerint nem szereted a társaságot

Az adatlapban a "DS40001440E-page 181" oldalon találsz egy összefoglalót a "21.7 Timer1 Interrupt" fejezet alatt a timer interrupt bekapcsolásáról. De sokkal részletesebb példák is vannak neten általánosan pic-ekhez (és még konkrétan timer0-hoz is, még ha nem is pont arra a pic-re):
Példa1 Példa2

Ilyen is van, ami még egy minta alkalmazást is generál.

Nem is tudom, kinek írjam... Ezért inkább új hozzászólásnak írom...

Minden (mai) fejlesző eszköz sok-sok segítő funkcióval rendelkezik. Nem csak megírni és lefordítani lehet a programokat és beprogramozva, abban a kis fekete tokban lehet tesztelni.

Most a Mikro C került elő, de szerintem a társai is így működnek:
El lehet indítani egy nyomkövetőt bennük (nem is kell hozzá PICkitx, IDCx). Ekkor szimulátorként működnek. Run / Start debugger. Ezek után lehet egyesével lépkedni Run / Step Over (eljáráshívást lefuttatva, de nem nyomon követve), Step Into (eljáráshívást is nem nyomon követve). Lehet töréspontig (előre kell elhelyezni jó megfontolt hely(ek)re) vagy a kurzorig.
Közben lehet vizsgálni a változók és regiszterek értékét Watch ablakban. Sőt, ha áll a program értéküket át is lehet írni.

A program fejlesztésekor ajánlatos használni, sok sok fejtörést meg lehet spórolni.

Ha már működik a programunk, érdemes megnézni a fordított kódot is. File /Open, kiválasztani a <projectnév>.lst állományt. Felváltva láthatjuk a forrás nyelven írt sorokat és a belőlük fordított assembly sorokat. Ha mást nem is tudunk kihámozni belőle, a nagyon hosszúra fordított sorokat érdemes megvizsgálni - nem lehetne rövidebb kóddal megoldani...

Elkezdtem nézegetni:
- Ahogy írták már mások is kitörlődött / megszökött egy sor. A pa deklarációja után kimaradt az értékadás. pa = & l[i][0];
- Milyen típusa is van a pa mutatónak? Olyannak kellene lennie, mint az l[][] tömb elemeinek. Azonban a int *pa; a deklarációja, az tömb pedig char l[6][26]; A char *pa; a jó megoldás.
/// Az int ebben a fordítóban 16 bites (2 byte - os), a char pedig 8 bites (1 byte - os). Az int típusra mutatóként deklarált változó a ++ műveletre 2 byte -tal megy arrébb a memóriában.

A Watch ablakba vedd fel a ps és a l változót és figyeld az értéküket.

A ledkockanagy_2 képen az is látszik, hogy a pa változó szépen ellépkedett az l[1][25] címére. Így nem használható az oszlopok() hívásában paraméternek. Az is látszik a ledkockanagy_3 képen, hogy az indexelés milyen műveleteket hajt végre ... CALL _Mul_16x16_U, 0 Nini egy szorzó rutin...

Tovább gondolkozva:
Ha a for ciklus sorban végiglépked az l[i][] tömbön, a pa mutató a ciklus végén (a delay -nél) ép a soron következő tömb elem elé (az l[i+1][0] -ra) mutat. Elegendő lenne csak a for előtt beállítani az értékét az l[1][0] -ra.

Még tovább gondolva:
Az egész nagyon röviden megoldható (az annyira bonyolultnak tűnő) assemblyben:

1. btfsc PREINC0,0, ACCESS
2. bsf LATA.RAx,0, ACCESS
3. btfss INDF0,0, ACCESS
4. bcf LATA.RAx,0, ACCESS

CSak 4 utasítás minden LED -hez.

Csak egy megjegyzés a kódhoz. Attól függően, hogy a regiszter az accessben van, az MPLAB (legalábbis a v8.8x verziókban) eleve azt állítja be 2. paraméternek. Ha azon kívül van, akkor banked-et ír be, persze ott figyelni kell, hogy jó bank legyen előtte kiválasztva. Ezért szeretem azokat a PIC-eket, ahol az összes felhasznált SFR az accessen kívül max. 1 bankban helyezkedik el.

Ez az assembly rutin tényleg jó, de nem folytattad a sort.
Ha pedig beszúrja a programjába mind a 8 bithez ezt az asm. rutint bitenként ugyanígy, érdekes végeredményt fog kapni. Lévén a PREINC0 csak az elején kell. A továbbiakban csak az INDF0 használatos.

Az az érdekes eredmény pont az lesz, amit a C csinál a 25 LATx bit beállításánál. Az l[][] tömbben a l[i][1]..l[i][25] rekeszek (char) 0. bitjén az a bit található, amit a LATx megfelelő bitjére kell kiírni. Így a PREINC0 minden ilyen blokkhoz kell.
Egyébként szándékosan hibásak a bsf LATA.RAx,0, ACCESS és bcf LATA.RAx,0, ACCESS sorok.
Ezeket minden LED -hez aktualizálni kell.

Valóban az a default, de én szeretem kiírni. Pl. olyan 18F, amiben vannak SFR -ek az ACCESS RAM-on kívül. Így látom, hogy kell e a BSR -t babrálni.

Na ezt most nem értem.
Tehát nem 1 byte adat 8 bitje kerül kijelzésre egyidejűleg?
Mert ha jól értelmezem a soraidat, akkor vagy egymás után több byte ugyanazon bitje kerül ugyanarra a portra, majd visszatér, a cím és egy bittel odébb lépve egy másik portot írogat át,
vagy több byte ugyanazon bitjét írogatja más-más portokra, majd visszatér és másik bittel teszi ugyanezt. Ez így elég logikátlan.

Nézd meg a feltöltött C programot is...

Nem, egy byte csak 1 bitet tárol (a 0. biten).
C -ből fordított kód 856 utasítás, az assembly 25*4+8 (mivel az LFSR 2 -nek számít) = 108

Igen, arra írtam azt, hogy ha az ACCESS-en kívül van, akkor lehetőleg 1 BANK-ban legyenek, és akkor csak az elején kell azt a BANK-ot kiválasztani, és kész. Az MPLAB "automatice" ACCESS/BANKED paramétert rak be attól függően, hogy hol van a regiszter (accessen kívül vagy belül).
Persze ha közben váltogatjuk a BANK-ot, mert mondjuk 86millió GPR-t használtunk fel, akkor nyilván ugyanúgy figyelni kell a BSR-re, vagy ha nem 1 további BANK-ban vannak az SFR-ek (hanem pl. ahogy az újabb PIC-eknél megfigyeltem, szét vannak szórva 14ezer BANK-ba az SFR-ek, és a BANK fele üres..).

Bocs, de mivel a C-hez nem értek, így ez nem jött le nekem a kódból.
Most már csak azt nem értem, hogy miért csak 1 bitet tárol 1 byte?.
Rosszul van megírva a program, vagy a C hibája?
"856 utasítás" Ez csak a táblázatkezelő? Akkor mennyi a teljes program?

Sajson lemaradt egy 2-vel osztás:
C -ből fordított kód 856/2 = 428 utasítás, az assembly 25*4+8 (mivel az LFSR 2 -nek számít) = 108
Így egy árnyalattal rózsásabb a helyzet.

Ezekre a kérdésekre nem tudok válaszolni, nem én fejlesztem ezt a programot.
A csomagban talált lst állomány szerint a méret: 0x60E2 / 2 = 12401 -- 37.8%
Remélem már érződik, amit szoktam írogatni: A magas szintű nyelv segít abban, hogy gyorsan készen legyünk a programmal és élvezzük a működését, mindaddig, amíg "elfér". Azonban elég kis terjedelmű feladattal képes megtölteni a programtárat.

Az emberiség legtöbb fejlesztése a kényelemre törekszik, ez a programnyelvekre is vonatkozik.
Hobbistáknak a C a kényelmes, persze nem úgy kellene ahogy ezt itt sokan művelik. Azt is ismerni kell.A fogok egy PIC-et meg bemásolok valami kódrészletet és mindenhol javítgatom 100-féle forrásból beszerzett info által az nem a működőképes megoldások közé tartozik.
Az ASM ebből a szempontból jobb, ott egy utasítás azt csinálja ami le van írva, nem kell túlzott háttértudás hozzá. A C is csak akkor egyszerűbb ha valaki ismeri, csak akkor éri meg a megspórolt idő amit nyer vele, ha nem ismeri akkor napokat elszórakozik valami apróságon azzal is.

Azért osztottad 2-vel, mert annyi utasítás?
Jó hosszú.
Mit tud ez a program a maga teljességében? Mondjuk a Zsombi projektjéhez képest?
(Viszonyításképpen, assemblyben megírva fordítás után 1065 utasítás. Mármint a Zsombi projekt.)