Mě osobně přijde projekt zajímavý, použitá řešení mi přijdou praktická a levná. Nejsem si jist, zda-li by tu mnoho lidí ocenilo nějaké výkresy krabičky a plošných spojů, ale na místě autora bych se zamyslel nad tím, že asi nebude sám, kdo má doma podlahové topení a podobné problémy řeší i jiní.
Možná, když už projekt funguje 2 roky, by stálo za to řešit mírné komerční využití, vyrobit třeba 100 desek plošných spojů, udělat pár krabiček, ručně povyrábět 100 kusů výrobků a zkusit to prodat, získat zpětnou vazbu a kdo ví, jít třeba pak do nějaké větší sériové výroby.
Je škoda, že mnoho autorů projektů s tím nejde do světa. Největší problém je, že když to člověk dělá sám pro sebe, tak to časem přestane udržovat a řešit (vyjde nová verze Arduina, nové součástky, ale člověk už problem neaktualizuje, protože mu stávající řešení běží).
Krátký koment. Proč? Protože to fakt není sranda.
Delší koment. Asi se to nezdá, ale vyrobit funkční prototyp je sranda oproti tomu, dotáhnout to až do konce. Zatímco prototpování vás baví a je to kreativní činnost, která vám jde od ruky, to ostatní je past vedle pasti a pruda.
Výroba úvodní série na koleně je skoro nesmysl. Dá to hodně práce. Kdo na to dnes má čas, když máte fulltime práci a odpoledne rodinu? Můžete do zadat do výroby nějaké firmě, ale při tom množství to vyjde draho a nemáte jisté, že to v důsledku nebude ztráta.
A jdeme dál - výběr spolehlivého HW, resp. dodavatele. Musíte to zabalit jak do krabičky, tak jako celek do balíčku, zařídit certifikace (přece jen to ovládá riziková zařízení), manuál (legislativní záležitosti), oslovit prodejní sít, atd...
Jasně, můžete se o to s někým podělit, můžete sehnat investora, můžete se vykašlat na práci a nechat se živit maminkou...
1. Úvodní série není od toho, aby byla výdělečná (podle mě stačí, když nebude prodělečná), je především o ověření konceptu, získání zpětné vazby od lidí, otestování funkčnosti a doladění věcí. Je to docela i doporučovaný koncept, a mimo jiné tak začínal třeba i Apple, když se všichni ohání nějakými velkými jmény.
2. Ano, je to podnikání, o tom žádná, není to zábava hraní si s tranzistory. Samozřejmě uvést to do komerčního provozu je práce, nemyslím si, že největší práce je udělat balíček (podívejte se, jak je baleno Raspberry Pi), manuál (viděl jste manuály k většině výrobkům? to fakt není nic ultra super), či certifikace (když se podívám co za šmejdy z Číny získává certifikace, tak si nemyslím, že je to nějaký problém, pokud zařízení člověka nezabije přes 220V, tak to certifikaci skoro jistě dostane).
Opravdový problém bych spíše viděl v prodeji (na tom to vázne v 90% případů), vyřídit marketing, získat zákazníky, domluvit se s prodejní sítí atd... To podle mě bude větší problém. Jenomže když vidím ty šmejdy co jsou navrženy v Číně, které dělá retardovaný inženýr tak, že to sotva funguje, tak člověku prostě dochází, že by to mohlo jít i lépe.
3. Ohledně toho, že se vykašlete na práci, necháte se živit maminkou a já nevím co, nevím to je prostě negativní pohled na věc. Ano, podnikání má rizika, jsou tam problémy - ostatně ok, že vám se do toho nechce chápu, úplně.
Ale já na to mám rozdílný pohled než vy. Je třeba vidět i druhou stránku věci, chodit padesát let do jobu, kde děláte co vám ostatní řeknou, když se vám něco nelíbí tak šoupete nohama, žijete v rutinní jistotě a v sedmdesáti budete rádi, když budete mít vůbec nějaký důchod, a budete ležet celý den v jednich plenkách, aby s vámi neměla pracovnice domova důchodců práci. Ano, i to je řešení, je to jisté a já vám tuhle možnost neupírám, ale ne všichni máme stejné cíle.
Taky mi doma už delší dobu běží něco podobného, co je v této sérii článků. Má to lepší výrazně parametry než to, co je běžně dostupné na trhu. Mám to plně pod kontrolou, můžu to doplňovat a vylepšovat. Žádné zpětné vazby od cizích lidí nepotřebuji, jsem jediný uživatel a vše je přesně přizpůsobeno mým potřebám. Běží to spolehlivě a mám z toho radost. Takže cíl 100% naplněn.
PS: NENÍ třeba vidět i "druhou stránku věci". Udělal jsem si to, protože to umím, protože je to (výrazně) lepší, než to, co se dá koupit, ale nemám žádnou potřebu to nijak komercializovat ani s tím jít na trh. Proč taky?
Otazkou je co to znamena "lepsi". Ja dost casto narazim na to ze lidi si vyvinou perfektni reseni jenom pro ne same ale nepremysli nad moznosti rozsireni nebo upravou parametru pro vice systemu a jejich kombinaci. Nebo napriklad supluji neschopnost majitele poridit si efektivnejsi kotel nebo se zamyslet nad systemem vytapeni jako celkem.
Kdyz si vezmes treba takoveho predrazeneho neflexibilniho vyrobce lokomotiv. Ten ma par reseni ale jsou brutalne modifikovatelne. Dalsi veci je ze drzi hodne velke skladove zasoby. Takze i za 10 let kdyz se dany svab nebude vyrabet, tak oni budou schopni ze skladovych zasob vyrobit/opravit ridici jednotku.
A to je to co platis.
BTW: A zapomen na naky substituce svabu za podobne typy. Tady nejsi u cloudovych startupovych gelousu a italskych vyrobcu pracek. Tohle je prumyslovy zarizeni a tam je nutny co nejvetsi determinismus a abys mohl pouzit stavajici PCB, low level testy a design. Takze svab se meni za identicky svab.
Neovládá riziková zařízení. Jedná se o nadřízenou dodatečnou regulaci. Riziková zařízení si mají poslední level regulace dělat nezávislé sama případně mít mechanické bezpečnostní prvky. Tak to u topenářských instalací také je.
Ale pokud si někdo chce dochlazovaci okruh na fosil pouštět skriptem nebo dokonce ručně, tak v tom případě je u mně nezodpovědný otravný hmyz u vody.
Díky za tip a podporu. Podobné řešení vytápění mi běží i u kamaráda, ale řídí tam mnohem více věcí (krb, soláry, fotovoltaika, žaluzie, LED světla a další).
Už několik měsíců po nocích pracuji na mírné komercionalizaci menších věcí. Některé budu brzy publikovat na blogu - třeba bezdrátový ovladač pro RGB LED se mi podařilo vměstnat do poměrně malé krabičky - a samozřejmě uprostřed trůní Arduino :)
Mám také něco jako moduly pro měření a regulaci, které mohou být zapojeny do LAN, a k nim malou "cloudovou službu", ze které jsou i ty snímky grafů. Ještě u těch modulů dolaďuji WiFi, Ethernet je už ověřený (na bázi v článku popisovaného W5100). Až to bude připravené, napíšu na svůj blog.
Takže jo, pokud někdo má zájem, může se mi ozvat, ale spíš než zaplavení pultů všech elektro prodejen v Evropě mými krabičkami bych rád zůstal specialistou na řešení nestandardních/nadstandardních požadavků. Mým hlavním cílem je nenechat se semlít přicházející vlnou IoT, které budou mít do budoucna přesně stejné bezpečnostní a jiné problémy jako dnešní routery za 500.
Tak IoT je takový buzzword, určitě budoucnost v tom je, ale asi jiná než si mnoho lidí představuje. Nemyslím si, že by vůbec frčelo zařízení prodávat jako nějakou krabičku v Datartu - podle mě by lidi stejně měli zájem o řešení (tj. instalace, nastavení, podpora, servis) a to by vás už třeba bavit mohlo, slyšet prostě zpětnou vazbu na vaše dítko, a třeba i vyjet k zákošovi a pomoc mu se servisem zařízení, pak se prošťourat v kódu a udělat opravenou verzi 2.0. Nějaký masový market bych v tom teda určitě nehledal - ostatně to není věc do paneláku ;-)
Co se týká bezpečnostních problémů routerů, tak to je spíše hrozný hype. Realita je taková, že většina poskytovatelů přístup k routerům blokuje na svých firewallech, takže se tam z internetu ani nedá dostat (i když jako zákazník kolikrát šlo získat přístup k ostatním zákazníkům ve stejné síti). Upřímně mi za 10 let nikdo žádný router nikdy nehacknul a ze svého okolí neznám člověka, kterému by se to stalo.
Zrovna zde na root.cz vycházejí články o každé bezpečnostní chybě jako o konci světa, a pak se člověk v článku dozví, že lze hacknout automat na plechovky coca coly, když na tom bude pracovat tým bezpečnostních expertů měsíc a jaká hrozná je to chyba. Nakonec v reálu na nádraží přijde fetka, bouchne do automatu boxerem a vezme si coca colu a má vyřešeno (přeháním, ale reálná bezpečnost je dost něco jiného než teorie).
Moje pointa byla v tom, že doma nechci mít uzavřené věci, do kterých nevidím a které někdo seká jak Baťa cvičky v miliónových sériích. Raději si to udělám sám po svém, přesně na míru, zdokumentuju to a nakonec to třeba zveřejním (a ještě si přitom užiju zábavu a něco nového se naučím). Pokud má někdo stejný pocit z komerčně dostupných řešení, může se mi ozvat a třeba se domluvíme.
Jinak jsem napsal, že jsem do malé krabičky postavil "dálkový ovladač pro RGB LED" a přitom jsem chtěl napsat "dálkově ovládaný řadič pro RGB LED". Tj. nikoliv vysílač, ale krabička, která na pokyn z dálkáče ovládá LEDky. Už je to v provozu v ložnici, řídí to "noční světlo" a rozsvítí se to nejen dálkáčem, ale i třeba na hlasitý zvuk (=pláč malého dítěte, kterého vyděsí tma, když se v noci probudí). To je jen příklad věci, kterou nevím, jestli bych našel na trhu, tak jsem si ji ubastlil :-) Možná bych o tom mohl napsat na Root, přiložil bych tentokrát i plošný spoj :)
S těmi uzavřenými věcmi je to pochopitelné, a i vás chápu, mám to podobné. Když mám VPS, chci mít root přístup a managovat si to sám, protože tomu rozumím a chci to mít pod kontrolou. Ale třeba komerční realita je taková, že hodně lidí co má e-shopy se raději zabývá balením balíků a pronajmou si manažované VPS, protože se o to zase nechtějí starat - to taky je pochopitelné.
Stejně jako automechanik si asi své auto nedá do servisu, tak ajťák si nedá do servisu svůj počítač. Ale třeba i já chci u svého auta mít pohodu a neřešit to, a jsem ochoten nechat si vyměnit olej, klidně i doplnit kapalinu do ostřikovačů v servisu, protože mě prostě auta zrovna neberou.
Jinak já osobně uvažuji o tom, že bych se věnoval podnikání. Jedna z možností je vzít něčí projekt a dotáhnout ho po marketingové/obchodní/legislativní stránce do konce tak, třeba tak, aby manažer co přijede po dlouhé práci v 10 večír do svého baráku za Prahou tam měl příjemnou teplotu a nemusel to řešit.
Ale o možnostech zatím uvažuji. Třeba mě osobně už po letech dělat jenom technické věci nebere a nevidím v tom svůj osobní rozvoj, ale dělal jsem to roky a mám pochopení, že lidé jsou různí a někteří se v tom realizují (i mě to baví, ale už se v tom tolik nerozvíjím, jako kdysi).
Osobne sa mi nechce verit, ze serial uz skoncil. Cakal som tiez odkaz na tie zdrojaky. :)
Vela ludi chce nieco presne na miru, ale v skutocnosti ich potreba nie je az taka "na miru". Malokto potrebuje operacny system na miru. Ludia maju podobne poziadavky.... Aj poziadavky na vykurovanie maju podobne.
Je fakt, ze malokto bude mat taku suhru osvetlenia teplotneho senzoru v obyvacke, podlahoveho kurenia a ostatnych specifickych veci, ako Vy, ale podobnost tam bude. Uz by to bolo len o parametroch systemu, ze napr. ak kurim 10h, tak pri nemeniacej sa teplote vonku a vypnuti kurenia teplota stupa este 2h. A u niekoho 1h. Neviem, ci komercne domace systemy pocitaju s predpovedami pocasia a parametrami vykurovacej sustavy, stratami domu pri zamracenom pocasi, pri vetre, ale asi nie. Ale ludom by sa to hodilo a skoda aby si to kazdy vymyslal nanovo.
Termostat ještě není ve stavu, kdy bych s ním byl tak spokojen, abych byl připraven uveřejnit jeho zdrojové kódy. Sice funguje, ale je stále ve vývoji, je pořád co vylepšovat. Časem se třeba objeví na mém githubu.
Co se týče regulace: pod prvním článkem série se v komentářích sešlo několik lidí "od fochu" a sršely z nich nápady, jak by regulace měla doopravdy fungovat. Něco tak sofistikovaného, jak tam vícekrát zaznělo, by tu jistě mohl někdo implementovat a pak teprve by to stálo za publikování. Ten můj párřádkový algoritmus by byl akorát pro pobavení :-)
Co se týče kúrenia po dobu 10h a při neměnné teplotě venku - tak to nefunguje, musel bych ještě měřit teplotu podlah. Původně jsem myslel, že ji odvodím z teplot vody z kotle a vody na vratce, ale dnes si to už zas tak nemyslím, protože v tom ještě hraje roli rychlost čerpadla. Víc se mi opravdu osvědčilo to chvilkové topení a pak chvilkové odpočívání.
Je to vlastně velmi podobné jako Cimrmanův šestidobý motor - ten taky odpočíval :-)
Ano domácí systémy s tím počítají. I kotel v základní variantě sleduje tendence teplot a umí vyhodnotit jestli se má odstavit a vytápět třeba jen teplou vodu. Základní parametry programuji topenáři a tím pádem by se měla pokrýt i tepelná dynamika objektu.
Hlavně to co popisují je opravdu sociální varianta která nemá žádné vyšší řízení. Divím se jaké keply a střepy jsou tu ochotni lidi provozovat.
Další věc je ta ze zcela jiné řízení vyžaduje dům do kterého fouká ze všech stran a úplně jiný přístup pasiv. Ne vždy se investice do řízení vyplatí a někdy je lepší nechat dům vytápět na nějakou udržovací teplotu a přemýšlet i nad fyzikou. Třeba u tech drevenych pasivu nagelovane betonové hlavy z panelákových univerzit vůbec nepřemýšlí nad stabilizacnimi akumulačními objekty- betonová podlaha/kamenna stěna etc.
Samozřejmě nadřízené řízení od renomovaných značek umí zpracovat vstupy z meteosenzoru a stáhnout si info o počasí. Jen je to fakt hodně drahé a většinou uzavrene. Je lepší investovat do nového kotle a tohle dobastlit s nějakým už predpripravenym řešením postupně jak finance dovoli.
jsou někde přístupná data, která používá aplikace Aladin na Androidu?
Veřejné výstupy modelu Aladin jsou na webu ČHMÚ: meteogramy a mapy. Od autorů Aladina pro Android je také k dispozici web s identickou grafikou: Aladin help. ČHMÚ je ale partnerem té Androidí aplikace, takže je možné, že autoři mají přístup ještě k jiným datům (nebo alespoň ke zdrojům toho, z čeho se pak generují obrázky na webu ČHMÚ). Dříve určitě existovaly podrobnější placené výstupy z Aladina, jak je to teď nevím – a pro domácí termostat by to byl kanón na komára…
No já bych potřeboval spíš oblačnost postupně na několik hodin dopředu. To nevím, jestli je v nějakých pixelech.
Mohl bych si odposlechnout komunikaci Aladinu na mobilu a pak ji zduplikovat jinde, ale to nevím jak moc je licenčně OK. Raději bych otevřená data, koneckonců ten úřad platíme všichni, takže by měli produkovat jen otevřená data.
Na Slovensku je situacia podobna. Aj ked shmu.sk je financovane statom, cize nami a naklady na dalsie kopie informacii nema, tak sa snazi si narokovat vlastnictvo dat. Meteo.sk ich dakedy parsovalo a pouzivalo ich data bez licencie, na co sa shmu hnevalo. Raz im aj podstrcili pre Strbske pleso o 5st. nizsiu teplotu a chvalili sa tym, ako ich odhalili. :D Ako to je teraz s licenciou neviem.
Osobne predpokladam, ze zakonne je to tak, ze co pride do mojho prehliadaca, s tym si v ramci mojej domacnosti mozem robit co chcem. Takze napriklad ked si zadam adresu http://aladinonline.androworks.org/ tak mam zdarma aj json data http://aladinonline.androworks.org/get_data.php?latitude=48.8555087&longitude=14.3326247 cize aj "CLOUDS_TOTAL", "CLOUDS_HIGH", "CLOUDS_MEDIUM" aj "CLOUDS_LOW" - podla vysky oblakov. Aj "WIND_SPEED" pre korekciu ochladzovania murov. Co viac si moze clovek zelat? ;)
Z toho by sa uz dala krasne vyrabat predpoved potreby vykurovania. V tejto relacii http://www.rozhlas.cz/meteor/prispevky/_zprava/jak-se-hodnoti-uspesnost-predpovedi-pocasi--1503766 sa hovori, ze predpovede pocasia na 24h su uz uspesne na 95%. To uz je krasnych 19x z 20tich vykurovanie na zaklade predpovede a 1x tak, ako to robite teraz - "dorovnavanim" teploty.
Mam doma tiez Arduino, ale pre taketo ucely sa mi jeho pamat zda prilis mala. Nechapem, ako ste tam natlacil celu tu logiku do 32kb. :) Podla mna by sa to malo vediet aj vyrovnat s pripadnou poruchou senzorov a kurit iba podla mesiaca v roku. Na to a na tuto predpovednu upravu uz by fakt bolo potrebne druhe Arduino, pripadne viac, ako 32kb RAM.
Je to krasa vidiet v googli na prvej strane pri hladani hned 4 projekty na parsovanie jsonu. :) Ak Vam treba skutocne len tie mraky, tak by som sa s tym neparal, precital na zaciatku cas predpovede, nacital "CLOUDS_TOTAL" a za tym je 55 po hodine sa meniacich predpovedi od 0 do 1. Niektore aj v plavajucej ciarke 1.5259022E-5 a niektore aj vacsie, ako 1:1.000946.
Norská předpověď yr.no poskytuje data ve strojově čitelné podobě (xml), např:
http://www.yr.no/place/Czech_Republic/Prague/Prague/forecast.xml
Dá se vybrat téměř libovolné místo v Evpropě...
Znamy mi doporucil nasledujici sluzbu, po registraci pristupy zdarma, :
https://developer.forecast.io/docs/forecast
Plus jsem nasel podobne, kde je mozne ziskat mistni pocasi, ale jeste nemam otestovanou uspesnost :
http://michaelwelburn.com/2011/11/02/comparing-weather-apis/
http://openweathermap.org/forecast
http://www.accuweather.com/en/cz/czech-republic-weather
Libor
Omylem jsem předtím odkázal na nápovědu, správný odkaz je Aladin počasí online.
Nejsem elektro, nejsem IT ani programátor. Jsem ale topenář (teď jako že doma topím, ne že mě to živí), hračička a taky kolenovrt. Celá série mě nadchla tak, že už mám Arduino týden v šuplíku a jakmile dojdou i všechny ostatní Dallasy a breadboardy tak se pustím do hraní, pro začátek alespoň měření a logování teploty v místnostech na 1-Wire sběrnici.
Co mi ale chybí je popis logiky toho termostatu. V úvodu je zmíněno, že podlahovka má douhou setrvačnost a že teplotní zisky za slunečného dne potom rozhodí celou teplotní dynamiku místnosti a ta se začne přehřívat. Jakým způsobem funguje to vlastní řízení teploty podlahovky? Porovnávají se venkovní teploty na severu a jihu a vydedukuje se, že je slunečný den a servo začne přivírat okruhy v podlahovce?
Díky za skvělou sérii.
Ano, to nejdůležitější jsem do seriálu nestihl napsat. Když jsem na podzim 2013 termostat narychlo spouštěl do ostrého provozu (zima byla na krku), prvním cílem bylo zarazit přetápění. Napsal jsem co mě zrovna napadlo: chvíli (45 minut) topit, pak přestat a chvíli se jen dívat, jestli teplota v místnostech reaguje a blíží se k požadované. Pokud ne, tak opět chvíli topit a pak zase přestat a dívat se (pamatujte, že v mém otopném systému mám jen jedinou regulovatelnou veličinu - a tou je kotel ON/OFF).
Tento jednoduchý princip se ukázal jako velice funkční, a teplota vzduchu díky němu dokonverguje k požadované s minimálním překmitem.
Dalším důležitým krokem na omezení zmatku vnášeného do systému solárními zisky bylo získat lepší reprezentaci teploty v domě. Nakonec se ukázalo, že pouhý aritmetický průměr teploty horního a dolního patra funguje velmi dobře - odstíní chvilkové chyby typu vyvětrání v jedné místnosti, a naopak dobře reaguje na celkové chládnutí domu, i když třeba do jedné místnosti na čidlo svítí Slunce.
A co se týče automatického vyhodnocování teplot naměřených na vnějších čidlech - k nim jsem paradoxně ještě vůbec nedostal, protože tím, jak mám čidlo v obýváku jen 10 cm nad zemí (v bývalé síťové zásuvce), tak na něj svítí Slunce přímo a tím mi vlastně jakoby reprezentuje to čidlo na jižní straně fasády. Je to teda shoda náhod, ale taky to funguje dobře.
Je mi jasné, že tohle není přenositelný algoritmus a že mi to funguje jen díky shodě šťastných náhod (orientace domu a okna na světové strany, umístění čidel atd.), ale prostě mi to teď funguje výborně a jedinou věc, kterou bych rád vyřešil, je "zbytečné" ranní topení, kdy v šest/sedm ráno ještě nevím, jestli v osm bude svítit Slunce nebo ne. Na toto budu potřebovat znát předpověď počasí, s tím mi čidla nepomůžou.
Uvidíme, co bude dál - termostat je stále ve vývoji.
Na ovládání bych si dovolil doporučit, ačkoliv to není úplně levné, displeje 4D Systems. Mají i nějaká ta rozhraní, GPIO, UARTy atd. a často tak k tomu člověk nepotřebuje ani další mikrokontrolér. Má to slušný vývojový nástroj, kde lze vše naklikat nebo klidně i od nuly naprogramovat, dle toho, co je přesně potřeba. Pořídil jsem si dávno jeden na testování a dají se s tím vážně dělat kouzla.
U podobných zařízení, jako je třeba tento termostat, se pak mohu v Arduinu (nebo jiném uC) plně věnovat logice a o uživatelské vstupy a výstupy se mi stará uC v tom displeji, který má dost výkonu na grafy, realtime video, zvuk, animace atd...
Chce to zadívat se na grafiku minimalisticky (dětskýma očima).
Výsledek je kolikrát velice pěkný a nestojí ani tolik námahy ani tolik zdrojů jak by se na první pohled mohlo zdát.
Obláček jsou 3 nebo více kruhů o různých průměrech vměstnány na malém prostoru :-). Předpokládám že v kódu minimální spotřeba. Nejlépe samozřejmě když se trochu (někdy dost) překrývají :-).
Sněží
oOOo
* * *
* * *
Prší
o0Oo
/ / /
Mlha :-)
- - ---
- -- --- -
- -- --
snad se k tomu v nejblizsi dobe dostanu, i kdyz nevim, u me je budoucnost nejista, pokud vubec nejaka. Kazdopadne diky a jsem rad, ze ta zmena verze kompileru pomohla usetrit tolik potrebny prostor + samozrejme ta uprava kodu... ten editor fontu je take zajimavy projekt, takze preji dostatek casu a odhodlani k jeho dokonceni...
Č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.
Zdroják vám nepošlu, Cčko moc neovládám.
Myšlenka je jednoduchá: Vložení (setRepeated), smazání a dokončení tasku (loop) provede vždy výpočet následujícího (= jediný průchod polem), pak už se jen čeká na nextRun (testován primitivním porovnáním s okamžitým millis()) uvedený v dopočteném tasku, nebo nastaví přerušení na uvedený čas.
To ale vyjde podstatně hůř.
- Polem se musí procházet vždycky, aby se zjistilo, co spustit.
- Porovnat dvě čísla znamená odečíst je a testovat zero flag (CMP nebo SUB). INC a DEC taky ovlivní zero flag. Nic na tom neušetřím.
- Countdown nevyžaduje předpočítání dalšího startu.
- Pokud se vejdu s dalším spuštěním tasku do 250 ticků systému, stačí u countdownu 8b, u porovnání času je potřeba 16-32b (sestřelí osmibit až hrůza).
- U countdownu nepotřebuju přepočet před startem.
- U countdownu, pokud není potřeba logování nebo real time, můžu tick count vyhodit úplně.
- Tick count by musel být volatile (mění se v přerušení timeru a i v průběhu té funkce), static (aby se nesmazal po vyskočení z té porovnávací funkce) a register (aby se ušetřila polovina přístupu do RAM) současně. U 32b tick counteru a 8b CPU znamená obětování čtyř registrů.
Na jednočipu, víc než kde jinde, musí být Occamova břitva pěkně ostrá. Nesjou zdroje nazbyt.
při porovnání dvou čísel se nic neodečítá, ale porovnává se po bytech. Tedy při předpočítání dalšího spuštění v každym kroku 1x sada lds (předpočítané nextRun) a pak sada cp/cpc vůči now, bez předpočítání 2x sada lds (lastRun + interval), sada sub/sbc a sada cp/cpc vůči now. Problém při počítání nextRun by byl možná spíš při přetečení při dlouhodobém provozu
Citation needed.
Odečítají se právě ty byte při tom porovnání. Algoritmus porovnání vícbytovýho čísla do puntíku sedí s rozdílem dvou čísel až na to, že se výsledek zahodí.
Při porovnání se stav vždycky musí dostat do flagů. Tzn. nějaká "porovnávací" instrukce, ze které vypadne "rovno", "menší", "větší". Ve druhé je podmíněný skok, který testuje flagy.
Jasně, šlo by na čip zadrátovsat něco ve smyslu 7485, ale proč? Znamenalo by to přivedení dvou sběrnic od registrů jako u ALU, drátovat výstupy do řadiče, další flagy, podmíněný skoky s dalšíma podmínkama pro tytyo flagy a podobný nesmysly.
Pokud ALU podporuje ADD a SUB, tak není potřeba vymýšlet opičárny navíc. Sběrnice ze dvou registrů tam jsou (zadarmo), odpadne blok komparátoru, SUB/SBC nastaví Z flag, pokud je výsledek nula (rovnost, A-B=0 <=> A=B) a N flag pokud B>A. A v dekodéru instrukcí stačí vyhradit varianty SUB a SBC bez ukládání výsledku (nepošle se write signál do cílovýho registru).
V AVR architektuře není o komparátoru ani slovo, popis ALU taktně mlčí a v přehledu ASM je u instrukce CP popis Rd-Rr, ovlivněno Z, N, V, C, H, 1 takt. Podobně CPC a CPI, založeno na rozdílu...
Mrkni třeba na http://www.atmel.com/Images/doc2552.pdf, tabulka na str. 369, instrukce CP, CPC, CPI
No a je z pohledu rychlosti jedno, jestli bude
CP R1, R2
BREQ LaunchTask
nebo
DEC R1
BREQ LaunchTask
Jenom v prvním případě nebude asi 8b stačit a trochu to nabobtná ;)
tohle generuje avr-gcc (bavíme se o konkrétní úpravě konkrétní knihovny která se tím kompiluje)
kód s předpočtem koncové hodnoty
if (x1 > x2) {
190: 50 91 09 01 lds r21, 0x0109
194: 60 91 0a 01 lds r22, 0x010A
198: 70 91 0b 01 lds r23, 0x010B
19c: 80 91 04 01 lds r24, 0x0104
1a0: 90 91 05 01 lds r25, 0x0105
1a4: a0 91 06 01 lds r26, 0x0106
1a8: b0 91 07 01 lds r27, 0x0107
1ac: 84 17 cp r24, r20
1ae: 95 07 cpc r25, r21
1b0: a6 07 cpc r26, r22
1b2: b7 07 cpc r27, r23
1b4: 08 f4 brcc .+2 ; 0x1b8 <main+0x2e>
kód bez předpočtu koncové hodnoty
if (x1 -x3 > x2) {
1ba: 80 91 08 01 lds r24, 0x0108
1be: 90 91 09 01 lds r25, 0x0109
1c2: a0 91 0a 01 lds r26, 0x010A
1c6: b0 91 0b 01 lds r27, 0x010B
1ca: 00 91 00 01 lds r16, 0x0100
1ce: 10 91 01 01 lds r17, 0x0101
1d2: 20 91 02 01 lds r18, 0x0102
1d6: 30 91 03 01 lds r19, 0x0103
1da: 40 91 04 01 lds r20, 0x0104
1de: 50 91 05 01 lds r21, 0x0105
1e2: 60 91 06 01 lds r22, 0x0106
1e6: 70 91 07 01 lds r23, 0x0107
1ea: 80 1b sub r24, r16
1ec: 91 0b sbc r25, r17
1ee: a2 0b sbc r26, r18
1f0: b3 0b sbc r27, r19
1f2: 48 17 cp r20, r24
1f4: 59 07 cpc r21, r25
1f6: 6a 07 cpc r22, r26
1f8: 7b 07 cpc r23, r27
1fa: 08 f4 brcc .+2 ; 0x1fe <main+0x74>
v té nepředpočítané verzi je úplně to samý co v nepředpočítané + něco navíc, takže je úplně jedno jestli alu komparátor obsahuje nebo ne, protože se volá v obou verzích stejně
Jste na sebe moc přísní. Jádro původní rady bylo IMHO v tom vypočítat po změně fronty, který další task by měl být volán, a pak na něj čekat v krátké smyčce. Zatímco současná implementace nehledá další task jen po změně fronty, ale neustále, protože stejně nemá nic lepšího na práci, takže vlastně běhá v delší smyčce.
Ve skutečnosti by to ale dle té rady fungovalo špatně, protože když bych náhodou minul ten přesný okamžik, kdy měl být spuštěn další task, tak bych pak nevěděl, který mám vlastně spustit a musel bych znovu celou frontu procházet a hledat, takže bych prd ušetřil, naopak bych to ještě zpomalil. Ta moje současná implementace prostě funguje správně (tj. tak, jak byla zamýšlena) a nemám důvod ji měnit.
Vůbec netuším, o čem píšete...
Na co budu pořád ve smyčce procházet pole, když v něm je pořát to samé, dokud do něj není něco přidáno, z něj ubráno nebo změněno (což dělají 3 přesně definovaná místa), což jsou k počtu cyklů smyčky zcela ojedinělé události, nehledě na to, že varianta s procházením pole neumožňuje programování časovače na probuzení pro operaci.
Chcete říct, že „now - t.lastRun >= t.interval“ je stejně rychlé jako „now >= t.nextRun“?
Máte potřebu řešit bitová harakiri s tím, že to možná přeteče a možná taky ne?
Dál nemám sílu.
Autorovi Taskeru děkuji za ušetření mi nejhorší práce, už jen doladím.
Dobrý den, byla to zajímavá série článků a jak jste "nakousl" na konci, za sebe mužu říct, další články/seriál(y) bych urcite uvítal.
Rad bych se Vás zeptal, nevím jestli si vzpominate na naší pár-příspěvkovou konverzaci co se týče regulace te teploty v domě, jaké tedy mate výsledky oproti původnímu zadání/ záměru? Tedy jestli se Vám daří topit bez překmitu teploty, jak jste vyčetl v úvodu série, jestli se nějak zkrátil čas k požadovanému vytopeni a jak jste s topením nyní spokojen, prostě by mne zajimalo nějaké celkové zhodnocení minulého a současného stavu, nějaké "dosažené vysledky" oproti uvodnimu motivu?
Dekuji
Zhodnocení je jednoduché: v domě je pořád teplo tak akorát a klesly mi účty za plyn, takže super. Můj termostat prakticky vůbec nepřetápí, teplota v domě kolísá minimálně. Navíc termostat díky síti čidel zvládá i opačnou situaci, kdy Slunce celý den svítilo a tak ohřálo místnost s termostatem, zatímco v jiných částech domu je zima. Prostě mise splněna!
Jak jsem psal v jiném komentáři a zmínil v článku, posledním nedostatkem je "zbytečné" ranní topení před tím, než vyjde Slunce - pokud vyjde. To ale vyřeším brzy, díky komentářům výše, které mi poradily, kde vzít strojově zpracovatelná data předpovídající oblačnost. Pak to bude teprve dokonalé - a dalším způsobem využiju to, že termostat je online.
I tak míním algoritmy ještě vylepšit - venkovní čidlo na jižní straně fasády je dost vysoko, aby si všimlo celkem brzy, že Slunce ten den opravdu vychází, takže to chci navázat na tu předpověď oblačnosti. A dále, rád bych nějakým způsobem počítal denní solární zisky, nějak integroval rozdíl mezi křivkami teplot na sluneční a opačné straně domu. To by mohla být taky zajímavá hodnota, i kdyby měla jen svítit na displeji.
Dalším plánem je, jak postavím meřicí "berlu Mrazilku", tak ji v jednu chvíli připojím do té krabice ve zdi, kde jsou otopní hadi z jednotlivých místností připojeni na společnou trubku - zapomněl jsem, jak se tomu správně říká. Chtěl bych si poměřit teploty na vratkách z jednotlivých místností, abych věděl, jak s teplem z kotle zacházejí jednotlivé pokoje. A tak. Prostě ještě se s tím dá hrát dlouho, ale teď je léto, a tak řeším zas jiné věci :-)
Kvoli tejto novej funkcionalite a aj kvoli "problemom" s casovacom/preruseniami nie je lepsie to riesit cez Arduino MEGA s 256kb RAM(https://www.arduino.cc/en/Main/ArduinoBoardMega2560) aj s moznostou viac preruseni. Je pravda, ze tych preruseni tam nebude tak vela, ako cidiel, ale aspon by bol pokoj so sietou a displayom.
Mozete definovat co presne znamena "klesly mi účty za plyn"? Cize povodna spotreba plynu a nova iba vplyvom regulacie?
Tak jednak v článku píšu, že by bylo lepší použít Arduino Mega (i ten odkaz v článku je - četl jste ho?), druhak Mega nemá 256 kB RAM, ale flash, ale hlavně o žádná přerušení nejde, ani v článku, ani jinde. Displej, síť ani čidla přerušení nepoužívají a nepotřebují. Mega se hodí akorát kvůli té větší flash paměti (a případně 4x větší RAM).
A ano, domnívám se, že mám nižší spotřebu plynu díky regulaci novým digitálním temostatem. Nedochází k přetápění = kotel topí méně hodin denně => ušetřím za plyn.
Dik, cital som ten clanok, ale Arduino mega som si specifikaciu pozrel az dnes. Tak pardon. Skoda pre 3 eura sa pripravovat o funkcnost, ale zas ked clovek zacinal, netusil, kam sa mu to rozrastie, takze rozumiem. :)
Znizenie spotreby tazko presne v ramci jedneho domu odmerat, pretoze bola urcite slabsia zima. Aspon na Slovensku.
Pekny projekt, len skoda ze nie je uverejneneho viac kodu.
Nakodit si nieco take len podla prikladov asi nezvladnem (cas&znalosti). Ale urcite sa o to pokusim.
Pripajam zopar napadov na "berlu Mrazilku":
http://www.espruino.com/temperature_display_pcd8544
http://www.espruino.com/wifi_humidity
Snad je to este aktualne.
Prajem pekny den.