Billentyűzet ismét: programozás „orosz rulett” módra

Már használom egy ideje a jó öreg Sun TYPE 5c billentyűzetet, teljesen meg vagyok vele elégedve. A firmware része az más kérdés, de éppen azt reszeltem egy kicsit... A fent linkelt irományban említettem is, hogy a RCTRL az nekem biza hiányzik, ezzel valamit kellene kezdenem. Az egész innen indul...

De ha már itt tartok, a makrózást is „fel lehetne éleszteni”, néha az is jól tud jönni. (Persze: megfelelő szoftverrel ez az OS oldaláról is megoldható, de ez meg nem erről szól most. :) )

Úgyhogy elő a „kedvenc editorom”, ill. a cucc forráskódja, aztán jöhet a reszelés. A C-s programozás még mindig nem az erősségem (bár azért haladgatok...), más programjainak a megértése meg amúgy is egy külön tudományág, de önbizalmam az most van. :) A megoldandó feladatok:

  • A KB oldali soros port kezelője „nem tetszik”, módosítani kellene;
  • Kéne a jobb oldali Control;
  • Makró;

A soros port kezelőjével „csak” annyi a bajom, hogy IT-ből van megoldva. Viszont egy másik IT rutin kezeli az USB-t, ami erősen időkritikus feladat, mivel a sima ATmega88-ban nincs hardveres USB interfész, az egész szoftveresen, bit-banging módon van megoldva. A kommunikáció elejére bitszinten „oda kell érnie” a programnak. Hogy a vonal változásától kezdve mennyi ideje van a kontrollernek hogy ne késse le az adást, azt nem tudom, de emlékeim szerint „nem sok”. Az eredeti soros port kiszolgáló rutinja ezért újra engedélyezi az IT-t, miután kiolvasta az USART adatregiszterét, hogy ez az idő (amit esetleg azon a részen tölt a program, amikor „nem eshet be” az USB-s vonal IT-je) minél rövidebb legyen. Viszont itt kezdődnek a C-s megoldás problémái. :) A soros porti adat feldolgozása egy hosszú rutin, benne néhány olyan függvény hívásával, ami az USB-s „driver” forrásában van, tehát külön fordul → a C fordítónak fogalma sincs, hogy milyen regisztereket használ. A C azt csinálja, hogy a hívó oldal menti azokat a regisztereket, amik neki kellenek, a hívott az használhatja (bizonyos megkötésekkel persze) bármelyiket. Itt viszont a hívó a megszakítási rutin, ezért az IT kiszolgáló a „bevezetésében” menti az összes regisztert (a végén meg visszaállítja természetesen). Csakhogy az AVR-nél ez 32 db. push utasítást jelent, amik – mivel az SRAM-ot használják – 2 órajel alatt futnak. Tehát csak a regiszterek mentése 64 órajelciklust elvisz. Ehhez hozzá jön még az SREG mentése ill. az USART adatregiszter kiolvasása, utána máris engedélyezhető az IT, ami kiszolgálhatja az esetleges USB-s kommunikációt. Hogy ez a „késés” sok-e vagy sem, azt nem tudom, valahogy nincs energiám az USB specifikációt átnyálazni... De viszonylag ritkán „esik be” USART-os IT, mivel a billentyűzet 1200 BAUD sebességgel tolja az adatait → ez maximum 120 kód másodpercenként. És amikor jön egy adat, az sem biztos hogy „eltalál” egy USB-s kommunikációs csomagkezdetet. Meg nem is érzékeltem KB elveszéseket, úgyhogy simán lehet hogy túlaggódom... :)

A jelenlegi állapot „így nem maradhat”, de a KB lassú sorosa itt segítség: a fő programhurok is „oda tud érni” a soros porti adatokért, ezért a kapott kódok feldolgozását bele lehet rakni a main-ba szimpla függvényhívásnak. Az IT-ben marad csak az USART adatregiszter olvasása, a kapott adat mehet bele egy 16 BYTE-os pufferbe, a főprogram meg onnan kiszedheti. Az IT-ben így nincs extra függvényhívás → tud optimalizálni a fordító → csak a tényleg használt pár regiszter lesz mentve → rövidebb ideig tart az a rész, amíg az IT le van tiltva. Hogy szükség van-e erre a 16 BYTE-os pufferre egyáltalán? Ebben se vagyok biztos... Olvashatná az USART-ot a főprogramból hívott feldolgozó közvetlenül is akár... De egyelőre marad ez a megoldás.

Ez eddig egy „elég szép” túrás, csak vajon működik-e? A programozó csatlakozóra jöhet a letöltő kábel, majd nagy lendülettel el is indítottam azt a szkriptet, ami az avrdude segítségével a megfelelő dolgokat beleprogramozza a mikrokontrollerbe... A móka amúgy most kezdődik: vajon bölcs dolog-e annak a billentyűzetnek a firmware-jét programozni, amin gépelve indítom el a programozást? :) A szekrényben találok még billentyűzetet, maximum elő kell szednem. A programozó szkript szépen elindult, csak van vele egy probléma. A letöltendő fw file-t relatív útvonalon éri el, de nem jó könyvtárból indítottam... A szerencsétlen avrdude odáig jutott, hogy kitörölte a m88 programmemóriáját, majd majd sűrű bocsánatkérések közepette közölte, hogy nem találja azt a file-t, amit le kellene töltenie. Facepalm...

Jó, akkor elő a fallback billentyűzet a szekrényből. Ezt sikerült kikapni:

Vajon szívatom-e magam? Facepalm 2...

De azért kétségbe kár esni, a szkriptből csak az elérési utakat kell kitörölnöm, az azért még megy ezzel is. Majd a módosított programozó szkript újbóli elindítása után működik az „eredeti” is, hurrá! :)

Következő feladat: RCTRL. Erre most jobb megoldást nem találtam, mint a Super3 vagy Menu itt Compose billentyűt ideiglenesen lecserélem erre. Eddig is simán megvoltam a menügomb nélkül, most is megleszek egy darabig... De már érik a következő projekt.

Végül maradt a makró: az eredeti „makró motor” csak ki lett kommentezve a forrásból, az alapok ott vannak. De a billentyűket elhasználtam, így egy kicsit módosítani kell az eredeti megoldáson. Ez se egy „agyon használt ficsőr”, így a négy programozható makróból maradt egy. Mivel a Power gombot is bekötöttem, így az használható egy „globális billentyű-billentyűnek”, de ez is majd későbbre marad... A Help billentyű nincs használatban, azt kineveztem az egy szem makró gombnak. A Power+Help elindítja a rögzítést (rövid csippanás a billentyűzetből, hála a beépített csipogónak), az ezután jövő leütések / felengedések megjegyződnek. Majd a végén egy sima Help a rögzítést befejezi (hosszú csippanás). Ezután az egyszerű Help lenyomására „visszajátszódik” az előbb rögzített móka. A limitációk ugyanazok mint az eredeti projektben: maximum 63 lenyomás/felengedés lehet, ha ennél több lesz, egy rövid csippanással kilép a rögzítésből a fw.

A csipogás az egy jópofa dolog, de a Sun-féle billentyűzet firmware nem túl segítőkész a kezelésében, látszik hogy ez sokadlagos feladat volt. Egyrészt be / ki lehet kapcsolni azt, hogy minden gombnyomásnál adjon-e hangot a KB, másrészt be / ki lehet kapcsolni a folyamatos „füttyöt”. Ennyi... A „rövid” csipogás hosszúsága úgy jön ki, hogy a billencs fele el van küldve egy Beep On kód, közvetlenül utána egy Beep Off. A soros port lassúsága miatt szól olyan hosszan, amilyenen... :) A „hosszú” csipogásban annyi a különbség, a be / kikapcsolás között menti a mikrovezérlő az EEPROM-jába a makró 64 BYTE-ját, ez ennyi ideig tart.

Most itt tartok, az elején összehozott bénázás után nem sikerült úgy (fel)programozni a KB-t, hogy működésképtelen állapotba kerüljön, de az azért még mindig jó megállapítás, hogy nem jó ötlet azon programozni, amit programozol. :)

Amúgy vannak még elképzeléseim a firmware-el kapcsolatban, csak az eredeti projekt forrása nekem egy kicsit kusza. Annak ellenére, hogy egy kicsit át is formáztam... :) Valahogy soha se ment más kódjának az értelmezése, legalábbis mindig kínlódtam vele. A saját logikám értem, de másét... :) Úgyhogy az lett az elképzelés, hogy csinálok egy saját programot erre a hardverre. Persze az USB Slave programját azt megtartom, azt a feladatot „nem merem” :) megcsinálni, de a többi az egyszerű mint a faék:

  • A soros porton, a KB felől jövő kódokat egy táblázat alapján át kell alakítani az USB HID szabványban leírt kódokká, majd attól függően hogy lenyomás (make) vagy felengedés (break), egy pufferbe be kell rakni / ki kell venni őket.
  • Az USB-ről jövő pufferben lesznek a visszajelző LED-ek állapotai, ezeket „át kell forgatni” a Sun KB fajta formára, majd a soroson kiküldeni.

Az alap az kb. ennyi. Ezt ki lehet majd egészíteni a +10 gomb extra kezelésével (mint most), készülhet több fajta „layout”, stb... De ezt a mostani kódba maximum úgy tudnám csak belegányolni, az meg elég nagy feladat. Akkor meg már csinálhatnák sajátot is... Az USB Slave rész kezelése a „problémás”, de azt meg ebből a projektből ki lehet lesni. Van egy olyan érzésem, hogy lesz ennek még folytatása. De az nem fog menni „orosz rulett” módon. :)

A végére egy link: itt a mostani reszelés végeredménye, az archívban benne van az eredeti változat is, ill. van benne egy Microsoft®-os :) doksi (KeyBoardCodes.pdf), aminek a C függelékében (26. oldal) ott vannak az USB-s billentyű kódok.

balagesz

---

2012.04.24.

Hozzászólások

Feliratkozás. Én majd egy elpusztult USB-s Fujistu-Siemens billentyűzetet akarok feléleszteni. Bár most már kedvet kaptam egy Sun billentyűzethez is.