Čekala jsem kdy to příjde a už je to tady! Nemám ráda arduino a možná teď pochopíte proč. Proč není dotyk obsloužen přerušením, ale ochmatává se? Proč není komunikace po ethernetu obsloužena přerušením, ale periodicky se dělá poll? Jistě. Obsluha přerušení a Cčko. To je klasická "storry", že. Navíc tam musí být podpora z hardwaru. To u dotykového displaye může být problém, ale u ethernetu by k čertu nemusel! Takže do popředí ve smyčce obsluhu displaye a vlastní zapínání/vypínání topení, přerušením od časovače obsluhovat čidla a externím přerušením potom ethernet (pokud to jde). Jednoduché. A teď to napište v Cčku. V assembleru s tím problém nebude.
Případně multitasking, což je jednoduchá věc. Přerušením od časovače aktivujete taskswap, do stacku hodíte obsah všech registrů, nakonec uložíte stackpointer do tabulky úloh, načtete do stackpointeru z tabulky úloh pro následující úlohu, pokud není následující úloha, vracíte se na začátek tabulky úloh a načítáte odtam. Pak obnovíte registry ze stacku a uděláte reti. Jednoduché. Fork se pak dělá okopírováním stacku (nikoliv pointeru), vložením hodnoty nového sp do tabulky úloh. Pochopitelně se vám to nesmí v paměti hryznout do ocásku, což je u AVR docela průšvih, neb mají nechutné množství registrů, takže stacky jednotlivých úloh jsou poměrně velké a paměti zrovna moc není. A teď to napište v Cčku... Už chápete v čem je ten problém? Cčko je pro daný úkol nevhodný jazyk a prostě mi svazuje ruce.
Závěrem. Pokud jde o zobrazování počasí. Můžete mi vysvětlit, proč má nejdřív nějaký server překousat předpověď, jiný zase přes tftp nabízet ikony a pak to složitě skládat v jednočipu, když by jaxi stačilo aby server na základě předpovědi nageneroval data, která se už pak jen šoupnou na správné místo na displayi? V podstatě bitmapa ve vhodném formátu. To nezabere prakticky žádnou paměť, neb se to natlačí rovnou do displaye. Navíc těch "obrazovek" může být několik cyklicky se měnících, ale to už záleží jak si to člověk udělá na tom tftp serveru. Připadá mi to jako nejjednodužší řešení...ale jsem jen hloupé děvče...
S tím IRQ a mltitaskingem - to je přesně to, proč nechápu nadšení pro Arduino a když vidím, jak se "profesionální firma" chlubí, že něco postavili na Arduinu, tak hned vím, ským mám tu čest.
Pod přerušením se nic nedělá. Resp. jenom ta najnutnější akce, přerušení musí být krátký. A co se preemptivního multitaskingu týká, tak na AVR je to error - not enough memory. Tam je jediná mořnost spustit timer, interrupt ho probudí ze spánku a zavolá se funkce (task) z tabulky. Funkcí je víc, volají se dokola. Jeden takt = jeden task. Při 100Hz má řekněme 9ms okno, co nevyužije, procák prospí (snížení spotřeby). V tasku stavový automat, takže task ví, co a jestli má zrovna dělat (a stavová proměnná se dá měnit z IRQ)...
Nechápu, proč by měl být kooperativní multitasking v C problém. Mám to rozchozený na H8, M16, AVR, ARM a MSP430 - jeden zdroják, bez problémů (jenom se jinak nastaví kompilátor a je tam jiný header). A když se tomu dají pocity, pak je to absolutně dokonalý ;) V ASM tam jsou vlastně jenom povolení a zákaz přerušení.
A co se zobrazování (nejenom počasí, ale grafiky obecně) týká - SPI FLASH řady 25, FT800 a nazdar. Pět pinů na procesoru, jenom se kopírují bitmapy. Stačil by na to i AVR...
K multitaskingu a multithreadingu existuje alternativa mnohem méně náročná na prostředky: hlavní smyčka událostí, probouzená v případě příchodu události.
Je to jen o trochu náročnější na přemýšlení při programování.
Přerušení obslouží hardware a nastaví příznak. Zároveň se hlavní smyčka probudí ze spánku, a vykoná vše potřebné. Pak se zase vrátí do režimu spánku. Pokud je to chytře napsáno, přejde do nejhlubšího režimu spánku, který podporuje probuzení na všechny sledované události.
Začal jsem psát alternativní nadstavbu pro Arduino, která by generovala optimální kód (tedy nastavení pinu na 2 takty, nikoliv na 56 taktů), a možnost práce s přerušením. Ukazuje se, že bude nutné přepsat prakticky všechny knihovny z Arduina, protože si nekontrolovatelně přivlastňují zdroje, a čekají v nekonečných smyčkách. Zatím toho moc nemám: https://www.dropbox.com/sh/wd1v7ma6deox1vc/AACgT_N74cGUuYO4Y0L1_2g0a?dl=0 (Až toho bude víc, dám tomu jméno a dám to na GitHub.)
Není nutné, aby bylo přerušení co nejkratší. Jen je pak nutné programovat velmi opatrně, aby nevznikly ani dlouhé úseky se zakázaným přerušením, ani nedošlo k vnořeným přerušením a přetečení (velmi malého) zásobníku.