Vlákno názorů k článku Arduino Mega na zbernici s PC od exo - Hele zas tak moc do toho nevidím. Ale...

Ok, rozdiel v mojom pozorovani moze byt dany tym, ze tie zariadenia o ktorych hovorim ja boli prevadzkovane pravidelne pod nulou a nad 50 stupnov ambient. V takej aplikacii RPi celkok spolahlivo do 14 mesiacov fyzicky skapalo (zatial 2 po sebe).

To věřím. Vědět to, co vím teď, tak věnuju daleko víc úsilí nějakému chlazení, klidně aktivnímu.

Zdravím, máš nějaké praktické zkušenosti s provozní spolehlivostí CM4 s eMMC? Díky.

CM4 ne, ale jiné SBC s eMMC používáme a problémy nejsou. Dost pomáhá rozdělení na SLC a MLC, které je na eMMC běžné.

na tu sd kartu sa aj nieco zapisuje ked odchadza ? Neda sa pouzivat ako readonly a vsetky data z toho poslat po sieti prec ?

Opotřebení SD karty není způsobeno zápisem, to je častý mýtus, co se tady v těch hobby komunitách opakuje. Je to úplně normální degradace NAND flashe, která zrychluje s druhou mocninou teploty. Pár cm od ní jsou napěťové regulátory a ty ji pěkně vyhřívají. Komerční SD karty mají typicky retenci ca. 10 let při 25 °C, kde retence je definována jako nějaký počet přehozených bitů za tu dobu. A samozřejmě na zabití softwaru stačí přehodit jeden bit :)

Systém je plně read-only, na mmc se vůbec nesahá (0 iops po dobu klidně 1 roku), ale i tak SD karta potichu umře. Linux jede celou dobu z VFS cache, takže o závadě karty se zpravidla dozvíme až po restartu systému, kdy je opravdu nutné na tu kartu sáhnout.

hmm, nepomohl by tedy kratky microsd extender - flex kabel s microsd konektorem/slotem? neco jako https://www.aliexpress.com/item/32965359717.html

Zajímavé, díky za tip :-) vyzkouším.

Skuste zahodit SD carty uplne a roboty su aj tak riadene nejaky serverom a ouobit netowrk BOOT a NFS mount a mate hlupe raspbery ktore bootne zo siete. Funguje ale az od 3 spolahlivo cez ethernet. Bezim uz 2 roky.

To je pohoda, bohužel v té naší aplikaci je to bez heatsinku a ještě navíc kousek od zdroje tepla.

Co je „targetovat“?

Dobrý den,
omluvám se za nepřesnost, přílišné zkrácení myšlenky. Ve většině automobilek a asi často i v průmyslu a také mezi teoretiky na návrh řídicích algoritmů je zvykem k návrhu a simulacím používat Matlab/Simulink. Po tom, co se otestuje/vybine návrh řízení proti modelu řízeného systému, tak se řídící část v blokovém zápisu Simulinku doplní o o bloky reprezentující reálné vstupy a výstupy na řídicí elektronice a s využitím Embedded Coderu (dříve Real-Time Workshop/Target) se převede/zkompiluje bloková reprezentace do jazyka C a s knihovnami realizujícími bloky pro propojení na periferie se celek přeloží a vnikne firmware pro daný HW (engine control unit). Seskládat tu podporu pro danou platformu (target) reprezentuje kus práce a příslušně vybavený HW od profesionálů je v 10k EUR. Nebo stojí podobné a možná i řádově větší částky částky podpora pro profesionální ECU. Na druhou stranu Matworks a občas i výrobci chipů chtějí tento postup zpřístupnit univerzitám na levném HW, aby vyhovali odborníky pro automobilky a ti byli zvyklí pak přejít na ta drahá řešení. Takže je, myslím, že rovnou v základní ceně, pro univerzity podpora cílové platformu ("targetu") Rasberry Pi. Ono riziko ztráty zisku z těch drahých platforem je zde v podstatě nulové, protože nikdo s přehledem to RPi do vážné aplikace s normálním požadovaným teplotním rozsahem a spolehlivostí nedá.

Ve skutečnosti ten target od Mathworks pro RPi je postavený na jimi dodaném C kódu podporujícím všechny Linuxy včetně RPi. Takže ho lze při nějaké znalosti použít pro cokoliv, musí se dopsat ty bloky v C pro periferie. Takže podpora jiných desek není až tak moc práce a lze tedy používat mnoho cílových Linux baze platforem i s čipy, které splňují nějaké základní požadavky. Druhá otázka je, že to co dodával Mathworks pro RPi a obecně i to jádro pro Linux má zásadní chyby v návrhu, kdy nemůže přesné časování zaručit. Posix signály ani na RT jádře nemají po celé cestě správně vyřešenou priority inheritenci atd. Dodané jádro je pak také bez fully preemptive patchů, takže věřit tomu i na vzorkovací frekvence okolo 100 Hz je výsada těch kdo spoléhají na své štěstí. problémy a jak je napravit i v té Mathworks verzi jsou popsané v odkazované práci.

Lze ale udělat iterfacing k Linuxovému jádru úplně vlastní, zbavit se závislostí na podivnostech a mnoha vrstvách RPi targetu s tím, že se překládá rychleji křížově na počítači vývojáře a ne na RPi SD kartě a vše chodí již podle pravidel RT Linux aplikací, zamykání do paměti, priotity inherence podle přiřazené priority tasku atd. Řešení je k dispozici na stránkách naší katedry https://github.com/aa4cc/ert_linux/ , úspěšně se používalo s RPi, Zynqem, NVidia Jetson a dalšími. Dokonce od tohoto ledna umí i NuttX, teoreticky všechny jím podporované verze, "jen" je po třeba dopsat bločky k A/D, D/A převodníkům. Ale zase tak moc práce to není, pro pysimCoder a NuttX nějakou desítku bloků proti obezným NuttX driverům napsal náš student v rámci GSoC běhěm léta https://cwiki.apache.org/confluence/display/NUTTX/%5B2021%5D+NuttX+Support+for+Rapid+Control+Applications+Development+with+pysimCoder . Většinu lze přímo vzít a upravit na S-funkce nebo do TLC pro Simulink.

No další věc je, že když Matworks vlastně ani o námi kolegům sdelené informace nestojí, a ještě chce za reálné nasazení ve firmách opravdu velké peníze, proč vlastně se s ním trápit. Na výuku a hraní již pysimCoder https://github.com/robertobucher/pysimCoder začíná být užitečný, jak pro Linux tak pro NuttX, třeba po další bakalářské práci bude mít i podporu vektorů a po ještě další nastavování parametrů za běhu.

Tak kdo chce může naše výsledky použít a třeba se i zapojit, jak do řešení pro profi nasazení založené zatím na SImulinku tak do práce na otevřeném řešení pro hraní a radost.

Pro obyčejné nevzdělance, co je za problém v RPi, Arduino v nějaké průmyslové automatizaci?

Rozumím tomu, že ve chvíli kdy potřebujete snímat a vyhodnocovat nějakou hodnotu 100tis. krát za sekundu (řízení nějakého obráběcího stroje, otáček atp...) tak nepoužijete arduino.

Já ale například vyráběl robota který má pár tlačítek, hydraulika nahoru/dolu, naviják nahoru/dolů, pojezd dopředu/dozadu s potenciometry pro úpravu zatáčení levá / pravá + plyn a tam arduino funguje spolehlivě už 10 let (sice ne denně). Dovedu si představit že by se takto mohla klidně zahájit i sériovka a žádné fatální problémy bych u toho neočekával.

Reakce robota které očekává obsluha je pod sto ms, což toto řešení bohatě poskytuje. Přidám plyn, do 100ms (samozřejmě ještě mnohem rychleji) se rozjedu. Zmáčknu naviják nahoru, do 100ms je naviják v pohybu.

Druhá věc je cena, a souhlasím, že by se to celé dalo udělat levněji, elegantněji, robustněji a pravděpodobně i bezpečněji na nějaké k tomu speciálně navržené desce.

Ale když to vezmu z pohledu funkčnosti. Obě řešení budou rovnocenné. O jakých implementacích tedy přesně mluvíte vy a proč musejí být tak náročné a drahé?

Nechci do vás nijak šít. Zajímalo mě to vždycky, proč firmy utrácejí tak obrovské peníze na něco co se dá kolikrát relativně snadno zbastlit na koleně.

Takto to zní samozřejmě hrozně, kdo by chtěl provozovat klíčové systémy (které při výpadku pošlou všech 1000 zaměstnanců ze směny domů - dokud se to neopraví) na nějakém zbastlenci.

Nicméně stejně tak si dovedu představit, že příjde nějaký údžbář s předprogramovaným ardu mikro, rozebere krabičku, vymění destičku kus za kus a jede se dál. Úplně amatérské mi to nepříjde a zvládne to i "cvičená opice". Obzvlášť pokud to arduino bude dostačovat tomu co se od něj žádá a vydrží v tom provozu třeba spolehlivě 7-10 let (třeba i díky dobrému pouzření a odpovídajícímu IP krytí).

Pak si dovedu klidně představit i situaci, kdy údržba co 5 let obejde provoz (stejně to tak určitě dělají i dnes) a preventivně vymění staré za nové.

Jsou nějaké zkušenosti s "drsnějším" prostředím a odpadáváním podobných (ardu, rpi) desek? Já to řešení vyráběl s kamarádem do zaprášené dílny + do exteriéru, takže prach, piliny, déšť, mráz, sníh, přímé slunce, teploty -25 až +50. A ardu drží už skoro 10 let.

Dobrý den,

o AVR netvrdím a ani jsme netvrdil, že nelze v běžném prostředí nasadit pro trvalý provoz pro aplikaci, kde hrozí jen škody ekonomické v běžném rozsahu. Když se dívám na ATmega2560 (je to snad ten čip do je na destičce), tak má rozsah od – -40C do 85C - Industrial. Pokud je čip ve stínu a v dostatečně dobře větraném zakrytování, tak je na zařízení do budovy a asi i rozvaděče ven v pořádku. Do auta již třeba pod kapotu nepatří. Když se sečte teplo z motoru a slunce, tak klidně v nějakém místě může být přes 100C. Pak se člověk diví, slyšel jsem o špatné volbě přepalovaním propojek konfigurovaného FPGA ve světelné křižovatce, kde došlo teplem ke spojení propojek a souhrnem návrhových opomenutí k tomu, že se ze všech stran na semaforu rozsvítila zelená. Docen Vysoký, můj vedoucí a školitel, navrhoval v 80 letech obvod pro řízení zapalování pro 613 z Tatry Kopřivnice. Obvod byl pěkný a v rámci hraní si s ním postavil řízení zapalování pro svojí škodovku, pro uložení map otáčky, podtlak, teplota na předstih použil EPROM paměť ze zásob s větším sledování parametrů. V Jugoslávii (dnes Slovinsku) při cestě na Vršic, převýšení asi 700 m se v půlce zastavil, aby se podíval na okno Prisojniku. Tím se zatavil větrák u motoru. Na slunci se teplo z motoru nemělo kde schladit, a EPROM se zmazala. Je to schopný technik, rychle předělal motor zpět na původní mechanické řízení předstihu. A takto mohu pokračovat, ano můžete mít štěstí a nic se nestane... Ale jak říkám AVR mi nepřipadá po této stránce jako zásadní problém, pokud sedí specifikace. Pokud by se opravdu jednalo o něco vážného, tak bych měl trochu větší důvěru k firmě, která běžně military součástky vyrábí. Do auta do prostoru motoru by měl být rozsah alespoň -40 až +125C. Když se podíváte i na velké procesory od NXP tak najdete i iMX8 (64-bit ARM) MIMX8QP5AVUFFAB, která to splňuje. Stejně tak v iMX6 rodině je takový typ. Není to ten nejvýkonnější... ten již i při ochlazení pouzdra bude mít na čipu teplotu mimo záruky. Ale to není čip, který patří moc do kritického řízení, z velkých tam patřily PowerPC třeba SPC5744PFK1AKLQ8 -40 až 135. A to nejen kvůli teplotě, ale protože je to čip, který netahá vodiče k velké nepolehlivé DRAM ven, ale má dostatek paměti (384 kB RAM a 2.5 MB Flash) na čipu s tím že i ta Flash je testovaná v daném rozsahu. Zároveň tam nebude komplikovaný systém s dynamicky nahrávanými knihovnami s on-demad stránkováním, kde musíte zpětně mlockall vynucovat, aby se aplikace držela jen v RAM atd... Bude tam nějaký RTOS (podle OSEK, Autosar nebo kód nagenerovaný ze SImulinku). Pak můžete dodržet časování. V tom bude to AVR, když jeho výkon stačí, s dobře napsaným kódem také v pořádku, jasně pro aplikace mnohem jednodušší, které do daného času s nějakým ověřením a rezervou zvládne. Na menší věci má ale i NXP procesory s rozsahem -40 to 150º C, třeba S32S s lockstepem, které odhalí i chybu v pipeline, lockstep atd... Stejně tak Ti TMS570LC4357-EP a TMS570LS3137-EP kde existuje i kvalifikace pro space.... A najdeme i menší MCU a další výrobce. Ale sále to není důvod pro běžné industrial zavrhnout AVR. Pokud by čip byl opravdu levý a stálo za to na něj aplikaci napsat na míru, tak to může mít smysl.

Proti AVR hovoří stáří koncepce, v dnešní době provozovat CPU, které nedovolí normální portaci běžného C kódu a algoritmů je podle mě škoda. Přitom AVR nesplňuje základní předpoklad pro jazyk C, do registru je možné uložit adresu na libovolné místo v jednotném adresním prostoru a je možné proti této adrese offsetovat. Ukazatel do programu je z jiného adresního prostoru než na data. Výsledkem jsou různé obezličky proti standardu jazyka C. Zároveň každá složitější operace s ukazatelem se musí řešit na několik instrukcí. Ano je to obrovský pokrok proti 8051, kde člověk musel rozlišovat DATA, IDATA, PDATA, XDATA, CODE. V době, kdy jsme pořádný mikrokontrolér/pro­cesor (např 68332/68376) ještě kvůli ceně dát do našich přístrojů dán nemohli, tak jsem si assembleru 51 užil hodně a dostat ten kód do normální C pro ARMy pak trvalo roky. Aplikační vrstvy uLANu jsme přepsal i do C pro 8051, ale do dnešní doby tam straší různé hrozné makro kompromisy, které umožňují kód zkompilovat na architekturu nesplňující základní předpoklady jazyka C. DOkonce jsem i pár věcí v SDCC pro 8051 opravil, spíš z takové divné chuti, aby to i dále bylo použitelné. Ale vím co pod tím je a reálně je to zcela špatně. Přitom na takto ubohé architektuře nakonec v těch částech, co mají být obecné, je nutné používat tříbytové ukazatele..... se kterými se pracuje na desítky instrukcí na operaci... která trvá několik cyklů. Podívejte se proti tomu na eleganci i té dnes přeonané instrukční sady MIPS/PIC32, nebo třeba i opravdu malou spotřebu na MSP430, ano je to omezený 16-bit, ale když rozšířili adresní prostor na 1MB, tak rozšířili registry a ALU na 20 bitů.

Nyní k Raspberry Pi,

Raspberry Pi 4 Operating temperature: 0 – 50C vzduch (to i v koupelně, za televizí atd může být někde více). U compute module 4 rozsah dokáží napsat teplota okolí -20°C až +85°C, ale zároveň The BCM2711 will reduce the clock rate to try and keep its internal temperature below 85°C. Pokud tedy budeme pracovat v prostředí s povolenou vnější teplotou 85C, tak se při 85C vnitřní nemůže odvést ani mili-Watt. Z toho vyplývá, že by se čip měl omezit na nulový odběr. Rovnou, pokud někdo něco takto rozporného napíše v oficiálním dataseetu, tak je nutné firmu vzít jako zcela neseriózní v tom co tvrdí a mít se na pozoru. Přitom jak napsalo několik lidí v jiných reakcích, tak minimálně jednoty procent RPi v aplikaci 24x7 do roka odchází. Ano, na hraní, kde většina odejde na nějaké chyby, zkratování, náboje atd. a experimentování s tím jak použít GNU/Linux, velký ARM Python atd. je to OK. Ale ne do něčeho seriózního, co se má vyrábět sériově. Tak to k specifikaci HW.

Nyní k real-time a OS. Jak jsem již psal dříve, je potřeba být velmi obezřetný, kam ještě pustit GNU/Linux. Bez fully-preemptive patchů je možné, že nějaká komplikovanější situace při třeba enumeraci USB dohromady se zprávou napájení a zátěží GPU a DMA povede k livelocků, prodlevám atd na desítky ms. Ano průměrná odezva a propustnost bude dobrá. ETHERNET na USB také mnoho věcí, zbytečných inerrupt událostí a dalšího způsobuje. Když použijeme jádro pleně preemptivní, tak dlouhodobým měřením vychází třeba, že 250 usec se nikdy za dlouhou dobu nepřekročilo. Ale opět ten HW je zbytečně složitý, GPU část a další mohou způsobit latence blokací sběrnic přes dlouhé DMA atd.. Obecně pak je potřeba vážit, jestli nepoužít raději menší/nebo i velký MCU. Ono i iMX6 má errata, že pokud použijete PCIe a dojde na ní k nějaké velmi nestandardní operaci (zrovna jme měli smůlu, že jí požadovaná zkouška na odolnost proti výbojům vždy vyvolala a šla vyvolat vnějším resetem připojeného ETHERNET řadiče), tak PCIe transakce nedoběhla a dané procesorové jádro se zaseklo na AXI, v zápětí pak druhé jádro narazí na společný lock nebo potřebu sesychronizovat scheduler a umře také. Do reálné aplikace do rozvaděče pak nelze takovouto věc dát. Postaními kanály jsme se dozvěděli, že na podobné problémy narazili i jiní a když supportu podepíšeme NDA, tak se dozvíme, že s tím nejde nic dělat ale již tom nebudeme pod pokutami smět mluvit. Takže i u HW, který byl na rozdíl od RPi opravdu na teploty, interferenci atd testovaný, musíte mít zkušenost, co je dostatečně spolehlivé a co ne (našla se alternativa jak vyřešit další ETHERNET přes konfigurovatelný switch) a i tak na kritičtější věci je potřeba hledat ještě vyšší spolehlivost..... TMS570, Rad-Hard PowerPC která drží i na roverech na Marsu atd.. Na druhou stranu občas se dějí překvapení, Ingenuity na Marsu na bázi čipu pro mobilní consumer grade telefony zvládla/měla štěstí že pracovala v prostředí s vysokou úrovní záření atd.... Ale to si mohli dovolit jen proto, že to bylo schválené jako experiment s vysokou akceptovatelnou míro nezdaru. Pokud bude další, kde se již bude předpokládat nějaký cíl mise, tak buď budou muset volit úplně jiný HW a ne Linux nebo to budou muset testovat na desítkách kusů na zemi s obrovskou rezervou a asi ani tak by to akceptovatelné nebylo....

Co se týče RT a GNU/Linux, tak si přečtěte třeba můj úvod zde na Rootu

https://www.root.cz/clanky/gnu-linux-pro-rizeni-a-rychlost-jeho-odezvy/

Co se týče HW a návrhu řešení, která vydrží desetileti, tak je to opravdu na dlouhé debaty, věc citu, zkušeností, třeba i ochoty riskovat a nebo masivně s rezervou testovat a rád se také poučím.

Přitom jak napsalo několik lidí v jiných reakcích, tak minimálně jednoty procent RPi v aplikaci 24x7 do roka odchází.

Odešlo RPi nebo SD karta?

25. 9. 2021, 15:45 editováno autorem komentáře

Hm. zajímavé info. "Proti AVR hovoří stáří koncepce, v dnešní době provozovat CPU, které nedovolí normální portaci běžného C kódu a algoritmů je podle mě škoda."

Toto jsem například vůbec netušil. Je ale fakt, že já jako neprofesionál, se do nižších vrstev programování nikdy nedostanu.

Dík za objasnění. Snad do budoucna plánujou i přechod na něco C pozitivnějšího než je tomu dnes.

Je ale fakt že v jednom ovládání máme encoder (otočný ovladač - ala mikrovlnka, nebo autorádio) a rychlostí - nebo asi přesněji pomalostí - snímání pulzů jsem byl zklamaný.

Neměl jsem ale čas ani chuť zkoumat, kde přesně je úzké hrdlo. Jestli při rychlejších otáčkách encoderu přestaly stíhat mechanické spínače, a nebo přestalo stíhat arduino načítat jednotlivé pulzy. To by se asi dalo ověřit kvalitnějším encoderem, nebo rovnou tím optickým. Toto už ale, jak uvádím výše, nestálo za další zkoumání. Výsledek byl i tak dostatečný. A že se sem tam při rychlejším otáčení nějaké pulzy ztratily není v rámci implementace problém. (nastavování času - ala mikrovlnná trouba :-))

No. Jak tak pročítám tu vaší prezentaci, tak jste RPi rozebral snad do posledního polovodiče. A našel na něm hromadu chyb. :-)

Na druhou stranu u spousty projektů MXx vypadá jako pořádný kanon na vrabce.

Dobré je ale to poutací video na MX53 - ve videu cena $159. Na stránce odkud jsem video spustil cena $299. A na českém webu k dostání za 6590Kč.

iMX53 jsem používali před mnoha lety, článek je pak z roku 2016. Ano i v i .MX53 jsou varianty s longevitou 10 a možná i 15 let. Takže stále je dostupná, ale obecně to nebyla stálice. i.MX6 se chytla a bude tu ještě dlouho, modulek s iMX6 Solo s jedním ARM jádrem vyjde třeba u SolidRunu s chladičem na 85 USD https://shop.solid-run.com/product/SRMX6SOWT1D512E008V15C0/ . Je ale potřeba si k němu udělat základovku. Proti RPi 4 bude výkon tristní, ale věřil bych tomu mnohem více. Modul i.MX8M Plus Quad – WiFi/BT je za $116, i ten bude o něco pomalejší než RPi4. Grafiku porovnat neumím, hezké je, že na iMX6 jsme již před lety rozjeli pro naše partnery Qt přímo nad open source drivery a mesou s EGL a Qt chodily i nad Waylandem. Plně otevřené řešení v té době bylo o něco pomalejší než ty originál bloby, ale pro spolehlivost a dlouhodobou udržovatelnost jádra z mainline je to o řád lepší. Jinak na slušné aplikace se kupují trochu dražší industrial verse, ty kolegové mají dojednané přímo.

Určitě je také pro low end dobrý Beagle Board Blask £40.32, Industrial £56.45 s tím že procesor je -40 až 90C na pouzdře. Tyto moduly se používaly dříve. Mohu se zeptat, jestli se něco již pokazilo. Vzhledem k tomu, že vedle toho jiskří pantograf na trolejovém vedení, tak to nemusí být jen teplotou a klasickým opotřebením.