"Nelze ovšem dosáhnout přesného časování ani generování přesných signálů"
To není přesné. Lze totiž generovat naprosto přesné signály díky využití DMA, viz (využívám je na regulaci otáček motorů):
http://www.djanku.cz/clanek/raspberry-pi-regulace-multistar-turnigy
Tohle je opravdu velmi pekny hack jak pouzit neco existujiciho v zarizeni jako hardwarovy PWM generator. Ale opovazte se mi tohle pustit do produkce nebo nedejboze servisovat.
Pockejte ale az vam zmeni desku nebo se zmeni DMA v jine revizi cipu. Tak budete potom nahraty. Regulatoru ktery je idealni pro tento design mam poslat s pripustnym velkym casovym rozptylem(kolem stovky ms pro avioniku staci) a jen napriklad par bitu s hodnotou pres nejake seriove rozhrani/sbernici a ten ma podle toho ridit motor.
Nezlobte se na mne, ale nejak mi prijde ze cely design je blbe a pak se to bastli. Regulator tam stejne je a tak co by komu udelalo koupit trochu inteligentni a nebo dodelat mezi to nekolikanozickovy atmel jako driver regulatoru s par radky kodu v asm nebo i v c. To je navic snadno recyklovatelne pro jine hw platformy nad tim.
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í...
vie niekto poradit funkcny navod na streamovanie videa z RPI? Najlepsie v HD ale hlavne nech sa to da na niecom pozerat (internet browser). Navod na strankach RPI som rozchodil ale dalo sa to pozerat len s nejakou platenou aplikaciou alebo len cez stranku tej firmy. Kde a co to bolo si fakt uz nepamatam.
zrovna jsem si s tim hral, kamera ted nezvlada slunko,ale jinak ujde,rPI nezvlada usb kameru,musi se tam dat napajeny hub.
tohle bezi na cubieboard
http://spital.cz:8090/stream.html
(melo by to byt videt,ale nefungoval mi port forward v ramci vnitrni site,tak to ted neoverim)
http://sourceforge.net/p/mjpg-streamer/code/HEAD/tree/mjpg-streamer-experimental/
http://shrkey.com/installing-mjpg-streamer-on-beaglebone-black/
apt-get -y install guvcview
guvcview -v -v # obrazek jede i pres ssh -X
apt-get -y install fswebcam
apt-get -y install xli pqiv # viewers
fswebcam -r 640x480 -v -v ./tst.jpg
xli ./tst.jpg # funguje i pres ssh -X
# apt-get install motion uvcc* fswebcam
apt-get -y install subversion libjpeg-dev libv4l-dev make imagemagick
svn checkout svn://svn.code.sf.net/p/mjpg-streamer/code/ mjpg-streamer-code
cd mjpg-streamer-code/mjpg-streamer-experimental/
make
export LD_LIBRARY_PATH=$(pwd)
./mjpg_streamer -i "input_testpicture.so -r 320x240 -d 500" -o "output_http.so -w www"
OK !!
make USE_LIBV4L2=true clean all
apt-get -y install uvcc* luvcview uvcdynctrl
luvcview -d/dev/video0 #funguje i pres ssh -X
while [ 1 ];do sleep 1;./mjpg_streamer -i "./input_uvc.so -d /dev/video0 -r 640x480 -f 7" -o "./output_http.so -p 8090 -w