Administrace komentářů

Děkuji za rekce. A úvod mi dovolte poněkud pravit představy o tom co je nebo není RTOS, rozhodně to není něco co vyžaduje definované odezvy „i vic než 10.000x za sekundu“. Jeden z nejrozšířenějších RTOS systému je FreeRTOS má standartně TICK_RATE_HZ nastaven na 1000 tzn základní časové kvantum s kterým pracuje je 1ms, bez problémů ho jde nastavit na 100, pak bude základní časové kvantum 10ms a pořád půjde o RTOS. Nechci zabředat do podrobností, ale Soft RTOS který bude pouštět úlohu 1x za sekundu by měl zajisti asi toto. Představme si, že řídíme pec, tzn sledujeme teplotu a podle porovnání požadované a změřené teploty buď následující sekundu topíme nebo netopíme zpětná vazba nějaký PID, ale to není důležité. Důležité je, že když tohle poběží hodinu a my budeme měřit počet a přesnou délku oněch sekundových úseků tak nakonec zjistíme, že jich bylo 3600 +- 10 a pokud porovnáme délky jednotlivých okének nebudou se tam běžně vyskytovat ani 100ms ani 10sekundové. Pokud jsem se správně dočetl Linux má 139 priorit pro úlohy a 0 až 99 se považuje za Real Time priority. Vim o několika PLC v kterých je Raspberry Pi a tak snad je v silách Linuxu zajisti, aby jedna úloha napsaná v C měla natolik vyšší prioritu než třeba Lighttd, že i když bude probíhat DDS útok na web měla přednost před zpracováním přijatých paketů. Nebo taky ne, ale aspoň by to program poznal a v peci vypnout topení, v nejhorším i za cenu resetu vyvolaného hw Watchdogem.

Proč to vlastně řeším, kamarád chce abych mu udělal řízení pece (proces ohřevu až 12 hodin). Většina opičáren je typicky komunikace, informávání uživatelů a zadávání parametrů programu je jak dělaná pro něco jako Rasperry PI a je mnohem pohodlnější to udělat na něm než na MCU. Pak je samotné čízení pece tam pro změnu je mnohem jednoduší a bezpečnější to udělat na MCU, ale byli by to dvš desky dvoje programování a řešení komunikace mezi tím nebo to narvat do toho většího s Linuxem.