Na ezeket a "röhögve elbírjákat" inkább hagyjuk ...

Miert? A PS/2 max 30KHz clock-jat interrupt kezeles nelkul is kibirod azert egy pl 8MHz-en futo AVR-rel (ha meg kulso kvarc/orajel, akkor 16MHz-ig is lehet menni, vagy hat feljebb is, ha bator vagy, vagy olyan AVR-ed van). Ami kritikus az ugye a B5 portra megy a scan row select es hamar valaszolni kell (ez volt talan a 11 Z80 orajel ciklus adta ido? ez 8Mhz-en futo AVR szamara ugy 22, 16Mhz-es szamara meg 44, es ahogy mar kifejtettem, kb 4 utasitas hosszu interrupt handlerig le lehetne menni, amibe az azert belefer), kb az az a projectben ami a trukkos, ez magyaran ugye a RW0 leeso elere triggerelt AVR megszakitast jelenti.

Úgy látom te sem követed a dolgokat "túl szorosan", de igen pont ez az első allomás, ahova el akarunk jelenleg érkezni. Ezért nyúzom zozót a custom mouse.xr -miatt, de végülis nem eszik olyan forrón a kályhát, lesz még neki ideje reagálni a kérdéskörre egyenlőre úgy tűnik ...

Kovetem, csak olyan vagy mint en, tul sokat irsz Ez onkritika is volt, nem kell megsertodni

Annyi a különbség, hogy én nem főprogramból tervezem (jelenleg) a PS/2 kezelést sem, hanem 3 megszak lesz, melyek egymást is megszakíthatják, és a legmagasabb prioritású az EP megszak lesz természetesen (így azt már nem szakítja meg a másik kettő reményeim szerint).

Aha. Akkor a forprogram semmit nem csinal (na jo, ez koltoi tulzas volt azert, hogy "semmit"), mert minden megszakitasban lesz Bar mondjuk akkor nem kell vele foglalkozni, hogy varj az adott esemenyekre, hanem "adodik", az is igaz.

Miert?

Azért mert én is így nyitottam hogy "lazán, meg röhögve" meg C -ben, meg babám ... azt most ott tartok, hogy azt tervezgetem, hogy még a főprogramot is kénytelen leszek lehet assembly -ben megírni, és a 10MHz z80 még mindíg egy kérdés ...

Szóval mindez nem "röhögve" hanem pedig hekkelve ...

csak olyan vagy mint en, tul sokat irsz

Tévedés. Sokat kell írni. Olvasni is.

Akkor a forprogram semmit nem csinal

Szerintem meg az csinál majd "mindent". Épphogy a megszakok azok amik semmit nem csinálnak.

A két PS/2 megszak a felszólításra beolvas és lerak egy tömbbe +1 bitet, és semmi mást nem csinál.

Az EP megszak meg a felszólításra beolvas egy 4 bites inputot és egy tömbből válaszol rá egy 8 bites outputot, és semmi mást nem csinál.


És aztán lesz a főprogram, aki akár C -ben lesz írva, nem fog gyorsan sem időzítve futni, és loop -ban feldolgozza a 2 PS/2 megszak által tömbökbe tolt biteket és azok hatására állítja azt a tömböt, amiből az EP megszak felelget az EP -nek.

Ráadásul a loop -jában még ő is frissíti az output értéket az EP irányába, azzal a komótos sebességgel, amire képes lesz a loop -ja.

Harmadrészt ő fog felelni azért a magasszintű logikáért is, ami a testreszabást fogja végezni, meg ilyeneket.

Szóval sztm pont hogy a megszakok azok, akik "nem csinálnak semmit" ...

Bár végülis ebben nem vagyok olyan biztos, mert a megszak elkezdődéséig csak 5 avr órajel telik el, akkor ott az ember gyorsan lerendezi a z80 -at (mondjuk további 5 avr orajel alatt)

Hmm, nem tudom amugy (utana kene nezni vegre) hany orajelciklus AVR-en az interrupt kezeles pontosan. Emlekeim szerint 4, de ehhez hozzajon az, hogy az eppen futo utasitast elobb meg kell csinalnia, ami legjobb esetben 1, legrosszabb esetben talan 3 (?) orajel ciklus.

és akkor igaz hogy utána kiesik még 5 avr órajel a megszak visszatérésekor, de mivel a z80 -nak 11 órajel (10MHz z80 -nál az 1 mikroszekundum) alatt csak felelni kell tudni,

Hat az jo kerdes, hogy kiesik-e. Marmint Z80 szempontjabol. Ugyanis,  ugye "legrosszabb" esetet elkepzelve (bar ez nem realisztikus annyira szerintem, mert Z80 csak leteszi vhova az eredmenyt stb kozben, tehat mas opcode is van!), pl       OUT (0xB5),A  / IN A, (0xB5). Azaz OUT utan azonnal IN. Utana viszont kisse nehezkes lenne Z80 szamara azonnal (nincs masik opcode) kezdeni elolrol, mert csak le kell tarolni az eredmenyt, vagy eleve loop-ban kerdezi, miegymas. Amit el tudok kepzelni mint legrosszabb eset, amikor a fenti szekvencia folytatodik, az pl ez:


Ugye itt kerdeses, hogy ilyen valaha komolyan kell is, hogy ennyire "surrun" jon egymas utan. Azonban meg ha van is ilyen, azt se felejtsuk, hogy egy IN vagy OUT vegrehajtasa a Z80-nak messze nem egy orajelciklus, es azt is vizsgalni kell, hogy egy adott Z80 utasitason _belul_ mikor tortenik az aktualis I/O muvelet valojaban. Azaz AVR interrupt szintrol nezve, a valaszt mar pl beallitottuk (az ugy is marad) mielott meg eljutott volna a Z80 az IN -ig vagy legalabbis az IN azon "reszehez" amikor a valodi I/O zajlik. Igy lehet, hogy maga pl az IRET az AVR-n meg az IN "vege fele" lefut, igy mire a kovetkezo OUT azon reszehez erunk ahol Z80 kozli hogy I/O request van, az AVR mar vissza is tert a megszakitasbol.

de valószínűleg nem tudja 11 órajel alatt a következő változását is megejteni a b5 porton, szóval mielőtt jön a következő EP megszak, a 11 z80 órajelen FELÜL lesz még több z80 órajelnyi idő, amíg nem tud jönni a következő EP megszak ... na ezen ciklusok alatt futhatna a másik két megszak és a főprogram ...
Szóval még az is lehet, hogy menni fog 10 MHz -es z80 -nal is ...

Nem kizart Tigrian kodjat lehet optimakolni azert, bar egyes ilyen muveletek (lasd ejszakai leveleimet) kisse hajmeresztoek es mashol okozhatnak problemat (pl tobbi megszakitas hasznalatanak ellehetetlenedese, cserebe viszont 2 AVR orajelciklus megsporolasa).

Hát ez már a plussz alkatrészes módszer, ami már majdnem mindegy akkor hogy egy másik mcu, vagy pedig egy dual port ram, vagy egyéb típusú dolog, amiket linkeltetek korábban ...

Ami miatt viszont mégis elgondolkodtató, az a kivezetett zsinórok száma ... ezeken az AVR -eken minimum 4 fajta busz/port van, amin keresztul hardveresen támogatva tudnak adatot cserélni, a soros porton kívül is ... szóval lenne hardveres, gyors, 2-4 érintkezős átviteli lehetősség épp elég.

És legrosszabb esetben 4(valami busz)+2(táp) = 6 kivezetett vezetékkel meg lehetne oldani.
Az azért sokkal kevesebb, mint a 8(key line)+4(key addr)+3(joy line)+1(key "megszak")+1(reset)+2(táp) = 19 drót.

A 6 vezetéket egy síma PS/2 csatin lehetne csatlakoztathatóvá tenni egy külső eszközzel ... és nem kéne valami 19 pólusú csatlakozó, meg széles szalagkábel ...

És nem kéne új ismeretlen elektronikákat sem beszerezni, csak venni +1 készre szerelt AVR lapot ... és akkor sebességkérdés is mindjárt megoldva ...

Ha meg már úgyis be kell forrasztani a drótokat, mindegy hogy beforrasztunk egy mini kis lapkát is, vagy sem ...

Nagyon szimpatikus !

Egész pontosan a belső cuccba nem kéne semilyen up/down uzenet,
az egy sima 16 bájtos tároló lenne, amiből végezné az EP frissítését,
és kívulről írni és olvasni engedné ezt a 16 bájtot.

persze 1-2 bájttal még lehetne több is, és akkor oda lehetne tenni speciális biteket, mint a reszet, joyok, vagy ilyesmi ...

Azt is lehet, csak ide tobb vezetek kell, meg specko alkatresz (pl DP RAM).

Nem, én a belső avr mcu -s dologról beszéltem.

Azt pontosítottam, hogy a 2 MCU közé nem kellenek magas szintű üzenetek, úgy mint up/down, mouse pos, ilyenek,
hanem a kommunikációjuk csak pár bájt írására olvasására kell szorítkozzon.

Akkor nem ugyanarrol beszelunk, mert nekem kulso kis dobozkakent jobban tetszene az egyik "fele" akkor meg fontos lehet, hany drottal es milyen hosszu drottal van osszekotve. Amugy pl a soros kommunikacio elonye extrem hulyesegre: pl PC-t hozzakotsz soros porton (vagy USB-serial atalakito) es akkor teszt vagy mas jeleggel PC-rol sw-bol is lehet "vezerelni" az EP-t, kvazi. Mondjuk ertelme nem tudom van-e.

Amugy ha mar Dual Port RAM-ot akarsz beepiteni, lehet aztan uber szofisztikali, pl nem csak a B5 output-al indexelni, hanem mas porttal is ami pl kulso joy-hoz kell, vagy a mouse box strobe jelevel stb, es akkor aztan kvazi minden eger/joy/bill kombinacio lefedheto talan, eleg csak a DP ram-ot megfeleloen irogatni, ez kisse komplexebb megoldas, es talan dragabb is, de le lehet fedni vele sok mindent es idozitesi gond sincs mint sw-bol AVR-rel megprobalni.

Na most megyek a falnak ...
Az összes többit már te kavartad bele ...

Oke, feladom, inkabb nezem a SymbOS disasm-ot. Ugyanis akkor nem ertem mit akarsz, de ezen ne vitakozzunk