Hol lehet olyan infót megtalálni, hogy pld. az LDI utasítással csak 16 -nál nagyobb (indexű) regiszterbe lehet értéket tölteni ?

Mert a datasheet -től azt várnám hogy ilyen benne legyen ott, ahol az utasításkészlet van leírva.

Pld. mikor beforrasztottam a PS/2 aljzatba a kábeleket, utána alig akart belemenni a billentyűzet csatlakozója ... előtte meg teljesen jó volt ... nyilván szétforrasztottam belül a lelkét szegénynek ... de hál istennek érintkezik mind a 4 csati, kimértem.

Az szokott lenni, hogy pl tulmelegitetted forrasztas kozben a cuccot, ezert a muanyag ize bize nemileg deformalodott kozben, es "elallitodtak" az erintkezok. Ez ellen megoldas lehet, ha vagy nem melegited agyon es gyorsan, profin forrasztas [ez az ami nekem se szokott osszejonni, kisse remegos kezem van sajna, bar csipesz stb segithet], illetve amit ilyenkor tenni szoktam az az a csunya megoldas, hogy beledugsz egy bele valo csatit a forrasztas idejere, igy nem tud "elallitodni" akkor sem, ha nemileg sikerul tulmelegitened. Bar nem tudom, sikerult-e erthetoen leirni mit akarok

Btw, ha mar EP-hez (ami ugye Z80-at hasznal) akar az ember MCU-t csatlakoztatni erdekes lehet (mar ha csak erdekesseg es nem gyakorlati szempontbol is), hogy elvileg Zilog is gyart/gyartott MCU-kat, pl:

http://en.wikipedia.org/wiki/Zilog_Z8

Valami olyan dolog, ami 4 biten engedi magát címezni, és 16 darab 8 bites regiszteréből (tárjából) felel egy 8 bites értékkel a 4 bites címzésre, azonnal.
Nem mellesleg engedi magát az előzőtől függetlenül feltölteni aszinkron módon.

Lgb már beírta: dual port SRAM.

Es vegul meg egy lehetoseg: a Zozo altal is emlitett Propeller nevu MCU, ami tobb magos "csoda". Ebben viszont tenyleg konkretan nulla tapasztalatom van ... Az biztos, hogy ha egy mag elbirja idozitesben a "matrix emulalast", akkor neki eleg csak azt csinalnia neznie, es masik mag foglalkozhat tobbi dologgal. Viszont a Propeller pl nekem emlekeim szerint lasabbnak tunik mint az AVR, itt 4 orajel ciklus egy atlag utasitas, ha jol remlik, AVR-nel a legegyszerubbek csak 1. Viszont cserebe tobb core Masreszt, a core-ok kozotti kommunikacio es a "kozponti" RAM resz elerese lassab is vagy mi, foleg ha tobb mag probalja egyszerre, szoval nem vagyok benne teljesen biztos, hogy ez igy idozitesre hogy a fenebe jon ki aztan Mondjuk irnak vmi uj verziorol amiben lesz majd bika sok RAM, meg sokkal gyorsabb is lesz, utasitas/ciklis szinten, es orajel max szinten is ... Akkor mar tenyleg erdekelne engem is, akkor lassan mar _TALAN_ nick-et is lehet vele emulalni Bar ez utobbit imho tovabbra is FPGA-ban vagy hasonloban kene mint logikai halozatot implementalni (vegulis az eredeti Nick is az, max nem FPGA-nak hivjak amibe szintetizalva lett, ma talan ASIC-nak hivnak?).

No, ez itt kerem egy AVR disassembler kimenete Tigrian task illesztojenek flash tartalmabol (ami ugye file-ban megvan csak a forrast sikerult elkeverni ...), altalam commentalva, remelem hirtelen nem szurtam el semmit, illetve az I/O port es register neveket atirtam numerikus ertek helyett (amit disasm kidobott) az adott ATtiny-nek megfelelo dolgokra. Ez maga az interrupt handler lenne, amit az INT1 aktivizal, mely utobbi a WR0 (low active) signalra van kotve. Azaz, ha valtozik, a B4 EP porton vmi, mert oda irtak, az alacsony lesz, gondolom AVR itt a lefuto elre reagalva megszakitast general. Valojaban az AVR flash elejen levo (boot loader ezt kicsit megkeveri, mert ATmega-n legalabbis akkor ket helyen is van, sajnos kevesbe emlekszem mar, remelem jot nezek hehe) interrupt tablaban kezdodik a jatek, ahol van sokfele interruptra RJMP (ugras) utasitas, a legelso amugy a reset, itt nincs feltuntetve.

Az elso erdekesseg, amit meg a hex dump-al is megaldott resz ele tettem maga az interrupt tabla ideillo resze. Itt jon az elso trukk, amit Tigrian alkalmazott. Ugyanis, egy utasitasnyi hely van egy interrupt-nak, utana jon a masik interrupt, tehat logikus, hogy onnan el kell ugrani, azaz normal esetben mindenhol RJMP all ebben a tablazatban. Viszont pont az INT1 helyen egy IN utasitas van. Ennek hatasa ugye az, hogy mivel utana mar masik interrupt belepesi pontja van, arra "fut ra" a dolog, ami nem gond, ha az az interrupt ugyse fordulhat elo. Megis miert csinalhatta igy? Gondolom azert, mert igy tudja a leheto leggyorsabban olvasni a B4-re kiadott erteket, amig a Z80 meg tartja a buszon, ha elotte RJMP-vel elugrik, az biza 2 AVR orajelciklus mielott meg vegrehajtodhatna az IN. Ha most Zozo intelmeit megfogadjuk, ez a hokusz-pokusz nem kellene, ha nem kozvetlenul az adatbuszrol venne le ugye, hanem a demultiplexer bemeneterol.

Valojaban amugy a fenti kod ugy mokodhet amit elkepzeltem. Van a foprogram, o foglalkozik a PS/2 kezelessel. Nem tul time critical, par MHz-en siman elkezel egy PS/2 szintu protokolt. Van valahol tarolva az AVR SRAM-jaban egy 10 byte-nyi teruleten az, ami megfelel 8*10 bitre vonatkozolag az "emulalt" billentyuzet allapotanak, a foprogram PS/2 kutyulasa utan ott "nyom meg" vagy "enged el" billentyuket, a megfelelo byte megfelelo bitjenek allitgatasaval. Az interrupt handler nyilvan a WR0 jel lefuto elere lep eletbe, es feladata az, hogy beolvassa, melyik row-t akarja scannelni az EP, es amilyen gyorsan lehet, ez alapjan a B porton kikuldje a fenti kis "taszt allapot tombunk" ezzel indexelt erteket.

A kulcs itt ugye az, amirol targyaltunk, hogy vmi 11 Z80 orajelciklus van, ha a leheto leggyorsabban EP OUT-ba tesz vmit B4-re majd azonnal olvassa is, igy ennyi ido alatt azt meg kell oldani AVR-en.

Mivel AVR-nek azert van par registere, ilyen esetben "felaldozhatunk" parat, amit az interrupt handler hasznal, es nem fogja menteni, ennek eredmenye az, hogy persze foprogramban nem igazan erdemes hasznalni, mert az elso int utan "el fog allitodni". Viszont igy megsporolunk jo par orajelciklust. Viszont, AVR eseten az SREG (status register, amiben van ugye carry flag, meg a szokasos dolgok) mentese / visszaallitasa tovabbra is a mi dolgunk. Az SREG mint I/O port elerheto (valojaban meg a CPU registerek is, sot RAM cimkent is, csak ugy lassabb lenne, vannak trukkok azert AVR-en ...).

Az a T-bites jatek (a T bit az un transfer bit, arra jo, hogy pl adott reg adott bitjet belemasolhatod, vagy kimasolhatod, igy egyszerubb mindenfele bonyolult elforgatasos jatek helyett "kivagni" adott bitet es mashova "berakni") azert kell, mert a kerdeses AVR eszkozon a portD ugye nem bitfolyamatosan van, mivel egyik lab pont onnan INT1 celra van eppen.

Szoval kb logikus, a portB (ahova a 'valaszt' kiirja ugye) kezelese erdekes. Lathatoan nem vmi adatot ir ki, hanem a DDR-t (Data Direction Register, azaz meghatarozza, hogy az egyes labak a portB-n ki vagy bemenetek) allit helyette. Miert is jo ez? Azert, mert parhuzamosan kapcsolodik szegeny taszt illeszto a billentyuzettel! Ha a billentyuzet es a taszt illeszto rossz csillagallas mellett ellenkezo szinteket allitana be az nem lenne tul szep, illetve akar tonkre is tenne vmit. Itt gondolom vmi olyasmi lehet, hogy a portB mint kimenet mindig 0-ra van allitva. Ha a billentyu nincs lenyomva, akkor az adott pin a DDR-el input-ra all, ami kb nagy impendancias allapot, tehat nem szol bele az AVR a jelszintbe. Ha le van nyomva, akkor 0 ertek kell, ekkor output-ba teszi az adott bit-et, es mivel a portB AVR-ben outputra fixen 0-ra van allitva, ez "lehuzza" GND szintre. Ha kozben EP billencs is le van nyomva, no para, mert az is csak foldre huzna le, tehat nincs konfliktus. Bocs, lehet hirtelen elneztem vmit, illetve csak az interrupt kod alapjan mondom ezt, de kb ez a megerzesem, hogy igy mukodik az egesz a fenti par byte-nyi AVR kodra ranezes utan.

Ja, az ORI azert van ott persze, hogy a D0 memoricimtol nezze azt a kis tablazatunkat. Ebben az AVR-ben csak 128 byte RAm van, de az adat cimterulet elejen az I/O elerheto szinten, a D0 valojaban a RAM vege elott 16 byte-tal van. Ez ugye eleg a 10 byte-os "tablazatra", mivel alapvetoen a select jel 4 bites, max nem lesz hasznalva a tobbi.

Azert van itt feher folt, pl az EOR R1,R1 hogy mire jo ... Elvileg ugye nullaza az R1-et, az oke, de utana ugysem hasznalja mar. Gyanitom, hogy ez valamiert a foprogramnak kell aztan. Hasonlo az R2, amit novel eggyel, de semmire sincs hasznalva, gondolom ezt is a foprogram nezi valahol.

Na, vege a mesedelutannak. Most nem akarok felelotlen igeretet tenni, de szerintem ezt meg lehet tomorebben is oldani ... itt ugye a kulcs az, hogy az interrupt kiszolgalasa es az OUT vegrehajtasa kozott eltelt ido az, aminek akkor ugye 11 Z80 orajelnyi ido alatt le kell futnia. Szerintem meg lehetne csinalni gyorsabbra is ennel, foleg, mivel nem feltetlen ertem, mire valo itt 1-2 dolog Mivel RAM nem kell tul sok az egesz cuccnak, akar fel lehet aldozni azt is, hogy a portD "nem folytonos" kiosztasa miatt vmi elkefelt matrixunk legyen, amiben van egy "nagy lyuk", cserebe a T bites jatek pl megsporolhato. Az R5 hogy mire kell neki az passz, szerintem felesleges. Ez talan szinten a foprogramnak szol, es arra kell, hogy programozni lehessen a taszt illesztot EP-rol? Lehet az R2 novelest erzekelve "latja" a foprogram hogy uj adat lett kiirva, es akkor nezi az R5-ot. Oszinen, en inkabb redundans modon (ha kell ilyen) megcsinalnam az IN-t a foprogramban is, ha a Zozo fele bekotest alkalmazzuk akkor az ott "taszt illeszto programzas" kapcsan nem critical, mig a matrix scan miatti lenne csak az interrupt-ban.

Szoval kiesne egy BST egy BLD, egy MOV, egy INC, egy EOR. Ez ot AVR orajelciklus sporolas az OUT-ig azonnal. Cserebe bonyolitottuk a foprogramot ha programozni is akarjuk az illesztot, es pazaroltunk RAM-ot mert nem "tomor" a kbd allapot "tombunk". Kovetkezo igen extrem optimalizacio: tegyuk az egesz interrupt handlert oda, ahol az int tablazat van Ezzel nyerunk ket tovabbi AVR orajelciklust (az RJMP nem kell) cserebe kb egyetlen interrupt-ot sem tudunk hasznalni AVR-unkon ami az INT1 utan all, hiszen ott a mi kodunk van helyette. Ezt most csak a hasamra utottem, lehet nem lehet kikerulni vminek a hasznalatat, es ez az elv nem mukodik. Mindenestre a legextremebb adott AVR-re (ami pl mas AVR-n nem is igy nezne ki feltetlen pl mas portkiosztas stb) valo optimalizaciot bevetve 7 AVR orajelciklust sporoltunk azonnal.

Na, most azt hiszem eleget irtam ebben a temaban, kerdeses, hogy valakit erdekelt-e egyaltalan

lgb, van neked valami tapasztalatod, hogy lehetne valami avr gcc flag -gel, vagy ilyesmivel lekorlátozni az avr gcc -t,

Sajna nem tudom, elso probalkozast kiveve amit tettem AVR-rel, sose C-ztem rajta Amugy guglival most rakerestem, vannak ilyen kerdesek, de ahogy latom (legalabbis amiket megneztem talaltokat), nem igazan van pozitiv valasz, vagy csak en neztem pont rossz talalatokat

Meg egy (az egesz interrupt handlerben out utan is egy, tehat ketto) AVR orajelciklus sporolas Ha nagyobb AVR es tobb RAM es/vagy egy teljes 8 bites port input eseten szamuzheto minden utasitas ami SREG-et allitani (flags), igy annak mentese/visszatoltese nem kell Igy egyben csokkentettuk az interrupt handler altal elhasznalt regiszterek szamat is. OMG, lassan nem marad utasitas szegeny interrupt handlerben annyira rovid Optimalis esetben kb ennyi:

IN  XL, INPUT_PORT
LD  XL, X
OUT OUTPUT_PORT,XL
RETI
Hoppa ... Ehhez persze az kell, hogy az X regiszter felso byte-ja fixen a foprogram alatt is kb jo helyre mutasson a memoriaba. Mondjuk ezt nem gondoltam elegge at, nem garantalt, hogy jo lesz-e igy. Ha igen, akkor viszont az a durva eset all fenn, hogy ketlem, ez tovabb optimalizalhato lenne, hiszen minden lepes (port olvas, megfelelo emulalat kbd row membol be, valasz kiir, interrupt vege) egyetlen egy utasitas mar csak.

A fenti kod pl ATtiny-n biztos nem megy, meg mason se, ha 256 byte-nal kevesebb RAM van viszont, mert az a trukk hogy elpazarolunk 256 byte-ot eleve, a kerdeses MCU-nak meg annyi RAM-ja sincs mar eleve. Ha fixen tudjuk h az INPUT_PORT-al jelolt porton mi jon a nem hasznalt biteken es az nulla lenne (Tigrian cuccan bizos nem mert a PS/2 data input is, egyszeruen tul keves a lab mashova tenni azon az AVR-n), akkor finomithato esetleg az LDD utasitassal, ahol konstans kis ertek adhato az Y-hoz (akkor az osszes Y YL persze atirando az X-rol) pl. orajel ciklusban ettol nem valtozik ha minden igaz. Vagy vmi hasonlo Kezdel belefaradni az optimalizalasba, meg hat elmult 1 ora is mar, ideje lenne inkabb aludnom, es nem szet-flood-olni szegeny forumot.