FreeRTOS ne
proč?
V ztracené odpovědi jsem to měl rozumně rozepsané.
FreeRTOS, alespoň podle všech informací, co mám, je řešení, které vysloveně nepodporuje komunitní vývoj. Zkusím vysvětlit dále. FreeRTOS nabízí relativně použitelný plánovač a základní synchronizační primitiva ovšem jen s vlastním nepřenositelným API. Pro malé systémy a stavbu vlastních řešení to nemůsí být vysloveně špatně a mnoha výrobcům čipů to dokonce vyhovuje. Každý má své HAL řešení (např Ti HalCoGen) které s FreeRTOS sintegruje. Stále OK až na to, že tím ztrácíte jeden z hlavních důvodů používání operačních systémů -- možnost přenést aplikaci používající rozumné API ovladačů na libovolný daným systémem podporovaný HW nebo architekturu. Je to mínus, ale lze se toho stále vzdát. O něco horší je, jak je kód FreeRTOS bez rozumných vrstev naplácaný do sebe s šíleným množstvím ifdefů (žádné pořádné rozdělení jako třeba RTEMS SuperCore, architekturně závislá část, BSP, Posix obálka, RTEMS originál API obálka). Jen analýza kódu je pak šílená a nakonec třeba zjistíte, že do verze vydané před před rokem a půl na bezpečnostních procesorech Ti dochází k přeplánování na v přerušení uvolněný task s vyšší prioritou až při příštím tiku nebo když se task s nižší prioritou sám vzdá procesoru nebo zastaví na synchronizačním objektu. Z pohledu kritické aplikace to lze považovat za kooperativní plánovač, a ten spíš do takové aplikace nepatří. Přitom zdokumentované takové chování není a v změti ifdefů se na začátek zdá, že to může být v pořádku. Ale není, to by si musel člověk základní operace pro Cortex-R přepsat a doplnit hooky po svém. V základu OS to nebylo. Teď je to zrovna na TMS570 vyřešené přes phantom interrupt, OK. Ale než použijete FreeRTOS někde jinde, tak si proveďte kompletní analýzu, co se vám vlastně zkompilovalo. A v tom prasáckém kódu to nakonec může znamenat víc času než si jednoduchý přepínač tasků napsat vlastní. OK, lze říct, že systém je ve vývoji a že se díky otevřenému charakteru a příspěvkům komunity časem dostane na slušnou úroveň.
Jenže s komunitou je hlavní kámen úrazu. FreeRTOS vás donutí používat nepřenositelné API, přitom pro svojí deklarovanou jednoduchost neobsahuje drivery téměř žádných periferií a ani příklady jak periferie typu SPI, CAN, I2C implementovat a jak vytvořit API nebo IOCTL podle nějakých pravidel. Přitom napsat na různých architekturách a BSP použitelnou infrastrukturu pro jednotlivé třídy zařízení je mnohem více kódu než jádro OS a podpora architektur. (Linux arch 136M (všech 31), kernel 7.2M, drivers 387M). Firmy a jejich obchodníci nadšeně vyberou OS zdarma (vždyť to má v názvu -- FreeRTOS), ale vlastně v každé firmě většinu OS píší znova a bez dobrých příkladů a často programátorští začátečníci. Výsledkem je vysloveně spatný kód a model. Každý má pak vlastní API zařízení a nemohou tedy využít efektu spolupráce. Některým firmám to i vyhovuje, nechtějí aby jejich "skvělou" investici do podpory jejich NDA hardware dali někomu zdarma. Bohužel i když si uvědomí, že mají totální bastl, tak alespoň podle mého dřívějšího hledání nějaká centrální koordinace práce na FreeRTOS neexistuje.
Důvody k této situaci jsou celkem pochopitelné, FreeRTOS vás dovede k používání API, ze kterého aplikaci přepsat na něco jiného je extrémně nákladné a tak nakonec začnete hledat, jak se ze situace dostat. A dostanete nabídku na certifikovaný SafeRTOS od firmy WITTENSTEIN. FreeRTOS je v podstatě code drop (možná i naschvál staré verze) z několika adresářů jejich komerčního řešení. V okamžiku, kdy do jeho nákupu nainvestujete velké peníze a dostanete i USB stack a další subsystémy ovladačů, tak přece nebudete vlastní vývoj i jen proti původnímu FreeRTOS dávat zdarma. A i když by jste chtěli, tak v okamžiku, kdy využijete infrastrukturu SafeRTOS, tak ani licenčně nemůžete. Asi vám stejně jako u Mathworksu nezbude nic jiného než pod cenou prodat své řešení do licencovaného poolu společnosti kontrolující danou technologii.
Alespoň takto jsem eko(nomy)systém okolo FreeRTOSu hned v jeho začátku vyhodnotil já a i při zatlačení na vystavovatele nějakého rozšíření pro FreeRTOS a SafeRTOS na letošním Embedded Worldu jsem nedostal uspokojivou odpověď, která by naznačovala, že se situace od té doby zlepšila.
U RTEMSu, Nuttx atd. opravdu neexistuje hlavními vývojáři podporovaná shaddow branch pro komerční řešení. Není to žádný code drop, vývoj probíhá v hlavních větví veřejných repositářů. Když máte nápad nebo nové drivery a kód napíšete dobře, dostanete ho do mainline. V mainline vidíte, jak se ovladače pro dané třídy zařízení dají napsat správně a s využitím již existující infrastruktury, takže je to psaní i pokud ovladač ještě neexistuje o řád jednodušší, při integraci do mainline dojde k review od těch, co znají systém nejlépe, takže máte určitou jistotu, že neděláte něco špatně, že díky nepochopení dokumentace chodí řešení jen náhodou a po drobném update systému nebo při jiném časování nedojde třeba k těžce odhalitelným chybám které se projeví pádem celého systému jednou za rok (v nejnevhodnější chvíli - selhání brzd, start letadla atd.). Zároveň pokud firma řešení nad shaddow branch používá, tak postupně oddiverguje od mainline a řeší opakovaně problémy, které jsou na mainline vyřešené správně a tak třeba jádra Androidu různých výrobců táhnou s sebou tisíce patchů z nichž je většina úplně zbytečných. Při integraci podpory a ovladačů do mainline se pak většinou přizpůsobení změnám infrastruktury provede v rámci změn v jádře/subsystémech. Prostě postupné sed/Coccinelle editace. Pokud po letech divergence chcete projekt/produkt nakolejit zpět na mainline, tak je to často těžší, než portaci provést celou znova. To si většina firem neuvědomuje a pak shání pomoc například u i u naší firmy.
Takže to je můj pohled na FreeRTOS a i vývoj trochu obecněji a doporučení spolupracovat s těmi, kdo mají o spolupráci a vzájemnou pomoc zájem a nekrmit vlastní energií ekonomiku, která je založená na zavírání kódu.
59 Odpovědí
30422 Zhlédnutí