@František Ryšánek - da se ke klasickym "desktop" deskam pripojit ten I2C touch? Vsude vidim ze to ma jeste volitelne RESET a pak povinne INTERRUPT. Jak tohle zprovoznit v ne-embedded zarizeni? Ocekavam tip na treba na LPC kontroler/bridge.. LPC header byva soucasti temer vsech desek.
Tohle mi moc nevoní dálkami. Několik důvodů/aspektů.
Já jsem I2C HID potkal poprvé na nějakém noťasu (Dell, tuším mobile Kaby Lake i5) a ten dotykový senzor je konkrétně touchpad. Zjevně pro to má moderní intelí čipset nějakou podporu. Tradičně míval intelský čipset (north nebo south bridge) tak 1 maximálně 2 kanály i2c/SMBus, na kterých bylo lze nalézt SPD EEPROMky DIMMů, hardware health monitory (lm-sensors) a třeba syntezátory hodin. Myslím, že do toho by I2C HID s interruptem moc nezapadl. No ale teď jsem koukal na
Kaby Lake U/Y series a našel jsem tam I2C portů snad osm. Bohužel v datasheetu nejsou nijak popsány, vedle obligátního "panáka" na str.12 je najdete už jenom v seznamu signálů v pinoutu. (Druhá část datasheetu je nezmiňuje vůbec.) V pinoutu nejsou vidět žádné dedicated piny pro IRQ, ale to nic moc neznamená, protože za interní IRQ linky (vstupy APICu nebo možná řadiče I2C) se dá tahat obvykle taky pomocí GPIO, což opět nevidím v DS popsáno.
Občas na nějakém PC motherboardu je vývod i2C na headeru k vidění, ale dost pochybuju, že by na to šel nějak snadno připojit TS - minimálně ten dedicated IRQ drát tam nebude k dispozici. Mimochodem některé tyto vývody na boardu mohou být "slave only", určené pro připojení externího *masteru* (managementové karty, diagnostiky apod).
Pokud se týče LPC, tak se obávám, že ani tady Vám pšenka nepokvete. Tenhle port je určený primárně pro připojení LPC POST reportéru. Dá se na něj připojit taky
sekundární LPC SuperIO šváb, pokud si dokážete v Linuxu dořešit dekódování adresního okna na upstream PCI/LPC(ISA) bridgi. Toto může klapnout i samospádem, díky subtractive decode nebo pokud LPC bridge dekóduje by default celé okno "legacy ISA" (což není úplně automatické). Každopádně se Vám v OS automaticky NEobjeví periferie obsažené v tomto přídavném LPC SuperIO švábu, protože A) o nich neví originální BIOS, takže je neoznamuje skrz ISAPnP ani ACPI, a B) si ty periferie napřed musíte nakonfigurovat (bázová adresa, enable, alternativní funkce na GPIO pinech). Potom, pokud víte kam jste si ty periferie posadil, dá se na ně sahat buď z kernelu (napsat si vlastní ovladač nebo pokonfigurovat nějaký kompatibilní stávající) nebo i z user space skrz IOperm, pokud Vám nevadí že neobsloužíte IRQ. No a pokud toto všechno zkousnete, tak nakonec z hlavy nevím o LPC SuperIO švábovi, který by obsahoval i2c *master*. Většina SuperIO švábů obsahuje HW monitor (často
LM78 compatible) , který má I2C rozhraní - jedná se ovšem o I2C *slave*. (Mimochodem ten health monitor bývá z hostitelského CPU vidět dvěma cestami: na ISA I/O portu a druhou cestou skrz I2C skrz north/south bridge.) Pokud byste si stavěl svoji vlastní přídavnou SuperIO destičku, tak I2C by na to nakonec připojit šlo, nakonec asi včetně IRQ, a to skrz GPIO - ovšem samotný I2C protokol jedině skrz bit-banging. Pro ten má Linux slušnou zabudovanou podporu, jenom naplníte nějaký struct definicí "zapojení", a dál si to brblá samo - ale žužlá to jednotlivé bity/hrany softwarově.
Vlastně je tu jedna možnost, jak získat autonomní HW řadič I2C, patrně včetně interruptu, na LPC: použít k tomu nějaký "embedded controller" na LPC. To je blízký příbuzný SuperIO švába, který ovšem obsahuje autonomní MCU jádro, tradičně 80C51, nebo nověji nějaký malý ARM. Používá se to v noteboocích / tabletech a odvozených embedded boardech. Ale prakticky veškerá dokumentace je pod NDA :-( Takového švába těžko seženete volně sypaného, a pokud ho někde uloupnete ze šrotu, tak k němu nebudete mít dokumentaci ani další podporu (nebudete vědět jak si napsat do něj firmware, ani nebudete mít example od výrobce čipu).
No a pak je dalších pár problémů v hostitelském OS. Totiž na i2c moc nefunguje PnP. Třeba lm-sensors mají jakousi rizikovou heuristickou auto-detekci: očichají pár well-known adres a podle toho co najdou, můžou v některých případech prohlásit s jistou statistickou mírou jistoty, že na té adrese sedí EEPROM nebo health manager (ten by tuším mohl mít nějaké minimalistické registry typu vendor/chip ID). Zároveň se lm-sensors obloukem vyhnou adresám, kde se vyskytují syntezátory hodin. Ale pokud se týče driverů pro již zmíněný
I2C HID nebo
dvě varianty nativního ovladače pro I2C TS konktroléry eGalax/EETI (to je jedna a ta samá slavná značka) tak se zdá, prostý "modprobe i2c-TS-ovladač" ničeho nedosáhne. Neexistuje "PnP strom", který by si registrovaný "entry point" ovladače automaticky zavolal. Ovladač se natáhne a je zticha. Pokud se podíváte do zmíněných tří zdrojáků, "na co se ovladač při zavedení chytá" a jaké má případně "argumenty při loadnutí", tak zjistíte, že uvnitř není žádný slibný module_param(), jenom module_i2c_driver() odkazující nepřímo na "struct i2c_device_id". No moment - ale k čemu device IDčka, když se na ně nemá co chytat?
Jsou tu dvě možnosti. Jednak aktuální ACPI zřejmě obsahuje strukturu/metodu pro dotykové senzory (touchpady/touchscreeny), zřejmě včetně odkazu na vstup/linku IRQ (kterou třeba BIOS v čipsetu předkonfiguruje = navlékne na konkrétní GPIO pin). A zřejmě Windows se na to umí chytit - přinejmenším do té míry, že pokud předložíte operačnímu systému pasující ovladače, tak se zavedou i bez ruční konfigurace třeba právě toho IRQ. Toto se samozřejmě uplatní v případě, že jste výrobce počítače/motherboardu, takže si podporu pro dotykové zařízení do BIOSu dopíšete (v souladu s tím, jak jste to na desce zadrátoval).
No a v Linuxu existuje vedle univerzálního PnP (které funguje na PCI, USB, v ideálním případě ISAPnP a ACPI) také podpora pro "hloupá nedetekovatelná zařízení", dokonce ve dvou historických evolučních variantách:
V principu jde o základní způsob(y), jak zařídit podporu pro různé embedded motherboardíky, oplývající nedetekovatelnými hloupými periferiemi, třeba ještě navíc pověšenými na GPIO. Pokud pro takový hardware zařizujete podporu v kernelu, napíšete si primitivní "ovladač" nebo dokonce jenom konfigurační soubor, a zavěsíte do zdrojáků jádra... Rozdíl / styčné plochy mezi oběma variantami popisuje starší
článek na lwn.net. Evoluční krok od "platform driverů" k "device tree" měl cosi společného s očištěním kernelu od duplicitních zdrojáků pro tentýž hardware - ve chvíli kdy adresář s "platform drivery" pro různé embedded desky ve vanilce začal hrozivě bobtnat...
Čili tudy vede cesta, pokud byste se třeba dostal k progresivnímu embedded motherboardu, který má vstup pro dotykáč vyvedený, nejlíp včetně IRQ, ale nějak Vám v Linuxu neklapne PnP na bázi ACPI. Dopsat si tu podporu sám, skrz "platform device" nebo "device tree".
Pokud se týče I2C dotykáče, tak samozřejmě nejste
první kdo to
řeší.
Mimochodem řadič EXC3132 není ani zmíněný na webu výrobce (EETI). Už tohle by mě v souvislosti s Linuxem nabádalo k ostražitosti :-)
Osobně moc nechápu, k čemu je dobré vracet se k i2c (pomalý dvoudrát bez PnP) když PC čipsety už mnoho let zpátky obsahují úsporné implementace USB (citelně rychlejší dvoudrát s PnP). Sice ten "interrupt mode" na USB1-2 je ve skutečnosti pořád jenom polling v režii mastera (HCI), ale je to myslím pořád rychlejší, než i2c popoháněné interruptem... Pravda je, že i2c slave je asi implementačně jednodušší než USB device - žeby vyšší potenciál k úsporám příkonu? Výrobně levnější? Nebo je vhodnější ve smyslu "vendor lock-in"? Protože funkční PnP je především svoboda pro koncové uživatele, adminy a cheap-skate opraváře... Kousek od každého? A že i2c namísto USB tlačí zrovna Intel... et tu Brute?
Čili výše uvedený text je jenom obsáhlejší variantou mého konstatování, že USB HID je jistota. A i tady je eGalax/EETI zřejmě vůdčí značkou, jejich kapacitní dotykáče s HID rozhraním vídám už pár let a je s nimi úplně nejmíň problémů.
Už jsem viděl taky slušný dotykový kontrolér od značky USBest/SiS, dokonce s velmi nápomocnou podporou přímo z Taiwanu (!) - šlo o rekonfiguraci z režimu "Windows-compatible HID touch device" na "USB HID mouse". Asi mělo tehdy dost váhu, když jsem řekl, že ten firmware v dotykáči řeším v počítači od Advantechu (konkrétně UTC-510).
Padla tady zmínka o ELO. To je další velmi tradiční dinosaurus, pro mě osobně první značka vůbec, se kterou jsem měl tu čest. Původně výrobce dotykových řadičů (moje první vzpomínky jsou tak 15-20 let zpátky), posledních pár let prodávají i kompletní monitory s dotykovým senzorem. Žeby nakonec i kompletní počítače? Asi proč ne :-) K těm svým dotykovým řadičům na RS232 mívali pečlivou, volně dostupnou dokumentaci. Nevím jaký je aktuální stav jejich sortimentu, ale mívali dotykáče rezistivní, SAW i kapacitní. Používal je kdysi Advantech, ale on i další taiwanští výrobci už dávno šmahem přešli na PenMount, eGalax, vzácně 3M. (Občas jsou k vidění všelijaké další bezejmenné asijské hrůzy, naštěstí opravdu vzácně.) Odhaduji, že taiwanci ELO zavrhli kvůli ceně.
20 Odpovědí
10322 Zhlédnutí