Tedy původně měla být v Brně úplně ta samá přednáška, ale když už je to tak profláklé, tak to zkusím trochu jinak − víc ukazovat a míň povídat. Ale předem varuji, že stejně jako v Praze se na automatizaci ve smyslu řízení něčeho nedostane :) A po zkušenostech se zasekáváním bych se bál automatizovat cokoli, co je aspoň trochu kritické (jako topení v akváriu nebo automatické krmení).
Zasekávání není normální, měl jsem RPi 512MB co se zasekával (USB problémy), po reklamaci a výměně za nový běží víc jak 4 měsíce 24/7 bez problému. Restartován mnou po cca 2 měsících jinak nonstop - není v krabičce, jen deska. A je přetaktovaný na 1000 MHz, s rasbian + apache2 + mysql s wordpressem a dalšími aplikacemi.
Zkusil bych ho reklamovat. Co je v logu? Chyby s USB - to je na reklamaci? Zřejmě existuje několik vadných sérii.
Máš k němu připojenou kameru? Já mám RPi v Nizozemsku čistě jako server a taky se ještě ani jednou nezaseklo. Problém je v podstatě jen s nějakou race condition v komunikaci CPU-GPU, která se při používání kamery poměrně intenzivně používá. Pak se stane, že proces zůstane viset v kernelu velmi dlouho (až si začne kernel stěžovat do logu) a v tu chvíli linux sice stále běží a je možné se do něj přihlásit, ale není možné jej rebootovat (protože na konci rebootu se má poslat zpráva do GPU aby provedlo reset a tahle zpráva neprojde). K obnovení činnosti je tak potřeba odpojit napájení. Na LD jsem dostal tip, že by mohlo stačit propojit RESET vstup s GPIO, a poslat tak v nouzi reset sám sobě. Ovšem jen za předpokladu, že v zaseklém stavu bude možné ovládat GPIO, což nevím.
Pokial tomu dobre rozumiem co pises tak watchdog ktorym je RPI vybaveny nezaberie? Mam 3 RPI doksy, kazda z inej serie. Ta najstatsia robi restarty asi 2x do dna pokial je CPU vytazeny (kompliacia gentoo) na ostantych dvoch sa mi to stalo raz z pripojenou kamerou. Ale doteraz mi watchdog vzdy zabral.
Watchdog je pro BCM2708 implementován již pár let, viz https://github.com/raspberrypi/linux/blob/rpi-patches/drivers/watchdog/bcm2708_wdog.c
Osobně jsem ho však nevyhodnotil jako téměř 100% řešení, takže ve své aplikaci používám bokem posazený STM32, který a) dělá komunikační most mezi RPi a periferiemi/akčními členy na RS485 a b) při příliš dlouhém komunikačním klidu odešle safe pakety směrem k periferiím (stop topení, čerpadla apod.) a provede hw reset RPi. Drobný problém je v tom, že pokud se RPi po resetu neprobere k životu, nedostanu (po netu) info o kritické situaci. To zjistím jedině tak, že přestanou chodit pravidelné statusy na server.
Mě se nezasekává, ale fakt je, že kameru nevlastním. Jenomže na svou aplikaci potřebuju RS-485, 8x vstup 24V AC, 8x výstup 24V DC s PWM a spolehlivý řízení.
Spolehlivý řízení není problém s jednočipem, ale web interface v jednočipu není sranda a i logování na USB FLASH s RPi tak nějak jednodušší... Oproti tomu lepit HW a řídit to z osmi GPIO pod preemptivním multitaskingem... No, řekněme, že IP stack na jednočipu by vyel o něco jednodušej.
Takže ideálka je připojit jednočip a oba procesory používat k tomu, na co jsou lepší. RPI na komunikaci, logování atd., aplikační CORTEX M0 na připojené desce na řízení...