Perifériaillesztés Android-eszközökhöz – 2. rész

Folytatjuk az egyik legelterjedtebb mobil operációs rendszer perifériaillesztési feladataihoz szükséges ismeretek előző cikkünkben elkezdett ismertetését.

OpenAccessory USB

Annak érdekében, hogy az Android-készülékek USB-kommunikációs képességét az USBHost hardvertámogatása nélkül is engedélyezhessük, a Google egy OpenAccessory nevű programstruktúrát is kidolgozott az USB-driverek fölé. Ez lehetőséget ad a tartozékok és interfészek fejlesztőinek, hogy a szabványos USB-port funkcionalitását egyedi, alkalmazásspecifikus USB-forgalom céljára használhassák. Az OpenAccessory protokoll ezt azzal éri el, hogy először is az USB-port néhány egyedi, gyártóspecifikus, készülékszintű vezérléseit olyanokra cseréli, amiket az egyedi készülékfejlesztő dolgozott ki. Ezek a parancsok az USB-meghajtóprogramokat egy bizonyos „tartozék-üzemmódba” kapcsolják át és arra készteti az USB-perifériát, hogy lekapcsolódjon a buszról, és tartozéküzem­módban csatlakozzon vissza, amelyben a készülékhez a Google gyártóazonosítója (VID) és egy vagy két specifikus termékazonosítója (PID) van rendelve. Ebben az üzemmódban tehát egy gyártó-osztályú interfész működik, és az alkalmazás ehhez fér hozzá.
Amit az OpenAccessory az alkalmazás rendelkezésére bocsát, az hasonló a FileStream^[1]-formátumot megvalósító interfészhez. Az adatokat éppen úgy lehet beírni egy streambe, vagy onnan kiol­vasni, ahogy azt a fájl írásakor vagy olvasásakor tesszük. Ez abban különbözik az USB-perifériakezelésnek a legtöbb firmware-megvaló­sításától, hogy az utóbbi esetben a csomagméret az USB-protokoll által használt szabványos mérettel egyenlő. Az ebből a különbözőségből adódó problémákkal az alkalmazásfejlesztőnek és a tartozék firmware készítőjének tisztában kell lennie.
Az Android-eszköz USB-meghajtója egy adatstream-et vesz, azokat csak „adatelemenként” látja, összefüggéseiben nem, ezért nem képes felismerni és értelmezni az adatok közé beszúrt parancsok lehetséges logikai töréseit.
Az alkalmazás „írás”-funkciójának két független hívásából származó adataiból olyan adatcsomagok épülhetnek fel, amelyek ugyanabba az USB-csomagba kerülnek. A firmware-nek kell figyelnie arra, hogy a vett USB-csomag tartalma az alkalmazás két független „írás” funkcióhívásából származó adatokat tartalmaz.
Ennek ellenkezője is előfordulhat: lehetséges, hogy az alkalmazás „írás” funkciójának egyetlen hívása annyi adatot generál, amennyit csak több USB-csomag képes elszállítani. Ilyenkor az Android-készülék USB-meghajtója tördeli csomagokra az adatot, elküldi a tartozéknak, és az USB-csomagméret szerint tördelt adatokat a tartozék programjának kell összeállítania a megfelelő formátum szerint.
A csomagolás és a feldarabolás egyszerre is történhet. Például az OpenAccessory-keretprogram jelenleg 64 bájtos adatcsomagokat használ. Ha az alkalmazás kétszer hívja meg az „írás”-funkciót egymás után, az első hívás 20 bájt, a második 64 bájt adatot küld. Következésképpen lehetséges a két adatszakaszt egyetlen 84 bájtos adatblokká egyesíteni attól függően, hogy az USB-meghajtó mikor veszi ki az adatokat a stream-ből, és küldi el azokat a buszon. Az USB-meghajtó ezek után ezt a streamet USB-méretű csomagokra tördeli, amelyben az első csomag adattartalma 64 bájt, a másodiké 20 bájt. Az első csomag eszerint tartalmazza az első „írás”-utasítás 20 bájtját és a második „írás”-utasítás 64 bájtjából 44-et. Ezt követi egy újabb USB-csomag, a második „írás”-utasításból fennmaradt 20 bájtnyi adattartalommal. A folyamatot a 2. ábra szemlélteti.

2. ábra Adatcsomagolás és -tördelés

Az utolsó feladat annak megértése, hogyan történik az „ömlesztett”, tömeges USB-adatátvitel (USB bulk transfer). Az USB-specifikáció szerint az USB bulk transfer akkor kész, ha

• pontosan annyi adatot küldtünk, mint amennyit a vevő vár, és

• az utolsó csomagnál rövidebb csomagot – például egy nulla hosszúságú csomagot is elküldtünk.

 Ahhoz, hogy egy olyan adatblokkot küldhessünk, amely a névleges csomaghosszúságnak (példánkban bájtnak) pontosan az egész számú többszöröse, utána egy nulla hosszúságú csomagot kell küldeni. Ennek elmaradása azt eredményezi, hogy az adat benne marad az Android USB driverében anélkül, hogy átadódna az OpenAccessory FileStreamnak – következésképpen soha nem továbbítódik.

Az OpenAccessory keretprogram használatát is engedélyez­tetni kell az AndroidManifest.xml fájlban (12. programrészlet).

12. programrészlet: Ezzel a sorral lehet engedélyezni, hogy egy alkalmazás hozzáférhessen az OpenAccessory keretprogram szolgáltatásaihoz

A készülék képes arra is, hogy automatikusan elindítson egy alkalmazást azzal a karaktersorozat (string) információval, amelyet a „tartozéküzemmódba” való belépéskor ad át. Ezt az USB Host API-hoz hasonlóan lehet beépíteni az xml-fájlba (13., 14. programrészlet).

13. programrészlet: Egy alkalmazás indítása OpenAccessory-üzemmódban

14. programrészlet: Egy szűrő segítségével határozható meg, melyik készülék indítja el az alkalmazást

Az OpenAccessory-keretprogram legnagyobb hátránya, hogy azt csak egy választhatóan alkalmazható könyvtár-kiegészítés valósítja meg az Android operációs rendszerben.  Néhány gyártó ezért úgy is dönthet, hogy nem építi be a rendszerébe, ezért nem lehetünk biztosak abban, hogy minden olyan készülék, amely teljesíti az operációs rendszer egy bizonyos változatára vonatkozó követelményeket, az valóban használhatja is majd az OpenAccessory funkcionalitásait.
Az Android 4.1 Jelly Bean verzióban bevezették az Android OpenAccessory (AOA) protokoll 2. verzióját, amely két további új képességgel áll az alkalmazásfejlesztők rendelkezésére:

• támogatja a digitális audio kimenet és

• a Human Interface Device (HID) vezérléseit a tartozéküzem­módból is.

Digitális audio

A digitális audiokimenet támogatása lehetővé teszi, hogy könnyen alakíthassunk ki az Android-készülekekhez audio „dokkoló­egy­ségeket”. Amíg csak az AOA 1. verziója állt rendelkezésre az audio dokkolók kialakításához, a fejlesztőnek egyedi protokollt és egyedi alkalmazást kellett hozzá kidolgoznia. Minden szabványos alkalmazás a headset és a hangszórók útján tudott csak audiokimenetet megvalósítani. Az AOA 2. verziójában az Android készülék minden audiokimenete az USB-portra is átirányítható, amely lehetővé teszi, hogy az Android-eszköz minden alkalmazása és a hozzákapcsolt készülék minden funkciója a dokkolt audioeszközön is használ­ható legyen. Az AOA V2 megengedi azt is, hogy az audiointerfészt a dok­koláskor lefutó alkalmazással vagy anélkül is használni lehessen. Ha a gyártói (VID) vagy termékazonosító (PID) nem kerül elküldésre az Android eszköznek,  mielőtt az a tartozéküzemmódba lépne, az elégséges feltétele annak, hogy a tartozékot a hozzá tartozó alkal­mazás elindítása nélkül lehessen dokkolni.  

Interfészvezérlések

A Human Interface Device (HID) vezérlései korábban csak az USB Host üzemmódban voltak elérhetők. Az AOA V2-ben a tartozékok küldhetnek HID-jelentéseket a hozzájuk kapcsolt Android-eszköznek és az operációs rendszernek a felhasználó kezelői beavatkozásairól. Ez hasznos a már említett audiodokkoló eszközök vezérlésénél, de olyan kezelőszervek illesztésénél is, mint az egér, a billentyűzet vagy a botkormány (joystick).

Összegzés

A tartozékok képességeinek és korlátainak megértése létfontosságú ahhoz, hogy egy hardvertervet jól működő Android-tartozékká alakíthassunk át. Ehhez olyan alkalmazási területeken is tapasztalatokkal kell rendelkeznünk, mint a többszálas programvégrehajtás, a vezetékmentes kommunikáció, az Android-eszköz hosztként való használata és a digitális audio. Az ehhez szükséges fejlesztési erőforrások – beleértve az ingyenesen letölthető és szabadon felhasználható firmware-t és az Android alkalmazási példákat is – megtalálhatók a Microchip Technology www.microchip.com/USB, www.microchip.com/wifi és www.microchip.com/bluetooth weboldalain.

Szerző: David Flowers – Microchip Technology

[1]A ”stream” kifejezés itt „adatáramlatot” jelent, amelyet rendszerint médiainformáció azonos idejű továbbítására használnak. Az adat csomagokra bontott formában érkezik, a vevő azonnal értelmezi és megjeleníti. Ehhez tehát nem szükséges az egész médiafájl letöltését megvárni, a stream első adatcsomagjainak vételekor a lejátszás azonnal megkezdődhet – lásd: a közismert videomegosztó szolgáltatásokat. A stream kifejezést – közkeletű magyar szakkifejezés hiányában – nem fordítjuk. – A ford. megj. 

Az előző rész megtalálható ezen a linken

www.microchip.com

Még több Microchip

Címkék: android