Názory k článku Arduino Mega na zbernici s PC
-
Další systém s RS-485 který vyžaduje polling, v bytě si nezapnete světla ani neuregulujete teplotu, když se pokazí PC hardware, který není v desktopových verzích moc vhodný k trvalému provozu. Přitom při větším počtu uzlů budou narůstat latence než všechny jednotky obejdete.
Zkuste se podívat na možnosti otevřeného protokolu, který jsme pro naše přístroje http://pikron.com/pages/products/hplc.html navrhli již před 30 lety a i ten nejstarší kus je možné zapojit s nejnovějším. Používá ho i kolega v zemědělství na svém domu atd. Na ČVUT FEL na něm kolegové postavili model řízení domácnosti, když zjistili, že jimi vedený Profibus.cz je jim v tomto směru k ničemu. Vyžadoval by placení poplatků atd. Většina práce za grantové peníze zůstala zavřená, velká C# aplikace. Ale tam kde za mnou došli zadarmo na radu, tak se něco do open-source řešení dostalo a nakonec jsem pro zábavu většinu funkcionality z té jejich vědyse dvěma studenty napsal i jako opensource v Qt.
Máme jak řešení jak ve formě USB převodníku, tak PCI/PCIe karty i běžný PC sériový port, podporujeme jedním kódem, GNU/Linux, Windows, NuttX i systémy bez OS. Běhalo to v ASM verzi se shodým API i na 8051 s 256 byte RAM, přitom jako even-driven multimaster. Plná verze chce tak 8 kB RAM, ale od 2 kB to jde.
uLAN projekt http://ulan.sourceforge.net/
Vysvětlení, jak je možné z jednotek sestavit vzájemně provázané funkce, kdy není potřeba žádný master, ano hodí se nód na monitoring, konfiguraci případně dynamické přidělování adres, ale když cokoliv z toho umře, tak jednotky dále plní své funkce a vazby
http://ulan.sourceforge.net/pdf/ulan-pdocochan-rtlws13.pdfNezávislá recenze experta z CMU.edu
Byron Jeff http://kahuna.clayton.edu/~byron/
Mon, 18 May 09 07:13:28 +0300
Qustion: I also looked at uLan. What kind of network is it?From first glance it's a rotating reservation slot system that uses the break character to seize the line and manage line arbitration. Slot reservation based on the previous master makes it pseudo token passing when all nodes are busy. Not a bad design overall.
Mon, 18 May 09 07:13:28 +0300
uLan seems to be a good compromise allowing for line arbitration at any time. But there's a cost for non deterministic arbitration.
Ano, řešení není úplně jednoduché, ano deterministická arbitrace se platí časem, ano, jsou zde potíže, že ne všechny kontroléry umí 9-bit komunikaci. Ale je to řešení, se kterým lze 30 vydržet.
Přitom je možné nad shodným kódem, který běží v jednotkách postavit i dynamickou jednotku ulan-genmod, kterou je možné neskriptovat v QML a pak je možné jak reálné tak v počítači vytvořené jednotky propojit a nechat je vzájemně komunikovat. Systém má plnou introspekci, administrační SW může vylistovat všechny parametry jednotky a dovolí nakonfigurovat propojení aniž by daný typ jednotky musel mít někde jinde EDS nebo stahovat něco z Internetu. Stačí pak zapojit pojmenované property do vizializace, teď bychom to s využitím SVG uměli nádherně. Ano systém slouží, bohužel nám výrobu analyzátorů opsaných z námi licencované verze mnoho let neplatili a i ty ostatní přístroje na pořádnou údržbu nevydělali. Takže jsem sám snad 20 let z těchto projektů neviděl korunu a nemohly se rozvíjet. Na grantech si vybrali celkově desítky miliónů... Ale stále si myslím, že má smysl vytvořit něco pořádného a dlouhodobě použitelného.
Tak se třeba někdo, kdo má zájem o dlouhodobě udržitelné řešení ozvěte. Můj e-mail opravdu není problém najít. Čas teď nemám, ale příští rok nakonec možná pro ty, co to bez nás zkazili, nakonec spíš z dobré vůle, než že by tu práci slušně zaplatili a chovali se kooperativne, zase něco vyvineme a uLAN asi použijeme. Alespoň projekt přežije.
-
Toho jsem si ani na tomto článku nevšiml, pokud je to bez galvanického oddělení, tak budiče zaručují funkčnost do rozdílu zemí +/-7V některé více, okolo 10 až 14 se mohou zničit. Je jasné, že rozdíly napětí na zásuvkách svítidlech atd. být mohou a při špičkách a poruchách velmi vysoké.
V těch projektech pro home automation se na uLANu většinou rozvádělo 24 VDC napájení spolu s linkou a jeho reference byla referencí pro komunikaci.
My ve všech laboratorních, medicínských a robotických a dalších aplikacích máme všechny RS-485 interface galvanicky oddělené. Na každé jednotce máme 47k odpory pro pull-up a pull-down. Tím zajišťujeme klidovou úroveň linky, umožňujeme dominant/recesive vysílání při arbitraci a zároveň srovnáváme plovoucí země galvanicky oddělaných budičů na jednotnou hodnotu. Teoreticky ty odpory mohou způsobovat nějaké odrazy, ale pro většinu aplikací ani linku na koncích neterminujeme a potíže jsme nikdy nezaznamenali. Nevím přesně, jestli v Agrosoftu mají vedení uLANu udeělěné jinak. Spíš si myslím, že ne, ale mohu se zeptat. Měli ho i mezi stájemi velkochovů a dalšími budovami venkem a na stovky metrů. Potíže jsem hlášené neslyšel. Předpokládám, že když to nebylo v zemi, ale jen provizorně vzduchem, tak jim něco mohlo odejít na blesky. Kolem je mnoho humpulácké elektroniky, jiskřících motorů krmiček atd... a opět nějaké zásadní problémy jsme neslyšel.
Takže při řešení jen v rámci jednoho vlastně malého rodinného domu si myslím, že kroucená dvojlinka bude OK. V 90 letech jsme si jí často na schodech s matičkou na konci stáčeli z opravdu těch nejlevnějších izorovaných drátků, co jsme nějaká kluba zdědili s odkupem vlastního projektu od bouraných Laboratorních přístrojů Praha.
-
Docela by mne zajímalo, proč všichni pro tyhle multimaster sběrnice tvrdošíjně používají RS-485, když už tu leta máme i levné budiče pro CAN sběrnici, které poslouží stejně a jsou navržené i pro koklizní stavy. Měl jsem v plánu udělat protokol, který by pro arbitraci využíval princip z CAN, třeba vysílal svoje ID a četl, zda přijímá to samé. Pokud ne, čekal by na další příležitost. Pokud by měl sběrnici volnou, poslal by svá data normálně seriovým protokDocela olem.
Pokud by jeden bit pro arbitraci trval jako celý byte plus stopbity následně přenášených seriových dat, tak by arbitraci příjemci vyhodnotili jako frame error a neragovali.
Dokonce by se dalo využít devítibitové adresování pro buzení příjemců při adresaci jen právě jich. -
A navíc s FT-CANem můžete mít i topologii do hvězdy, v podstatě neřešíte impedanci, odrazy (všechny konce mají aktivní přizpůsobení). Když nemáte nataženou dvojlinku, tak to jde i po jednom drátě (proti zemi, a opravdu stačí na obou koncích zemnicí tyč, vracet to opravdu hlínou).
Mám nějaké senzory natahané po stodole po nějakých původních silových drátech, kterým se papírová izolace dávno rozpadla, a chodí to bez problémů. Jednou žílou napětí, jednou data (CAN H), return vlhkou zdí/zemí.
-
Transceiver stojí dolar (moře destiček na aliexpressu).
Jestli Arduinem myslíte nějaký odpad z 90. let typu ATmega nebo ATtiny, tak si ještě připatíte další 1-2 USD za CAN controller (a s tím pak mluvíte po SPI). Soudobější čipy (STM32, ESP32, ...) to mají v sobě.
Jestli Arduinem myslíte ten softwarový ekosystém, tak ano :-)
22. 9. 2021, 12:11 editováno autorem komentáře
-
Automotive HSCAN transceiver mam zrovna naquotovany za EUR 0.204 :-), je to levnejsi nez RS485kove (ty neumim koupit tak levne).
Vyhoda RS485 je, ze to je UART, takze si tam implementujete cokoliv chcete, ale musite resit vse okolo.
CAN-BUS funguje tak, ze mate 'mailboxy' do kterych sypete az 8 bytove zpravy, controller se stara vlastne uplne o vsechno, o prijem, odesilani, kolize, ... jen v aplikaci musite kontrolovat jestli se zpravy odeslaly a zda to co chcete se prijima. Akorat potrebujete spravny MCU.
Pro predstavu, takhle nejak to vypada na aute (id, data):
15.4.2021 19:23:12.693 0000028B 0000000000000000
15.4.2021 19:23:12.712 00000281 0000000000000000
15.4.2021 19:23:12.762 00000281 0000000000000000
15.4.2021 19:23:12.772 00000286 0000000000000000
15.4.2021 19:23:12.782 0000039E 0000000000000000
15.4.2021 19:23:12.792 0000028B 0000000000000000
15.4.2021 19:23:12.802 00000380 0000000000000000
15.4.2021 19:23:12.808 000003C4 000006
15.4.2021 19:23:12.812 00000281 0000000000000000
15.4.2021 19:23:12.822 0000029B 0000000000000000
15.4.2021 19:23:12.862 00000281 0000000000000000(je to body can nejakeho starsiho auta,)
22. 9. 2021, 13:07 editováno autorem komentáře
-
Spravny MCU ani netreba. Existuju aj separatne CAN PHY na SPI, dokonca aj v THT verzii, takze sa to da spajkovat dohromady aj trafopajkou. U CANu by som skor ako nevyhodu videl, ze pre dlhsie spolahlive vedenia je s tym trocha ostara to cele nakonfigurovat skrz presne hodiny a odrusenie. Dalej tam je mozna nevyhoda v tom, ze vela PHY bude riesenych len pre 125/250/500(/1000) kHz, co moze byt pre vela aplikacii overkill. A nakoniec RS485 je v podstate fyzicka vrstva CANu bez jeho CSMA/CA daneho arbitrazou.
-
"A nakoniec RS485 je v podstate fyzicka vrstva CANu bez jeho CSMA/CA daneho arbitrazou."
Dovoluji si nesouhlasit, NE to rozhodne neni ! Nechapu kde se tento nesmysl dokolecka bere.
Ano, SPI CAN controllery jsou, ale stoji ale vic nez nejaky Cortex-M3/4 s CANem. Jeste je nekde pouzivame a je to tragicke reseni.
-
Mohli by ste svoj rozpor mojho tvrdenia rozvinut? Rad sa niecomu priucim.
A zrovna dnes to s cenou toho Cortexu s CANom ani nemusi byt pravda. Najlacnejsie L0+ co uz ma CAN bude kludne za 5+ eur, ak vobec bude k zohnaniu.
Kazdopadne suhlasim s tym, ze ATmega je mrtva vec (tusim velku cast tych cipov sam Microchip uz ani nevyraba a su to iba klony) a netreba na nom stavat nove dizajny.
-
Mrknete na prubehy signalu z nejakeho datasheetu, nebo pres google images a bude to myslim jasne hned. Stejne na nich je to, ze maji dif. signal, takze mozna RS485 xcvr pujde pouzit na prijem CANu, ale to pujde i LM393. V laboratornich podminkach.
FTCAN je tim jak jdou proti sobe CANH/CANL podobny RS485, ale ma spoustu detailu navic, jeden z nich je treba zde zminovana terminace a fault mody.
Sehnat nejaky levny Cortex s CANem nemam az takovy problem, obcas je potkavam, nejde-li o tisicova mnozstvi. Posledni dobou celkem casto prochazim ruzne arrow/digikey/... a vykupuju co je zrovna skladem (ne teda ty SoC, jine souc.)
-
arduino nie je len atmega. je to libka ktora je portovana na vela cpu vratane STM32, esp8266, esp32. NO a ma kopec kniznic na rozny HW vzajomne kompatibilnych. Ano kvalita je otazna ale ak chce clovek nieco polepit trafopajkou a nestudovat datasheety k tym svabom je to idealne. Staci pozriet projekt tasmota
-
CAN (treba CANOpen) je super ale neni to pro "kurvilky", protokol uz je moc slozita zalezitost.
Zatimco RS-485 (treba modbus) je tak strasne primitivni, ze ho pochopi kazdej za jeden vecer a behem druhyho vecera napise svoji implementaci.
A ja to mam stejne, ac jsme v byvalem zamestnani pouzivali CANOpen velmi hojne na pokrocile urovni, tak domu bych si to nedal
Pokud budete chtit CAN radic znasilnit do nejakeho nevyhovujiciho protokolu, tak z toho muzete bejt celkem smutnej (treba opakovani zprav v tom muze udelat celkem hokej). + je tam hrozne velka rezie zprav...
Pokud chcete znasilnit pouze budic CANu a honit pres to treba UART, tak tim proti budici RS485 nic moc neziskate (atorat to ze pri kolizi mozna vyhraje dominantni uroven). Navic tam ale pravdepodobne nebude zachovanej "bit stuffing", coz muze mit negativni nasledky na spolehlivost prenosu (neumim posoudit jak moc vazne)
Jako nejvetsi nevyhodu ale vidim, ze nemuzete pouzit nic z toho co uz existuje. Jako treba nakoupeny senzor, nakoupeny prevodnik CAN-USB, nakoupeny analyzator sbernice... Nic. Prijde mi to jako cesta do pekel. To bych radeji venoval par tydnu do studia canopenu...
-
Nejako nevidim dovod CAN akokolvek znasilnovat. CANopen je len volitelna, tuho aplikacna vec. Nikoho nikto nenuti ju pouzivat (ofc kym si nenakupim gadgety, ktore na holom CANe nevedia chodit). Jedina povinna vec je CAN ID a nadavat na to a s nim spojenu arbitraz je, ako keby clovek nadaval na to, ze I2C vyzaduje adresaciu.
-
Kdyz jsem mluvil o znasilnovani reagoval jsem na prispevek od "TechnikTom", ze ktereho se mi zdalo, ze chce pouzit CAN pouze jako fyzickou vrstvu ale budit to z radice UARTu.
Pochopitelne muzete jet na "cistem" CANu v tom vam nijak nebranim. :)
Jenom uz jsem videl par projektu, kde se po CANu tunelovala seriova linka (pekne jedna zprava jeden znak) a velike prekvapeni jak strasne je to pomale (rezie) a jeste vetsi prekvapeni, ze se po nasazeni zjistilo, ze se obcas nejake znaky opakuji.
Tak mi prislo dobre na to upozornit, ciste z edukativnich duvovu ;) -
Pointa CANu je právě že žádnej protokol po večerech implementovat nemusím. Na jednom konci vložím do mailboxu struct, vyšlu ho s daným IDčkem, a na všech ostatních nodech (které dané ID zajímá) se mi ten stejnej struct objeví v jejich mailboxech. Neřeším jak, proč, protože už to vyřešili jiní místo mně.
Ano, vědět jak funguje jeho bit timing, bit stuffing, arbitrace atd. je přínosem hlavně pro diagnostiku, ale nepotřebuju to k provozu. Narozdíl od bastlení nějakých hrůz nad holou 485 nebo nedejbože modbusem a jeho 16bitovými typy :-)
-
Vyhoda CANu je moznost prioritozvat spravy (podla "adresy") a hlavne fungovat asynchronne. Je nutene si rozmysliet adresaciu ale potom posielenie sprav je limitovane len 8byt payloadu aj ked vacsinou si vystacim len 0 bytami na riadeni sluzi uz rovno adresa. z pripojenim na ESP32 mam portov jak hadov nemusim implemntovat nic z pohalhu CAN BUS deje sa to "samo" staci par centovy prevodnik z ALI. Tak isto lahko mozem implmenovat lopatovac z CAN na MQTT niekde ked uz je siet. RS486 a postupne obvolavanie kazdeho je opruz. Hlavne ked chcem riesit tlacitko a naslednu reakciu (zvoncek) nebude predsa zvoncek zistovat kazdu sekundu a nestalcil niekto tlacitlo aby som zacal zvonit ??? Treba rozlisovat senzory a aktivne prvky. Senzor ma posielat svoj stav a kazdy koho to zaujima ma reagovat.
-
CAN je pěkný, ale arbitrace běží na bittime a tak pro 1 Mbit/s nemůže být linka delší než 30 metrů. V rámci našich CAN projektů, příspěvků do kernelu, QEMU atd. na ČUT FEL vznikl i vlastní CTU CAN FD řadič a jsme v kontaktu s návrháři CAN FD a teď CAN XL protokolu. Klasický CAN má potíž krátkýc zpráv a omezení délky linky nepřímo úměrně rychlosti. CAN FD po dobu přenosu dat přechází na vyšší rychlost/bitrate, ale již když jsem návrh prvně viděl, tak jsem prezentujícímu z CiA říkal, že budou zásadní problémy s nevyváženým buzením při data bitrate a že by linka z dominant recesive měla přejít po dobu přenosu dat na push pull. Automobilky měli s CAN FD ze začátku mnoho potíží a dnes se používá místo slibovaných 20 Mbit/s na data je 2 Mbit/s. I tak to není ono, přidávají se do budičů řízení zakončovací impedance, které při přechodu dominant recessive slouží k potlačení odrazů a zákmitů, improved signal integrity. Nakonec se stejně výrobci rozhodli pro návrh nového standardu, CAN XL, kdy se pro arbitraci používá dominant recessive a po dobu datového přenosu se přechází na push-pull (něco co měl uLAN na 8051 vybavené jen úplně primitivním UARTem vymyšlené před 30 lety, takže o tolik jsme byli napřed). Výhoda CAN XL pak je, že přechází po dobu data pase na nižší a symetrické napěťové úrovně a že po dobu arbitrace je recessive nula a dominant od rozdílu 1V, jako u klasického CANu. Tady náš původní uLAN pro spolehlivost vyžaduje v klidovém stavu rozvážení, protože u komerčních RS-485 transceiverů většinou není definovaný vložený offset do dohodovací diferenciální úrovně. Pokud by tam bylo definované, že je třeba od 0.3 do 0.7 V tak by to nebylo potřeba, ale zase v datové fázi by to zkracovalo nuly. Ale i tak je otázkou, jestli mnoha koncepcích nebude uLAN stále dále než CAN XL. Přitom řadič na CAN FD ano na CAN XL si bez placení licenčních/patentových poplatků nemůžete dovolit prodávat a asi ani řešení, kde by to bylo vyřešené nějak v "soft-core". uLAN byl dokumentovaný a zdrama od začátku.
-
Skuste si s Raspberry definovat inicialny stav pinov pri starte OS. Je to celkom problem. Mam napr. problem s otvaranim garazovej brany, ktora sa mi pri restarte niekedy otvori, pretoze Raspberry pri inicializacii rozne nastavuje GPIO piny. Ovladanie brany je jednoduche cez skratovanie polov, tzn. akekolvek zapnutie ma za nasledok pohyb brany.
-
Jan HrachStříbrný podporovatelA jak to měl teda řešit? (když to má někde v baráku, kde je normální teplota a vlhkost, tak to snad ani moc neumře)
-
Mám na tom postavené tři průmyslové roboty a žádný adrenalin v tom nevidím. Proč si to myslíte? Za mě ideální řešení jak je uvedeno výše. a) jednoduchá programovatelnost b) jednoduchá údržba.
A všechny tři stroje jedou bez potíží. Jediné na co jsme zatím při tom bastlení narazili byly naše vlastní chyby (tlačítkem občas problikne 1 i když na něj nikdo nesáhnul (špatné stínění), špatně odrušené cívky relátek, které po odpojení spálily desku atp :-)).
Zatím jsem nepřišel na nic, kde bych řekl.. kruci. Toto je chyba arduina. -
Desítky % to nejsou ani náhodou, to bych neměl co žrát :-) ale ano, spolehlivé to není. SD karta je permanentně 30-40 °C nad ambientem (takže běžně třeba 60 °C), LAN controller na RPI3BP je od 50 °C nestabilní (a jeho crash vede k oops kernelu, zvýšená aktivita spojená s následným rebootem generuje další teplo a tak se to samo nespraví).
Máme v provozu cca 1000 zařízení s tímto, servisů s novou SD kartou je tak 5 za měsíc, takže roční failure rate je kolem 6 %.
22. 9. 2021, 13:40 editováno autorem komentáře
-
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
-
Pokud se jedná o průmyslovou nebo automotive nekritickou aplikaci, ne jen bastlení, tak doporučuji něco jako Solid-Run,,Variscite, atd s iMX6/8, podívejte se na garantované teplotní rozsahy atd. Kdo opravdu umí s Linuxem, tak rozjet na takovém systému i třeba celý Debian je bez potíží. V mnoha firmách jsme jim pomáhali takové řešení zavést a desky drží. Kde je potřeba FPGA, tak buď Xilinx nebo Intel/Altera ARM SoC.
Když na tom něco záleží, tak tam Linux nepatří a procesor by měl být alespoň lock-step nebo dva nezávislé, vybírali jsme MCU pro Porsche a vybrali a navrhli systém s TI TMS570. Smysl to má buď bez OS nebo třeba RTEMS si umím představit, že je zvládnutelné certifikovat. Vidím, jak se to připravuje pro ESA a NASA. Teď jsem byl u výběru TMS570 i pro drážní/tramvajové zabezpečení a kolega jednotku navrhuje.
Ano, v knowledge baze OTREES https://gitlab.fel.cvut.cz/otrees/org/-/wikis/knowbase pro nadšence a studenty ukazuji, že jejich oblíbené Raspberry Pi lze použít k řízení PMSM motorů s regulační smyčkou nad 1 kHz atd... Ale to je na hraní, ano snažil jsem se pomoc se snížením opotřebení SD karet firmě, která si RPi vybrala, ale obecně si myslím, že je perfektní na získávání znalostí, ale dále nepatří. Viz moje přednáška Je Raspberry Pi použitelné pro řídicí a robotické aplikace? https://www.youtube.com/watch?v=I_4cAhW46dM http://cmp.felk.cvut.cz/~pisa/installfest/rpi_overlay_and_rt.pdf
Bohužel mnoho lidí/nadšenců, co pozoruji, neumí nebo je líných znalosti přenášet dále a ustrnou u Arduina, které je 20 let za technologií a to i pro ty malé aplikace atd... stejné je to s RPi. Do verze čtyři určitě katastrofa s ETHERNETEM na USB. Taková kmplexita a overhead do vážných aplikací nepatří. Pak jsou takoví lidé i ve velmi seriózní firmě místo s nabízenou pomocí s iMX6 bastlit vše na RPi a přidat nepoužitelný CAN controller na MCP2515 SPI. Microchip CAN FD SPI verze jsou již mapováním na SPI použitelné... Pak se stráví hromada času snahou pomoci takto špatně rozhodnutému projektu, kde kvůli neschopnosti targetovat Matlab na něco jiného, než jim se špatnými RT vlastostmi zabalí Matworks vede k hromadě práce, ale alespoň měl náš student výplatu https://dspace.cvut.cz/bitstream/handle/10467/68605/F3-DP-2017-Prudek-Martin-Dp_2017_prudek_martin.pdf , kdyby ale rovnou poslechli naše doporučení a třeba i za každou jim věnovanou hodinu zaplatili 10k, tak by ve výsledku hodně ušetřili a měli robustní řešení na roky. Tak by je také možná v Praze nyní nerušili....
-
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/procesor (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.
-
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.
-
Nejako som nechapal, preco na taku primitivnost, ako meranie jedneho Dallasu treba atmegu32. Potom som sa pozrel do zdrojakov a vidim, ze arduino.h a C++. Not good.
Kazdy, kto prerastie Arduino shieldy, vezme do ruky pajkovacku, nebodaj si navrhne vlastny plosak, by sa uz mal na Arduino vykaslat. Obmedzuje ho to v rozlete. V skutocnosti Arduino neprinasa ziadne zjednodusenie, vsetko co vie arduino sa da dosiahnut inak, ale stale podobne jednoducho. Inu Atmega je primitivny kontroller. A ked clovek z Arduina vystupi, zisti, ze aj ine kontrollery, ktore toho vedia viac su vlastne rovnako primitivne ako Atmega, len opat trocha ine.
S Arduinom sa cloveku lahko moze zdat OK, ze na takyto "stredne velky automatizacny task" treba Atmega32, aj ked sa v skutocnosti podobna funkcnost da vtrepat do <7kB. (v 1kB bootloaderi mam serial / i2c komunikacny protokol s podporou remote flashingu a diagnostiky odvodeny od ISO14229-1).
A dalej mi pride cely dizajn uplne blby. Komunikacna kniznica by mala byt niekde na spodku a aplikacia by mala byt nad nou. Takto je to strasne tazkopadne, ak by som chcel do komunikacie pridat nieco, na co autor na zaciatku nemyslel. Pritom sa to da aj naopak, bez C++ka a s ovela mensim memory footprintom.
-
Podle mě Arduino má svoje místo, teď jde jen o to, kde je ještě vhodné a kde nikoliv. Má několik zásadních výhod. V první řadě bych to viděl hlavně na integrovaný převodník USB-UART a bootloader, díky čemuž se snadno programuje bez nutnosti vlastnit cokoliv jiného než USB kabel. Pak je výhoda velký ekosystém knihoven (ano, vím, kvalita může být poněkud... různá) a obrovská komunita, co dokáže poradit s vyskytnuvšími se problémy.
Ale jinak souhlasím.
-
Tak zasa no. USB-uart prevodnik je zalezitost max. dvoch eur. Jedina vec, cez ktoru nepojde vlak je ten predprogramovany bootloader. Programator pri ATmege moc zmysel nema, pretoze nim zas tak vela spravit nemozno (M8 nema ani debugwire), ale oplati sa nanho zvyknut si. Na inych procesoroch je to uzitocna vec. Ale USBasp stoji tiez radovo jednotky EUR a pre velkych junkies, co este niekde maju paralelny port, da sa urobit doma uplne z nuly asi za jedno euro.
-
Tak ono je to hlavne o tom ze koupim za 2 dolary desticku pripojim a jedu. Proste ta pocatecny zed je hrozne nizko (temer zadna neni).
Pak IDE ktere vybec neni spatne. Ne neni to na profi praci, je to zase o jednoduchosti kdy si nainstaluji a uz prvni tutorial jede. Par minut a z toho ditete je najednou hacker. Pak uz je to o postupu jak se s tim hraje a pripaji desticky a dela co ho napadne.Kazdy kdo zacne rikat ze je Arduino spatne uz tohle ma za sebou a mel by si vybrat neco profi. Pak kdyz se bude trapit 2 dni s instalaci "neceho" oceni ze tady to slo samo a za cenu velikeho zjednoduseni.
PS: Mne arduino bavi prave pro tu jednoduchost. Na profi veci mame HW oddeleni ktere to udela 100x lepe ale az za 2 mesice.
22. 9. 2021, 12:54 editováno autorem komentáře
-
Ja prave pisem, ze v momente, ked uz som schopny do ruky zobrat pajkovacku, alebo mi prestavaju tak obecne stacit shieldy, je vhodny cas sa na cele Arduino vykaslat. Dalo by sa povedat, ze v momente, ked mu zacne clovek rozumiet, tak ho zacne brzdit.
A ono to trapenie je vacsinou prinosne. Ked proste pichnem Arduino do USBcka a ono to ide, v IDEcku kliknem na jedno tlacidlo a program mam v Arduine, tak je sice fajn, ze to funguje, ale moc som sa nenaucil. To moze byt OK, pokial nieco potrebujem rozpohybovat a nejako velmi netuzim vediet, ako to funguje (napr. umelci, na ktorych bolo Arduino povodne cielene). Na druhu stranu ak stravim dva dni riesenim toho, ze "nieco" nefunguje a nakoniec to rozchodim, tak mi to da viac, nez dva dni stahovania examplov z netu a vytesovania sa nad sebekomplikovanejsim ozivenym shieldom, ktory chodi bez toho aby som napisal jediny riadok zdrojoveho kodu.
Nezacinali sme vsetci takto s Linuxom? Teda aspon ti, co s nim zacinali v 90tkach a kratko po roku 2000?
-
Jan HrachStříbrný podporovatel
> Ja prave pisem, ze v momente, ked uz som schopny do ruky zobrat pajkovacku, je vhodny cas sa na cele Arduino vykaslat.
Já myslím, že pájku dokážu vzít do ruky moc dobře, ale Arduino používám pořád - jednak na bastlení přímo ty desky (typicky nějaké Fakeduino Nano za $2 z Aliexpressu), jednak custom desky typicky dělám tak, že tam plácnu AtMegu328 a v ní mám Arduino SW.
> Ked proste pichnem Arduino do USBcka a ono to ide, v IDEcku kliknem na jedno tlacidlo a program mam v Arduine, tak je sice fajn, ze to funguje, ale moc som sa nenaucil.
Ale kompilátor si taky nepíšeš sám a svoje MCU si nevyrábíš sám z křemíku, byť by ses při tom jistě mnoho naučil. Alespoň já mám typicky cíl někde dál, a rozumět MCU je k tomu samozřejmě důležité, ale není to primární cíl.
Btw. zrovna ta Dallas knihovna je pěkně zákeřná v tom, že requestTemperatures() defaultně blokuje, jenže teploměrům trvá změření teploty asi 800 ms.
-
Nové STM má rovnou v sobě DFU, takže lze rovnou přes dfu-util --device 0483:df11 -a 0 --dfuse-address 0x08000000 -D neco.bin naflashovat. Přitom ten bootlader v ATmega lze asi softwarově zlikvidovat, nevím. Ten v STM ROM vydrží vše. Jasné je, že kromě DFU nabízí každý současný Cortex-M MCU SWD, takže stačí jeden STM kit nebo maličký adaptér SWD_USB, třeba náš http://pikron.com/pages/products/accessories.html , jeho konstrukci jsem již několikrát zdarma nabízel, jestli si ho nechtějí udělat další nebo se lze dohodnout na nějaké hromadnější výrobě, a můžete krokovat přes OpenOCD každou desku a to na úrovni HW. Jak něco takového nabídne historické AVR?
Když již musíte Arduino studio tak je třeba Teensy 4.1, to má druhý malým MCU vyřešený HW loader kompatabilní se studiem. Můžete zkusit to a až zjistíte jak je Adruino omezující, tak si na něm pustit NuttX.
Jinak různé USB a CAN a RS-485 loadery jsme si pro každý náš systém připravili. Jsou od nás ve veřejných GITech... atd. Takže AVR nemá již nic co nabídnout. Jen tu komunitu podobných tápačů ve tmě a pak schopných, kteří kvůli neochotě tápačů jít dále, složitě připravují řešení, jak ze slušných procesorů udělat omezené hračky s tím jediným ne-IDE, které jsou ochotní někteří připustit.
-
Jan HrachStříbrný podporovatel
> Přitom ten bootlader v ATmega lze asi softwarově zlikvidovat, nevím.
Lze, ale velmi složitě (na zápis do flashky jsou speciální instrukce, které se jinde nepoužívají). To DFU v STM zase vyžaduje skočit do něj z tvé aplikace, ne? Takže to můžeš snadno bricknout tak, aby to vyžadovalo fyzický reset. Oproti tomu Ardiuna se resetují (a do bootloaderu se vstupuje) zataháním za RTS linku sériáku.
-
DFU minimálně na L476RE je v ROM od výroby a při přivedení VCC na BOOT0 najede do DFU rovnou po resetu. Takže nevidím jak to zlikvidovat. Otázka je, jak je BOOT0 na různých kitech dostupný. Na HW od Ing. Porazila pro Elektroline se na to myslelo a dělal jsem na to pak další level boot loaderu přes CAN, do které lze vynutit start dalším uživatelským tlačítkem, i když je jednotka v rozvaděči.
-
Jan HrachStříbrný podporovatel
> Otázka je, jak je BOOT0 na různých kitech dostupný.
No ne, na kitech samozřejmě dostupný je (používal jsem jenom čínský BluePill), jde mi ale o to, že to někam daleko dám a pak to bricknu a co pak jako budu dělat. (kamarád se mi vysmál, že se tohle může stát jenom blbci, a že přece do vzdálených zařízení bude nahrávat jenom otestovaný firmware… načež asi za půl roku přesně takhle bricknul při ladění jednoho problému zařízení 250 km daleko)
-
Jan HrachStříbrný podporovatel
Kde jsi vzal tu atmegu32? V článku ani v diskuzi se string "32" vůbec nevyskytuje (kromě "STM32").
> V skutocnosti Arduino neprinasa ziadne zjednodusenie, vsetko co vie arduino sa da dosiahnut inak, ale stale podobne jednoducho.
Tak ukaž jak se vyčte třeba ten Dallas nebo DHT22 „bez arduina“.
> Nejako som nechapal, preco na taku primitivnost, ako meranie jedneho Dallasu treba atmegu32.
Není potřeba, ale rozdíl cenový mezi tímto a nějakým MCU který „stačí“ je asi 10 Kč. To se jednak nevyplatí řešit když se vyrábí pár kusů, a jednak i když se těch pár kusů vyrábí, tak je lepší tam dát tu součástku o 10 Kč dražší, aby až pak přijde další požadavek, se to dalo jednoduše doprogramovat. (Pokud někdo dělá velké série, tak to samozřejmě vidí jinak.)
-
Poziadavka na Arduino Mega je z toho dovodu, ze samotna kniznica toho vie ovela viac ako je toho popisaneho v clanku. Je tam kopec semi-autonomnych zariadeni ako termostat, LCD, ovladanie 3cestneho ventilu apod. Toto vsetko bez potreby zasahu z master-a.
Je to vsak len prva cast clanku, kde ukazujem zaklady ako sa pracuje s kniznicou. V pripade, ze bude zaujem, doplnim dalsie casti, kde rozpisem jednotlive zariadenia. -
Dovod na Mega je ten, ze jednoducho 2k RAM v Arduino Uno je nedostatocne pre podporu komunikacneho rozhrania (buffers, stack) aj na dynamicky alokovane tzv. virtualne zariadenia vnutri v Arduino. Mam tam napr. 10x ovladanie zaluzii, 5x detektor stlacenia tlacidla, 10 teplomerov na jednom Adruine. To vsetko si vyzaduje urcitu RAM.
Skusal som to upravit pre Arduino Uno a dalsim dovodom bola absencia dalsich HW UARTov, cez SW UART mi to neslo. Aj ked si skor myslim, ze to bolo nedostatkom RAM.
Arduino Mega sa da z AliExpresu kupit za par drobnych a mozem, povedat, ze funguju spolahlivo - na domace ucely. Nehovorim o profesionalnom pouziti, kde sa vyzaduju rozne certifikaty a vyhlasenia o zhode. -
Zdravím,
děkuji za zajímavý článek.Domácí automatizaci mám také na deskách Arduino Mega (4x) s Ethernet Shieldama. Pro nahrávání sketchů je mám všechny spojené a napájené v rozvaděči přes powered USB HUB, který je v Raspberry Pi.
Komunikace s RPi v reálu probíhá přes MQTT po Ethernetu.
Používám již 5 rok. Spolehlivost jak Arduina tak RPi je za mně velmi velmi vysoká. Ovládám přes 80 relé včetně všech světel, zásuvkových okruhů, čerpadel atd. Poslední výpadek byl 2 roky zpátky když odešel no-name USB HUB.
Pro ty co mají Arduina daleko a nemají zde LAN pro ethernet shield tak je to zajímavé řešení.
-
A není lepší mít v RS-485 protokolu možnost updatovat aplikace po celém domě na dálku. Prč ty jednotky dávat do rozvaděče, když mohou být přímo tam, kde něco řídí. uLAN na malých MCU umí nejen Flashovat, ale i číst a modifikovat paměť za běhu aplikace přímo z komunikačního přerušení. Takže je možné zanalyzovat na dálku, když se něco zasekne, zresetovat jednotku atd. Tedy když aplikace nezakáže přerušení nebo úplně nerozháže paměť. To vše od dob 8051, kde byla ještě možnost i na dálku aplikaci zastavit a krokovat. To jsem na ARMy zajím nedopsal a nepotřeboval.
-
Článek zrovna asi v blízké době nestíhám, mám ve firmě závazek k ESA a na škole k výuce pokročilých architektur procesorů https://cw.fel.cvut.cz/wiki/courses/b4m35pap/start .
Dostatečný přehledový popis je na stránkách projektu http://ulan.sourceforge.net/ , úvod to těch zajímavých vlastností pro domovní automatizaci je shrnutý v příspěvku na RT Linux Workshop z roku 2011 http://ulan.sourceforge.net/pdf/ulan-pdocochan-rtlws13.pdf , prezentace zde http://ulan.sourceforge.net/pdf/ulan-pdocochan-slides-rtlws13.pdf .
V podstatě dokument, který má status naší interní specifikace protokolu, je překlad odpovídající kapitoly z mé mé diplomové práce (rok 1996, kdy jsem návrh z firmy poskytl jako ladící protokol jednotky řízení motorů autobusů, kterou jsme s kolegy v rámci diplomové práce vyvíjel) http://ulan.sourceforge.net/index.php?page=3 , http://ulan.sourceforge.net/pdf/ul_drv.pdf . Dokument byl postupně rozšířený o novou vrstvu dynamického adresování a těch procesních kanálů pro dopravu procesních dat. V dokumentu jsou popsané jak služby ovladače (shodné pro Linux, NuttX, Windows i sysless - u posledního volané jako funkce z knihovny). Verze s OS umožňují i otevření z více procesů a monitoring toho, co aplikace posílá, případně lokální posílání mezi více aplikacemi. V dokumentu jsou popsané a vyobrazené vývojové diagramy, které se mapují na stavové automaty, které řeší funkce protokolu bez nutnosti blokovat procesor, vše jsou jen odezvy na IRQ, timeout nebo příchod první zprávy do prázdné fronty na odeslání.
Projekt by si k současným 30 letům od dodání prvních přístrojů, které jím komunikovali, zasloužil nějakou oslavu. Plánoval jsem, že bych přivezl různé generace přístrojů a zařízení na LinuxDays (vlastně z vitriny, kde je na ÚOCHB vystavená za odvedené služby naše první sestava, by to také nebylo daleko) a připravil přehledovou přednášku s ukázkou činnosti a zájemcům pak na stánku předvedl více. Ale v online formě to spíš nemá smysl a ani kvelitní video nestíhám připravit, takže se soustředíme na pysimCoder https://github.com/robertobucher/pysimCoder na OpenAltu a na ten weekend zprovoznění pro zájemce i naší laboratoře a konferenčního řešení, kterým jsem zpřístupňoval HW v době lockdownu https://ppisa.rajce.idnes.cz/20210306-InstallFest/ . Půjde si na dálku řídit motory, přehrávat FPGA návrhy, zkusit pysimCoder.
Pokud bude zájem, tak nechám uLAN a oslavu jeho vzniku na InstallFest 2022 nebo LinuxDays 2022 a budu doufat, že již budou naživo.
Pokud by byl nějaký větší zájem o shrnutí na Rootu, tak si to zařadím do fronty. Ale ono to bude spíš příliš ořezané opakování toho, co jsem lépe popsal jinde. Ale třeba se mi podaří napsat nějaký výcuc z jiného úhlu, který může být pro někoho zajímavější.
ČLÁNKY DO MAILU