De végső soron nem gáz, mert az arduino "hivatalos" kontributált listáján van egy teljes PS/2 billentyű kezelő

En most csak arra utaltam, ami segithetne megfejteni azt, hogy miert "megy tonkre" a cucc, vagyis serult a flash tartalma. Nyilvan lehetne ujat csinalni, de szerintem itt vmi komoly gixer van, ilyennek nem kene tortennie. Ha meg megtortenik, lehet egy mas design-nal is elo fog jonni. persze, lehet hogy nem

Emlékeim szerint gyors, többszöri, gép ki-be kapcsolgatástól tudott megdögleni. (Asszem valami EXDOSt próbáltam csatlakoztatni, amit csak többedik próbálkozásra látta a gép.)
Volt amikor az EP-s programmal helyre lehetett rakni, de amikor a boot loader sérült, akkor lehetett kiforrasztani.

Hmmm, igy belegondolva ... Van vhol leiras, hogy AVR pontosan hogy lett rareszelve a gepre? pl AVR reset laba? A problema az, amire amugy az AVR leirasa is figyelmeztet, hogy specifikacion aluli feszultsegszinten nyilvan (mint minden elektronikus alkatresz) nem mukodik megfeleloen, kulon kiter arra hogy flash serules is lehet, mert pl a programkod vegrehajtasa soran total hibasan ertelmez dolgokat, stb. Ennek a leiras szerint azonban vannak ellenszerei. Egyik pl az, hogy RESET-ben kell tartani az AVR-t amig tapfesz nem normalizalodik. Ezert is kerdeztem, hogy lett bekotve az. Lehet, az EP ki-be kapcsolasnal foleg gyorsan egymas utan novelte a valoszinuseget, hogy tul alacsony tapfesz tovabb fennmarad, az AVR-nek meg nem volt kulon RESET elhozva az EP-tol? Masik ajanlott ellenszer: a mar emlitett BOD (Brown-Out Detector, vagy mi a szosz). Ezt a FUSE bitekkel kell beallitani programozasnal, es arra jo, hogy adott feszultsegszint alatt nem engedi hulyeskedni az AVR-t, cserebe sleep modban tobbet fogyaszt az MCU (ennek EP-n nincs jelentosege, csak mas projecteknel ahol sleep-eltetik is a cuccost neha). Ja, es ha boot loader-t nem nagyon kell frissiteni: szokott lenni egy lock bit arra, hogy a loader legalabb ne legyen irhato. Illetve Atmel-ek irnak meg par dolgot, kulon szekcio van a flash corruption megelozesere, bar 2012-ben is kb hasonlot irtam, most el is olvastam a specifikacio vonatkozo reszet (mondjuk nem eppen a kerdeses ATtiny-et, de gondolom ezek altalanos ervenyu tanacsok).

Btw, Zozo, pont amit te is kuldtel PDF, 157. oldalon ott is irnak errol, "Preventing Flash Corruption".

Tul'keppen lehet, csak nemi FUSE bit allitas kene az eredeti MCU-s taszt illeszton (BOD bekapcsolasa), es utana nem fordulna tobbe elo a gond?

Hmmm ... most jut eszembe, hogy ps/2 -höz is gyártottak vezetéknélküli cuccokat, sztm. nekem is van otthon, még tíz évvel korábbról ... Ilyen külső egységek voltak, rádióval, amik ps/2 -be mentek bele.

És mivel mostmár nem beépíthető egységben, hanem roncsolás nélkül kivezetett, külső eszközben gondolkodok a billentyűnél is, ezért akár a ps/2 -t is lehet komolyan venni, nekem is ...

Úgyhogy akár ps/2 -nél is lehet vezeték nélküli a dolog, nem is kell megvárni az USB -t.

PS/2 elonye, hogy egyszeru. Hatranya, hogy ugye egyre kevesebb van belole bill+eger manapsag. Ezen segithet a passziv USB-PS/2 atalakito, ami filleres dolog, elektronika nincs is benne. Ezzel az a gond, hogy csak akkor mukodik, ha a kerdeses eszkoz "tudja" a PS/2-t is, meg ha USB kabele is van, elektronikus szinten PS/2-t kell beszelnie a cuccnak, hogy mukodjon. Anno C64DTV moddingnal talalkoztam viszont azonnal olyan USB billenccsel amivel nem ment passziv atalakitoval. Viszont, van aktiv PS/2-USB kulso atalakito is, azzal elvileg mennie kell PS/2-re dugva minden USB-s bill+egernek. Tehat a kerdes tenyleg az, hogy megeri-e az USB-vel a szivas ezek utan. Mondjuk egy USB host az EP-be azert cool lenne, lasd az USB hattertaras topic-omat, ha nem is bill+egerrol van szo eppen

Na, itt megall a tudomanyom, pl nem tudom, hogy sima USB hub-ot ra lehet-e tenni egy atlag MCU vagy akarmi altal implementalt USB portra, es tudja-e kezelni vagy o mindig csak egy eszkozre szamit. Anno voltak olyasmik amik pl USB hub-rol nem mentek, tehat valami kulonbseg kell, hogy legyen ... Pedig tenyleg jo lenne Igen, abban igazad van, hogy az USB a bill+egerre kicsit mas teszta mint USB hattertar fogadasa, max az egyeduli kozos pont az USB En abbol indultam csak ki, hogy ha nekiallnek ilyennek, inkabb megprobalnam egy fust alatt (persze ha megy, fene tudja ...) megoldani az osszes USB-vel lehetseges/celszeru dolgot, es az sem baj, ha nem kulso. Persze ennek hatranyai is vannak, ha egyaltalan meg lehet igy oldani, elegge elvi szinten gondolkodok meg csak ezen ... Aktiv USB-PS/2 atalakitot en is csak "hallottam, hogy van" latni nem lattam

Az az USB host könyvtár, ami arduino alá van írva, az 99% hogy kezeli a hubot ... más usb host implementációk kiköthetik, hogy ők tudnak hubot fogadni, vagy csak egyből az eszközt ...

DE az valóban nagy só lenne, ha EP -n lenne egy USB, amire hubbal rákötöd a PC billt/egeret/joyt/játekvezérlőt/háttértárat ... és működnek ...  !

És ez nem kivitelezhetetlen, amennyire itt most belemásztam a dolgokba ... szinte mindenünk megvan már hozzá ...

Persze én biztos nem fogok az USB háttértárhoz EXOS bővítőket írogatni, meg magamtól nem találnám meg azt sem, hogy kellene átadjam az adatot az EP -nek,

de úgy értem, hogy Zozóval, mint a billentyűzetet is ... hogy megmondja ... na úgy már mindenünk megvan hozzá ...

Zozo, kb. mi az a minimális vezetékszám, amit ki kéne vezetni az EP -ből abban az esetben,
ha szeretnék USB -n betöltést is csinálni az EP -be ?

Bar nem vagyok Zozo .., de szerintem ez attol fugg, hogyan oldod meg. Konkretan: ha az USB illeszto cuccosod kulso, onnantol te dontod el, hogy kommunikal az az EP-vel, vegulis ket droton RS232-vel is mehetne akar, bar ez nyilvan inkabb vicc Gondolom 8 bites parhuzamos adatatvitelre gondolsz. Tehat 8 vezetek azert kell. Meg ugye GND sem art. Aztan kell egy jel, amivel EP tudatja, hogy olvasni akar a cuccosodrol egy byte-ot, illetve pl masik jel, amivel azt, hogy irni. Es ugye nem art tudni, hogy ez most parancs, vagy adat, tehat meg egy, ami ha pl I/O port, akkor az A0, es akkor van egy pl parancs port, meg eggyel felette az adatport, vagy forditva. Feltetelezve, hogy barmilyen megoldast is valasztasz, a cimdekodoklas mar meg van oldva (pl cartridge eseten, ha nem kell az egesz cartridge, akkor vegulis mind1, csak kisse pazarlas, hogy 64K-t elhasznalsz ket szem portra). Ha az EP buszara csatlakozol, akkor valoszinu, hogy elo kell allitani a select jelet neked valahol persze. Ha meg EP-n belul teszed, akkor erevenyes lehet a fenti vazlatom, hogy csak azon vezetekek mennek ki a gepbol, amik mar "elo vannak keszitve".

Errol jut eszembe: mindig szivfajdalmam volt, hogy most csinalni specko nyakot (ami bemegy cartridge helyere, vagy a buszbovitore, stb), stb, ha az ember ilyenekkel akar jatszani. Tenyleg nem lenne rossz otlet, ha az EP cartridge megoldasahoz hasonloan (ahol o eloallit oda custom RDCARD jelet stb) lenne egy uj csati, amin 8 bit adat van RD/WR, es mondjuk 4 szem adat, es csak I/O porton erheto el, ami mar "elo van dekodolva", igy 16db I/O port le van foglalva neki. Igy konnyebb lenne kiserletezi, foleg, ha a csatlakozo valami egyszeru lenne pl egy 25 polusu regi rs232-hez (sorry, nem tudom a nevet) hasonlo. Olyan csatit lehet kapni, nyak-ba ultethetot is, vagy dugaszolhatot, miegymas. Vagy lehet mas valakinek persze jobb otlete is Esetleg EXTCOL jelek pl oda is atvezethetoek lennenek, hatha valaki ilyennel is akar jatszani. Vagy ez hulye otlet?