Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Pontiaq 17. 01. 2018, 23:43:35
-
Zdravím :-)
Rád bych se zeptal zkušenějších ohledně mikrokontrolérů. Mám zkušenosti s řadou 8051 a s jejich programováním v Assembleru. Moc mě MCU zajímá a rád bych se mu co nejvíce věnoval. Jenže nevím, jak bych měl začít. S Arduinem jsem si řekl, že by pro mě bylo lepší spíše samotné MCU, abych se naučil, jak vše funguje samo o sobě. Kterou řadu, propřípadě typ, MCU byste mi poradili? Které mají budoucnost před sebou a vyplatí se s nimi učit? Jak bych mohl vůbec začít? Plánuji pořizovat potřebné věci z Ebaye. Doporučili byste mi nějaké živé a zvlášť založené fórum na mikrokontroléry? Také záleží na finančních možnostech a návodech.
Jak jste začínali vy? Jak jste se odrazili? Rád bych se co nejvíce sám vzdělával. Na čem rádi programujete vy? Živíte se programováním a vývojem s MCU? Na Arduinu mě konkrétně zaujal ESP32 v poměru výkon/cena. Studuji VŠ Elektrotechniku, tedy potřebnými znalostmi bych měl disponovat.
Za každou radu moc děkuji, jen vás prosím, odpusťte si urážky a napadání. Děkuji
PS: Vedu diskuzi na více fórech, aby se někteří nedivili, hledám odpovědi všude možně ;).
-
Nějaký kit s STM32.
-
...Studuji VŠ Elektrotechniku...
Kde a co studuješ a ve kterém ročníku?
IMHO máš štěstí, že jsi přímo u pramene. Nemůžeš se přímo tam zapojit do nějakých aktivit? Když jsem studoval já (to je ale let), zapojil jsem se do studentského vědeckého kroužku (tak se tomu tehdy říkalo) a hodně mi to dalo, dostal jsem se k vědomostem co bych se k nim v normální výuce nedostal ani náhodou. Asi se u vás najde nějaký doktorand co uvítá pomocnou ruku.
-
Chod do arduina (Atmel AVR 8bit). Ma hadam najvacsiu komunitu + obrovsku databazu kniznic. Na zaciatok je to vyborna volba. A ako s nim zacat? Myslim, ze neexistuje jednoduchsi sposob ako:
Arduino Basics 101: Hardware Overview, Fundamental Code Commands (https://www.youtube.com/watch?v=BtLwoNJ6klE)
Arduino Basics 102: Control Structures, Variables, Interrupts (https://www.youtube.com/watch?v=YT3birSKLLU)
Arduino Basics 103: Library, Port Manipulation, Bit Math, Faster PWM/ADC (https://www.youtube.com/watch?v=EVm0qVJ56II)
Electronic Basics #30: Microcontroller (Arduino) Timers (https://www.youtube.com/watch?v=IdL0_ZJ7V2s)
Neskor sa da prejst na Atmel Studio, co je skutocne IDE so simulatorom a debuggerom, ktore dalej podporuje novsie AVR32 mikrokontrolery.
-
Na začátek určitě arduino. je tu velká komunita, plno knihoven a příkladů. z jednoho vývojového prostředí se dají vytvářet projekty pro různé platformy : klasické arduino, tedy 8bit AVR, ARMová arduina (zero a due), nebo zmíněné ESP8266 nebo ESP32.
Jako bonus vývojové prostředí je multiplatformní. nevýhoda editor vývojového prostředí je na ho..o, nemá inteli sense a není tu debug, takže pro větší projekty asi časem skončíš u atmel studia provozovného pod wine.
Na začátek bych se určitě vykašlal na STM32. kitů je málo, komunita malá, příkladů málo, knihovny pro různé senzory si člověk často musí psát/upravovat sám, kity jsou dražší a člověk se tam hodně potrápí se složitým přerušovacím systémem a DMA.
Pokud si na elektro VŠ podívej se jestli nemáte nějaký předmět na mikrokontroléry nebo embeded programování, základní teoretické znalosti jako co je stavový automat se určitě hodí. Na VUT to byl předmět "Mikroprocesorová technika a embedded systémy"
-
Kdysi dávno, cca před dvěma desítkami let, jsem na VUT absolvoval předmět Mikroprocesory (nebo tak nějak :)), který se točil hlavně kolem 8051. Pak jsem se po mnoha letech k MCU vrátil a stavěl si různé bastly právě na 8051 od Atmelu. Postupem času jsem přešel na AVR a teď začínám s ARMy.
Co se týče Arduina, je to dobré pro naučení se základů. Spousta lidí u něj zůstane, ale pro serióznější použití bych ho nedoporučoval, zvlášť, pokud budeš uvažovat o náročnějších aplikacích. Pro důvod mrkni třeba na https://www.youtube.com/watch?v=648Tx5N9Zoc (https://www.youtube.com/watch?v=648Tx5N9Zoc)
Co se týče Atmel studia, osobně s ním mám velmi špatné zkušenosti, konkrétně pro procesor ATmega644P nebylo schopné vygenerovat funkční kód. Problém byl se špatně generovanými skoky, program skákal ne na definovaná místa, ale náhodně někam do kódu. Po několikadenním trápení se s hledáním chyby a prolézání diskusí jsem našel podobně postižené jedince, kteří bug reportovali před několika lety a ten nebyl dosud opraven. Řešením pak byl přechod na jiné (placené) IDE.
Budu nesouhlasit s jedním, z předřečníků, že pro STM32 je málo kitů a jsou drahé.
Pro základní seznámení (a i spoustu aplikací) Ti vystačí https://www.aliexpress.com/item/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module/32656040083.html (https://www.aliexpress.com/item/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module/32656040083.html) za necelé $2, ze kterého jsi schopen si postavit i nástroj pro debuggování v aplikaci viz. https://github.com/blacksphere/blackmagic/wiki (https://github.com/blacksphere/blackmagic/wiki)
Dál nesouhlasím s tím, že se musíš trápit s přerušovacím systémem a DMA. Nemusíš, zdrojů je dost :)
Já osobně mám objednaný kit http://cz.farnell.com/stmicroelectronics/stm32f429i-disc1/dev-board-advanced-line-mcu/dp/2506924?CMP=i-ddd7-00001003 (http://cz.farnell.com/stmicroelectronics/stm32f429i-disc1/dev-board-advanced-line-mcu/dp/2506924?CMP=i-ddd7-00001003) protože si chci pohrát s rozhraním pro kameru a displej. Cena je včetně dopravy 937,- Kč. Nemyslím, že je to nějak strašné.
A úplně obecně si chci postesknout, že všude v tutoriálech se používá funkce delay, která na určitý čas prostě zastaví procesor. Nikde ale není naznačeno, že se to dá dělat i jinak, a že můžeš pseudoparalelně komunikovat třeba po sériové lince, provádět měření na převodnících, refreshovat display, komunikovat s pamětí a cojávím co ještě.
-
Ramirez - zkus se mrknout na chibios, vyvíjí jej chlápek, který dělá přímo pro ST v Itálii, a STM32 má v tom "OS" vynikající podporu.
-
Ahoj,
studuji též VŠ elektro, můj obor se ale zabývá konkrétně MCU i když klasické analogové elektrotechniky je tu i tak až až.
Na začátek bych si asi ujasnil co chci dělat. Chci si hrát? Nebo se tím chci živit? Pokud bych se tím chtěl živit šel bych jednoznačně do STM32. Když se podíváš různě po nabídkách práce embedded sw tak je to většinou právě STM32. Pokud hrát tak asi komunita kolem Arduina bude fajn, i když i kolem STM32 se motá taky spousta nadšenců a myslím si že lidem kteří rádi vidí více do HW bude spíše vyhovovat to STM32.
Další zajímavá cesta může být FPGA + softcore CPU, tam už ale většinou může jeden zapomenout na open source no. Možnosti jsou pak ale skoro nekonečné.
Co se týká nějakých kitů pro STM32. Tak na ebay se válí děsná hromada extrémně levných kitíků s STM32F103 ... to může prozatím stačit, ale asi bude potřeba nějaký programátor přihodit. Nebo pak discovery kity přímo od ST. Jsou fajn, je na nich úplně všechno potřebné a taky nestojí svět.
-
Které mají budoucnost před sebou a vyplatí se s nimi učit?
ARM, protože za stejnou cenu dostaneš podstatně výkonnější hardware (výkon jádra, paměť, množství periferií i jejich rychlost, např. Hi-Speed USB). Jenže ten je na rozdíl od Arduina nebo AVRek obecně prostě komplikovanější (jednak je to složitější architektura, jednak nevím o existenci nějakých knihoven a návodů pro lamy jako je kolem Arduina/AVR. Existují porty Arduina na některé ARMy, ale většinou je to nedotažené).
(+ pokud si koupíš jakoukoli populární periferii, většinou k tomu je driver právě počítající s Arduinem)
Jak jste začínali vy? Jak jste se odrazili? Rád bych se co nejvíce sám vzdělával. Na čem rádi programujete vy? Živíte se programováním a vývojem s MCU?
Začal jsem před 7 lety s Arduinem, mikrokontroléry se zabývám spíš okrajově, a měl jsem několik komerčních zakázek na AVRkách s Arduinem, LUFA i surovým Cčkem bez ničeho (custom bootloader, žádné knihovny se tam nevešly; totéž bych udělal pro nějakou aplikaci s kritickým časováním, jak píše Ramirez).
Pozn. Arduinem ve svém příspěvku nemyslím to „IDE“ ani ty předražené desky, ale ty knihovny pro abstrakci hardwaru.
-
Zdar,
záleží co chceš přesně dělat. Ale pokud jen tak na doma, tak bych spíš doporučil nějaký atmel. Konrétní typ si vyber podle toho co potřebuješ, aby mcu měl a uměl (počet UARTu, timeru, přerušení, AD převodníků, počet IO apod.). Programování je pak pořád stejný.
Arduino není nic jinýho než nějaký atmel, který má jen zavedený bootloader, aby šel programovat přes sériovou linku (na desce je před ním jen převodník USB - UART). Takže klidně si kup klon arduina za 200 a nemusíš dělat obvod na nepájivým poli. Stáhni si atmel studio a můžeš začít.
Arduino je jen v podstate sada knihoven, ktera toho ma spoustu nachystanyho. Programovat v atmel studiu se muze i tak jak v IDE arduina (pri vytvoreni projektu nastavis, ze se jenda o arduino).
Arduino je dobry jako deska, pro vyvoj a pak na finalni produkt si udelas svoji desku a program do ni nahrajes.
-
A pokud to chces presne pochopit, tak urcite nedoporucuji jak nekdo psal zacit Arduinem (nemyslim desku, ale jejich IDE a vsechny knihovny). Pokud zacnes solo projektem v C/C++, tak sam zjistis, jak je co provazany, protoze musis vedet k cemu jsou jaky registry pro nastaveni veci.
-
Jak uz tu psali prede mnou - vymysli si nejakou ulohu a pak muzes premyslet, z ceho to udelat.
A Arduinu bych se nebranil. Sice jsou ke vsemu knihovny, ale stejne je lepsi si nejdriv precist nejakou dokumentaci a projit zdrojak dane knihovny, at vis, co to dela a proc to nedela, co chces ty, aby to delalo. Protoze, co si budeme povidat, spousta tech knihoven je fakt strasnych a nekdy mi z nejake knihovny staci vzit jenom jednu funkci a jeste si ji priohnout. Aspon je z ceho vybirat a nezacinas z nuly.
-
Ked mas skusenost s x51, tak by som doporucoval ist do STM32. Su omnoho vykonnejsie, a aj komplikovanejsie proti x51, takze nudit sa nebudes. Discovery kity od STM zacinaju okolo 10 Eur, a je tam vsetko co treba. Staci si vybrat. Najlepsie STM32F0xx alebo STM32F1xx na zaciatok. Navodov je na nete plno aj v cz (vecsinou prave na STM32F103). Okrem toho napr. na mcu.cz alebo mikrozone.sk, je vzdy zopar ludi co s STM32 robia. Isto, "komunita" nie je tak siroka ako u arduina, ale zase ti ludia vecsinou vedia co robia, a nelepia len kniznice ako pride ;)
-
Ak ste už začali s assemblerom, ani ja by som nešiel opačným smerom (k spomínanému Arduinu a v tutoriáloch obľúbenej funkcii delay, ako tu niekto spomínal). Namiesto toho odporúčam pozrieť si napríklad jeden z kurzov na University of Texas na edX - naučíte sa ovládať periférie (písať jednoduché ovládače), pracovať s prerušeniami, používať semafory apod. Kedysi tu vyšiel na blogu článok o jednom z nich https://blog.root.cz/lubomirpatek/podte-sa-naucit-programovat-mikroradice-arm/
Trocha nevýhodou je, že v kurze používajú dosku s procesorom ARM od Texas Instruments, ale ak to myslíte vážne, cena s poštovným okolo 20 $ by nemala byť až takým problémom.
Odvtedy kurz trocha pozmenili (rozdelili ho na dve časti) a pribudol ďalší diel ktorý sa zameriava na programovanie v reálnom čase (s RTOS) - ale aj tam sa počíta s ďalšou doskou či dokonca dvoma.
Kurz je zdarma a tak si ho môžete pozrieť aj bez dosky, ale bez nej sa nedajú robiť testy (aspoň v minulosti to tak bolo). Platí sa len ak by ste chceli aj certifikát, ale jeho význam sa mi zdá prakticky nulový.
Kurzy nájdete tu:
https://www.edx.org/school/utaustinx
Dnes sú už všetky tri kurzy "self-paced", takže nemusíte čakať na termín. Nenechajte sa odradiť tak trocha neprirodzeným prejavom prednášajúcich ani nie vždy najlepšie editovaným učebným textom (bol to viac-menej len text bez grafickej úpravy - ide o text z učebníc vydaných autorom kurzu) - kurz je inak dobre štrukturovaný a postupuje celkom systematicky.
-
Existuje (na linuxu) nějaký emulátor Arduina?
-
Existuje (na linuxu) nějaký emulátor Arduina?
Vážně ti to za těch 70 Kč https://www.aliexpress.com/item/NEW-UNO-R3-ATmega328P-CH340-Mini-USB-Board-for-Compatible-Arduino-Hot-sale/32374958769.html nebo 45 Kč https://www.aliexpress.com/item/Mini-USB-CH340-Nano-3-0-ATmega328P-Controller-Board-Compatible-For-Arduino-Nano-CH340-USB-Driver/32828813070.html stojí se matlat s emulátorem? Stejně potřebuješ periférie.
-
Jestli puvodni tazatel umi asm i8051, doporucil bych nejaky jednoduchy MCU, treba i to Arduino (a k tomu si koupit avr-isp a z Linuxu to programovat normalne gcc-ckem z commandline, zkouset i assembler).
Vetsi procesory typu STM32 (SAM7/PIC32, apod.) jsou samozrejme taky zajimave kdyz odber nehraje roli, ale je tam casto daleko vetsi problem rozchodit slozitejsi periferie tak, aby se skutecne chovaly jak maji. Uz jenom proto, ze procesor a periferie maji casto shodne hodiny a tak se da snadno na osciloskopu triggerovat, coz je u toho ARM/MIPSe casto nemozne.
-
Existuje (na linuxu) nějaký emulátor Arduina?
Vážně ti to za těch 70 Kč https://www.aliexpress.com/item/NEW-UNO-R3-ATmega328P-CH340-Mini-USB-Board-for-Compatible-Arduino-Hot-sale/32374958769.html nebo 45 Kč https://www.aliexpress.com/item/Mini-USB-CH340-Nano-3-0-ATmega328P-Controller-Board-Compatible-For-Arduino-Nano-CH340-USB-Driver/32828813070.html stojí se matlat s emulátorem? Stejně potřebuješ periférie.
Emulator byl (je) dobry kdyz clovek potrebuje zjistit jak neco funguje. Jsou myslim 3 typy embedded vyvojaru:
- ti co se nehnou bez debuggeru a emulatoru (vetsinou zacatecnici)
- ti co se bez debuggeru nehnou
- ti co debugger temer nepouzivaji a debuguji pres I/O piny ci nejaky seriovy port
A pak je virtualni skupina (do ktere se rozhodne neradim) ktera i slozite veci oddebuguje v hlave.
-
Nejčastěji je ale potřebovat sledovat celý systém i s perifériemi a s tím emulátor pouze MCU stejně moc nepomůže.
-
Moc děkuji za vaše odpovědi. Rád bych se zaměřil na dělání vlastních projektů, avšak s tím, že bych to jednoznačně mohl využít v budoucím zaměstnání. Takže mi jde hlavně o to, abych svůj čas využil co nejefektivněji a právě výběr MCU je pro mě podstatný. Kdyby se našli zakázky atd. a zajímavá a dobře placená práce na zajímavých projektech. Co se většinou požaduje? Jak je to se Siemens společností?
-
Tento kit s MCU mě zaujal. Co si o tom myslíte? https://os.mbed.com/platforms/KL25Z/
-
Tento kit s MCU mě zaujal. Co si o tom myslíte? https://os.mbed.com/platforms/KL25Z/
je to CORTEX-M0
u farnella cca 370,- bez DPH a dopravy
u conrada cca 330,- bez DPH a bez dopravy
V prvnim mem postu jsem ti linkoval CORTEX-M3 za 2 dolary od Číňana vcetne dopravy (ale počkáš si :) ).
Nebo tady mas CORTEX-M4 za podobnou cenu, jako je ten kit, co o nem uvazujes:
http://cz.farnell.com/stmicroelectronics/nucleo-f401re/nucleo-board-mcu/dp/2394223 (http://cz.farnell.com/stmicroelectronics/nucleo-f401re/nucleo-board-mcu/dp/2394223)
http://cz.farnell.com/stmicroelectronics/nucleo-f411re/dev-board-cortex-m4-mcu/dp/2433469 (http://cz.farnell.com/stmicroelectronics/nucleo-f411re/dev-board-cortex-m4-mcu/dp/2433469)
http://cz.farnell.com/stmicroelectronics/nucleo-l476rg/dev-board-arduino-mbed-nucleo/dp/2493816 (http://cz.farnell.com/stmicroelectronics/nucleo-l476rg/dev-board-arduino-mbed-nucleo/dp/2493816)
-
Která verze je ale lepší?
-
Najde se nějaký tutorial, co by usnadnilo studium Cortex-M4? ;)
-
Myslím, že jakékoliv ARMy nejsou vhodné jako další stupeň pro někoho, kdo dělal v ASM s 8051.
Opravdu jako mezistupeň doporučuji spíš nějakou desku ala Arduino a naučit se programovat to v GCC.
Výhodou je, že funkci HW ( čidla, akční členy ), lze většinou ověřit pomocí nějakého hotového příkladu v Arduinu a pak si to zkusit napsat v GCC. Nebudete pak současně zápasit s HW a konfiguarcí periferií processoru, rozchozením programátoru ( využijete bootloader Arduina ) atd.
Na těch jednoduchých Atmelech lze pochopit filozofii ovládání periferií atd.
U ARMů je to většinou schované v nějakých knihovnách ( a i tak je nastavení funkce pinu třeba na 10 řádků kódu )
a v přístupu k HW procesoru tam z hlediska programátora nevidím oproti Arduinu zas takový vzdělávací rozdíl.
Jinak místo Atmel Studia používám spíš WinAVR, má i simulátor, kde je pěkně vidět co se děje s příslušnými registry, jak dlouho konkrétní část kódu trvá atd.
Další málo známý hezký free simulátor je pak součástí vývojového prostředí VMLAB zde:
http://www.amctools.com/ (http://www.amctools.com/)
Lze tam nadefinovat i jednoduché zapojení periferních součástek a připojovat virtuální osciloskop, voltmetr atd.
Bohužel nemá novější procesory, končí myslím u ATmega168.
Ale je to pro Windows, tak přes VirtualBox...
( Byť je tam i sekce věnovaná provozování a konfiguraci ve spojení s WINE )
-
Co sa tyka devboardov tak skus:
https://www.olimex.com/
-
Ja bych se byt vami zcela vybodnul na nejake "zapadni" devkity. Skocte na ebay, najdete par prodejcu ruznych arduino ci st32 desticek, vzal bych k tomu i nejaky plnohodnotny velky ARM typu RPI, proste tak 10 desek. K tomu 3-4 ruzne displaye at' je vyvoj zabavnejsi (pozor, neplati, ze cim jednodussi display, tim levnejsi - 0.96" mono OLED muze stat stejne jako 2.4" 65k TFT).
A k tomu nejake programatory na ty desky. Cele to bude stat nejakou desitku dolaru. Udelate si nove vanoce, pak se rozhodnete, postupne bych si vsechno osahal. Dorazi to docela rychle, 14-30 dnu, a to se da vydrzet.
-
Pridal bych se k doporuceni STM32. Pokud se planujes zivit v teto oblasti, zacinat s Arduinem mi prijde jako ztrata casu. Ze zacatku te rozdil mezi Cortex-M0+/M0/M3/M4/M7 atd. nemusi moc zajimat (zjednodusene receno, M0/M0+ maji osekanou instrukcni sadu a casto osekane/jednodussi periferie)..
Ackoli chapu, ze tvuj dotaz je zamereny na mikrokontrolery (bez MMU), z hlediska zamestnani bych doporucoval se co nejdrive zamerit na Cortexy-A (Raspberry Pi atd.).
-
Ahoj,
kdybych se nacházel na tvém místě s tvými zkušenostmi, tak bych se určitě vybodnul na Arduina a podobné destičky a skočil rovnou po ARMu. Pro seznámení a úvodní zápolení poslouží některý ze řady ARM Cortex-M0+, které se často doporučují jako náhrada levných 8 bitů. I když se člověk na první pohled zděsí deklarované větší složitosti, po krátkém laborování zjistí, že na nich vlastně nic složitého není.
Mně kdysi výborně posloužila, již zde jmenovaná, destička FRDM-KL25Z od bývalého Freescale, dneska NXP. Sice stojí poněkud více, ale koho dneska zabijí tři, čtyři stovky, že? Pokud bys chtěl používat k vývoji IDE a ne hned na začátku bojovat s gcc, make, dbg v shellu, tak výrobce nabízí zadarmo prostředí MCUXpresso s navázaným ekosystémem. Další možnost pak představuje poskládání si svého toolchainu na aktuálním releasu Eclipse.... :-)
Na netu je ohledně této destičky k nalezení hafo odkazů, na prvním místě bych si dovolil uvést tento: www.mcuoneclipse.com
Zde nalezneš takřka všechno ;-)
Za zmínku stojí i projekt mbed.org, pokud ho tu již někdo neuváděl.
-
Pridal bych se k doporuceni STM32.
STM má fajn čipy, ale ta driver knihovna je děsná. Mnohem víc se mi líbí co poskytují výrobci k Energy Micro EFM32 (mají to dokonce na GitHubu) nebo třeba TI Tiva C.
Ze zacatku te rozdil mezi Cortex-M0+/M0/M3/M4/M7 atd. nemusi moc zajimat (zjednodusene receno, M0/M0+ maji osekanou instrukcni sadu a casto osekane/jednodussi periferie)..
Naprosto souhlasím. Cortex M0+ je pro začátky úplně v pohodě a přejít výš už pak není problém.
-
Ja dělal s Arduinem takové malé věci. Vcelku mě tohle odvětví fascinuje, totiž, na co to jako je? Ten HW už je tak levný, že nechápu, proč na nějaký monolit raději nenasadit nějaký rtos a neprogramovat normálně v C++? Proč se štvát s assemblerem, řešit přerušení, dma atd., nedostatek knihoven, neustálé vynalézání kola psaním něčeho, co už existuje 100x.
-
chápu, že třeba mirkovlnka nebo řj v autě to potřebuje, nebude se tam přece pokaždé starovat os, ale jak často se dostanete k takové práci v ČR? Mikrovlnku stejně naprogramuje Číňan a v automotive stejně nepíšou kód ručně, ale generují ho ze schémat, co jsem tak slyšel.
-
Pridal bych se k doporuceni STM32.
STM má fajn čipy, ale ta driver knihovna je děsná. Mnohem víc se mi líbí co poskytují výrobci k Energy Micro EFM32 (mají to dokonce na GitHubu) nebo třeba TI Tiva C.
Souhlasim. I kdyz EFM32 kity jsou o trosku drazsi, tak enablement a dokumentaci maji oproti ST nebo NXP(Kinetis) lepsi. Jen nevim, jak jsou na tom s nejakou komunitou, navody atd. S knihovnami pro TI Tiva C bohuzel nemam zkusenosti.
-
Ten HW už je tak levný, že nechápu, proč na nějaký monolit raději nenasadit nějaký rtos a neprogramovat normálně v C++? Proč se štvát s assemblerem, řešit přerušení, dma atd., nedostatek knihoven, neustálé vynalézání kola psaním něčeho, co už existuje 100x.
Čo má spoločné RTOS s problémami s prerušením, DMA a knižnicami ? RTOS je na MCU vačšinou len plánovač úloh, semafory, mailboxy, sw časovcče atd. Bez kvalitnych knizníc (bud vlastnych alebo cudzich) na ovladanie HW sa aj tak dalej nepohneš, a je jedno či tam bude alebo nebude RTOS.
Ono existuje nejaký MCU kde nie je problém s knižnicami ?
Použitie prerušení a DMA je elegantny sposob ako sa vyhnut pouzitiu RTOS (ktorý vie vytvorit dalsie problémy navyše).
Dnes je velka moda stavat rozne lacne low power pseudo IOT senzory ktore by mali vydržať 5-10 rokov na jednu bateriu. Aj v ramci lacneho hw možno najsť ešte lacnejši mcu. Pri 1000ks serii aj procak lacnejsi o 0,1€ už spravi 100€ rozdiel. Tam je potrebne vyuzit ten hw na maximum.
Analogoiu može byt operak LM358 - je stary ale pomaly najlacnejsi. Je vela modernejších, low power, rail to rail operakov parametrovo podobnych, ale cenovo drahsích ako LM358, tak pokial to fakt nie je nutne, tak sa stale pouzivaju "klasiky" za minimalnu cenu.
-
Dokonce jsem našel nějaké tutorialy právě na KL25Z: https://www.youtube.com/watch?v=BAzKg3vcB88&list=PLWy-YwxbAu8FDpD2saP1p6IFHgvbzODyc. Což rozhodně usnadní studium.
-
Tiez sa priklanam ist cestou ARM ak sa tomu chces vazne venovat. Zacinat s aurduino platformou je super pre tych ktory, vedia aspon ako tak programovat, do elektroniky sa nevyznaju, s pajkovacou si nerozumeju a nemaju ani ambiciu ist tymto smerom. Ja ho pouzivam na male hobby projekty pre znamich, "hranie sa", velmi urychluje vyvoj vdaka knizniciam skoro na vsetko. No pocul som aj o firmach ktore v nom robia komercne veci. Viem si to predstavit iba v malej casti projektov.
Pred 10r som zacinal s ASM na AVR, potom C. Na arduine ma velmi irituje nemoznost vidiet obsah registrov, priamo v procesore krokovat program... mozem sa len domnievat ze procesor... robi to co po nom chcem. HW debug je super pomocka aj pri uceni sa, da sa rychlo overit co kod robi s procesorom.
Ako tu uz niekto spominal s AVR studiom (verzia 7) mam aj ja zlu skusenost, "pokazil" sa mi pri nej AVR Dragon (50eur) pri ladeni cez DebugWire, stale to mrzlo, vypadavalo, az po zopar "tvrdych" restartoch ho uz AVR studio nevie najst. Super to fungovalo este na asi 10 rocnej verzii 4, no editor nic moc.
Nastavit periferie pri ARM STM32 v porovnani s AVR je ovela zlozitejsie, treba si zvyknut na iny pristup, avsak ani tie niesu dokonale, na diskusiach sa riesi vela bugov, hlavne STM kniznice... Ale aj napriek tomu by som "vaznejsi projet" robil na nich.
Pre blikanie LEDkou a pochopenie ako to funguje odporucam Cortex M0, ma ovela jednoduchsie periferie ako M3, je najviac "AVR friendly" npr https://www.ebay.com/itm/1PCS-STM32F030F4P6-ARM-CORTEX-M0-Core-Minimum-System-Dev-Board-for-Arduino/182216811895?epid=556113683&hash=item2a6cf7e577:g:aDAAAOSwSv1Xkte~
Ako programator debbuger pouzit toto: https://www.ebay.com/itm/ST-Link-V2-Programming-Unit-mini-STM8-STM32-Emulator-Downloader-M89/262670560884?hash=item3d2862ae74:g:a7YAAOSwmLlX~hMO
Procesory STM32 su uz lacnejsie ako AVR a nahrava im aj nedavne uvolnenie vyvojoveho prostredia Attolic TrueSTUDIO v PRO verzii bez obmedzeni. http://blog.atollic.com/truestudio-for-stm32-9-released
Co ponukaju iny vyrobcovia ARM procesorov, netusim...
-
Ten HW už je tak levný, že nechápu, proč na nějaký monolit raději nenasadit nějaký rtos a neprogramovat normálně v C++? Proč se štvát s assemblerem, řešit přerušení, dma atd., nedostatek knihoven, neustálé vynalézání kola psaním něčeho, co už existuje 100x.
Čo má spoločné RTOS s problémami s prerušením, DMA a knižnicami ? RTOS je na MCU vačšinou len plánovač úloh, semafory, mailboxy, sw časovcče atd. Bez kvalitnych knizníc (bud vlastnych alebo cudzich) na ovladanie HW sa aj tak dalej nepohneš, a je jedno či tam bude alebo nebude RTOS.
Ono existuje nejaký MCU kde nie je problém s knižnicami ?
Použitie prerušení a DMA je elegantny sposob ako sa vyhnut pouzitiu RTOS (ktorý vie vytvorit dalsie problémy navyše).
Dnes je velka moda stavat rozne lacne low power pseudo IOT senzory ktore by mali vydržať 5-10 rokov na jednu bateriu. Aj v ramci lacneho hw možno najsť ešte lacnejši mcu. Pri 1000ks serii aj procak lacnejsi o 0,1€ už spravi 100€ rozdiel. Tam je potrebne vyuzit ten hw na maximum.
Analogoiu može byt operak LM358 - je stary ale pomaly najlacnejsi. Je vela modernejších, low power, rail to rail operakov parametrovo podobnych, ale cenovo drahsích ako LM358, tak pokial to fakt nie je nutne, tak sa stale pouzivaju "klasiky" za minimalnu cenu.
No tak vzdyt o ty knihovny jde. Resi se tady, jaky procesor low level programovat. Vzdyt nejvetsi mnozstvi knihoven bude stejne napsanych v C, Ty si treba budes hrat s njakym ARM procesorem, ale co udelas, az budes potrebovat zpracovavat treba obraz z kamery, nebo posilat nejake data po LAN nebo pres WiFi? Na Arduinu to udelas, protoze je tam velka komunita a knihovny jsou, ale co treba ty dalsi monolity, ktere tu uvadite? Co kdyz budes potrebovat zalozit na tom monolitu i nějaký malý server, který bude moct reagovat na okolí. Fakt by me zajimalo, co se tady u nas v CR v prumyslu realne na tech mikroporcesorech dela, kdes najdes uplatneni, kdyz umims programovat ARM.
-
No tak vzdyt o ty knihovny jde. Resi se tady, jaky procesor low level programovat. Vzdyt nejvetsi mnozstvi knihoven bude stejne napsanych v C, Ty si treba budes hrat s njakym ARM procesorem, ale co udelas, az budes potrebovat zpracovavat treba obraz z kamery, nebo posilat nejake data po LAN nebo pres WiFi? Na Arduinu to udelas, protoze je tam velka komunita a knihovny jsou, ale co treba ty dalsi monolity, ktere tu uvadite? Co kdyz budes potrebovat zalozit na tom monolitu i nějaký malý server, který bude moct reagovat na okolí. Fakt by me zajimalo, co se tady u nas v CR v prumyslu realne na tech mikroporcesorech dela, kdes najdes uplatneni, kdyz umims programovat ARM.
[/quote
Presne tohle je prede mnou. Zpravovat obraz z kamery, zvuk z mikrofonu, zkomprimovat je, poslat streamem pryc a na druhe strane ho dekomprimovat, zobrazit na LCD a poslat do repraku.
A jak to udelam? Vezmu si datasheety k procesorum, ke kamere, k LCD a dalsim periferiim, ktere k tomu budu potrebovat, nastuduju si je a napisu si to kompletne sam. A proc? Protoze ty knihovny, co jsou ke kamere, LCD atd. dostupne pro arduino jsou sice fajn, ale nikdy nemas jistotu, ze budou delat to, co potrebujes, ve vsech situacich. A to si proste v produkcni verzi nemuzes dovolit.
-
No tak vzdyt o ty knihovny jde. Resi se tady, jaky procesor low level programovat. Vzdyt nejvetsi mnozstvi knihoven bude stejne napsanych v C, Ty si treba budes hrat s njakym ARM procesorem, ale co udelas, az budes potrebovat zpracovavat treba obraz z kamery, nebo posilat nejake data po LAN nebo pres WiFi? Na Arduinu to udelas, protoze je tam velka komunita a knihovny jsou, ale co treba ty dalsi monolity, ktere tu uvadite? Co kdyz budes potrebovat zalozit na tom monolitu i nějaký malý server, který bude moct reagovat na okolí. Fakt by me zajimalo, co se tady u nas v CR v prumyslu realne na tech mikroporcesorech dela, kdes najdes uplatneni, kdyz umims programovat ARM.
Presne tohle je prede mnou. Zpravovat obraz z kamery, zvuk z mikrofonu, zkomprimovat je, poslat streamem pryc a na druhe strane ho dekomprimovat, zobrazit na LCD a poslat do repraku.
A jak to udelam? Vezmu si datasheety k procesorum, ke kamere, k LCD a dalsim periferiim, ktere k tomu budu potrebovat, nastuduju si je a napisu si to kompletne sam. A proc? Protoze ty knihovny, co jsou ke kamere, LCD atd. dostupne pro arduino jsou sice fajn, ale nikdy nemas jistotu, ze budou delat to, co potrebujes, ve vsech situacich. A to si proste v produkcni verzi nemuzes dovolit.
-
Prijde mi, ze spousta diskuteru typu "vybodni se na XXX a delej YYY" zije v zaujeti sve technicke bubliny. Jinymi slovy, nikdy jsem nedelal aplikaci vylozene vhodnou pro YYY, zato jsem delal jen pro XXX, tak vidim jen XXX. A ono je treba jeste ZZZ.
Existuje spousta typu problemu a jejich reseni.
- Ultra low cost a casto i low power MCU: ruzne blbosti typu dalkove ovladace, ovladani mikrovlnky, atd. Do tohoto segmentu se casto profiluji ruzna FPGA typu Lattice iCE40 a neni k nim potreba MCU. Priklad: vetsinou jen development kity.
- Slozitejsi MCU/SoC typu vetsi AVRka/PICy nebo male ARMy/MIPSy/TriCore/PPC/apod: na slozitejsi a vypocetne narocnejsi aplikace, kde je stale ale nutny primy pristup na hardware v realtimove urovni (rizeni motoru, ruzne senzory). Priklad: Arduino
- "Velke procesory" s MMU a milionem periferii, na kterych bezi nejaky plnohodnotny OS, ktery zase prinasi vyhodu snadne konektivity, hromady hotovych veci, jednoduche debugovani, apod. Priklad: RPi,vsechny ty xxxPi.
Pokud bych teprve sel do oboru (od "nuly"), zabyval bych se uplne vsim a zacal bych zrejme prostredni kategorii. Ta ma dostatecne nizkourovnovy pristup, ale clovek neni pohlcen slozitosti tech velkych systemu. Na druhou stranu neni omezeni tech uplne malych, kde clovek zapasi s kde cim (malo pameti, malo periferii, dlouhy takt,atd.)
-
je to jak pise mhi_, jen trosku doplnim, ze v mezere mezi AVR/PICy na jedne strane a 32bitovymi masinami ARM/MIPS/TriCore na strane druhe je cely ekosystem 16bitovych MCU, napriklad velmi elegantni MSP 430. Je to tusim prvni MCU teto kategorie, na ktery portovali Rust, takze to otvira dalsi zajimave moznosti do budoucna.
I ten assembler na MSP 430 se da naucit, oproti 8051 je to sranda.
-
Zde bych si dovolil nesouhlasit. Autor tohoto vlákna se ptal, jak a s čím začít v oblasti MCU. Nevidím tedy důvod mu motat hlavu výčtem možných řešení (včetně těch bez MCU) a různými existujícími architekturami specifickými pro jednoho výrobce nebo takovými, se kterými se pravděpodobně už v praxi ani nesetká.. a pokud setká, tak mi nepříjde vhodné s nimi začínat..
Mainstream je dnes z pohledu jader (v general purpose oblasti) !podle mě! ARM Cortex-M nebo Cortex-A (pro ty větší SoCs). Navíc existuje spousta "oficiálních" vývojových kitů za pár stovek i s debugerem na desce, takže stačí jen zapojit do USB a už lze zkoušet blikat ledkou.
FRDM-KL25z určitě není špatná volba.
Ještě bych doporučil tuhle sérii: https://youtu.be/3V9eqvkMzHA (https://youtu.be/3V9eqvkMzHA). I když je pro jinou desku a čip, většina věcí se dá zobecnit.
-
Zopakoval bych svuj post o 3 vyse, vidite dle meho nazoru jen to svoje pole pusobnosti. Udelejte s Cortex-M neco na baterku ... neni to moc prakticke. Stejne tak vzit ARMa a chtit po nem nejake presne casove synchronizovane ovladani (takovy bit-bang, napr. proti nejakemu FPGA/CPLD). Vetsina ARMu co znam maji GPIO hodinove oddelene od jadra, navic nemate definovanou latenci. Treba s dsPIC24 nebrani nic clockovat data ven na 40MHz x 16bit. Nebo pouziti v zarusenem prostredi (potrebujete "humpolacky" MCU). Prikladu by slo napsat desitky. Podle me je tech oblasti kde se vyplati jine veci nez ARM hromada.
Je samozrejme mozne, ze za par let bude cena a proudovy odber ARM MCU bezicich na stovkach MHz tak nizka/nizky, ze zaniknou vsechny ty AVR/PIC18/dsPIC/MSP430 apod., ale zatim to tak neni. A ja osobne o tom dost pochybuju.
-
Zde bych si dovolil nesouhlasit. Autor tohoto vlákna se ptal, jak a s čím začít v oblasti MCU. Nevidím tedy důvod mu motat hlavu výčtem možných řešení (včetně těch bez MCU) a různými existujícími architekturami specifickými pro jednoho výrobce nebo takovými, se kterými se pravděpodobně už v praxi ani nesetká.. a pokud setká, tak mi nepříjde vhodné s nimi začínat..
Bez orientace v oboru bude tazatel v praxi stejně nepoužitelný, takže to lze chápat i tak, že chce získat celkový přehled a sám se rozhodnout, na co se zaměřit. Podle mě je ten trh dost jasně segmentovaný podle požadavků na složitost, výkon a spotřebu zařízení. Do IOT nicméně odhaduju spadají asi všechny stupně (jednoduchá čidla na periférii vs. složitější řídící jednotka v centru), takže bych tipoval, že bude toho muset umět vícero.
-
Zopakoval bych svuj post o 3 vyse, vidite dle meho nazoru jen to svoje pole pusobnosti. Udelejte s Cortex-M neco na baterku ... neni to moc prakticke. Stejne tak vzit ARMa a chtit po nem nejake presne casove synchronizovane ovladani (takovy bit-bang, napr. proti nejakemu FPGA/CPLD). Vetsina ARMu co znam maji GPIO hodinove oddelene od jadra, navic nemate definovanou latenci. Treba s dsPIC24 nebrani nic clockovat data ven na 40MHz x 16bit. Nebo pouziti v zarusenem prostredi (potrebujete "humpolacky" MCU). Prikladu by slo napsat desitky. Podle me je tech oblasti kde se vyplati jine veci nez ARM hromada.
Je samozrejme mozne, ze za par let bude cena a proudovy odber ARM MCU bezicich na stovkach MHz tak nizka/nizky, ze zaniknou vsechny ty AVR/PIC18/dsPIC/MSP430 apod., ale zatim to tak neni. A ja osobne o tom dost pochybuju.
Já jsem spíše nechtěl rozebírat tohle téma v tomto vláknu, protože to tazateli podle mě nijak nepomůže.
Jen rychle zareaguji. Výrobky na baterku s Cortex-M je spousta a je to dnes už běžná praxe. Například výše zmíněné chipy od SiliconLabs (ale nejen ty) jsou velmi úsporné, Cortex-M0+ tuplem. Zmiňujete stovky MHz, ale přeci frekvenci jádra můžete snadno snížit a dostanete se na úroveň desítek MHz s velmi nízkou spotřebou. Navíc pokud to bude možné, tak v reálné aplikaci bude jádro většinu času uspané. Zbytek, a to včetně přesné časové synchronizace a dalšího odběru, už zavisí na konkrétním MCU a jeho periferiích, jako je RTC, DMA atd.
Zmiňujete cenu, ale ta je díky cenové politice některých firem velmi nízká, mnohdy nižší než vámi zmiňované ostatní architektury.
Samozřejmě situací/aplikací/oblastí existuje spousta a souhlasím s vámi, že někde lépe pasuje ultra low-power MSP430 a někde zase DSP dsPIC. Proto jsem zmiňoval tu "general-purpose" oblast, kde si myslím, že portfolio ARM jader (od low cost M0+ po M7 s SIMD instrukcemi, případně i řada Cortex-R) jich pokreje většinu (proto ideální pro začátek).. ale souhlasím, že určitě ne všechny.
To jestli je ARM vytlačí ostatní architektury je otázka (já doufám že ne).. Jen pro zajímavost : http://www.embedded-computing.com/embedded-computing-design/the-msp430-mcu-just-gained-an-arm-based-cousin-the-m4-based-msp432 (http://www.embedded-computing.com/embedded-computing-design/the-msp430-mcu-just-gained-an-arm-based-cousin-the-m4-based-msp432).
Ondrej Nemecek, ale pokud bude mít zkušenosti s programováním MCU (nejen z univerzity), bude něco vědět o architektuře atd., tak si myslím, že jako fresh-out pohovorem většinou projde:)
Omlouvám se autorovi za off-topic.
-
Děkuji vám moc za rady. Jen bych ještě přece jen potřeboval poradit s výběrem jádra Cortex Mx. Jedná se o jádro M0+ s frekvencí max 48Mhz, vyšší řády M3 a M4 mají výkon větší, včetně instrukční sady. Rád bych s tím kitem frdm kl25z různě experimentoval, a tak se ptám, zda je to dostatečné, abych tak nemusel později rychle dokupovat jádro rychlejší. Sice má kl25z dost slušnou hardwarovou výbavu, ale je o něco dražší. Nebo můžete doporučit i jiný, pokud možno lepší vývojový kit? Zkušenosti s programováním v C už mám ze střední školy a moc mě to bavilo, takže mi stačí si už jen znalosti osvěžit a dát se hned na to.
-
Děkuji vám moc za rady. Jen bych ještě přece jen potřeboval poradit s výběrem jádra Cortex Mx. Jedná se o jádro M0+ s frekvencí max 48Mhz, vyšší řády M3 a M4 mají výkon větší, včetně instrukční sady. Rád bych s tím kitem frdm kl25z různě experimentoval, a tak se ptám, zda je to dostatečné, abych tak nemusel později rychle dokupovat jádro rychlejší. Sice má kl25z dost slušnou hardwarovou výbavu, ale je o něco dražší. Nebo můžete doporučit i jiný, pokud možno lepší vývojový kit? Zkušenosti s programováním v C už mám ze střední školy a moc mě to bavilo, takže mi stačí si už jen znalosti osvěžit a dát se hned na to.
No samozřejmě záleží, co na tom chceš dělat. Potom se dá soudit, jestli je to dostatečné nebo ne.
Ale obecně, Cortex-M0+ je velmi osekané jádro (ještě víc než M0), které vzniklo jako levná a úsporná náhrada 8mi bitů (jen pro zajímavost, jádra M3 a M4 byly na trhu dřív, než M0+..takže se osekávalo z nich). Např. instrukční sada obsahuje z velké části pouze 16bitové instrukce, což tě může limitovat při využítí pracovních registrů jádra (zbydou jen 3 bity v instrukci na určení pracovního registru). Na druhou stranu pipeline je jen 2-stupňová, což může být výhoda..ale asi ne moc signifikantní:) Dále, architektura je z pohledu sběrnic Von Neumann. Má také méně stupňů přerušení a pokud se nepletu, nejdou maskovat samostatně, což může být problem při použití RTOSu.
Naopak M4F s floating point unit je docela komplexní jádro s SIMD instrukcemi (dobrý základ pro NEON na Cortex-A;) a spoustou jiných užitečných instrukcí a konfiguračních registrů, s kterými při chytrém využití může být aplikace efektivnější (ale většinou dražší a s větším pouzdrem) než s Cortex M0+, jelikož čím rychleji něco spočítáš, tím déle může procesor spát nebo celkově běžet na nižší frekvenci. Podpora pro RTOS je lepší, stejně tak systém sběrnic.
Otázka ale je, do jaké míry tě tyhle detaily jádra budou zajímat, pokud budeš používat C a pravděpodobně nějaké předpřipravené knihovny jako Mbed. Pochybuju, že se hned ze startu pustíš do nějaké ultra low power aplikace.
Další věc jsou ostatní periferie. Obecně, "nižší frekvence, méně tranzistorů = menší plocha, nižší cena, nižší spotřeba", a to je často cílem MCU s M0+, takže i periferií je často méně a jsou jednodušší. Od NXP si můžes jako alternativu ke FRDM-KL25Z koupit kit FRDM-K64F s M4F, kde máš ale mnohem složitější DMA kontroler, SPI atd.. stačí si otevřít referenční manuál a hned poznáš rozdíl:)
Myslíš, že budeš potřebovat ze začátku složitý DMA kontroler, kterým budeš triggrovat a vazbit přes cross-bar jiné periferie ideálně bez probuzení jádra pro ultra low power aplikace? Nebo několik MAC jednotek a VLIW architekturu (potom bych tedy doporučoval nějaký DSC, jak zmiňoval kolega předemnou)?
Já si osobně myslím, že ne, ale nechci tě podceňovat ani to za tebe rozhodovat.
Jen pokud bych mohl jednu radu, tak to zas tak neřeš..nekupuješ auto.. a věřím, že kit za pár stovek by ti koupila i univerzita.. Tipů na kity jsi podle mě dostal dost a z mého osobního pohledu jsou všechny více méně ok.. takže prostě jeden z nich vyber a začni;)
Good luck!
-
To eltech: Pekna odpoved, uplne suhlasim :)
Z mojho skromneho pohladu a nazoru.
Odporucam pre zaciatocnika najst si take prostredie (IDE) ktore mu bude vyhovovat a potom platformu ktora ma snad najrozsirenejsiu komunitu, dobre spracovane Drivery (SDK) a co to je popisane na webe.
Z toho by asi najvyznamnejsie vyslo Arduino, ale to osobne neodporucam (Wiring spravi zle navyky, Takmer ziadna kontrola na code flow, a pre buduceho embeddistu, to nieje vobec vhodny zaciatok).
Po com by som sa pozrel:
STM - Velka komunita a dostupne tutorialy, maju aj SDK, kity sa daju v CR v pohode zohnat
NXP - Vacsia komunita, help dostupny v podobe mcuoneclipse, SDK, IDE zalozene na Eclipse
TI - Osobne som mal od nich iba jeden kit, ale nikdy som s tym neprisiel extra do kontaktu
AVR - IDE zalozene na Visual Studio, pekne spravene Drivery, avrfreaks to isti.
Osobne mam skusenosti s Kinetis-mi , tak pisem na margo tejto rodiny (Da sa to aplikovat na akykolvek ARM)
KL25 pouziva CM0+, ma vsetky klasicke periferie(I2C, SPI, PWM, ADC, UART, Timer) + USB, DMA, dost RAM aj Flash.
Pre zaciatocnika viac nez vhodne! Preco? Periferie su KISS (Keep is simple, stupid), Periferku nastavis zopar registrami, alebo pouzijes driver z SDK, robi to co ma. Samozrejme, jednoducha periferia nevie robit komplexne veci, ale CM0+ ma aj DMA, takze dokazes spravit niektore komplexnejsie ukony pouzitim DMA - DMA je jednoduche, ale svoj ucel splni. Freertos bezi viac nez dobre.
K64F je uz CM4, takze floating point + hardwarova delicka, cip je uz pekne nabuchany. Ma zlozitejsie SPI, DMA, PWM aj Timer, naviac ma podporu Ethernet-u, SDHC kariet, Flexbus (SDRAM/LCD).. v skratke, je to raketa.
Neviem ci niekedy vyuzijes plny potencial toho co ti ponuka.. mne sa to nepodarilo, prakticky asi obmedzenie to nema a zvladne to hodne zaujimave veci. Co som na tom rozbehal:
- Data logger na SD kartu (Freertos +Fatfs)
- Kamera OV7660 a prenos obrazu na LCD (DMA + GPIO -> Flexbus)
- Riadenie BLDC motora (Hall / Sensorless) (PWM + PDB + ADC)
Takze, ako bolo spomenute, proste si nieco kup a zacni :)
-
Dovolil bych si trosku kanibalizovat toto vlakno, ale ono se to bude hodit i puvodnimu tazateli. Mate srovnani STM32 / NXP / pripadne ARM Atmel (SAM) ?
Prave se rozhoduju, ze bychom predelali neco co je postavene na PIC18 na ARMa, potrebujeme USB + CAN + pomerne rychle GPIO resp. navazane capture timery, abych stihal zpracovavat ruzne digi signaly. Atmelu se chci vyhnout po mych minulych zkusenostech, kdy clovek zjisti "ze veci nejsou jak by mely byt". NXP i ST jsem driv pouzival, ale ne ty moderni rodiny (mam tu nejake vzorky, ale v komercni aplikaci to neni, skoda ze cinani maji devkity hlavne pro STcko).
Padaly tu rady s ruznymi "velkymi" procesory, tak ty kvuli slozitosti rozhodne nedoporucuji. Treba nakonfigurovat nejakou periferii u MediaTeku/Allwinneru stoji mnohdy treba i stovky radek (ty periferie jsou navrzene docela univerzalne a sikovne "oregistrovane", takze z toho jsou takove svycarske noziky :-). Kdo zna puvodni Freescalovsky PPC QorIQ, tak ten je tomu nebjbliz.
Jak se tu resi jestli ARM-rulez nebo ne, tak v automotive je naprosto bezne, ze spouzivaji ruzne PPC / V850 / TriCore aJaNevimCoVsechnoJineho, naopak ARMu tam je poskrovnu (ale nejaky se taky najde).
-
To mhi_:
Ako to ma STM a AVR to neviem, ale u NXP mas K64, ktory obsahuje CAN (example su obsiahnute v SDK) (alebo si napises baremetal), USB obsahuje (Bud SDK, alebo si stiahnes solo Driver) a k rychlosti GPIO, zalezi..
Neviem ci v novej implementaci pouzivaju uz FGPIO, ale cez Timer + DMA + GPIO -> +-6MHZ Pin Toggle...
-
Ad periferie: to mi je jasne, pouzit MCU selector umim (dokonce uz mam vzorky) a USB a CAN controllery jsou vsude podobne a nebojim se jich :). Slo mi spis o to "jak se s tim v praxi pracuje". Treba PIC18/24 umim dostat do stavu vytuhnuteho CAN controlleru (nejde povolit buffer, nebo tak neco) pouhym nastavenim logickeho rozporu mezi CANTX/CANRX (neni to tak uplne jednoduche, ale princip je ten, ze se tam ve udela dlouhodoba kolize). U MCP2515 se da situace resit tim, ze clovek "zataha za reset", ale to nejde udelat u procesoru s CANem.
O AVRko nemam zajem, to je z blata do louze, kdyz uz tak ten ARM/MIPS.
-
Tak to CAN je jedina periferia s ktorou som nerobil (nebol dovod)...
Tak to jedine si prejst vsetkych mainstream vyrobcov ARM-u a hlada zle recenzie na ARM.. a vybrat si toho kto ich ma najmenej DELENO velkost komunity :D
-
Tak jak se tu nekdo ptal, dneska mi dorazil balicek z CN (objednavano pred mesicem). Koupil jsem mimo jine veci jen tak na hrani:
https://www.ebay.com/itm/UNO-R3-Mini-Micro-USB-ATmega328P-CH340G-Replace-ATmega16U2-Compatible-to-Arduino/201927954809?ssPageName=STRK%3AMEBIDX%3AIT&var=501935531922&_trksid=p2057872.m2749.l2649
https://www.ebay.com/itm/USBASP-USBISP-AVR-Programmer-Adapter-10-Pin-Cable-USB-ATMEGA8-ATMEGA128-Arduino/310506909410?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649
celkem nejakych 110 Kc. Pozor, ten prodejce se chova dost neochotne kdyz treba dorazi nefunkcni kus, odkazy jsou jen pro informaci o co jde.
Byl jsem az prekvapen jak je to snadne. Nejprve bylo nutne udelat redukci mezi usbasp (schema http://eecs.oregonstate.edu/education/docs/ece375/USBASP-UG.pdf ) a ICSP schema je na https://learn.sparkfun.com/tutorials/installing-an-arduino-bootloader/connecting-the-programmer (10 minut prace, potreba 2 konektory a par dratu).
V ubuntu staci dat sudo apt-get install avr-libc avrdude binutils-avr gcc-avr srecord (1 minuta i s hledanim)
main.c:
#define F_CPU 16000000UL
#include <avr/io.h>
#include <util/delay.h>
int main(void)
{
DDRB = 0x20;
while (1) {
PORTB = 0; _delay_ms(500);
PORTB = 0x20; _delay_ms(500);
}
}
A minimalisticky makefile:
all:
avr-gcc -o main.elf main.c -mmcu=atmega328 -O2
avr-objcopy -j .text -j .data -O ihex main.elf main.hex
avrdude -p ATMEGA328p -c usbasp -U flash:w:main.hex # nutno dat prava k device nebo pod rootem!
10 minut prace. A blika to ledkou "L". Nemusel jsem nic krome te redukce bastlit a je to cista prace bez veskereho odpadu co sebou nese arduino.
Takze pokud nekdo chcete zacit, objednejte a za mesic + 30 minut prace je prvni aplikace a za +- 100 Kc. Se slzou v oku vzpominam na doby, kdy mne zakoupeni vseho na blikani ledkou (PIC16F84) stalo vic nez tisicovku a nez jsem zablikal, trvalo mi to snad 2 dny uceni se a instalace MPLABu apod. Zrovna jsem mel stesti na nejakou ne prilis fungujici verzi a nebyla k tomu skoro zadna literatura krome datasheetu... to byly doby.
Jinak to Arduino jsem koupil jen za tim ucelem, abych mohl naprogramovat neco na jeden "shield" a nechtelo se mi dratovat nebo pod ten shield kreslit vlastni desku.
Mam jeste desky se STM32 + stlink, muzu napsat i o nem.
-
10 minut prace. A blika to ledkou "L". Nemusel jsem nic krome te redukce bastlit a je to cista prace bez veskereho odpadu co sebou nese arduino.
Kdyby sis koupil Arduino Nano, měl bys té práce ještě méně a o něco levněji. Nemusel jsem ani bastlit redukci - prostě jsem ho připojil dodaným USB kabelem k PC a mohl jsem programovat. Navíc je to mnohem menší. Pokročilejší pak přejdou na Arduino Mini Pro, které je ještě menší a ještě levnější, ale nemá ten USB převodník.
Zrovna se však piplám s ATtiny85, které se na drobnosti do 6 I/O hodí o něco lépe a je to prcek.
-
Potreboval jsem neco "pod" ten shield ktery mne zajima, to uz jsem rovnou mohl pouzit nejakeho ARMa ci PICe. V minulosti jsem myslim Ard. nano koupil, ale nekde skoncilo zapadle prachem.
Asi doslo k nedorozumeni, vyse uvedenym postupem jsem prepsal bootloader arduina (po resetu jde rovnou do aplikace). Samozrejme to slo rozjet i s tim arduino bootloaderem, ale to ja neumim ani se nehodlam ucit, na nic to nepotrebuji.
-
Bootloader se hodí, není pak potřeba programátor. Prostě se to po resetu pošle přes seriovou linku. Co se učení týče.. žádné není. avrdude se používá pořád stejně, jen se možná zvolí jiná rychlost, jiný usb port a jiný typ (dle konfigurace bootloaderu).
-
Uceni: ja ten arduinacky bootloader vubec neznam. treba jak se skrz nej passuji interrupty. Rozhodne nejsem proti mit nejaky bootloader, ale uz jen popravde receno kdybych si mel zvolit desku MCU+serial-USB vs. ciste MCU, tak bych asi volil druhou variantu. Vetsinou totiz delam veci kde ten seriovy port vubec nevyuziju- bud' staci LEDky/display na zobrazeni stavu nebo je seriak moc pomaly a data se musi vyhodnotit v MCU). Casto je mym nastrojem taky osciloskop a na MCU jeden trigger pin...
Pro muj styl prace uplne nesedi ta "arduino-cesta", ani po HW ani SW strance. Je to hodne dobre pro "bastleni" ve stylu slepim neco v jednom-dvou kusech, pripadne kdyz clovek zatim nerozumi/nechce rozumet embedded vyvoji a vsem souvislostem.
-
No tak vzdyt o ty knihovny jde. Resi se tady, jaky procesor low level programovat. Vzdyt nejvetsi mnozstvi knihoven bude stejne napsanych v C, Ty si treba budes hrat s njakym ARM procesorem, ale co udelas, az budes potrebovat zpracovavat treba obraz z kamery, nebo posilat nejake data po LAN nebo pres WiFi? Na Arduinu to udelas, protoze je tam velka komunita a knihovny jsou, ale co treba ty dalsi monolity, ktere tu uvadite? Co kdyz budes potrebovat zalozit na tom monolitu i nějaký malý server, který bude moct reagovat na okolí. Fakt by me zajimalo, co se tady u nas v CR v prumyslu realne na tech mikroporcesorech dela, kdes najdes uplatneni, kdyz umims programovat ARM.
Presne tohle je prede mnou. Zpravovat obraz z kamery, zvuk z mikrofonu, zkomprimovat je, poslat streamem pryc a na druhe strane ho dekomprimovat, zobrazit na LCD a poslat do repraku.
A jak to udelam? Vezmu si datasheety k procesorum, ke kamere, k LCD a dalsim periferiim, ktere k tomu budu potrebovat, nastuduju si je a napisu si to kompletne sam. A proc? Protoze ty knihovny, co jsou ke kamere, LCD atd. dostupne pro arduino jsou sice fajn, ale nikdy nemas jistotu, ze budou delat to, co potrebujes, ve vsech situacich. A to si proste v produkcni verzi nemuzes dovolit.
Ale to delas jako skolni projekt, ne? Kdo ti něco takového zaplatí? Na desktopu to máš práci na pár dní, ale ty to máš na pár měsiců. To by mě opravdu zajímalo, kde se u nás něco takového vyvíjí.
-
Kolegové jen chtěli naznačit, že jste si mohl ušetřit práci s tou redukcí ( koupě programátoru se samozřejě může hodit ).
Stačilo propojit tu Arduino desku s PC USB kabelem a místo vašeho příkazu:
avrdude -p ATMEGA328p -c usbasp -U flash:w:main.hex
použít něco jako:
avrdude -v -p atmega328p -c arduino -P /dev/ttyUSB0 -b 57600 -D -U flash:w:main.hex:i
Pak by to tam AVRdude natlačil s použitím bootloaderu, který tam už je od výrobce.