Biztos, higy egyszerübb lenne, ha beszélném azt a nyelvet...
Sajnos arrol már remaradtam.
Az ASM-t is majdnem elfelejtettem >20 év szünet alatt....

Jó pap holtig tanul, programozni sosem késő . Az Arduino igen egyszerű, magyarul(és németül is) elég sok könyv és portál foglalkozik vele. És, hogy a topicnál maradjunk, van külön szervó könyvtára is (pl itt)

Ezt én tudom, a fiamat probálom rávenni, hogy egy kicsit többet foglalkozzon az arduinoval. Már mégépitett egy néhány müködö szerkezetet, de az utobbi idöben nem igen szorakozott vele.
Én meg szeretem a kihivásokat, ami az assemblyben mindig benne van.

Épp a minap találtam egy olyan áttételes léptetömotort, amiben olyan kacifántos áttétel van, hogy miatta a motor, mint léptetömotor, kezelhetetlen.
A hülye áttétel miatt nem tudod a lépésekkel a meghatározott irányba forgatni ( amugy az arduinobol valo).

Írtam itt előrébb - és látszik, mennyire láma vagyok az egészhez:
Már tudom írni pickit2 íróval is 12F629, és a 16F648 pic-et is....!!
Ami után működött: bekapcsoltam valami kis pipával a VDD-t, és előtte feltoltam 5 v-ra. Innentől kezdve mentek az írások/olvasások.
Ilyenkor világít egy led a pickit2 írón. (active). Ez mit jelent?
Így kellene megírnom a 16F887-t is, hogy ez az 5v be van kapcsolva?
(Amikor kiveszem a PIC-et a foglalatból, előtte lekapcsolom az 5V-ot.)

Mindig tanulok valamit

Van olyan PIC, amit 12V-on kell programozni, lehet, hoy ez is olyan.

Ezek nem:
16F887 Üzemi feszültség: 2...5.5V

Diginewl akcióban
Gondolkodtam a szervók egyenkénti bekapcsolásával kapcsolatban. Arra jutottam, hogy ha már ennyire belesüppedtem a PIC-be körülnézek ott. A PIC kapcsolná be FET-en keresztül a szervókat induláskor.
Találtam egy viszonylag egyszerű asm kódot. Ebben a mintázatot még én is át tudom írni. Egyféle elég is lesz.
Abban kérem a segítséget, hogy az ismétlődést hol lehet belőle kivenni? Azaz csak egyszer fusson le, miután az összes bekapcsolt ne indítsa újra a műveletet.

(Pattern 0 esetében:
call t100m ;Wait 100msec
movlw h'ff' ;Set LED off data
movwf portb ;Output data
call t100m ;Wait 100msec
Ezt a részt, ha kiszedem akkor nem megy tovább?)


Gondolom ez a 16F628-on is elmegy. Ha 10 Mhz helyett 8Mhz kristályt kap akkor kicsit megnövekszik a bekapcsolási idő...
Az ötlet innen jött

Tudtok ebben segíteni?

Ez csak a LEDeket kapcsolja ki. Valahol máshol van az ismétlödés.
Itt csak 2 idözités van meg portkezelés. Az ASM-t nem tudom a tableten kinyitni.

A keyscan process végén, mikor már minden subroutine-t meghívott, van olyan, hogy "goto keyscan" azaz megismétli újra a keyscan-t, ebből lesz a végtelen kör. Ha csak 1x akarod lefuttatni, akkor ki kell szedni a "goto keyscan"-t, és így kéne kinéznie a ***Key Scan Process***-nek:

;**************** Key Scan Process ********************
keyscan btfss porta,ra0 ;RA0 ON(Low lebel) ?
call ptn0 ;Yes. Call Pattern 0
btfss porta,ra1 ;RA1 ON ?
call ptn1 ;Yes. Call Pattern 1
btfss porta,ra2 ;RA2 ON ?
call ptn2 ;Yes. Call Pattern 2
btfss porta,ra3 ;RA3 ON ?
call ptn3 ;Yes. Call Pattern 3
btfss porta,ra4 ;RA4 ON ?
call ptn4 ;Yes. Call Pattern 4

Köszönöm!
Így áll le a ciklus... végülis tökéletesen egyértelmű


Valamint a pattern mintából ki kell szednem a már alább beírt részt, amivel kikapcsolja az összes led-et.

Ezt ki fogom próbálni! De már tudom, hol akadok el, és ezt nem értem:
Próbáltam ezt az asm-kódot, ahogy eddig volt hexre fordítani a megszokott mplab programmal, de azzal a technikával, amit eddig alkalmaztam NEM sikerült! Nem értem.
Nyitok egy új projekt wizard-ot pic megadva stb-stb-ahogy szoktam, és a build rengeteg hibával elszáll....
Már megint mit csinálok rosszul?

Előrebocsátom, semmit nem dolgoztam eddig PIC-el, az AVR-t jobban szeretem , az asm hibát is csak azért találtam meg, mert az assembly nyelv elég általános. De ha a hibákat leírod, akkor megnézem mit találok, látatlanban (a hibák leírása nélkül) viszont semmit nem lehet mondani.

Egy kérdés az AVR gurukhoz. A programom elvileg müködik, márha bookmarkolok egy helyet a progibam (F5). Ha itt megnyomon akkor szépen beolvassa a dolgokat és elvégzi a munkát ( háttérben 3 megszakitással vezérelt alprogram). Ha kiiktatom a megállito gombot (F5), akkor elvégzi a feladatot, de a végén történik valami, amitöl hibát csinál. Léptetve nincs ott semmi.
Lehet hogy valamelyik megszakitás okozza a gondot? Az utolsoban egy display féleséget vezérlek, aminek igen lomha a processzora igy meglehetösen sokáig tart mig elvégzi a dolgát. Ha megállitom ciklusonként a kodot, akkor hibátlanul megy.
Hogyan lehetne ezt az AVR Studioban valahogy kivizsgálni?

Mi a hiba, amit kiír?
Egyébként be lehet rakni breakpoint-okat a kódba (szimpla vagy dupla kattintás a sor szélén azt hiszem), és a debug fülön végig lehet menni egyesével a breakpointokon: mindegyiknél kiírja a változók állapotát, asm-ben talán a regiszterértékeket is.
Mondjuk a megszakításokkal csínján kell bánni, ha lehet, kerülni kell, mert elég nehéz debugolni: röviden így lehet összefoglalni a megszakítás lefutását:
1) megszakítás jel beérkezik
2) összes belső regiszter (program counter is, minden) kiírása a RAM-ba, majd regiszterek ürítése
3) megszakítási kód betöltése, megszakításnak RAM memóriahely foglalás
4) megszakítás lefutása
5) regiszterek ürítése, megszakításmemória felszabadítása
6) RAM-ba mentett regiszterek visszatöltése, program folytatása.
Mint látható, a megszakítás olyan, mintha a program többi része nem is létezne, ezért a megszakítás-függvények csak saját változókat használhatnak, hiszen a többihez nem férnek hozzá (kivéve ha C/C++ ban a változónak van "volatile" előtagja, ilyenkor megszakítás közben is elérhető).
Akkor érdemes megszakítást írni, ha valamilyen külső jel kell egy esemény bekövetkezéséhez és a jel rövid idejű/fontos a nagyon pontos időzítés (pl lábon beérkező "értesítés" adatbuszon keresztül beolvasást kérve, vagy belső időzítő jelzése az idő leteltéről. (ezek csak példák, biztos van más eset is)), egyéb esetben az átláthatóság és a könnyebb debug miatt ajánlott elhagyni a megszakítást.
Etwg, nem ismerem a kódot, hogy tényleg szükség van-e a megszakításokra, de ha valószínűleg valamelyik megszakítás a hibás, akkor én vagy átírnám a megszakításokat és meghívható függvényként használnám őket, vagy addig csupaszítanám a programot, míg meg nem találom, hogy hol a hiba. (gondolom már lejött, hogy annyira nem szeretem az interrupt-okat , csak ha tényleg szükség van rá és nincs más mód)
(A fentiek csak AVR-re érvényesek biztosan!)

Ha léptetem vagy berakok breakpointot ( elég egy) akkor minden jol megy. De ha kiveszem az utolsot akkor valami történik és átir két fontos változot 0-rol 0x60-ra. Sem léptetve sem egy breakpointtal ezt nem teszi.
Nekem azért kellenek a megszakitások, mert az egyes feladatok idöhöz vannak kötve, azaz a motorba szabályos idöközökbe kell jelet küldeni.
Az a baj hogy az kijelzö igen rafinált, oda egy soros porton kell küldeni a 32 LEDnek a vezérlést igy csak ez az egyetlen feladat 70 lépést igényel ( meg némi köritést).
Én amellet, hogy nem igen szeretem az interruptokat gyakran nem is értem, hogy hogyan müködnek. Higyan kell rájuk várni vagy hivatkozni stb.

A soros port is egy megszakítást / időzítőt használ, lehet a többivel összeveszik.

Ez nem szabványos soros port, hanem csak soros adatátvitel (DATA/CLK). Képtelen vagyok kibogozni mi a baj. Léptetve vagy egy breakpointtal minden tökéletes de amin simán elinditom valami összezavarodik.
Ma már elég volt. Alszok rá egyet.

Sikerült a fordítás asm-hex-re.
Kaptam segítséget
Valami disable case sensitivity-t kellett pipálni, és már kijött a hex.
Most néhány nap szünet, mert meg kell építenem az áramkört, hogy egyáltalán ki tudjam próbálni, működik-e az időzítő program.
(remélhetőleg ma megérkeznek a leszabott bútorlapok, és végre építhetek bútort, ami az utolsó lépés lesz a tavaly elkezdődött építkezésünkben)

Csak sötétben tapogatózom... (AVR-t programoztam már párat, ismerem a megszakításokat és nem félek használni... )
Írtad, hogy több megszakításod is van. Előfordulhat, hogy miközben az egyiket kiszolgálja, befut egy következő? Ha van breakpoint, vagy lépésenként hajtod végre, akkor ugye sokkal több ideje van be is fejezni az előbbit a következő befutásáig. Természetesen önmagában még nem gond a megszakítás kiszolgálása alatt befutó másik megszakítás, de nagyon könnyű ilyenkor elszúrni valamit. Pl. megszokásból minden megszakítás ugyanoda ment adatokat, így a második felülírja az elsőét.

Akkor is jelentkezik a hiba, ha a breakpoint a program legutolsó utasítására mutat? (ahol már úgysincs jelentősége...)
Ha nem, akkor megkerülted (nem megoldottad) a problémát. Persze egy fejlesztés során, ha hosszabb lesz a program, akkor a hiba ismét előjöhet...
Ha igen, akkor azt a pontot kellene megtalálni, ahonnan kezdve már hibázik (ahová a breakpointot behelyezed).

Nekem is ez az érzésem. A program (eddig) 4 részböl áll.
A boot szakaszbol, ahol beállitja a kiindulo pontokat. (Elfordit egy motort, és kijelzi a helyzetet.)
A következö részben vár a nyomogombokbol érkezö parancsra.
A motor elvégzi a parancsot. A motor amikor leáll egy árammérséklö parancsot kap.
A kijelzö mutatja az állást.

A nyomogombokat beolvaso ciklus egy gyorsabb megszakitásban van (kb 50Hz), miután elég sok gombot kell beolvasni és pergésmentesiteni.
A motor hajtása egy lassu megszakitásban van mert annak lassan kell mennie (50/4Hz).
A motor állásait menetközben mutatja kijelzö.
Ha léptetem, vagy van benne breakpoint ( általában a nyomogombok olvasásához teszem), akkor minden megy ill ha meg kell állnia meg is áll. Ha kiveszem a breakpointot akkor már a bootszektor végén amikor a motor megáll és a kijelzö ezt kijelzi, majd néhány pillanat után a motor ujra áramot kap és elkezd kuszni. Lehet, hogy memoria (SRAM) konfliktus van, csak ezt nem tudom, hogyan kell Studioban ezt csinálni.

Az egyszerűbb/olcsóbb AVR-ekben nincs megszakítás megszakítása, hanem ha egy megszakítás közben egy új megszakítás jön be, akkor az újabbat csak akkor kezdi el, amikor az előző befejeződött. Lehet hogy itt van a bibi, hogy bejön egy újabb, de addig vár a futásra, amíg már nem jó, és ez adja a problémát.
Jobb AVR-ekben van pioritáskezelő és ha egy nagyobb pioritású jön be, akkor az épp futó megszakítást ugyanúgy kiirja a RAM-ba, mint a program többi részét. Memóriaütközés nem fordulhat elő, mert a verem (stack) tetejére írja az újabb értékeket, a stackpointer meg automatikusan mozog
(Hogy melyik MCU-ban van pioritáskezelő és melyikben nincs azt nem tudom, a honlapjukon kell megnézni)

Ugyanúgy (ugyanolyan sebességgel), mintha egy mozgató parancsot kapott volna (mint ahogyan a boot szakaszban van)? Vagy lassabban?

Nem lehetséges, hogy a nyomógomboktól érkező parancs indításkor még "valami" (nem állítasz be kezdeti értéket)? Amikor én csináltam parancsra működő motormozgatást, akkor a megszakítással beérkező parancsot eltároltam, és a parancs kezelése után töröltem. A főprogram meg ezt a tárolót figyelte, hogy van-e parancs.

Esetleg a gombok beolvasásánál nincs valami inicializálva (lebegő bemenet), amit debug esetén lerögzít, rendes futásnál viszont nem? (Ennyire nem ismerem a lelkivilágukat, de ki tudja...)

Sajnos egész máskép. Gyorsan megy kb 2 másodpercig majd meg teljesen lelassul 2-3 mp-ként egy ugrásra. Ilyen vagy hasonlo rutin nincs a kodban.
A gombok hasonloan vannak kezelve ahogy irod, mert a gombokat át kell számolni igy elég macerás szamologép van ami azután kiadja a parancsot a motornak, hogy mehet. Ha elvégzi a munkát akkor a parancsok nullázva vannak.

Az nem lehet bibi, hogy az egyik gombot még számolja, de már a következő gomb is megjött, így a számolás már teljesen téves útra visz? Ha lehet minden számolást egyszerű 2 vel szorzom összeadom dologra redukálni, a lebegőpontosak nagyon nagyon lassúak.

Az nem mert már alapbol ugy van irva a rutin, hogy csak az elsö gombot fogadja el, és azt még prellmentesiti is, utánna azonnal lekapcsolja a gombok olvasását. Azokat csak akkor kezdi el ujra, ha már a motor célba ért és megállt.
A szerkezet már müködött, csak még akkor nem volt megirva a display kodja. Azota van a gond ( az egy hihetetlenül lassu macerás kod, de müködik. )

Milyen LCD ? 20 MHz en hajtod? Minden megáll, vagy csak a kijelző?

Ötletek:
1. Ha átmenetileg kiveszed a kijelzést, akkor ismét rendben működik?
2. A kijelzés nem használ olyan RAM területet, amit használ a motormozgató / parancsértelmező / gombfigyelő (téves indirekt memória címzés miatt nem azt használja, amit te elterveztél)?
3. A kijelzés rutin belépéskor mindent elment és ugyanolyan sorrendben vissza tölt befejezéskor? Nekem volt olyan problémám, hogy (szintén megszakításban) valamit nem mentettem el, amit "elvileg" nem is használtam benne, de a mentés-visszatöltés beillesztése után furcsa módon megjavult...

Ez nem LCD, hanem csak egy halom LED MM5451-l hajtva.

Nem tudom, elvben a kijelzés mindössze két változot használ, amivel nincs is baj. Ha ezekben lenne konflitus azt talán a léptetés is kijelezné. De az megy. Megprobálom kikapcsolni a kijelzét (kiiktatom a megszakitást), meglátom mi lesz. A mult héten ugy vigan müködött.

A következő lépésekkel próbálnám behatárolni a hiba helyét:
1. Minden marad, csak a megszakítás lekapcsolva. (amit írtál)
2. Megszakítás engedélyezve, de maga a rutin üres, egyből visszatér megszakításból.
3. Valamit csináljon a rutin, pl. számoljon el addig, ahány utasítás az eredeti rutinban volt, hogy teljen az idő.
4. A rutin mentse el és töltse vissza a rutinban érintett változókat.
5. Ha darabolható, akkor részenként visszaírni az eredeti rutint.
Nem kell kitörölni az eredetit, elég egy ugrás a végére.

Nem tudom. Most kikapcsoltam a displayt. A helyzet nem változik. Ha van breakpoint akkor pontosan ugy megy ahogy kell. ( már vagy 5-6 helyen probáltam). Ha kiveszem akkor a ciklus vége után ujraindul.
A breakpontokbol F5-l nem tudom szimulálni az ujraindulást.

Tehát, ha jól értem, akkor a programban most benne van a display vezérlő kód, de a megszakítás le van tiltva és így is hibásan működik. Tehát a hiba nem a display rutin működésében van, hanem abban, hogy "ott van".

Ha jól emlékszem (mostanában nem foglalkoztam AVR-rel...) van egy megszakítás-tábla, amiben el lehet helyezni a megszakítás-rutin címét. Ha nincs ilyen rutin, akkor egy egyszerű visszatérésre kell mutatnia.

1. Előfordul, hogy két különböző AVR esetében némileg eltér ez a táblázat. (Az egyik esetében az 5. cím ehhez a megszakításhoz tartozik, míg egy másikban ugyanahhoz a címhez egy másik funkció.) Többnyire kompatibilisek egymással, de nem teljesen. Az egyikben van A/D, a másikban nincs, de van valami egyéb rész, ami viszont az elsőben nincs, így mindkettő ugyanazt a címet kapja, hogy a többi funkció meggyezhessen. Nem túl gyakori, de láttam már ilyet.
Ez abban az esetben lehetséges, ha közben típust váltottál, de egyáltalán nem biztos, hogy tipusváltás esetén ennek be kell követkznie.

2. Előfordulhat-e, hogy amikor a display rutin belekerült a programba, akkor az adott megszakításhoz tartozó címet nem átírtad ennek a címére, hanem beszúrtad? Így minden ez utáni megszakítás egyel arrébbira mutat... Vagyis az ugrótábla "egyel hosszabb", mint kellene. Ha ez az 5. megszakítási címre került be, akkor az eddig a 7. megszakítási címen működő program címe a 8. megszakításhoz került. Vagyis amikor bejön a 7. megszakítás, akkor nem a megfelelő (7.) rutin, hanem a 6. rutin fut le.

Nekem már megvannak régen ezek a megszakitási rutinok, ki vannak dolgozva pontos idözitésekre, és ezeket használom szinte mindenütt ahol kell. Itt már nem kell általában semmit átirni csak az egyes jelzett helyekre bemásolni az oda illö kodot. Igy nem hiszem, hogy a magával a megszakitással lenne a gond, sokkal inkább a használatával illetve az oda berakott kodokkal. Amugy annek ellenére hogy már többször bizonyitott, hogy jo a megszakitási kod, mindig bajban vagyok, hogy mit és hogyan kell berakni..... ( mindig elfelejtem a pontos modját ).
Most is a programom manuális vezérléssel több szerkezetben fut, most ehhez irtam a programozott vezérlést meg a display kodot. ( a megszakitások ugyanazok mint a müködö szerkentyükben. Igaz, hogy azokban sokkal rövidebb a kod. Csak egy van ehhez hasonlo, ahol LCD display van, azzal is veszödtem majdnem egy évig (megszakitásokkal).

Apropó hosszabb-rövidebb kód... Én egyszer belefutottam olyanba, hogy a hosszabb kód miatt messzebbre kellett ugrani (messzebbre került a megszakítás-rutin), emiatt más (hosszabb) utasítás kellett, ettől pedig minden elcsúszott... Úgy oldottam meg, hogy a megszakítás tábla közelébe tettem egy messzebbre mutató ugró utasítást.

Ilyenek nekem is vannak. Azt sem igen tudom,,hogy miért nem müködik a hosszabb ugrás a rjmp-vel, amikor ugyanarrol a helyröl a rcall, vagy call simán müködik.

Nem ér minden jó ötletemet eleve ismerni...
Vissza tudod még állítani az eredeti, jól működő állapotot?
Abból kiindulva olyan lépésekkel kellene felépíteni a dislpay-es programot, hogy eldönthető legyen melyik lépés okozza.

Ezt zongoráztam végig ma délután, nem sok sikerrel. Majd holnap talán eszembe jut valami.

Találtam a kodban egy érdekességet, csak még nem tudom mit kezdjek vele.
A kijelzö frissitése a motor megállása után további két IRQ ciklust igényel. Ezt még nem tudom miért.

Lehet a call meg a sok megszakításhívás együtt veremtúllépést okoz. A megszakításból, rutinhívásból rossz helyre keveredik vissza. ASM ben talán van olyan lehetőség, megkeresed a programodban ahol legtöbb szubrutin van egymásba ágyazva, ott elindítod az összes megszakítást, ha ott nem hibázik visszatéréskor, A veremmutató nem ér érvényes adatterületre , akkor jó. ( ha közelít már az sem egészséges, hátha valamit nem vettél figyelembe.)

Ez mind jo, csak hát elég láma vagyon ilyen mélységü hibakereséshez. Már egyszer sikerült ilyen dolgokra rátennem egy figyelöt, de most nem találom sehol sem a Studioban, hogy ezt hogyan kell aktiválni.
(Ez a legnagyobb kinom. A studio szuper, mindent tud, csak igen rossz a HELP benne és nem tudok kiigazodni hogyan kell ilyen beállitásokat csinálni.).

Az Ultimate-IT-portálra rakd fel a kérdésed, ha nagyon nem találsz választ Stackoverflow

Kösz.

Én mindig így kezdem a programot (ez éppen egy 2313-as volt):
rjmp RESET
rjmp EXT_INT0
rjmp EXT_INT1
rjmp CAPT1
rjmp COMP1
rjmp OVF1
rjmp OVF0
rjmp UART_RX
rjmp UART_UDRE
rjmp UART_TX
rjmp ANA_COMP

; ALAPBEÁLLÍTÁS KEZD
RESET:
ldi valtozo, low(RAMEND) ; A RAM tetején lesz
out SPL, valtozo ; a STACK helye
_____________________________________________________
Függetlenül attól, hogy használok-e megszakítást és melyiket.

Ezt meg a program végére:
EXT_INT0:
EXT_INT1:
CAPT1:
COMP1:
OVF1:
OVF0:
;UART_RX:
UART_UDRE:
UART_TX:
ANA_COMP:
reti
________________________
Azután amit használok, azt kiveszem innen. Mint pl. az UART_RX esetében.
Ha meg túl messzire kerül, és reklamál a fordító, akkor beteszek egy feltétel nélküli ugrást kellően közelre.
Ha te is így csinálod, akkor nem szóltam...

Egy kicsit bonyolultabban, mert mint irtam, megvannak már a kidolgozott rutinok, de alapjában nem igen térnek el tiédtöl. ( az én programomban már benne vannak az idözitések, és az azok által inditott megszakitások.).

Értem...
De ugye ehhez hasonlóan rjpm-k vannak a legelején, vagy legalábbis ki vannak hagyva ezek a helyek?

Egy kicsit másképp.
Van egy init subrutin, ami beállitja a stacket. Majd van egy másik rutin ami biztos ami biztos alapon kitörli teljes RAMot.
Ezután jönnek a timer beállitások 2 van, de alapbol csak egyet használok, ami rendszerint egy külön fájlban van pl timer0.asm ill. Timer1.asm.
Utánna van az irqvec.asm ahol ott van minden irq
Pl.
Jmp INT0addr
Jmp ovf0_irq
...
....

Amit nem használok azt egyszerüen kikapcsolom egy ;
Vagy ujabban forditva szoktam csinálni.

Azaz minden lehetö irq dummyra van állitva

Jmp dummyrti ; equ ADCCaddr = 0x002a. ;ADC conversion complete
....
Rcall main

Dummyrti:
Reti. ; return from irq

Stb, (28 sor) s ha használni kell, akkor törlöm a dummyrti-t, illetve behelyettesitem a mellette állo szoval (az equ után levövel).
Ezzel elintéztem a megszakitásokat. Majd van egy harmadik asm fajl a bground.asm ahol ki van dolgozva a megszakitás használata, jelen esetben a

Jmp ovf0_irq ; ugrik ide.

Igy a program elején ezt a 2 extra fájlat kell csak belistázni (.include "bground.asm") és már ezekkel nem is igen kell foglalkozni, elég a bground kijelzett helyére beirni a megszakitási kodot.
Ez az eljárás néha elégge bonyolitja a kodot, viszont modulokra bontja, amit késöbb egy másik projekthez aránylag egyszerü használni. A jelenlegi kodban is 14 ilyen külön fájl van a ezeken a beállitásokon kivül, külön fájlban vannak a macrok, meg a subroutinok, és természetesen az adott programhoz specifikus fájlok mint pl a motor.asm, vagy a keyboard.asm stb. Igy ezeket, csak meg kell találni és beilleszteni az adott munkába.

Értem.
Tetszik a moduláris, újra felhasználható felépítés!

Ha jól sejtem, akkor minden program legelején ez a bground.asm van, és ebben van valami olyan, mint amit én is írtam.
Amikor a hiba felmerült, akkor
- belinkelted a Display rutint tartalmazó file-t
- a bground.asm-ben átírtad a megfelelő megszakítás ugróutasításának a címkéjét dummy-ról a megfelelőre.
Ezután, amikor visszaírtad a megszakítást a dummy-ra, már nem javult meg a program?
Van egy "eredeti" bground.asm-ed, amit össze tudsz hasonlítani a megváltoztatottal? Lehet, hogy egy félregépelés okozza a hibát...

Akkor azt csinálnám , tennék egy ledet valamelyik felesleges lábra (vagy felhasználnák egyet a meglévők közül) amit a program jól azonosítható részén kapcsolgatnák,esetleg ellenkezőjére váltanák. Így legalább ki lehetne szűrni, nagyjából hol kanyarodik el a kiválasztott iránytól a program. Bár ha megszakítás téríti el, elég nehéz eset. Esetleg ha már van kijelző, arra is lehet informatív adatokat küldeni a kötelezőek helyett.

Természetesen jol örizve megvannak az eredeti "üres" asm kodok (sok munka van a kidolgozásukban), - ez a jo az egészben, igy bármikor vissza tudok menni és össze tudom hasonlitani a jelenlegivel. Illetve megvannak a müködö programok is amiben hasonlo struktura van. Ma nem volt idöm vele foglalkozni, de majd holnap ujra elöveszem. A legbosszantobb - ezt ma este vizsgáltam , hogy gyakorlatilag folyamatosan kuszik a kod. A meccs alatt 2 fordulatot tett meg a motor. Ez a legrosszabb benne, mert tényleg nagyon lassan mászik el a végállásbol. A meghajton vannak LEDek igy látom mikor indul meg és milyen lassan lépeget, csak azt nem tudom még szimulálni, hogy miért. Néha a Studio olyasmit jelez ki, hogy bizonyos regiszterek tul vannak töltve, de egyszerre több is, amit inkább a dragon meg a processzor kapcsolatának tartok. Ujratöltés után minden rendben van.

Ez megvan. A motor amikor célba ér, akkor lekapcsolja a program az áramot és lekapcsolja a motor flaget, ami lehetövé teszi a gombok olvasását. Pár másodperc mulva viszont ujra visszakapcsolja és megfutamodik mintegy 200 lépést majd meg lelassul 2-3 másodpercenként egy lépésre. Ilyenkor már a tasztaturát kellene olvasnia, amihez kiküldi a jeleket a portra ( ezt kijelzi egy LED azaz a kod odaugrott, de onnan nem tudom miért visszaugrott valahova és a két flaget ami a motort engedélyezi átirta 0-rol 0x60-ra), de ha a mot0r forog/kuszik (flagje van) az viszont letiltja a tasztatura olvasását.
Azt az átirást nem tudom honnan veszi, és nem tudom, hogyan lehet a Studiot erre állitani, hogy ezt deritse ki. A 0x0118 meg a 0x119 RAM cim változik amikor rossz (ott vannak a 0x60 tartalmak) a program szerint ott csak 0/1 lehet. Azt kellene kitalálnom hogyan állitsak a studioban egy valamit ezekre a cimekre, hiyg kiderüljön mikor történik ez. Ha léptetem akkor soha, ha kiveszem a breakpointot akkor meg igen.
Lehet olyan breakpointot a Studioban konfigurálni ami csak akkor állitaná meg a kodot ha azon a cimen vagy egy bizonyos tartalom (0x60) vagy forditva nem 0 ill 1 van. Már ez is sokat segitene, mert azon a két flagen más a program szerint nem lehet.

Az alábbiakban az SG90 szervóba beépített motor (a beépített kb. 250-es áttétellel együtt mért)
néhány jellemzője.
A motort 5V-ra kapcsolva az áram kb. 0,5ms alatt fut fel 1A-ra és kb. 2ms után kezd el forogni és
kb.5ms múlva gyorsul fel annyira, hogy az önindukcióval gerjesztett feszültség annyira megnő,
hogy az áram leesik 0,8A-ra. 60ms után az áram már csak 0,2 A, a kimenő tengely 90 fokot fordul,majd beáll a kb.0,1A.
A teljes SG90 szervo bekapcsolási tranziense a belső áramkör felállása miatt kb. 20ms-ig tart,
ez alatt a kimenő tengely akár 30 fokot is el tud fordulni.
A felhúzás nélküli szervó kb. kb. 2V tápfeszültségnél össze-vissza tud ugrálni, ez a
felhúzásosnál nem fordul elő.
Ebből következőleg olyan tápegységet kell használni, aminek a kimenő feszültsége max. 100ms
alatt eléri a végértékét. Ezt a 230VAC/5VDC kapcs. üzemű tápok tudják, de pl. egy klasszikus
trafo-Graetz- puffer elko – UGH05 nem mindig.
Ha a bemenet fel van húzva az ellenállással a tápfeszültségre, gyakorlatilag 3ms alatt lezajlik a
tranziens, a kimenő tengely nem is mozdul meg.
Nálam 8 szervo egy 3A-s kapcs. tápról rezzenés mentessen áll fel.
Más probléma a vezérlés alatt 20ms-ként fellépő impulzus jellegű áramigény biztosítása.
Az első kb. 10ms idejű 1A csúcsáram kb. 10 pulzus után leesik kb. 1ms-ra ill. 0,5 A-re a 180
fokos tartomány esetén. Nyilván nem egyszerre kell járatni a szervokat, de pl. 5ms-mal eltolt pulzusokkal maximálisan ki lehet használni egy tápegységet.