A jó kis PS/2-es egereknél és billentyűzeteknél nem kellett ilyen marhaságokkal marketingelni 
push - interrupt request - enjoy
üzenetek
hozzászólások
No, azért PS/2-es egérrel játssz inkább te. Jó kis 80 Hz, amit szélsőséges esetekben sufnivarázzsal lehetett 200-ig húzni. Egy álom, főleg, hogy értelmes optikai tudtommal nem is létezik olyan csatlakozóval. 
[ Szerkesztve ]
Én még mindig PS/2-es billentyűzettel nyomom, 125Hz!
De ezek között is válogatni kell, mert jobb/rosszabb eredményt ad aszerint, hogy milyen minőségben szolgáltat órajelet, milyen a kábelben lévő erek folytonossága, és milyen állapotban vannak a csatlakozóban az érintkezők.
Én elhiszem, hogy az USB gyorsabb, csak nem tud ennyire sima lenni, mint ez, ami be van drótozva a cpu-ba.
[ Szerkesztve ]
nyunyu
(félisten)
Nem akarom megint kommentálni a Kailh Coppert
4000Hz-s bullshitről az USB szabvány is tud?
(Egy buszon van másodpercenként 1000 időrés, ezen osztozik váltakozva 8 eszköz, így jön ki az eszközönkénti default 125Hz, vagy ha valaki több rést fog össze, akkor 250/500/1000)
[ Szerkesztve ]
dqdb
(nagyúr)
4000Hz-s bullshitről az USB szabvány is tud?
Tud, 8000 Hz-ig lehet fokozni.
Mindenesetre a nem optikai kapcsolós változatnál rengeteg értelme van a 4000 Hz-nek az 4-5 ms környéki pergés mellett.
Ha jol implementalod a pergesmentesito algoritmusodat, akkor nem lesz benne semmi keses. Ha moho modon minden uj inputot egybol kikuldesz es utana "befagyasztod" annak a kapcsolonak az allapotat a pergesi idore, akkor lenyegeben semmit nem keshetsz. Persze a pergesi idonel rovidebb lenyomasokat sehogy sem fogod tudni megbizhatoan erzekelni...
No, meg az megint mas kerdes, hogy a kapcsolok szkennelese stb. is megy-e legalabb 4kHz-el, hogy legyen is ertelme az egesznek...
nyunyu
(félisten)
4000-szer végigolvasni a billzetet az 440 ezer gomb címzés+beolvasás másodpercenként, ezek gondolom nem egy órajelciklust igényelő műveletek.
Van egyáltalán ilyen gyors mikrokontroller, ami ezt végig tudná pásztázni?
(Ha jól rémlik, CM használt valami 72MHz-s Arm M0-t pár éve.)
Ja, meg a fényorgia fluiditásának biztosítására is kell pár órajelciklus 
[ Szerkesztve ]
kisfurko
(senior tag)
Ha jól csinálod, és jó a hardware, akkor soronként olvasod, abból meg van 6. Persze, utána kell még kicsit processzálni, kimaszkolni a változásokat, azokat elküldeni.
Feri7619
(tag)
Ez csak marketing. Megteremtik az igényt, a vevőkört... amelyik kap rá.
A világ leg jobb e-sportolója sem tudja kihasználni a 8000hz egér, a 4000hz billentyű és a 480 hz monitor előnyeit. Ennyi! Ez divat és marketing. Megteremtik az igényt a vásárlásra, más haszna nincs! Ki gondolja komolyan, hogy valaki is érzékel akár egy ezred másodperces késést? 
Ketlem, hogy egy egesz sort egyszerre be lehetne szkennelni, de a billentyuket 8-asaval siman. Es ugy meg tenyleg nem annyira sok munka van vele.
dqdb
(nagyúr)
Ha jól rémlik, CM használt valami 72MHz-s Arm M0-t pár éve.
Custom vonalon egyre több nyáktervező áll át a korábban ezen a területen egyeduralkodó ATmega 32U2/4 vonalról STM32F072-re (vagy az STM32 család másik tagjára). A nevesített modell szintén ARM M0 és 48 MHz-es, mert billentyűzetben felhasználva nem nyújt kevesebbet sehol sem, bizonyos téren többet nyújt, és egyszerűen olcsóbb (plusz ha az elmúlt 1-2 hónapot nézzük, akkor kapható).
Domonkos: ha egy ESP32 alapú apróságnál nem csináltam volna pontosan azt egy nyomógomb kezelésére, amit leírtál, akkor el tudnám intézni egy hmm, erről nem hallottam, jó ötlet szöveggel, de így le kell hülyézni magam
GreatL
(őstag)
Asus van mert magyar kiosztású, í a helyén... valamiért utálom ha angol, bár az angol nyelvvel nincs gondom.
kisfurko
(senior tag)
Igen, ha csak 8 bites I/O portjaid vannak, akkor egy utasítással csak 8 oszlopot olvasol. Én direkt úgy vezetékeztem az Atmega32U4-gyen, hogy a B és a D porton legyenek az oszlopok. Ha egyszer elkészül a firmware, majd kihasználom ezt, addig marad a QMK.
dqdb
(nagyúr)
QMK-ban is le tudod cserélni a gyári matrixscanner kódot sajátra.
Szabad--e olyat kérdezni, hogy a mikrovezérlőben egy teljes kiolvasás procesz és adat küldése az USB-re mennyi időt vesz igénybe? Mennyire módosítja ezt, ha Low-power mikrovezérlőt használsz, agresszívebb energiagazdálkodással?
dqdb
(nagyúr)
Erre nem tudok válaszolni sajnos a jelenlegi ismereteim alapján, de az az érzésem, hogy a második kérdésedre a semennyire a helyes válasz.
Az épített billentyűzeteim mindegyikén QMK firmware fut, ezt ismerem valamennyire, de ebből a legalsóbb szinttel, azaz a mátrix kezelésével még nem volt dolgom. Itt van egy rövid összefoglaló róla, nekem a kívánt funkcióhoz a process_record szint alá nem kellett mennem még (és arra is csak egy elég speciális funkció miatt, amúgy csak a layoutot kellett volna definiálnom). A QMK-ban (pontosan az alatta lévő TMK-ban) alkalmazott kód vezetékes billentyűzetekhez készült eredetileg, és emiatt az ahogy a csövön kifér megoldással figyeli a mátrixot mindenféle energiagazdálkodás nélkül (hacsak ezt egy adott billentyűzetnél nem szabják jobban testre, ami nem egyszerű), ez az egyik oka, hogy ritka holló a wireless custom és ami akad, annak sem túl jó az üzemideje (a másik oka a licencek összeférhetetlensége a GPL-es QMK és a kedvelt nRF családok SDK-ja között).
A ZMK nyújt mindkét problémára megoldást (LP mód és MIT licenc GPL helyett), ezzel gyakorlatban még nem találkoztam, egyszer majd talán ránézek (van egy nem BT-s nyákom, ami támogatott).
[ Szerkesztve ]
Semplar
(őstag)
Már a mechanikus kapcsoló is visszalépés, de viszik, mert trendi...
kisfurko
(senior tag)
Tudom. A saját firmware az csak egy a sok értelmetlen projekt közül, ami valószínűleg sose lesz kész
nyunyu
(félisten)
Hajaj, lassan két kezemen se tudom megszámolni, hány billzetről ötleteltem már itt a fórumon, de azóta sincs kész : ![;]](/dl/s/v1.gif)
(De legalább ma megtaláltam a fél éve szétszedett GMMK csavarjait, így elméletben talán össze is tudnám szerelni hangtompítás után.)
[ Szerkesztve ]
