Eszembe jutott, hogy a műszerem tud mérni frekit is, így beleírtam az arduino loop -ba, hogy semmi más ne csináljon, csak egy digitális lábat kapcsolgasson.

Ilyen formában 99.02 KHz lett:

void loop()
{
        digitalWrite(12, HIGH);
        digitalWrite(12, LOW);
}



Ilyen formában pedig, 105.6 KHz

void loop()
{
        while(true)
        {
         digitalWrite(12, HIGH);
         digitalWrite(12, LOW);
        }
}



Egy 16 MHz -es AVR -en ...



Külön érdekesség, hogy a freki méréshez elég csak a műszer egyik tüskéjét odaérinteni a lábhoz, és már mutatja is a frekiértéket, még az is mindegy, hogy melyik tüskéjét ...

Ez vajon miért van ?

A 16kHz jó lesz.
De miért nem méred ki a multimétereddel a billentyűzeten, mennyi a CLK órajele?

Mit értesz azalatt hogy jó lesz ? Nem hinném hogy én állíthatnám az órajel frekijét, meg még ha állíthatnám is, az állítási parancsot először az alapértelmezett órajelfrekivel kellene lekommunikáljam -> szetm ez nem állítható.

A billentyűzet hardver tervezésekor állítanak be egy frekit (egy range -en belül, melyről írtam), amit nekem kezelnem kell tudni. Szeretnék felkészülni bármilyen billentyűzetre, nem csak az enyémre. Nagyobb freki, gyorsabb reakcióidő ... lehet hogy igényesebb billentyű nagyobb frekin tolja az anyagot.

Lemérni meg még azért nem mértem le, mert még nem jött meg a PS/2 billencsem, és ha majd le is mérem, akkor is csak az enyémet fogom tudni, nem minden PS/2 billencsét.

Ha jól tippelem max 11 Z80 órajel alatt kell megoldani a dolgot.

Az ugye kis csalással 3 mikroszekundum,

namost ezt írja egy ember assembly -vel megoldott 16MHz -es AVR megszakításról:

"So in total, an ISR using the ISR define will take you 2.625 µS to execute, plus whatever the code itself does."

Itt:
http://www.gammon.com.au/forum/?id=11488



Ez persze még mindíg nem egy raw megszakítás rutin, hanem egy ISR nevű makróval létrehozott függvény, aminek még nem néztem utána, lehet ezt már az AVR C tartalmazza, és lehet nem véletlenül azt csinálja, amit.
Így néz ki:

How long does it take to execute an ISR?

According to the datasheet, the minimal amount of time to service an interrupt is 4 clock cycles (to push the current program counter onto the stack) followed by the code now executing at the interrupt vector location. This normally contains a jump to where the interrupt routine really is, which is another 3 cycles.


Then an ISR routine (declared with the ISR define) does something like this:

// SPI interrupt routine
ISR (SPI_STC_vect)
 118: 1f 92         push  r1   (2)    // save R1 - the "zero" register
 11a: 0f 92         push  r0   (2)    // save register R0
 11c: 0f b6         in  r0, 0x3f (1)  // get SREG (status register)
 11e: 0f 92         push  r0  (2)     // save SREG
 120: 11 24         eor r1, r1 (1)    // ensure R1 is zero
 122: 8f 93         push  r24  (2)
 124: 9f 93         push  r25  (2)
 126: ef 93         push  r30  (2)
 128: ff 93         push  r31  (2)
{
That's another 16 cycles (the cycles are in brackets). So from the moment the interrupt occurs, to the first line of code being executed, would be 16 + 7 cycles (23 cycles), at 62.5 nS per clock cycle, that would be 1.4375 µS. That's assuming a 16 MHz clock.

Then to leave the ISR we have this code:

}  // end of interrupt routine SPI_STC_vect
 152: ff 91         pop r31 (2)
 154: ef 91         pop r30 (2)
 156: 9f 91         pop r25 (2)
 158: 8f 91         pop r24 (2)
 15a: 0f 90         pop r0 (2)    // get old SREG
 15c: 0f be         out 0x3f, r0 (1)  // restore SREG
 15e: 0f 90         pop r0 (2)    // now put old R0 register back
 160: 1f 90         pop r1 (2)    // restore old value of R1
 162: 18 95         reti (4)      // return from interrupt, turn interrupts back on
That's another 19 clock cycles (1.1875 µS). So in total, an ISR using the ISR define will take you 2.625 µS to execute, plus whatever the code itself does.




Magyarul, ha ezt kell használjam, és nem lehet rövidíteni a kódot (simán lehet, hogy csak azért ment el ennyi mindent, hogy C -ben írhassam a megszak kódot), akkor az EP mintegy 3 mikroszekundumunként szaggat(hatna akár) és az én kezelőmön a 16 MHz -es AVR -emen 2.625 mikroszekundum menne a kezeléssel.

Vagyis az idő 90% -a menne el a megszak kezelésére ... és a tényleges bitbeállítások még benne sincsenek ...

Tehát ha egy (eddig talált legnagyobb frekimegjelölést) 33KHz -es frekit veszünk alapul a PS/2 clock -nak,

akkor 30 mikroszekundum időm van (vagy esetleg annak a fele, nem vagyok biztos hogy a data a teljes periódus alatt ki kell egyen tartva) beolvasni a data -t, vagyis lekezelni a PS/2 megszakítást,

az EP 11 ciklusa, amit Zozo mondott az 3 mikroszekundumra teszi azt az időt, ami alatt le kell cseréljem a bill vagy joystick biteket, vagyis lekezelni az EP megszakítást,

úgy hogy egyikből se vesszen el semmi, mert ha PS/2 megszak elveszik, akkor hülye karaktert olvasok be, ha meg EP megszak elveszik, akkor az EP fog hülye bill/joy -t beolvasni ...

mindezt úgy, hogy a 16 MHz -es ezközömön a megszak kezelése akár 2.625 µS ideig is tarthat ...

ja, és a megszak elindulásáig egyéb idők is befigyelhetnek, ezt is írják ...

bíztató kilátások ...

Hát amiről írtam az eléggé assembly volt már ...

De igen, sok paraméter van még azért,

pld. az EP nem fogja 3 mikroszekundumos loop -pal pörgetni folyamatosan a bemenetet, hanem néhány portváltással beolvas, és aztán békén hagyja 1-2 frame -ig az inputot,

amit én egy ténylegesen raw assembly -ben megírt megszakkal kezelek, remélem a 3 mikroszekundum tört része alatt (nem igaz, hogy nem tudom egy 16 MHz -es AVR -en stabilan kezelni, amit egy 4 MHz -es z80 loop -ban pörgetni képes akár), vagyis megkapja a bitjeit, legyen az joy vagy bill,

ennek a megszaknak kell a legnagyobb prioritása legyen, és akár még a PS/2 megszakot is megszakíthatja, ha másképp nem megy,

de igazából úgy gondolkodok, hogy raw assembly -ben a 3 mikroszekundum mittudomén felébe bele kéne férjen a teljes EP megszak kezelés, plussz a teljes PS/2 megszak kezelés, hisz a PS/2 megszak csak egyetlen bitet kell letároljon valami tömbbe, az EP -jé pedig befrissítsen max 8 kimenetet egy tömbből,

az idő második felében pedig ezeknek a tömböknek a kezelése zajlana a főprogramban, olyan sebességgel, amennyi időt a megszakítások hagynak neki ...

Ebből tehát az következne (elvileg, gyakorlatban nem tudom ez mennyire érezhető majd), hogy ha az EP pld. állandó loopban szkennelné a billentyűt, akkor egy bill változás lassabban kerül majd az EP -hez, ha meg csak néha, mondjuk 50 Hz -enként beolvas párat (ami az átlag gyakorlat sztm.), akkor gyorsabban ...

De azért eléggé ki kell élezni a jelenlegi információk szerint azt a két megszak kódot ahhoz, ha azt akarjuk elérni, hogy semmi se veszhessen el soha ...

Fogok azon a két megszakon bíbelődni még sokat sztm ...




És ez csak a PS/2 vs EP. Még nem néztem, hogy az USB könyvtár (melyet valószínűleg nem szeretnék újraírni, és valószínűleg az arduino könyvtárra épül, melyet ez esetben nem lehet kihagyni majd) vajon hány darab és milyen hosszú megszakításokkal operál vajon, hogy lehet majd azt az EP 3 mikroszekundumos dolgávala összeegyeztetni ...

Tök jó, hogy a PS/2 doksik a neten nem értenek egyet abban, hogy a PS/2 clock frekije milyen range -be esik ...

Beszélnek 10-16.7 KHz, vagy 20-30 KHz -ről, de olyat is találtam amelyik 33 KHz -ben maximalizálja ...

Szuper, és tudni tud bárki valamit is ?

Szerintem sajnos fel kell keszulni a "legrosszabbra", azaz, hogy lehet akar 33KHz is amit  a billencs nyomat. Amugy szoktak olyat is, hogy a CLK vonal szintvaltasa az MCU interrupt labara van kotve. Igy nem kell allandoan figyelni. A gond akkor van, ha amugy a "foprogramban" az idozites fontos, es bezavar, ha kozben jon egy megszakitas ...

igy eleve nincs regiszter mentes/visszaallitas, plusz egyeb C overhead-ek se persze.

Ja ... és gyorsan letolok magamnak így assembly -ben egy USB libet is ...