Keresés

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

  • Domonkos

    addikt

    válasz Domonkos #70 üzenetére

    Na de akkor nezzuk, hogy tenylegesen mibol is elunk! :)

    Ahogy azt emlitettem, a legtobb firmware a kiosztast retegekben kepzeli el. Egesz termeszetes otlet.
    Altalaban egy 3 dimenzios tombbel van az egesz megvalositva, amiben a dimenziok a sorok, az oszlopok es a retegek.
    A retegeket altalaban be es ki lehet kapcsolgatni aszerint, hogy epp melyik funkciot szeretnenk elerni. Mar most megjegyeznem, hogy itt direkt (es a jovoben is) funkciot irtam gomb / billentyu / karakter / stb. helyett, mert ez a legaltalanosabb. Mi a baj a tobbivel?
    A billentyuzeten billentyuk vannak, es nem gombok. A billentyu amugy is a fizikai resze a dolognak, ami nem minden esetben jo kifejezes ezekben a kontextusokban. A karakterrel az a gond, hogy nem minden billentyu - peldaul az fn - leutese eredmenyez kimeno karaktert a kabelen.
    Egyebkent a "funkcio"val sem vagyok nagyon elegedett, de ez legalabb elegge altalanos, hogy magaba foglalhassa az osszes eshetoseget. Peldaul abban az esetben, ha egy leutes az tenyleg csak egy karaktert ut, akkor arra meg mindig gondolhatunk ugy, hogy a leutes az igazabol egy funkciot hajtott vegre, aminek az eredmenye (vagy mellekhatasa (... ki milyen hatterrel jott)) egy karakter lett. Viszont, hogy ezt a funkciot mettol-meddig tekintjuk "egy funkcio"nak, az megint csak vita targya lehet. Ahogy az elozo kommentemben is irtam, ugy minden egyes leutest sok-sok funkcio dolgoz fel (noha legtobbjuk csak siman ignoralja) es ezert nem lenne celszeru altalanositani es azt mondani, hogy az egesz lanc az csak egy hosszu funkcio. Bar egy fuggvenyhivassal feljebbrol tenyleg csak egy, de nekunk sosem lesz ugy egy klassz firmware-unk, hogy nem megyunk ezeken mi magunk vegig.
    Lenyeg a lenyeg: a leutesek (es felengedesek) funkciokat hivnak meg, amelyek amellett, hogy egy-egy karakter kikuldesere kesztethetik a billentyuzetet, meg sok mas dolgot is csinalhatnak. Egy picit altalanositva minden allapotatmenetre rahuzhatjuk, hogy valami fuggvenyt hivott meg, de azok a fuggvenyek - mondjuk a legtobb billentyu felengedese - nem valt ki semmi mellekhatast. Sima No-Op-ok.

    Szoval altalaban van egy alap-reteg, ami mindig aktiv. Ha vizualisan szeretnenk elkepzelni, akkor ez a legalso. Amikor egy masik reteg is aktiv, az azon levo funkciok "elfedik" az (azonos pozicion levo) lentebbieket. Ha tobb reteg is egyszerre aktiv, akkor a logikailag legfelso aktiv reteghez rendelt funkciot fogja figyelembe venni a billentyuzet. Altalaban lehetoseg van egy transparent (de sok mas neven is fut) keycode-ot is hasznalni, aminek az a lenyege, hogy nem fedi el a reteg alatt levo funkciot. Ennek ugye nem sok ertelme van, ha csak egy-egy reteget kapcsolgatunk be az alap fole egyszerre, de ha harom vagy tobb reteg aktiv, akkor lehetoseget ad komponalasra.

    A valtogatasra van vagy fel tucat kulonbozo modszer, ami ilyen-olyan esetekben johet jol:
    - Valthatunk ideiglenesen, amig a billentyut nyomva tartjuk. Lenyomaskor bekapcsolhatunk vele egy reteget, felengedeskor kikapcsolhatjuk. Ezt csinalja a laptopokon az fn, de igy mukodik a normal shift is, ha egy pillanatra ugy tekintunk a kis es nagy betukre, mint ket egymas folott levo retegre, amit a shift-tel valthatunk.
    - Van gombnyomasra ide-oda kapcsolhato retegvaltas is. Ez kb. ugy mukodik, mint a caps-lock. Ha sok kulonbozo karaktert kell bevinni egy masik retegrol, akkor erdemes lehet talan ezt a valtast hasznalni az elozo helyett. Itt ugyan vesziteni fogunk egy extra leutest amikor majd vissza kell valtani, de ha olyan az input, akkor ez sokszor sokkal kenyelmesebb lehet. (peldaul szamologepezesnel a szamok lehetnek a jobb kez alatt, jelek pedig a masik oldalon)
    - Az elso variaciot kombinalhatjuk, hogy amellett hogy az adott billentyu retegvaltasra is hasznalhato, ha nem nyomunk meg semmi mast a valtott retegen, akkor felengedeskor egy masik funkciot valthatunk ki. Ezt rengetegen hasznaljak arra, hogy a modositoknak adjanak plusz egy funkciot, vagy epp arra, hogy a modositokat kozelebb vigyek a home-row-hoz (konkretan ra is lehet rakni (home-row mods)). Azt hogy a "felengedes" funkciojat minek kell triggerelnie, az megint csak egy vitatott kerdes, mert siman lehet egy timeout is a felengedes helyett (vagy a felengedes es a timeout hivhat kulonbozo funkciokat is attol fuggoen, hogy melyik tortenik elobb...) szoval ez egy nyitott kerdes - rengeteg szemelyre szabasi lehetoseggel.
    - Ezek nagyreszt kombinalhatok tapping-gel is, amiben az elobb emlitett valtasokat tovabb lehet komplikalni, peldaul olyannal, hogy 2-3 vagy tobb (gyors) leutesre kulonbozo retegekre lehet valtani. Igy akar egy billentyuvel is meg lehetne oldani az osszes retegvaltast.

    Es ezek meg csak az alapok voltak.

    A tovabbiakban eldontom, hogy ezek kozul erdemes lenne-e valamelyiket ennel jobban is kivesezni vagy egybol mehetunk a bonyolultabbakra.
    Ti hasznaljatok valamelyiket? Vagy szeretnetek valamelyikrol egy jobb diskurzust? Hatha adnank egymasnak valami uj, mar bevalt otletet! :)

    .spoiler
    Pompas lenne, ha sikerulne ennel a temanal vagy valami hasonlonal egy kicsit tobbet idozni - mikozben ezt a topikot aktivan tartjuk - mert a hatterben ugyan keszul egy ujabb, egy olyan otletekre epito firmware, amit soha az eletben nem latott ez az elcseszett hobbi, sajnos par komponens licensze miatt jelenlegi formaban nem tudom publikalni. A komponensek ujraimplementalasahoz pedig ujra szakirodalmat kell olvassak. Sohaj.

  • Domonkos

    addikt

    válasz Domonkos #67 üzenetére

    Ha egy kicsit jobban korulnezunk, akkor azert talalhatunk az interneten par egyeb, a mienknel egy kicsit jobban kifejlett alternativat is. Most talan az egyik legnepszerubb QMK neven fut, ami egy TMK fork, millionyi hozzaadott funkcioval.
    A terveim szerint a kovetkezo par napban egyesevel vegegmegyek az osszes feature-on es jol vegiggondolom es (kifejtem), hogy az egyes megoldasok hogy es mikent lehetnek hasznosak.

    Az otlet az osszes feature-nel nagyjabol ugyanaz. Talan az egyik legtermeszetesebb is.
    A firmware-uk - hasonloan a mienkhez - eloszor beszkenneli az osses billentyut. Ha nincs valtozas a billentyuk allapotaban (nem nyomtunk le ujat, es nem is engedtunk fel egy mar lenyomottat sem), akkor lenyegeben nem csinal semmit, hanem csak elorol kezdi a szkennelest. Ha van valtozas, akkor - egy esetleges debounce logika futtatasa utan - a billentyut a keymap-nek megfeleloen egy keycode-hoz rendelik. Itt erdemes megjegyezni, hogy ez a keycode nem (feltetlen) az a keycode, ami majd az USB-n kimegy, hanem csak egy "funkciohoz rendelt azonosito" (amit egy sima enum-mal is lehetne definialni) - ami egyebkent egy nagyon jo absztrakcio (de az ovukenel ezt egy kicsit meg tovabb is lehet tolni). Hogy epp melyik lesz az a keycode ami a leuteshez lesz rendelve (vagy funkcio amit a billentyuzet majd vegrehajt) az a keymap-tol es a billentyuzet egyeb allapotaitol is fugghet (a billentyuzet egyeb allapotat pedig a keycode feldolgozasanak mellekhatasai tudjak majd befolyasolni - ez nem eliras, tenyleg oda-vissza vannak egymasra hatassal).
    Szoval miutan megvan a keycode, az rovidesen feldolgozasra kerul. QMK eseteben ez epp ugy tortenik, hogy a TMK-s feldolgozas utan athivnak a quantum/quantum.c:process_record_quantum()-ba. Ez egy bool funkcio, es a felepitese nekem nagyon szimpatikus. Lenyegeben egy nagyon hosszu funkcio1 && funkcio2 && ... lanc amiben minden egyes funkcio eldontheti, hogy: csinal-e valamit a keycoddal, megvaltoztatja-e, vagy csak siman "lenyeli", rovidre zarva a tovabbi funkciok elereset. Az otlet tenyleg csodas, de a funkciok helyes sorrendjet eltalalni nagyon-nagyon nehez. Abban az esetben ha tobb olyan funkcio is van, ami ugyanazokra a keycode-okra figyel, akkor neha nem a felhasznalo altal remelt sorrendben reagalnak es nem vart eredmenyt produkaljak. Megcserelni oket elegge konnyu, de megbizonyosadni arrol, hogy a cserevel nem rontunk-e el valami mast ugyancsak nehez feladat.

    Szoval; mik is ezek a funkciok? :)

  • 0xmilan

    addikt

    válasz Domonkos #67 üzenetére

    Jelen! Bar jo melyre kellett gorgetni az 'itt szoltam hozza' listaban. :P

  • Domonkos

    addikt

    válasz Domonkos #66 üzenetére

    Nos, a probanyak nem igazan hozta azt kontent szintjen, amit titkon remeltem tole, de sebaj; terjunk inkabb vissza a programozashoz! :)
    A posta mar kozel jarhat a cuccommal, szoval ideje lenne ezt befejezni, hogy kesobb ne kelljen mar masra varni. :))

    Kb. ott hagytuk abba, hogy a firmware alapja mar mukodott, karaktereket tudtunk irni az osszes billentyuvel, de azok nem voltak semmilyen rendszer szerint rendezve. Olyan sorrendben jottek ki a droton, ahogy az a hardveres matrix adta. Elso koron at kellene mappelni oket. Mondjuk dvorak kiosztasra. Ez nem kellene, hogy nehez legyen, mert ehhez csak a keymap tomb elemeit kell egy kicsit atbabralni.
    A nagyobb feladat az az lesz, hogy hogyan tesszuk majd elerhetove a tobbi billentyut.
    Ugye a datahand-en van felenkent 25+1 billentyu. Osszesen 52. Ez pont a fele annak, mint amennyi egy full meretu billentyuzeten van - meg egy laptophoz kepest is keves.
    Szoval valahogy meg kellene oldani azt is, hogy olyan karaktereket is lehessen utni, amiknek nem jut majd dedikalt billentyu. De hogy? :F

    Tapasztalt szamitogep felasznalokent azert szerencsere lattam mar a gyakorlatban mukodo megoldasokat erre a problemara.
    Talan a legelterjedtebb az a laptopokon is hasznalt fn-billentyus. A mukodese egyszeru: A billentyuzeten van egy extra, specialis funkcioval ellatott billentyu (fn), ami onmagaban (altalaban) nem hasznalhato semmire, de hasonloan, mint mondjuk a shift, amig nyomva tartjuk, addig egyes billentyuknek megvaltozik a funkcioja. Majd ha felengedjuk, akkor minden visszaall az alap (base) allapotba. Ez egy eleg hatekony modszere annak, hogy lenyegeben megduplazhassuk az osszes elerheto funkciot. Es a legtobb felhasznalashoz altalaban eleg is szokott lenni. Egyedul talan ott lehet elrontani, ha nem jol valasztjuk meg a karaktereket amiket szamuzunk erre a retegre. De egyebkent ha ez sikerul ES az fn-t is kenyelmes poziciora tudjuk helyezni, akkor kb. meg is oldhatja ezt a problemat. Es ez egy tenyleg jo megoldas. :K

    De letezhet-e ennel jobb? Tovabba mit csinaljunk abban az esetben, ha nekunk pont 52 billentyunk van? Ha egyet felaldozunk az fn-re, akkor a 2*51 mar nem lesz elegendo a 104 kulonbozo funkciora... :N
    hmmm... :(

    Mindenkeppen kell valami jobb! De mi?

    Kep ma sajnos nem lesz - es egyebkent ez a bejegyzes sem itt rendeltetett volna befejeztetni - de az elmult 5 honapban elvesztett olvasoimat talan konnyebben visszaszerzem, ha egy kicsit lassabban inditom ezt a blogot vissza. - Vagy ha mar mindharman ittvagytok, akkor szoljatok! ;)

  • Domonkos

    addikt

    válasz Domonkos #62 üzenetére

    Es, hey! Ket honap utan ujra itt! :)
    Sajnos ilyen-olyan okok miatt nem nagyon volt lehetosegem a billentyuzetezessel foglalkozni, amiben talan annyi jo van, hogy igazabol ti sem maradtatok le ugy igazan semmirol.

    A kovetkezo napokban ki kellene talalni, hogy mennyire akarjuk az eddig megepitett konstrukciot tovabb vinni - mert egyebkent szerintem mukodokepes lenne - viszont egyeb elvi okok miatt megsem biztos, hogy ebben a formajaban szeretnem majd hasznalni...
    Arrol nem is beszelve, hogy $60-nyi kontroller egy billentyuzetben nevetsegesen sok.

    Barcsak lenne valami alternativ megoldas ami tobb honapnyi kontentet es megannyi tanulasi lehetoseget biztositana szamunkra! :U

    Az asztal es a fal koze beesve ezt talaltam:

    Tobb honapnyi kontent es megannyi tanulasi lehetosegnek az alapja

  • -igu-

    veterán

    válasz Domonkos #62 üzenetére

    "A kovetkezo napokban ki kellene talalnunk, hogy hogyan lehet egy jobb kiosztasba elrendezni a billentyuket."

    tűkön ülök
    vagy mi

  • Domonkos

    addikt

    válasz Domonkos #61 üzenetére

    A bal oldal tesztelese egyszeru.
    Mivel a sajat Teensy-m meg uton van, a jobb oldalbol athelyezve tudjuk egyelore kiprobalni a mukodest - egyszerre a kettot nem. :(
    A proba menete megegyezik a tegnapival. Flash-elni nem kell; a hardver majdnem teljesen megegyezik; a szoftver maradhat ugyanaz.
    Es ez is szepen mukodik! Szuper! Hardveres problemaba innentol tenyleg nem fogunk utkozni. :)
    A kovetkezo napokban ki kellene talalnunk, hogy hogyan lehet egy jobb kiosztasba elrendezni a billentyuket. Annyi mar most is latszik, hogy a matrixbol az Y es a 2 helyen levo karakterekhez nincsenek fizikai billentyuk. Azokkal nem nagyon kell majd torodnunk, csak a tobbivel.

  • Domonkos

    addikt

    válasz Domonkos #58 üzenetére

    ...and all I got was this lousy t-shirt.

    Szoval akkor: make
    Eeeeees:

    Size after:
    text data bss dec hex filename
    2224 2 39 2265 8d9 datahand.elf

    Kint is van! 2226 byte, ami az osszes felhasznalhato memorianak az 1.7%-a. :) Kompakt.
    A teensy_loader-rel ugyanugy felrakhatjuk, mint az elejen a peldaprogramot.
    A folyamat csupan masodpercekig tart, aminek a vegen az eszkoz visszacsatlakozik, az operacios rendszer pedig felismeri:

    [28859.985183] usb 3-1: Product: Datahand
    [28859.985188] usb 3-1: Manufacturer: Domonkos
    [28859.988464] input: Domonkos Datahand as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/0003:16C0:047D.001A/input/input65

    A billentyukhoz hozzaerve pedig:

    Wooo!! Siker! :)) :))
    Oruljunk egy kicsit tobbet:
    :)) :)) :))

    Elsore! ;)
    Es alig tartott egy honapig.
    Mar csak a masik oldal van hatra. Szerencsere mivel szuper portabilisre irtuk a kodot, igy az atvitel egyszeru lesz. A varakozasunk az az, hogy a masik oldalnak ugyanezeket a karaktereket kell majd utniuk hasonlo sorrendben, mert a billentyuk matrixa megegyezik. Sot! Amennyire jo szoftvert irtunk, a hardver majd biztosan orulni fog, hogy futtathatja es emiatt sem fog keresztbe tenni. :K

    De hogy holnapra is maradjon kontent, a masik oldal kiprobalasat elrakjuk addig. :P

  • 0xmilan

    addikt

    válasz Domonkos #58 üzenetére

    > Egyebkent kerdesek johetnek! :K

    Milyen csomagokra varunk a postatol? :D

  • Domonkos

    addikt

    válasz Domonkos #56 üzenetére

    📈

    Vegul mar csak egy feladat maradt, tudatni a hoszttal hogy mi is tortent. Ez szerencsere egyszeru. Annyit kell tennunk, hogy az usb_keyboard.h altal deklaralt keyboard_modifier_keys-t es keyboard_keys[]-t a korabban osszegyujtott scan code-okkal feltoltsuk, majd meghivjuk az usb_keyboard_send() fuggvenyt. A tobbit a hardverhez kapott fuggvenyek intezik.
    Szoval a kuldes rank eso reszet implementalhatjuk mondjuk igy:

    static uint8_t
    send_updates(void)
    {
    static uint8_t prev_keys[NKRO] = { 0 };

    if (!memcmp(keys, prev_keys, sizeof (keys))) {
    return 0;
    }
    memcpy(prev_keys, keys, sizeof (prev_keys));

    keyboard_modifier_keys = 0;
    memcpy(keyboard_keys, keys, sizeof (keyboard_keys));

    return usb_keyboard_send();
    }

    Sajnos ma sem usszuk ezt meg kisebb trukkok nelkul, itt is be kell vetnunk egyet. Ha nem tortent valtozas, akkor nem kell semmi valtozast kuldjunk. (A jelenlegi megertesem alapjan a tobbszori kuldessel nem csinalnank kart, de abszolut felesleges.) A billentyuk nyomva tartasat nem kell egyeb modon kozolnunk, mint amikor a lenyomas tortenik, akkor elkulnedi a lenyomott karakterkodot - a tobbi lenyomott billentyu kodjaival egyutt - majd felengedeskor kikuldeni a tovabbra is nyomva tartott billentyuk kodjait a felengedett billentyunek a kodja nelkul. Ha azt szeretnenk jelezni, hogy egy billentyu sincs epp tartva, akkor egy csak 0-kat tartalmazo tombot kell kuldjunk.
    A keyboard_modifier_keys hasonloan mukodik a modokra, viszont ott minden egyes bit egy-egy modosito billentyunek lenne megfeleltetheto. Mivel mi nem hasznaltunk eddig egyet sem, igy ezt most fixen 0-n hagyhatjuk. Kesobb erre persze szuksegunk lesz, szoval mar most sem erdemes kihagyni a kodbol.
    Tovabba mar csak ez a par deklaracio hianyozhat:

    extern uint8_t keyboard_modifier_keys;
    extern uint8_t keyboard_keys[6];

    Es egyebkent keszen is lennenk. Ha mindent jol csinaltunk akkor nem maradt mas hatra, mint egy forditas plusz egy flasheles; es utana johet az elesben valo teszteles - egy oldallal. :( Mert a tovabbhaladas jelenleg csak a postan fog mulani. Ha sikerul a heten kihozniuk a csomagjaimat, akkor a blog szunet nelkul folytatodik, ha nem akkor lehet hogy egy kis kenyszerszunet kovetkezhet. Elnezest miatta, de nem tudom mar lassabban irni a blogot. :D

    Egyebkent kerdesek johetnek! :K

  • Domonkos

    addikt

    válasz Domonkos #54 üzenetére

    Ohh, most latom csak, hogy az elso if blokk utan lemaradt egy:

    prev_key_state = keys_down;

    Termeszetesen ugy nem lenne sok ertelme az "elozo" allapothoz hasonlitgatni a mostanit, ha az sosem koveti a valtozasokat. :B

  • Domonkos

    addikt

    válasz Domonkos #55 üzenetére

    🧠🚲

    Nos, a kiosztas megalkotasahoz igazabol ketfele modszer kozul valaszthatunk:
    - Ha meg nem lattuk az eszkozt mukodni, akkor siman visszakovethetjuk, hogy mi hova van kotve es huzalozva es annak alapjan megsejthetjuk, hogy melyik billentyu valojaban melyik kp-hez fog tartozni
    - Vagy ha mar mukodik a billentyuzet, akkor siman kezdhetunk egy "abc"-s kiosztassal, majd a billentyuket egyenkent lenyomva a karaktereket a helyes pozicioba rakhatjuk.

    Bar akarmennyire is nem mukodik meg a billentyuzet en megis az utobbi mellett fogok donteni, mert sokkal kisebb idoraforditassal lehet eredmenyhez jutni vele, meg akkor is, ha nem feltetlen az elso vagy a masodik flashelesre lesz meg a helyes kiosztas. Tovabba, amig nem mukodik az eszkoz, addig a helyes kiosztas sem ad tul sokat az egeszhez. :U

    Szoval kezdjunk mondjuk ezzel:

    #define N_ROWS 14
    #define N_COLUMNS 4
    #define N_KEYS (N_ROWS * N_COLUMNS)

    const kc_t PROGMEM keymap[N_KEYS] = {
    KEY_A, KEY_B, KEY_A, KEY_B,
    KEY_C, KEY_D, KEY_C, KEY_D,
    KEY_E, KEY_F, KEY_E, KEY_F,
    KEY_G, KEY_H, KEY_G, KEY_H,
    KEY_I, KEY_J, KEY_I, KEY_J,
    KEY_K, KEY_L, KEY_K, KEY_L,
    KEY_M, KEY_N, KEY_M, KEY_N,
    KEY_O, KEY_P, KEY_O, KEY_P,
    KEY_Q, KEY_R, KEY_Q, KEY_R,
    KEY_S, KEY_T, KEY_S, KEY_T,
    KEY_U, KEY_V, KEY_U, KEY_V,
    KEY_W, KEY_X, KEY_W, KEY_X,
    KEY_Y, KEY_Z, KEY_Y, KEY_Z,
    KEY_1, KEY_2, KEY_1, KEY_2
    }

    Ez 2*2*14 billentyu. Ha visszanezzuk, hogy hogy toltjuk fel a keys_down bitmezot, akkor talan ez egy jo elrendezes lehet, mert az egyik hand unit-bol csak olyan poziciokbol olvasunk amelyeknek a 4-gyel valo osztasi maradeka 0 vagy 1 (ezzel a tordelessel az elso ket oszlop), a masik oldalrol pedig 2 vagy 3 (a jobb oldali oszlopok). Igy legrosszabb esetben csak az oldalakat cserelhetjuk fel. :)
    A KEY_# konstansok azok az usb_keyboard.h-ban vannak definialva. Ezek az ertekek egyeznek azokkal, amik az USB HID szabvanyban is szerepelnek, szoval egyeb transzformaciora itt nem lesz szugsegunk. :K
    Egy dolog lehet meg itt emlitesre melto, az pedig a PROGMEM kulcsszo; ami nem szabvanyos C-s kifejezes. Ez egy avr-gcc kiegeszites es arra lehet hasznalni, hogy a forditot ravegyuk, hogy a programmemoriaba pakolja a "valtozonkat". Ezzel 54 byte-nyi memoriat sporolhatunk. :))

  • Domonkos

    addikt

    válasz Domonkos #54 üzenetére

    Kapizsgaljatok mar, nem? :D

    Ami "ki fog menni a droton", az a lenyomott billentyuknek megfeleltetett karakter kodok (USB- es billentyuzetes-lingoban scan code). Azt hogy melyik billentyu tenylegesen melyik karaktert fogja utni, azt mi hatarozhatjuk meg.
    En ezt a kovetkezo implementaciot valasztottam:

    static kc_t
    get_keycode(const kp_t kp, const bool press)
    {
    (void)press;
    return pgm_read_byte(&keymap[kp]);
    }

    A kod maga nagyon egyszeru, lenyegeben csak a keymap[] tomb kp-adik elemet adja vissza. Az egyetlen kisebb csavar az egeszben az annyi - mivel a keymap-et hagyomanyosan mindenki statikusra irja az elso firmware-eben, es mi sem teszunk most maskepp - hogy folosleges azt memoriaban tarolni; igy kerhetjuk a forditot, hogy a tombot rakja a programmemoriaba. Viszont mivel a programmemoria kulonbozo cimteret hasznal, igy annak eleresehez egy konverzio szukseges. Ezt a konverziot a pgm_read_byte() vegzi el - ezt a fuggvenyt nem kell nekunk implementalni, az avr-es konyvtarbol ingyen kapjuk.
    De hogy pontosan hogyan kell a keymap[] tombot feltolteni, hogy az egy dvorak kiosztast eredmenyezzen, azt holnap kitalaljuk! :K

  • 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. :P
    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! :K

  • 0xmilan

    addikt

    válasz Domonkos #51 üzenetére

    Amikor azt irtad, hogy "egyszeru", akkor egyaltalan nem ez volt az elso gondolatom. :D
    Nem hittem volna, hogy optikai kapcsolok vannak benne - mar ha ez annak minosul.

  • Domonkos

    addikt

    válasz Domonkos #50 üzenetére

    A billentyuk felepitese egyebkent egyszeru.
    Mindegyik gomb-kut tartalmaz 5-5 infravoros LED-et es infravoros fenyre erzekeny fotoellenallast. A billentyuk alaphelyzetben blokkoljak a fenyt ami miatt a fotoellenallasok ellenallasa magas lesz. A billentyuk lenyomasakor az ellenallas lecsokken, ami a felhuzoellenallasokon es az invertereken at pozitiv/magas jelkent olvashatunk a mikrokontrolleven.
    A kepen egy szetszedett billenty lathato.

  • Domonkos

    addikt

    válasz Domonkos #49 üzenetére

    Egyebkent tudjatok, hogy a dinok miert tudnak olyan konnyen kikukucskalni azokonn a szuk reseken?
    Azert, mert azok egyaltalan nem szuk resek.
    Nem tudom, hogy ez milyen mertekben lehet a gyari allapota a tenyertamasznak, de ha egy kicsit kozelebbrol nezzuk a billencs egyeb reszeit - foleg a muanyag darabokat - akkor azert talalni meg hasonlo megoldasokat. Noha, a tobbi egy kicsit talan szofisztikaltabb.

    Ha tovabb kesik a postam, akkor majd azokrol is rakok be kepeket. :K

  • Domonkos

    addikt

    válasz Domonkos #47 üzenetére

    NAPster

    NAPster, NORMan tesoja a bal oldali hand unit-on lakik es a szamokert es az irasjelekert felel. A dino-tesojatol onnan lehet megkulonboztetni, hogy neki piros a szeme es legtobbszor balra nez.

    Szerk: Most olvasom, hogy NORMan tesoja az igazabol a funkciokert felel, tovabba nem is NAPsternek hivjak, hanem valami F-betus neve van. :(

  • -igu-

    veterán

    válasz Domonkos #46 üzenetére

    csak a fordualtszám 1000 (ami a kerületi sebességből adódik), nem sietünk sehova

    /de ez a topik nem rólam szól, nyomassad te a kontentot

  • Domonkos

    addikt

    válasz Domonkos #44 üzenetére

    💾🖐️ > 🎹

    Vegul mar csak egy fuggveny kell, hogy az osszes billentyu allapotat megkapjuk. Ez a fuggveny szerencsere egyszeru:

    static uint8_t
    read_keys(void)
    {
    uint8_t b;
    uint8_t e;
    uint8_t s;

    b = PINB;
    b &= 0b10000000;
    b >>= 7;

    e = PINE;
    e &= 0b01000000;
    e >>= 6;

    s = b | (e << 1);
    s <<= 2;

    return s;
    }

    Mivel ezen a ponton a multiplexer mar a jo sorra van allitva es a propagaciora is vartunk eleget, igy itt mar nincs mas dolgunk, mint kiolvasni az adott soron az osszes billentyut, majd azt visszajuttatni a hivonak. A fenti kod pont ezt teszi.
    Bar trukkosen nezhet ki, a fuggveny nem csinal mast, mint a bal oldali hand unit 2 billentyujet olvassa ki a megfelelo portok megfelelo labairol es azt az s valtozon keresztul, annak a 2-3. bitjein visszajuttatja a hivonak. Ha a hardver ott tartana, hogy a ket felet ossze tudtuk kapcsolni, akkor itt kellene kiszednunk a jobb fel ertekeit is, amit a 0-1 bitekben tarolhatnank. Amig ez nincs meg, addig az a ket bit fixen 0 lesz, es a firmware ugy fogja kezelni, hogy azokat a billentyuket sosem nyomtuk le.
    A read_keys() es a read_keyboard() kozott iratlan egyezmeny, hogy a billentyuk allapotat azt a legalso 4 bit-en cserelik ki egymas kozt. :K

  • -igu-

    veterán

    válasz Domonkos #43 üzenetére

    Az én szakmámban a sebesség mértékegysége m/min, kerületi sebesség forgástesten, annak a fizikai kivetülése (átmérő függvényében) a fordulatszám.

  • Domonkos

    addikt

    válasz Domonkos #41 üzenetére

    Yes!

    A tegnapi kod megelolegezte a select_row() es a read_keys() helyes mukodeset a sajat helyes mukodesehez. Ma ezek kozul kellene egyet megirnunk. Kis szerencsevel ezek is egyszeruek lesznek.
    A sor kivalasztasat implementalhatjuk mondjuk igy:

    static void
    select_row(const uint8_t row)
    {
    uint8_t d = PORTD;

    d &= 0b11110000;
    d |= row;
    PORTD = d;
    }

    A row valtozo a read_keyboard() fuggvenybol jon. Ez a Teensy-n a jelenlegi setup-ban egy kettes komplemens abrazolasu szam a [0, N_ROWS) tartomanybol. Es ez pont alkalmassa teszi arra, hogy egybol a multiplexer inputjaira irjuk. :))
    A fenti kod azert ennyire egyszeru, mert az inputok azok a mikrokontroller ugyanazon portjanak 4 egymas melletti labara vannak kotve. Ez egy nagyon kedves gesztus volt a hardver eredeti tervezojetol. Innen is koszi! :R

    Ha az elrendezes egy kicsit kuszabb volna, akkor a biteket egyenkent kellene ide-oda irjuk. Ami meg szinten nem a vilag veget jelentene, de a kodot is egy kicsit osszekuszalna.

    Kis erdkesseg:
    A 0-13 tartomanyhoz egyebkent talalhato egy nagyon jo Gray szekvencia. Szoval ha valaki egy kicsit szerencsetlenebb labkiosztassal talalja magat szemben - Professional 2 - akkor ajanlom ennek a hasznalatat. - viszont mivel ez a blog a DH200-rol szol, igy annak az algoritmusnak az implementalasa az olvaso feladata marad. ;)

  • -igu-

    veterán

    válasz Domonkos #41 üzenetére

    ez az 1000-es érték nekem is szinte mindig a biztonsági zónát jelenti, bár nálam tényleges, fizikai sebesség
    ha ezt választom, nagy baj nem lehet :DDD

  • Domonkos

    addikt

    válasz Domonkos #40 üzenetére

    Warning! Typing on your DataHand System is much faster than it appears!

    Egy sort beolvasni egyszeru:

    static uint8_t
    read_row(const uint8_t row)
    {
    select_row(row);
    _delay_us((double)ROW_SWITCH_TIME_us);

    return read_keys();
    }

    Csak ki kell valasztanunk a multiplexeren a megfelelo csatornat, varni egy picit amig a hardver propagal, majd kiolvasni az ertekeket.
    A fenti kod pont ezt csinalja.
    Hogy pontosan mennyit kell varni a ket akcio kozt, azt leginkabb majd kiserletezgetessel fogjuk csak kideriteni. Bar a multiplexer es az inverter ertekeit a datasheet-jeikbol konnyen kiolvashatjuk, a fotoellenallas pontos tipusanak ismeretenek hianyaban, ott csak tippelni tudunk. Bar tipikus ertekeket ismerek, jelenleg inkabb hajlok arra, hogy egy boven hosszu varakozast allitsak be, minthogy azert szivjak majd kesobb, mert tul keves idot hagyok a propagaciora...

    Szoval amig nem latom a dolgot mukodni, addig:
    #define ROW_SWITCH_TIME_us 1000

    Es ha majd kesobb hianyzik a sebessegbol, akkor ezt lehet csokkenteni. :K

  • Domonkos

    addikt

    válasz Domonkos #39 üzenetére

    Learning the DATAHAND SYSTEM Makes You a Winner!

    A billentyuk allapotat beolvasni egyszeru:

    static void
    read_keyboard(void)
    {
    keys_down = 0;

    for (uint8_t row = 0; row < N_ROWS; row++) {
    const uint8_t b = read_row(row);
    const uint64_t b64 = b;
    const uint8_t offset = row * N_COLUMNS;

    keys_down |= b64 << offset;
    }
    }

    Ennek a fuggvenynek a celja az az, hogy a keys_down valtozo erteket egy olyan allapotba hozza, ami a billentyuzet billentyuinek tenyleges allapotanak megfeleltetheto. A kesobb meghivott fuggvenyek ennek a valtozonak az erteke alapjan fognak mukodni.

    A billentyuk azok vagy lenyomva, vagy felengedve vannak - egyszerre a ket allapot egyikeben - szoval azok reprezentalasahoz egy-egy bit is elegendo.
    Korabban kideritettuk, hogy a billentyuzet matrixa az 14x2-es mindket oldalon. - bar oldalankent csak 26 billentyuvel - Hogy ezt mind beolvassuk, vegig kell iteralnunk az osszes soron, es soronkent ket-ket billentyut (vagy 4-et, ha a ket felet egyszerre olvassuk) kell elraknunk a valtozoba.
    Mivel egy sor beolvasasa onmagaban egy kulon lepesnek tekintheto, ezert azt kiszerveztem egy kulon fuggvenybe.
    Szoval ha megelolegezzuk, hogy a read_row() fuggveny helyes erteket ad vissza, akkor nincs mas dolgunk, mint azt a billentyuzet poziciojanak megfelelo helyre "tolni" a keys_down valtozoba.
    A fenti kod pont ezt teszi.

    Magat a valtozot pedig definialhatjuk a megfelelo scope-ban mondjuk igy:
    typedef uint64_t kb_state_t;
    kb_state_t keys_down = 0;
    #if ( N_KEYS > 64 )
    #error "Too many keys on the keyboard"
    #endif

    Kenyelmes, mert nincs 64 billentyunel tobb billentyunk. Mondjuk kinek is kellhet annyi? :U

  • Domonkos

    addikt

    válasz Domonkos #38 üzenetére

    Step 1. Power down your computer.

    A run() fuggveny egyszeru:

    static void
    run(void)
    {
    for (;;) {
    read_keyboard();
    process_keys();
    send_updates();
    }
    }

    Ahogy azt a main() fuggveny targyalasanal emlitettem ennek nem kell visszaternie. A for ciklus kontroll kifejezeset ezert uresen is hagyhatjuk.
    Egyebkent meg 3 dolgot kell ismetelgetni:
    - Kideriteni, hogy mely billentyuk vannak lenyomva
    - Hozza kell rendelni az epp lenyomott (vagy felengedett) billentyukhoz a tenyleges billentyuzet-funkciokat
    - Vegul tudatni a hoszttal, hogy mik is az esemenyek

    Az eredeti kodban van egy 4. akcio is, egy szimpla 2ms-es varakozas. A komment szerint ez a szoftveres pergesmentesites miatt van. Bar ez az altalanos mikrokapcsoloknal tenyleg szukseges, nekunk megsem fog kelleni, mert a Schmitt trigger-en keresztul olvasott optikai kapcsolok nem peregnek. Egyebkent ennek lennenek szofisztikaltabb implementacioi is, de egy eredetileg breadboard-ra epitett billentyuzetnek nem nagyon kell semmi tobb.
    Szoval en ezt most lehagyom. :K

  • Domonkos

    addikt

    válasz Domonkos #37 üzenetére

    This reduction of finger workload can boost your productivity.

    A portok inicializalasa egyszeru:

    static void
    init_ports(void)
    {
    DDRB = 0b01111111;
    PORTB = 0b10000000;
    DDRC = 0b11111111;
    PORTC = 0b00000000;
    DDRD = 0b11111111;
    PORTD = 0b00000000;
    DDRE = 0b10111111;
    PORTE = 0b01000000;
    DDRF = 0b11111111;
    PORTF = 0b00000000;
    }

    2 dolgot kell megtenni az osszes portnal:
    - Beallitani az "iranyat", hogy input vagy output
    - Illetve az "allapotat"
    -- Kimeneti iranynal a 0 az GND-kozeli feszultsegre kapcsolja a labat, az 1 pedig VCC-kozelire
    -- Bemeneti iranynal pedig a 0 az "normal" mukodest eredmenyez, az 1 pedig egy beepitett felhuzo ellenallast kapcsol be.

    Elobbire a DDR_ valtozok, utobbira a PORT_ "valtozok" hasznalhatok. A portokon talalhato 8 I/O pin-t egyszerre lehet beallitani, kulon-kulon nem; vagyis de, de ahhoz egy kis bitmagiat kell hasznalni. Itt meg nem, de kesobb majd fogunk egy keveset. :K

    Hogy honnet tudjuk, hogy mit mire kell kapcsolni?
    A pin-eknel, amiket a korabbi napokon kimertunk, ott egyertelmu.
    A nem hasznaltak iranyat pedig en szeretem kimenetire es alacsony logikai ertekure allitani, mert amellett, hogy a fogyasztasra is jo hatassal van, a PCB-t sem cuck-olja tovabb. :K

  • Domonkos

    addikt

    válasz Domonkos #36 üzenetére

    Using the DataHand System is Good for You

    A belepesi pont a main() fuggveny lesz.
    A belseje ennek igencsak egyszeru, lenyegeben ez csak a peldaprogram egy kicsit strukturaltabban es a timer nelkul:

    int
    main(void)
    {
    CLKPR = 0x80, CLKPR = 0;

    init_ports();

    usb_init();
    while (!usb_configured()) {
    const double freq_ms = 111;

    set_led(NAP_LED, true);
    _delay_ms(freq_ms);
    set_led(NAP_LED, false);
    _delay_ms(freq_ms);
    }

    greet_user();
    run();
    }

    Az orajelet erdemes a legelejen lerendezni. Ezt a prescaler allitasaval tudjuk megtenni. 16MHz-et kerunk.
    Utana a port-okat erdemes egybol inicializalni. Bar ezt is csak egyszer kell megtenni, a kod konnyebben lesz ertheto ha azt egy kulon fuggvenybe szervezzuk ki.
    Utana az USB kapcsolatot lehet kiepiteni. Itt mi tul sokat nem rakunk az egeszhez, a peldaprogramhoz kapott konyvtarbol hivogatunk 2 fuggvenyt, amig a kapcsolat ki nem epul. Annyi extra van csak az egeszben, hogy en szeretem latni, hogy eppen a folyamat melyik statuszban van, es mivel elegg kezenfekvonek talaltam erre a feladatra a billentyuzet egyik LED-jet villogtatni, igy amig az USB-re varunk, addig a NAP LED fog villogni ~4.5Hz-en. A kedvenc frekvenciamon. :)
    Utana udvozoljuk a juzert a billentyuzet kepessegeinek megfeleloen. Ez a fuggveny egyebkent arra is jo lesz, hogy meg egy napi kontentet adjon a blognak, ha a csomagjaim tovabb kesnek.
    Legvegul pedig belepunk a run() fuggvenybe, ami az egesz logikat fogja keretezni. Ez a fuggveny nem ter vissza, addig fut, amig az eszkozt ki nem huzzuk, vagy a Reset gombot meg nem nyomjuk. Ez lesz felelos a tovabbi feladatokert.
    Egyszeru. :K

    Extra info a tovabbiakhoz:
    Bar a kod lenyegi resze az ide mind be lesz masolva, a boilerplate es trivialis dolgokat nem fogom mind kiirni. Ha valakinek megis kell, akkor azokat kulon kerdesre be tudom masolni, de szeretnem ha a blognak ez a resze is konnyen ertheto tudna maradni.
    Szoval a kodnak nem feltetlen celja lesz az, hogy "jo" legyen. Elsodlegesen csupan annyi, hogy feltamassza a billencset es hogy jo alapja legyen ha kesobb tovabb szeretnem majd fejleszteni.
    A sebesseg, meret, fogyasztas kibalanszolasa az olvaso feladata marad. ;)

    Ellenben a kerdesekre a meglevo kodhoz nyitott vagyok!
    Esetleg ha van "feature-request", akkor azokat is megfontolom a meg meg nem irt reszekhez, de ha nem lesznek az sem baj. A blog vegere egy 6KRO firmware azert el fog keszulni. :K

  • Domonkos

    addikt

    válasz Domonkos #35 üzenetére

    Instead of making your fingers move to the keys, they (the hand units) bring the keys to your fingers.

    Szoval miutan a make vegzett, tobbek kozt egy datahand.hex file-al lettunk gazdagabbak. A Teensy Loader-nek ez lesz az inputja.
    Ha a Teensy-t csatlakoztatjuk a gephez, mikozben nyomva tartjuk rajta az (egyetlen) reset-re kotott gombot, akkor az Program modban indul. Ekkor "varja" az uj programot.*
    Egy teensy_loader_cli --mcu=TEENSY2PP -w datahand.hex kiadasaval pedig oda is adhatjuk neki.
    A loader automatikusan, az iras vegeztevel ujra is inditja a mikrovezerlot, ami a programnak megfeleloen ~10 masodperc inaktivitas utan "ut" egy-egy space-t.
    Ha pedig a port B-n vagy D-n levo labait egy vezetekkel a foldre huzom, akkor a labnak megfelelo billentyut.

    Szuper! Mar nagyon kozel vagyunk! :))

    Bar Program modba ugrasztani csatlakoztatas utan is barmikor lehet, elso flash-eleskor a kolcson kapott eszkozt azert erdemes ovatosabban kezelni. :B

  • Domonkos

    addikt

    válasz Domonkos #33 üzenetére

    These panels may then be attached to the sides of your computer monitor.

    Na jo; akkor szoftver.
    Szoval az egyik oka, hogy a Teensy++ 2.0 lett a kivalasztott, az az, hogy szinte majdnem teljesen pin-kompatibilis az eredeti 8051-el, a masik, hogy a gyarto honlapjan az 5 elerheto peldaprogram kozul az egyik az pont egy billentyuzetes.*

    Szoval ha a Teensy-s peldaprogramot letoltottuk, akkor csak par tovabbi szoftverre es konyvtarra lesz szuksegunk. A GNU szoftvergyujtemenybol ezeket mind kedvezo licensz alatt szerezhetjuk be. A gcc, binutils es glibc AVR-es valtozataira lesz szuksegunk az Intel :B .hex file eloallitasara, amit a szinten GPL licenszu Teensy Loader-el juttathatunk fel az eszkozre.

    A peldaprogramhoz kapott makefile azt sugallja, hogy a forditas is rettenet egyszeru lesz, bar mielott ezt megtennenk, mar most erdemes lehet 2 dolgot atirni. Az egyik a TARGET, hogy ne example* legyen a file-ok neve, illetve az MCU, mert az meg kulonbozik attol, ami a ++ 2.0-ban van.
    Innen pedig egyszeru:
    make

    Es bumm!
    7 hiba es 1 figyelmeztetes. :))

    Ezek szerencsere egyaltalan nem nehezen javithato gondok. A figyelmeztetest azt egy nem hasznalt valtozo miatt kaptuk, a 7 hibat pedig azert, mert az ujabb fordito mindenkepp const-qualified valtozokat akar a programmemoriaba helyezett "valtozokhoz"...
    warning: unused variable ‘t’ [-Wunused-variable]
    error: variable ‘device_descriptor’ must be const in order to be put into read-only section by means of ‘__attribute__((progmem))’
    ...

    Fair.
    7 const kulcsszo beillesztese es a nem hasznalt valtozo kitorlese utan minden szepen fordul.

    *Bar tudom, hogy nemreg QMK altal is szupportalt billentyuzet lett a Pro 2 - es hogy azt kb. 5 sor atirasaval valoszinuleg mukodokepesse lehetne ezen a billentyuzeten is tenni - a projekt egy ideje nem tetszik. Amilyen iranyba megy es amilyen modon hozzak meg a fontosabb donteseket en inkabb nem veszek reszt benne. De a kodjuk core resze az biztosan az egyik legjobb forrasa a billentyuzetes logika helyes implementacioinak.

  • Domonkos

    addikt

    válasz Domonkos #32 üzenetére

    Mondjuk igy.

    A Teensy-n az elso GND labat kihajlitottam es egy ujabb socket-tel az E port 6-os labat atvittem a helyere.
    >inb4 Nem lesz ez egy extra antenna?
    De. - igazabol minden az - De max. ~14kHz-en, amin ez jelet fog tovabbitani, ugy nem fogok vele foglalkozni.

    Amugy barmi mas nem hasznalt labat is valaszthattunk volna, az E6 megis kezenfekvo volt, mert az az Intel-en a VPP, amire itt biztos nem lesz szuksegunk.
    A socket-en azt a labat szinten kihajtottam oldalra, hogy ne zavarhasson be.

    Ha ezeket mind beraktuk a helyukre, akkor holnap mar a szoftver resze johet. :))

  • Domonkos

    addikt

    válasz Domonkos #31 üzenetére

    Kozben kaptam kolcson egy Teensy++ 2.0-t, amig az enyem meg nem erkezik - innen is koszi! :R - szoval hamarosan elkezdhetjuk a projekt izgalmasabb reszet. :))

    A hardvert igazabol mar majdnem felterkepeztuk - legalabbis azokat a reszeket, amik a minimum hasznalhatosaghoz szuksegesek lesznek - szoval nincs akadalya, hogy a Teensy-t bepattintsuk az Intel volt helyere beforrasztott socket-be es irjunk ra valami firmware-t.
    Vagyis de.
    A Teensy labkiosztasat elnezve, az 1-es labon GND van. Az nem annyira jo, mert a DH200-on ott tudnank az egyik oszlopot olvasni. Jobb lenne, hogyha azt valahogy at tudnank vinni egy masik labra, ami szabad.

    Na, de hogy? :F

  • Domonkos

    addikt

    válasz Domonkos #30 üzenetére

    Mivel nagyon sikerult belejonnom a kiforrasztasba, igy megcsinaltam a jobb oldal-t is. A ket oldal ezen NYAK-jai egyebkent semmiben sem kulonboznek. Egyetlenegy berakott jumper-rel tobb van ezen az oldalon, mint a balon. - Amit nem igazan tudom, hogy mire hasznalhatott az eredeti logika, mert a DH200-nal az oldalak nem egymashoz, hanem egy Interface Box-hoz voltak kapcsolva. Azt gondoltam, hogy ha azon amugy is van 2 kulon bemenet, akkor nincs nagyon ertelme plusszban megkulonboztetni az oldalakat, mert hogy melyiket hova dugom, ugyis egyertelmuve tenne. Bar ebben az esetben a ket Pod-nak nem tul sok mindent kellett volna csinalniuk. A LED-ek kapcsolgatasara szerintem meg lett volna olcsobb megoldas is.
    No, mindegy. Ha lesz lehetosegem, akkor belekukkantok abba a firmware-be! :K

  • Domonkos

    addikt

    válasz Domonkos #29 üzenetére

    Rossz hir, hogy a programomat kb. egy nappal elore sem tudom, jo hogy igy legalabb egy picit meg elorebb sikerult a projektet loknom.
    A billentyuzet beviteli eszkozkent valo hasznalatahoz sikerult az osszes fontos huzalt osszecsipogtatnom a multimeterrel.
    Ezek egy resze a multiplexeren vannak:

    pin funkcio
    1 R4
    2 R5
    3 R7
    4 R9
    5 R11
    6 R13
    7 R12
    8 R10
    9 R8
    10 R6
    11 R0
    12 (GND)
    13 R1
    14 R3
    15 R2
    16 (JP5/1)
    17 (NC)
    18 (GND)
    19 (GND)
    20 P1.5
    21 P1.4
    22 P1.3
    23 P1.2
    24 (VCC)

    Ahol a 20-23 pinekkel - amik az Intel-en az 1-es port 2-5 labaira van huzalozva - valaszthatjuk ki, hogy melyik sor (R#) LED-jeit szeretnenk felkapcsolni; amiket a szinten az 1-es port 0 es 1 pinein olvashatunk vissza.
    A visszaolvasott ertek az termeszetesen a LED-ekkel szemben elhelyezett fotoellenallasoktol jon, am azok nem kozvetlenul a processzorba jonnek vissza, hanem egy-egy Schmitt trigger-en keresztul. Ezek a vonalak amugy szinten 5V-ra vannak felhuzva egy-egy 4.7k-s ellenallason keresztul. Bar a jelet meg nem lattam, gyanitom, hogy kellemesen "digitalis" es pergestol mentes lesz. Nem szeretnek meg egyszer pergesmentesito algoritmusokat implementalni.

  • Domonkos

    addikt

    válasz Domonkos #27 üzenetére

    Jo hir, hogy ido kozben visszakerult hozzam a multimeterem. Rossz, hogy a het tovabbi reszeben szinte semmi lehetosegem nem lesz a projektel erdemben foglalkozni.
    Par imazs kep mar be van keszitve a kesobbi hozzaszolasokhoz, de nagy elorelepesek biztosan nem lesznek.
    Viszont ha vannak kerdesek, vagy elmelkedesek, akkor azokra valoszinuleg fog jutni egy kis ido! :K

    A mai kepen a kiszerelt bal oldali billentyukutak vannak a juzer felol, lapos szogbol fotozva.
    A kozepso ujjhoz tartozo kut, nem csak a perspektiva es a rovidules miatt latszik alacsonyabbnak, hanem mert amugy is az.
    Szerintem elegge jol el van talalva a magassag - mondom ugy, hogy ami billentyuzetrol ezt a szoveget is gepelem kb. hasonlo magassagbeli kulonbsegekkel bir - viszont paran akik itt a kornyezetembol probaltak azoknak fura volt. (-> a lapos billentyuzeteken gepelok :P )
    Nekem leginkabb csak az a nem tetszo benne, hogy az azonos billentyuk kozepei egy kicsit tavolabb vannak, mint a hagyomanyos klaviaturakon (> 3/4") - ami extra tavolinak hat a choc-spacing-es billentyuzetektol atulve. Bar szerintem szokhato lesz, mert azert nem kell nyujtozkodni, de a prototipizalaskor biztos nem a kis kezu vagy rovid ujju emberekkel tesztelhettek. :U

  • Domonkos

    addikt

    válasz Domonkos #25 üzenetére

    Amig a rendelesre varok, addig beforrasztottam egy DIP socketet.
    Jo lesz meghagyni a lehetoseget, hogyha visszaszerzem a muszereimet, hogy az eredetin is tudjak majd tesztelni. Hatha abbol tudunk meg majd valamit.

    Ez a tegnapihoz kepest nagyon konnyen ment. Bar a socket hajlamos elhagyni a labait, ha nem sikerul pont keresztul vezetni azokat a furatokon; de csak egy pici ugyeskedes kell ahhoz, hogy az osszessel egyszerre betalaljunk es az egesz beuljon a helyere. Onnantol a forrasztas pedig sima rutinmuvelet. :K

  • Domonkos

    addikt

    válasz Domonkos #21 üzenetére

    Hat. Nem mondom, hogy a chip nem szenvedte meg a kivetelt, de vegul csak kijott.
    A kiforrasztas amugy sem a kedvenc mufajom, es a tudat, hogy egyebkent unobtainium-ot forrasztok szinten nem segitett, de munka kozben arra probaltam gondolni, hogy ez is csak egy sima billencs es semmiben sem kulonb azoknal, amiken mar amugy unalmas dolgozni.
    Mivel most a rework station-hoz nem fertem hozza, es a wick-et is csak a folyamat befejeztevel talaltam meg, igy a munka csak egy pakaval es onszippantoval tortent. Eddig sokszor bevalt, es most is probaltam, hogy ha a szippantas elott egy kis extra forraszoont rakok a labakra, akkor konnyebb a szippantot ugy beleszurni a megoldvadt onba, hogy az egybol kijojjon, viszont most az extra on inkabb csak atfolyt a NYAK masik oldalara es ott hatalmas csomokban felgyulemlett. Ezt nem volt egy kifejezetten nagy elmeny eltavolitani.
    Szoval az egesz folyamat kb. 30 percet vett igenybe.

    A kiforrasztott chip-pel nem tudom, hogy mit kezdjek. Ujraprogramozni nincs sok ertelme, mert nem fog kozelebb vinni a celhoz. Esetleg a rajta futo kodot probalhatnank meg valahogy lementeni rola, de nem tudom, hogy annak mennyi ertelme lenne.
    Sem az ISA, sem a licensz (amit sejtek) nem tetszik.
    Lehet, hogy csak felrerakom es majd kesobb lesz egy masik projekt amibe fel tudom hasznalni.

    A kep tetejen lathato blue-pill bar egy igen kezenfekvo alternativa lehetne a 8051 helyere, asszem nala tudunk majd egy jobb megoldast talalni.

    Ha a posta kelloen gyors, esetleg en tudom majd az idot kelloen sokaig huzni, akkor kiderul, hogy mi is lesz a kivalasztott. :K

  • válasz Domonkos #7 üzenetére

    FFC lapos rugalmas vezeték ;)
    Mondjuk sosem hallottam lefordítva még. (Dolgoztam régen kábelkonfekcionáló gyárban, igaz, nem az FFC részlegen.)

  • 0xmilan

    addikt

    válasz Domonkos #21 üzenetére

    > A trapez korrekciot nektek kell megcsinalnotok!

    Bar nem tudom, hogy ez most segittet-e barmin is. :D

  • Domonkos

    addikt

    válasz Domonkos #18 üzenetére

    A mai nap sok effort-ot nem raktam a projektbe - itt egy kep a tegnapi PCB hatuljarol. Hatha valaki tenyleg vissza szeretne fejteni, hogy mi is tortenik igazabol. Meg talan prezervacio szempontjabol sem rossz, ha megmarad...
    A trapez korrekciot nektek kell megcsinalnotok! A kepek egy 28mm (FF ekvivalens) gyujtotavolsagu objektivvel keszultek.

    Pontositas a tegnapi szoveghez: Az Intel chip tajolasa termeszetesen horizontalis. De igy jar az a blogger, aki az elore megirt szoveg melle az utolso pillanatokban forgatgatja be a kepet. Es a multimeteremet is tuti, hogy elveszitettem legalabb szerdaig. :B

  • dugo_

    veterán

    válasz Domonkos #18 üzenetére

    Ha a napokban sikerul egy multimetert szerezzek

    Világ dőlne össze bennem, ha kiderül, hogy nincs legalább 3 multimétered a fiókban. ;]

  • Domonkos

    addikt

    válasz Domonkos #11 üzenetére

    A 3. NYAK a legnagyobb. Itt kapott helyet az osszes logika.
    Bar arrol napokig lehetne meselni, hogy mi mit csinal es mi miert felelos, ma megsem reszletezem ki az osszes komponenst, csak azokat, amik szamunkra hamarosan fontosak lehetnek.*
    Ezek pedig szerintem a kovetkezok:
    - Jobb alul, vertikalis tajolasban van egy Intel 8051. Ami a billentyuzetes szempontokbol fontos az az, hogy a processzor 5V-rol mukodik, van rajta 4 I/O port, es hogy egy olyan utasitaskeszletet hasznal, amivel meg nem volt dolgom. :B
    - Tovabba balrol a 3. chip (= integralt aramkor) az egy 74hc154, ami egy 16 csatornas, digitalis (de)multiplexer. Ami fuszerezett (= seasoned) billentyuzet-epitokent arra enged kovetkeztetni, hogy ez a billentyuzet-matrix igencsak unorthodox lehet. Megis hova kellhet 16(!) csatorna, hogy leolvassuk a 26 billentyu allapotat?!? Ha a napokban sikerul egy multimetert szerezzek, akkor konnyebb lesz kideritenem a miertjet. :K - bar a szemfulesebbek a tegnapi keprol mar sejthetik a trukkot.

    * probaltam kelloen jo kepet kesziteni, hogy az osszes felirat olvashato maradjon, ha valaki megis, mar most kivancsi lenne...

  • 0xmilan

    addikt

    válasz Domonkos #14 üzenetére

    Utolag megtalaltam am a referenciat. A macskas resz miatt egyertelmu volt, hogy valami idezet. Meg nem is szoktal igy beszelni. :D

    ...de legalabb neked is tok jo az alvasi ciklusod.

  • 0xmilan

    addikt

    válasz Domonkos #12 üzenetére

    Ez meg angolban sem egy elterjedt valami, szoval szerintem annak hivod, aminek akarod. Sorry, egyaltalan nem egy negativ megjegyzes volt. :)

  • 0xmilan

    addikt

    válasz Domonkos #9 üzenetére

    Szerintem annak a tortenelmi pillanatnak lehettunk a szemtanui, amikor valaki eloszor forditotta magyarra a key-well kifejezest. 🥹 :D

  • Domonkos

    addikt

    válasz Domonkos #7 üzenetére

    A finger-well-ek korul egy vekonyka szivacsreteg van. Ennek szerintem pusztan esztetikai szerepe lehet. Ezt egyben le lehet huzni a gomb-kutakrol.
    Ez a resze a billentyuzetnek egyebkent mindket oldalrol emelheto, igy tetszoleges magassagba, vagy dolesszogbe allithato egy kelloen nagy tartomanyban. Az allitashoz a ketoldalt talalhato szarnyasanyakat kell meglazitani, kezzel beallitan a megfelelo magassagot, majd visszaszoritani.
    Ha teljesen lecsavarjuk az anyakat, akkor a finger-well-ek a NYAKkal egyutt egyben kijonnek.
    Bar nem tudom, hogy gyari megoldas volt-e (van egy tippem), de a szalagkabel csatlakozoja, mindket oldalon par csepp ragasztoval a tuskesorra van ragasztva.
    A NYAKon egyebkent egyetlen egy 150 Ohm-os ellenallas talalhato.

  • Domonkos

    addikt

    válasz Domonkos #4 üzenetére

    Fel is nyitottam! :))
    A hazat igazabol csak 3 rovid Phillips csavar tartja ossze. Egyik sincs leragasztva vagy eldugva - mindharmat elsore meg lehet talalni. Ha ezeket kiszedtuk, a billentyuzet teteje egy darabban leemelheto, miutan kihuztuk a ledekhez futo FFC-t (tokom tudja, hogy mi a magyar neve...). Semmi titkos muanyag ful vagy pocok amit keresgetni kellene. Ez egy hatalmas plusz szerintem. :K
    Belul sincs tul sok meglepetes. A tenyertamasz alatti reszt csak a por es kosz tolti ki. A tobbin pedig 3 NYAK osztozik, meglehetosen szellosen, szalagkabelekkel osszekotve. A 90-es evekhek kepest is rettento kis komplexitasu.
    Mar ilyen tavolbol is latszik, hogy itt bizony eleg sok minden kezzel kerult osszeszerelesre. Ami a projekt szempontjabol megint csak egy pozitivum, szerintem. :)

  • Domonkos

    addikt

    válasz Domonkos #1 üzenetére

    De nezzuk is, mikkel gazdagodtunk az uzlet altal!
    Hasznalati utmutato, garancialevel, egy rajz a billentyuzes kozben javasolt testtartasrol, egy a gyakorlast segito szoftver es persze maga a billentyuzet ket megsargult fele, DE nem az egesze! Ugyanis a DH-200 eredetileg egy "interface box"-szal jott, ami a szamitogeppel valo kommunikaciot tenylegesen vegezte, es amibe a billentyuzet felei (pod-ok) be voltak dugva. Tovabba a kabelek sem voltak reszei az uzletnek - amit csak azert emlitenek meg, mert egy tepozaras kabelkotozot azert kaptam. :)
    Az elozo tulajdonos elmondasa szerint ezeket nem o hagyta el, mar hozza is hianyosan erkezett a klavi. Ami a projekt szempontjabol nem egy rossz dolog, hiszen igyis-ugyis atepitem, bar tuti adott volna egy kis megnyugvast ha legalabb egyszer latom mukodni meg mielott felboncolom. Viszont akkor egy sokkal rosszabb alkupoziciobol indultam volna, mert igy a sargulas mellett a teszteletlensegre is hivatkozhattam.
    Nem gondolom, hogy amugy egy ilyen eszkoz kepes elromlani.
    Holnap talan fel is nyitom. :))

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

Hirdetés