Vlákno názorů k článku Výroba vlastnej mechanickej klávesnice vyhovujúcej vašim potrebám od ventYl - Holy bosy makefile a obsolete procesorova architektura. Takto...
-
Holy bosy makefile a obsolete procesorova architektura. Takto sa to v automotive robi, pan kolega!
Na novy design by som uz asi nic s AVRkom nepouzil, aj ked v tomto momente este mam styri kusy na stole. Snazim sa ucelne zlikvidovat stare zasoby, nez prejdem na ARM. Zvlast SMD varianty uz neposkytuju absolutne ziadnu vyhodu, snad okrem toho, ze netreba ozivovat veci ako HAL.
Kompaktne rozlozenie klavesnice je OK, ale asi by som ho az takto neoptimalizoval. Vsetko sa da vyriesit mappingom v SW.
-
SW mapping může být celkem nepohodlný při používání virtuálních strojů nebo RDP. A nenašel jsem dostatečně použitelný způsob, jak si udělat třeba virtuální numpad: https://unix.stackexchange.com/questions/366552/numpad-emulation
A ne všechno lze vyřešit SW mappingem, zejména pokud klávesnice nemá dostatečnou podporu pro stisk různých kombinací kláves. Jsou tu tři limity:
* Typicky máme maticové klávesnice. Mnoho klávesnic je bez diod, což znamená, že nezvládnou některé kombinace tří a více kláves. (Zkuste si, jestli vaše klávesnice zaregistruje správně LevýShift+CapsLock+S…) To pak nevyřeší ani firmware. Typicky na to moc nenarážíme kvůli vhodně navrženým maticím, které řeší nejtypičtější kombinace, ale při přemapování ty typické kombinace mohou být jiné…
* USB HID dovolí přenést maximálně šest současně stisknutých kláves plus modifikátory. Některé klávesnice to ohackují tím, že se tváří jako několik klávesnic (situace podobná zapojení několika klávesnic do USB hubu).
* Pokud už klávesnice má nějakou klávesu Fn, typicky její stisk zpracovává sama, a není možné jej zpracovat softwarově jinak. -
Kdyz uz jsi narazil na makefile v automotive, tak my to tak pouzivame. Vuci makefile mam silne vyhrady (napriklad jeho chovani k bilym znakum je des. To ze rozlisuje mezery a tabulatori vi snad kazdy, ale kdo bezne vi, ze mezera na konci radku se dostane pri prizazeni do retezce?)
Ale cim to nahradit? Vetsina modernich nastroju jde ve snaze automatizace moc daleko a clovek ztraci kontrolu. To je problem zejmena v nutnosti mit opakovatelny build (nejen stejne soubory, ale i logy). Nebo nutnost zpracovavat soubory i jinak nez kompilatorem a to i v mezikroku. Navic je tu nutnost se obejit bez externich sluzeb, protoze preklad musi byt mozny i offline na zakonzervovane (verze vsecho) virtualce. -
Zakonzervovana virtualka, to tiez tvrdo smrdi automotive :) Ja to volam fosilie.
Ja mam roky skusenosti s CMakeom a videl som ho uz pouzity na vsetkom od Embedded projektu velkosti tejto klavesnice po enterprise Windowsiu GUI aplikaciu. Myslim, ze moderny CMake, ak je robeny spravne a nezneuziva sa na veci, na ktore by sa zneuzivat nemal, je vhodna cesta.
Z automatickych ficur Cmake-u prakticky jedine, co pouzivame je detekcia compiler toolchainu. Kedze je to embedded projekt, tak package management je pre nas nerelevantny. Napisal som tenky layer na spravu "third parties", ktory je v CMake-u iba preto, ze gro toho, co third parties robia je, ze pridavaju nove include cesty, setuju premenne vovnutri CMake-u a tu-tam prihodia nejaky CMake modul. Dalo by sa to urobit aj v Pythone, ale vela cinnosti by bolo duplikovanych.
CMake je potom pouzity cisto na definiciu build grafu. Bezne kroky, ktore idu do prekladaca tak, ako tradicne kroky pri kompilacii aplikacie, custom kroky (napr. buildovanie imageov) volaju externe utility. Bud priamo binarky, alebo kratke specificke kusy Pythonu urcene na jednu konkretnu ulohu.
V podstate takto to bolo aj predtym, akurat tie externe pythony nevolal CMakeom generovany makefile, ale batak.
-
Ono bohuzel neni mnoho moznosti jak to resit jinak. "modernich" reseni uz jsem videl pousty, ale nakonec to vypada stejne nebo podobne jako PlatformIO. Kdyz se po projektu po par mesicich vratim, nikdy nevim, jesli vubec pujde znova prelozit (z cele rady duvodu, predevsim kvuli sprave knihoven a verze kompilatoru) Pro profi nasazeni nepouzitelne na cokoli, na hobby projektech me to jen pije krev.
-
S tymto sa potyka nie len embedded development a jedina seriozna odpoved je CI. Kompilovat, kompilovat a kompilovat. Projekt musi byt zostaveny tak, ze na 3 prikazy funkcne ekvivalentne configure & make & make install dostanem flashovacie kontajnery z uplne holeho systemu, kde nie je nic, maximalne nainstalovany toolchain (ale nesmie byt v ceste). Ziadne kroky na manualne nastavenie prostredia typu tychto 45 premennych zavedieme do prostredia tak, aby sa uz ziaden vnutrofiremny projekt, ktory pouziva coilen trocha iny toolchain na tejto masine nedal skompilovat. Toto je toxicke.
Za takych podmienok sa to da trebars raz tyzdenne checkoutnut na Jenkinse, buildnut, vygenerovat flashovacie kontajnery a tie porovnat s baseline-ou. Ak baseline nesedi, tak si v logu pozrem, co sa na serveri zmenilo.
Za mna robustnejsie riesenie, nez po roku - dvoch - troch vytiahnut fosilizovanu virtualku, na ktorej sa po oziveni spustia updaty a skoncim s nefunkcnym systemom tak, ci tak. Alebo sa nepustia a skoncim rovnako s nefunkcnym systemom, pretoze mi napriklad chybaju certifikaty, alebo korporatne nastavenia.
-
KateStříbrný podporovatel
Mě spíš než ARM zaujalo ESP32 pro možnost vyrobit snadno bezdrátovou klávesnici. https://github.com/Galzai/MK32/wiki
Zvlášť split keyboard varianta zní hodně zajímavě :) https://github.com/Galzai/MK32/wiki/Split-Keyboards
20. 4. 2020, 12:41 editováno autorem komentáře
-
Architektúru a makefile som vôbec neriesil nasiel som firmware TMK, klavesnicu GH60 a na tom som začal stavať. Firmware som mal napísaný a nahraný za pár minút (aj keď všetky klávesy boli "1") potom som to už len šperkoval. Prečo by som mal použiť ARM a nie stavať na niečom čo už je overené aby som nemusel znova vynaliezať koleso. Berte prosím do úvahy že ide o hobby projekt a čas ktorý mu môžem venovať sa musí vtestnať do času keď synátor neplače, žena nič nechce a dom sa nerozpadá. Aký procesor do klávesnice by ste použili vy a prečo? V práci ani nevedia čo je makefile programujem hlavne C# a PLC-ecka. Linux a elektroniku mám ako psychohygienu.
-
Nezhadzujem snahu urobit si nieco, akurat podobne ako mam nazor, ze Arduino je pre kohokolvek mimo umelca skor na skodu nez na uzitok, pretoze hole AVR podpori kreativitu viac (inu, arduino shield je mozne napojit aj na hole AVRko), tak mam nazor, ze obcas nezaskodi to koleso vynajst.
Okrem samotneho kolesa sa clovek este priuci co-to navyse. A tieto dodatocne vedomosti maju vacsiu hodnotu, nez to, ze na konci procesu bolo koleso.
Pouzil by som napriklad procesory z rodiny STM32 (ale rovnako dobre budu fungovat akekolvek embedded ARMy). Devkit sa da zohnat radovo za cca 10-20 eur. Programator je jeho sucastou. Priamo v doprovodnom HAL package-i je hotovy example implementujuci USB HID zariadenie. Konkretne to emuluje mys, ale prepnut na iny typ HIDu je uz potom trivialne jednoduche.
Rozchodit I/O z matice klavesnice je potom uz robota podobne narocna ako s AVRkom, kedze sa jedna o semi-custom layout.
Preco by som ho pouzil? AVR je vysoko pravdepodobne soon-to-be-dead platforma. Navyse ako pozeram sucasnu ponuku AVR u Microchipu, tak sa dost obmedzuju na low RAM, low FLASH aj u ATmega. 4kB RAM a 48kB flash moze niektorym projektom nestacit.
ARM, napriklad STM32 zacina na procesoroch cenovo a vykonovo porovnatelnych s najvykonnejsimi AVRkami, ale umoznuje projekt skalovat na radovo vykonnejsie MCU prakticky bez nutnosti zasahu do SW. Pre mna je taka architektura cennejsia nez ready-made projekt, pretoze to, co sa naucim na uplne lowendovom MCU mozem potom zhodnotit (mozno aj profesionalne, kto vie aka bude buducnost?) na procesoroch vyssej rady.
Dalsia vyhoda je, ze k ARMkam obvykle netreba dokupovat drahy proprietarny debugger, ale funguje SWD/JTAG v podstate akejkolvek proveniencie (opat, devkit obsahuje debugger pouzitelny aj pre externy procesor). Osobne k AVR debugger nepouzivam, pretoze mi prislo zbytocne investovat donho vyse 100 eur (lepsiu cenu som na AVRICE inde nenasiel).
Ten vyvoj je potom taky... civilizovanejsi.
-
V tom pripade doporucuji zajit na eBay a za ceny urcite do 50 Kc za polozku koupit
STLinkv2
stm32f103c8t6 "bluepill" miniplosnakDevkity jsou proti tomu neskutecne drahe; do toho miniplosnaku lze zapajet spoustu STM32ek v QFP48 pouzdru, treba i STM32F302 apod.
Obloukem bych se vyhnul HAL knihovnam, ja pouzivam CMSIS (.h s definicemi periferii a vse delam rucne). Na USB existuje alternativni minimalisticky stack, nejsem si jist zda v nem je HID, ale CDC chodi suprove, nekde tu je na foru thread kde mi toto bylo doporuceno.
