Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: Electrin 23. 01. 2018, 10:03:55
-
Ahoj,
rád bych se na vás obrátil s dotazem z embedded sféry: v naší takřka garážové firmě fušujeme do vývoje řídicích automatik s mikrokontroléry ARM Cortex-M0/4, FW píšeme rovnou pro holé železo, bez RTOS atd. Máme vytvořené aplikační knihovny, bohužel dost divokým způsobem, zejména co se týče ovladačů. Do budoucna bude vhodné implementovat určitý standard, mně by se líbil POSIX, hlavně z důvodu možného nasazení některého z POSIX-like RTOS či možnosti snažšího přechodu na embedded Linux.
Máte někdo zkušenosti s psaním ovladačů pro malé MCU standardizovaným způsobem, zejména pro POSIX? Co to všechno obnáší? A vyplatí se to vůbec?
Děkuji moc za případné odpovědi.
-
IMHO to nestojí za to, v čem je třeba write(fd_do4, &value_do4, sizeof(value_do4)) lepší než do_set(4, true)?
-
Uznávám, že nasazení standardu typu POSIX atd. přinese určitou režii, ale na druhou stranu mi zajistí jednodušší přenositelnost kódu a jednotné API.
V aktuálním čase připomínají naše knihovny pohádku o kočičce a pejskovi... :)
-
Uznávám, že nasazení standardu typu POSIX atd. přinese určitou režii, ale na druhou stranu mi zajistí jednodušší přenositelnost kódu a jednotné API.
V aktuálním čase připomínají naše knihovny pohádku o kočičce a pejskovi... :)
pokud vím tak neexistuje garance, že pro tenhle technologický IO bude k dispozici posixové API a pokud existuje, tak záleží na driveru jak interpretuje data, tj. můžete mít soubor pro GPIO modul nebo jinde soubor pro každý pin zvlášť a dostanete něco jako
#if DESKA_TYP1
value = 0x00ff01000;
write(fd, &value, 1);
#elif DESKA_TYP2
do_write(4, true);
#else
#error deska not supported
#endif
zkrátka to co teď máte schované v knihovnách (jak má být) přenesete do aplikace
-
Normálně se to dělá tak, že si uděláte soubory "hw.h" a "hw.c" kam dáte funkce které pracují přímo s HW. V případě změny MCU akorát vytvoříte jiné "hw.h" a "hw.c" - samozřejmě ne vždy je použití elegantní (pokud potřebujete rychle zapisovat do registrů a "smrdí" vám makra, atd. atd.)
-
Pár názorů tu už padlo, ještě doplním něco k zamyšlení
- Je dobré si říci kolik ta určitá režie je. Čím menší procesor(RAM/FLASH) tím víc to bolí. Navíc čím více je api high level tím více má tendenci bobtnat o různé tabulky a buffery(UART atp.)
- U složitějších periferií může být problém, že unifikované api "schová" nebo "znepříjemní" přístup k určité funkcionalitě.
- Mezi různými periferiemi stejného typu mohou být i dost velké rozdíly, to co jde někde s malou režiií, může mít jinde o mnoho větší požadavky
Také může nastat situace, že konkrétní interní API je tak nekompatibilní s Unifikovaným že jediné rozumné řešení je použít jiné api(ať už z důvodu režie nebo jiného). Nebo, pokud je to vůbec možné, tak z unifikovaného ponechat jen některé základní funkce. Pak už je to takový kočkopes. - Specifické featury - rozšíření. Implementovat všude/někde/Za jakou cenu?
Cena může být hodně různá i naperiferií stejného druhu aje jiného typu. - Někdo to musí napsat a odladit. Na všech podporovaných architekturách
- Mělo by se to otestovat na všech variantách(cpu) a ve všech kombinací parametrů(nebo alespoň těch očekávaných) - některé periferie mají parametrů docela dost, a navíc ne všechny kombinace jsou všude platné!
Chci tím také řící, že tím že se periferie překryje mezivrstvou, tak se na ni začnou lidi spoléhat, a opravdová podporovaná funkcionalita té periférie není tak na očích. Čím později se na to přije, ... .
- Je to další vrstva kde se může skrývat chyba, obvykle se to přikládá k projektu jako .obj bez ladících informací a s maximální optimalizací. tj pokud to není opravdu, opravdu, opravdu hodně otestované a stabilní tak to může přinést další problémy.
Za mne pokud to jde, tak se spíš se snažit IO oddělit do extra souboru/ů než se snažit za každou cenu unifikovat.
Většinou je to docela dobré řešení a je hned vidět kolik kde a jak se využívá RAM/FLASH)
Ono pokud je třeba velká míra abstrakce a znovupoužitelnosti, tak pak už je na zvážení jestli nepoužít nějaký plnotučnější OS, i za cenu většího procesoru/ram/flash. A tyhle střední/menší procesory nechat na jednodušší věci, případně věci kde potřebujete mít zaručené odezvy atp. - v tom případě jsou ale unifikační mezivrstvy někdy spíše naškodu, obzvlášť pokud se na ně spoléháte ale nekontrolujete je.
Editace: (bylo myšleno ponechat střední/menší procesory jako spolupracující jednotky k tomu velkému)
-
Zapomněl jsem reagovat ještě na část
Do budoucna bude vhodné implementovat určitý standard, mně by se líbil POSIX, hlavně z důvodu možného nasazení některého z POSIX-like RTOS či možnosti snažšího přechodu na embedded Linux.
Možná se pletu, nejsem specialista na posix, ale posix definuje api směrem k aplikaci, ne směrem k "ovladačům".
Ovladač je podle mne spojen s daným konkrétní operačním systémem a nevystavuje přímo posix api(to je až další vrstvou OS).
Navíc jestli jsem to pochopil správně, tak by se nejdřív psali tyhle ovladače do stávajících aplikací a až pak by se portovalo na nějaký OS. Tj tu posix mezivrstvu by také musel někdo nvrhnout/napsat/odladit.
Jinými slovy jsem skeptický k snadnému portování ovladačů a podle mne to bude spousta zbytečné práce.
-
Pánové,
děkuji moc za vaše názory a připomínky. Když to tedy vezmu kolem a dokola, tak pro začátek bude asi nejlepší učesat a vnést řád do našich knihoven, bez toho, aniž bych nad nimi vyvíjel další vrstvu.
I když se v další iteraci standardizaci nebráním, hlavně z hlediska šťouravosti a osobní zvědavosti :D