Új hozzászólás Aktív témák

• #54 Domonkos addikt Domonkos #51

  Új Válasz 2023-11-12 19:22:21 #54

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Domonkos

  addikt

  válasz Domonkos #51 üzenetére

  

  Hey, tobbi szaktarsam! Hogy halad az a touch-typist-a valas?

  Ebben a lepesben feldolgozzuk a billentyuzet eddig begyujtott allapotat. Amink van, az a keys_down valtozoban 1-1 bit arrol, hogy az adott billentyu eppen nyomva van-e tartva vagy sem; es amit szeretnenk az valami olyasmi, ami jol leirja hogy a billentyuzeten "valojaban" mi is tortent.
  Ez a megfogalmaaz ugyan egy kicsit tag, de a legeslegegyszerubb esetben csak annyirol van szo, hogy a billentyukhoz (a kiosztasnak megfelelo) karaktereket fogunk rendelni.
  Hogy melyik kiosztashoz? Hat... azt is nekunk kell implementalni - egyebkent termeszetesen dvorak.

  Szoval mit is kell egy ilyen lepesnek megtennie?
  Nezzuk mondjuk ezt az egyszeru implementaciot:

  static void
process_keys(void)
{
static kb_state_t prev_key_state = 0;

if (keys_down == prev_key_state) {
return;
}

memset(keys, 0, sizeof (keys));

uint8_t n = 0;
for (kp_t i = 0; i < N_KEYS && n < NKRO; i++) {
if (!BIT_AT(keys_down, i)) {
continue;
}
keys[n++] = get_keycode(i, true);
}
}

  Rogton a fuggveny elejen van egy fuggveny-szkopu valtozo deklaralva, ami arra van hasznalva, hogy ha a billentyuzet fizikai allapotaban nem tortent valtozas az elozo scan ota, akkor a feldolgozast is rovidre tudjuk zarni.
  Itt szinten megjegyeznem, hogy a billentyuzetek kuldhetnenek teljesen valid allapotfrissiteseket akkor is, ha amugy nem tortent lenyomas vagy egyeb - ahogy azt pledaul az eredeti peldaprogram is tette ~10s inaktivitas utan, de tradicionalisan senki sem ir aszinkron firmware-t az elso probalkozasra. Ebben a blogban mi is maradunk az alapoknal.
  Egyebkent meg csak vegig kell mennunk az osszes billentyun es reagalni azokra, amik le vannak nyomva. Azert csak azokra, mert az USB-n csak azt a maximum 6 (NKRO) karaktert kell kikuldenunk, amit epp nyomva tartunk. Jogos kerdes lehet, hogy mi van akkor, ha nem csak a lenyomott, de a felengedett billentyukre is szeretnenk reagalni. Termeszeteser azt is itt tudnank megtenni - ahogy a makrokat es az egyeb ujhullamos dolgokat is itt lenne erdemes lerendeznunk, de a fuggveny mar igy is majdnem 20 sor hosszu, szoval ezek implementalasa az olvasora fognak maradni. Tovabba a get_keycode() fuggveny is azert hivhato meg 2 parameterrel, mert a billentyuk egyebkent siman csinalhatnanak 2 kulonbozo dolgot is lenyomasra es felengedesre. Amugy a retegek hasznalatanal szinte elengedhetetlen lesz, hogy akkor is jo karaktert kapjunk vissza, ha a lenyomas es felengedes kozt valahogy sikerult reteget valtanunk. Ezt azert hagytam benne a kodban, mert ha a vegen meg lesz erdeklodo, akkor errol szivesen irok. Egyebkent erdeklodes hianyaban el fog maradni - es a nem hasznalt argumentrol kapott figyelmeztetes a ti lelketeken fog szaradni.
  Osszegezve itt annyi tortenik csak, hogy a nem lenyomott billentyuket kihagyjuk, a lenyomottakhoz pedig kikeressuk a megfelelo betut (/karaktert/funkciot/makrot/stb.)

  Mivel a keys[] tomb csak N_KEYS hosszu, igy a feldolgozast N_KEYS darab billentyu rogzitese utan meg kell szakitanunk. Bar erre szinten vannak szofisztikaltabb megoldasok is, azok sajnos nem fernek be 20 sorba. Amugy, igen, ennel az implementacional a hardveres elrendezes befolyasolni fogja azt, hogy N_KEYS+ billenty leutese eseten mik is lesznek azok a billentyuk amiket kikuldunk.
  Ez a fuggveny onmagaban is meg tudna tolteni egy teljes blogot - mar igy is eleget irtam rola - szoval inkabb itt vannak az egyeb implicit modon hasznalt dolgok:

  #define BIT_AT(num, n) (!!(num & (1ull << n)))
#define NKRO 6
typedef uint8_t kc_t;
typedef uint8_t kp_t;
kc_t keys[NKRO] = { 0 };

  Ha valamit kihagytam, akkor szivesen valaszolok minden kapcsolodo kerdesre!

Új hozzászólás Aktív témák