Názory k článku MicroPython a STM32 na doskách Nucleo32 a Nucleo64
-
Michal SmržStříbrný podporovatelZnačná nevýhoda je, že chybí debug. Teď nedávno byl implementován sys.settrace(), takže se debug blíží.
-
Tak nevím, jestli jsem autora pochopil správně:
1) Oficiálně STM32F4 nejsou podporovány, ale někdo někde něco našel, tak není problém to používat.
2) Když nejsou k něčemu knihovny v C, budou automaticky v Pythonu.
3) Pokud jde o časování a kalibraci periferií, neprůhledná knihovna v Pythonu je lepší, než si prostě nastavit registry periferky v C/ASM.
4) Pokud je jednočip výkonný, je potřeba jeho výkon snížit Pythonem na polovic nebo i níž. Přece tam nebudu dávat brouka za pajcku a den optimalizovat kód v C, když stejnou službu udělá brouk za pětikilo po týdenní optimalizaci Pythonu.
5) Pokud je někdo lepič špagetový a není schopný programovat v C, v Pythonu se mu to bez problémů povede perfektně a na první dobrou.
6) Pokud někdo nerozumí jednočipům a elektronice, nevadí. Stačí si myslet, že umí Python a má vyhráno.
7) Debugger je pro zbabělce, správný extrémista vybleje binárku a hodí rovnou do produkce.Ale kde jsou ty ostatní pohádky, třeba O střízlivém Milošovi, O pravdomluvném Andrejovi, Jak Vladimír Krym Ukrajincům daroval,... ?
-
Článek jsem nečetl celý, protože mě STM moc nezajímá, ale MicroPython používám na ESP32.
Řekl bych že se vše odvíjí od použití. Pro domácí bastlení kde čtu hodnoty z teploměru a odesílám přes MQTT nevidím důvod mít oficiální port a ani nevidím problém v tom používat MicroPython.
Ano je jednodušší na použití než C (zvláště pro nás lepiče) a ani C neochrání od lepení... postahovat něco ze stackowerflow a splácat to do kupy aniž bych tomu pořádně rozuměl je, řekl bych, nezávislé na použitém jazyce.
To že dnešní doba vede k tomu aby byl každý "programátor" bez znalosti HW je špatně a já to sleduju od nástupu arduina. V tomhle jsme za jedno... Na druhou stranu pokud programátor dělá aplikaci na PC a jen potřebuje někde sesbírat data aby měl s čím pracovat, tak pro vlastní potřebu proč ne...Takže zas tak bych to neodsuzoval...
-
Dobrý deň, k Vašim pripomienkam (od autora):
1. Zoznam podporovaných a nepodporovaných platforiem je uvedený v
https://micropython.org/download2. Knihovny pre obsluhu periferii v MicroPython-e pre STM32 sú napísané v C s využitím HAL a niekde LL, nie v Pythone.
3. V článku sme spomínali komplikovanejšie periférie - bežne pracujeme s modulmi, v ktorých treba obsluhovať napr. 60 registrov a výstupom je blok sekvencie 1k dát z DFT v komplexnom tvare, v článku išlo o použitie Pythonu pre ladenie na aplikačnej (čo, kedy a v akom poradí do registrov zapísať), nie na jednoduchej komunikačnej úrovni (zapíšeme čosi do registrov).
Nikde (!) v príspevku nie je deklarovaný MicroPython ako finálne behové prostredie - ale ako dočasný diagnostický nástroj. Výhody konceptu priamej interaktívnej komunikácie s perifériami pochopí len ten, kto musel vo svojej profesionálnej praxi riešiť v produkcii zmeny vlastností komponentov dodaných výrobcom - častokrát ešte bez erraty, diagnostika, modifikácie a konfigurácie prototypových zariadení inštalovaných v nedostupnom prostredí (sondy v 100m vrte, vákuová komora, detektory na vrchole anténnej sústavy, senzory v integrované v telese vozovky, atď.) ...4,5,6,7 + záver Vašeho príspevku - bez komentáru, moja odborná úroveň mi bohužial neumožňuje kvalifikovane odpovedať na tieto pripomienky
-
"2. Knihovny pre obsluhu periferii v MicroPython-e pre STM32 sú napísané v C s využitím HAL a niekde LL, nie v Pythone."
Aha. Takže tím se hodně vysvětluje. Chtít po někom používat HAL snad ani není legální - §144 zákona 40/2009 Sb. Pokud tohle nějaká otrlá bytost z jiné planety dokáže hodit do nějakýho wrapperu tak, aby to něco dělalo, tak je to opravdu vysvobození. I kdyby to napsal v obfuskovaným TCL.
"3. Výhody konceptu priamej interaktívnej komunikácie s perifériami pochopí len ten, kto musel vo svojej profesionálnej praxi riešiť v produkcii zmeny vlastností komponentov dodaných výrobcom - častokrát ešte bez erraty, diagnostika, modifikácie a konfigurácie prototypových zariadení inštalovaných v nedostupnom prostredí (sondy v 100m vrte, vákuová komora, detektory na vrchole anténnej sústavy, senzory v integrované v telese vozovky, atď.) ..."
Abstrakce od HW je snad jasná, ale proč prostě nepoužít něco ve stylu https://freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_IO/FreeRTOS_Plus_IO.html, když se bez OS blbě dělá cokoliv? Ale stejně tak člověk získá jenom dělící čáru a buďto se plácá nad ní, nebo pod ní...
"V článku sme spomínali komplikovanejšie periférie ... v článku išlo o použitie Pythonu pre ladenie na aplikačnej (čo, kedy a v akom poradí do registrov zapísať), nie na jednoduchej komunikačnej úrovni (zapíšeme čosi do registrov)."
Proč nevyhoví něco jako moduleWrite( moduleRegId_t register, moduleRegValue_t value) ? Co se skrývá v implementaci je jedno, jako typ moduleRegId_t si hodím emum s registry a aplikace víc nepotřebuje. Co je pod tím, to si odšéfuju podle desky a použití. Aplikaci je houby po tom, jestli rozhraní s někým sdíllí nebo jestli se použije DMA...
-
ad 1) někomu to může stačit. Na začátku. Pak už ne, tak vezme něco jiného.
ad 2) to někdo tvrdí? Navíc spoustu knihoven můžeš portovat z RPi
ad 3) Časování v MPy je dostatečně přesné pro účely, za kterými MPy vznikl. Osobní zkušenost a testy. A registry u periferie stejně nastavuješ přes rozhraní té periferie, tak je jedno, jestli to uděláš kódem v MPy nebo C. A pokud tím myslíš něco jiného než například nastavení citlivosti čidla připojeného přes například i2c, vyjádři se laskavě přesněji.
ad 4) Na ESP32 Micropython funguje a je to čip za 50,-. Na většinu věcí MP stačí, pokud nestačí sáhnu po C. optimalizovam MP netřeba,.
ad 5) Tvé tvrzení je založené na nesmyslném předpokladu. Z (ne)schopnosti programovat v C nijak nevyplývá (ne)schopnost pracovat v Pythonu.
ad 6) Říká se tomu růst a vstupní odpor. Zkoušel jsem programovat své ESP32 v oficiálním SDK a člověk než napíše jediný řádek kódu, tak postahuje mnoho různých knihoven a SDK a toolkitů a pomocných aplikací a musí načíst tunu dokumentace. A to ještě nenapsal ani řádku aplikace. Oproti tomu MPy - stáhne dva nástroje, jednu binárku 4MB a dokumentace je u toho a za půl hodiny bliká s ledkou. Tento člověk jednoho dne narazí na limity MPy a buďto to vzdá, nebo si danou aplikaci přepíše do vhodnějšího jazyka.
ad 7) Jako bod 5, zcela nesmyslný vstupní předpoklad.
Na některé mé aplikace je MPy zcela ideální, na některé zcela nevhodný. Celkově na mne Tvůj přispěvek působí jako od člověka, který se cítí uražen tím, že někdo vytvořil snažší způsob, jak pracovat s MCU, než používáš. A hned Tě to uráží. Jenže si neuvědomuješ, že zrovna v tomto případě srovnáváš své profesionální nasazení s velmi schopnou hračkou pro děti/edukačním nástrojem, který má přitáhnout zájemce o problematiku. Viz bod 6.
Python používám denně v práci, C umím také, jen ho už nepoužívám každý den. U svých aplikací pro MCU jsem s MPy narazil na limity a přepsat kód do C mi zabere spoustu času. Mnohem více, než mi zabralo jeho vytvoření v Pythonu. A ne, Arduino není pro mne řešením.
P.S. Stejně tak psaní profesionalních aplikací v prostředí Arduino je dle mého názoru fušeřina. Ze stejných důvodů jako použít MPy.
4. 12. 2019, 10:04 editováno autorem komentáře
-
Nespojuju Python s lepením. Spojuju neschopnost autora udělat cokoliv složitějšího s lepením, protože:
- jediný způsob, jak udělat něco komplexního, je metoda "Rozděl a panuj"
- pokud si celek rozdělím na bloky velikosti, kterou zvládnu zpracovat jako algoritmus, je vyhráno.
- když se nepodaří problém rozdělit na menší celky, vznikne špagetový kód a jeho tvůrce se do něho zamotá.
- a vůbec při tom nezáleží na tom, jestli je to v C, MPy nebo Basicu. To je jenom způsob, jak sdělit stroji, co po něm vlastně chci.No a autor se přece veřejně přiznal, že motivace pro MPy byla jeho neschopnost udělat něco rozsáhlejšího...
-
Mám doma regulaci bazénu, kdy čtení několika teplot a přepínání pár relé řeším Arduinem, samotné řízení a zobrazení řeší Raspberry 1 s dotykáčem. V čem udělám chybu, když místo Arduina použiju nějaký obdobný mikrořadič za pár (který to s prstem v nosu zvládne) s funkčním Micropythonem nebo třeba Luou (pochopitelně odladěnými, to nerozporuju)? Upozorňuju, že ve znalosti C nemám žádné ambice (spíše je mi z něj na blití).
Proč je dnes mnoho počítačových aplikací vytvořeno ve vyšších jazycích, když bychom to stále mohli bouchat v C, jak se to kdysi dělalo, ale už tak nějak nedělá?
Opravdu má tak zkušený vývojář embedded jako vy potřebu věšet do diskuse tak HLOUPÉ komentáře?
-
Nahrazení Arduina čímkoliv není chyba, spíš naopak. Stejně tak není chyba zvolit si jazyk podle vlastního uvážení a danýho use case. Na domácí bastlení si zadání a use case definuješ sám, tak si hrej.
Problém nastane, pokud
- výrobek jde do sériové výroby a má se dělat třeba 20k ks. Pokud kvůli jazyku/stacku musím použít o 100Kč dražší MCU, dělá to 2M. Pak je úspora 100 člověkohodin argument, za který šéf rovnou strhává prémie.
- pokud mám za něco ručit zákazníkovi a použiju kód třetí strany, u kterýho nevím, jak funguje a jak ho kdo testoval
- pokud narazím na nějaký právní omezení, např. GPL pro kód třetí strany a zákazník požaduje 100% closed sourceHloupý není komentář, který upozorňuje na hlouposti. Sorry, ale glorifikovat jazyk, který zpomalí a nafoukne kód na opravdu drahým HW a ani nenabídne interaktivní ladění jako GDB s argumentací, že mimo něj nemusí člověk nic umět a líp se to ladí, to můžou napsat jenom tři typy lidí:
a) Markeťák, který chce lidem vnutit horší řešení z víc peněz,
b) Frikulín, který se nadchl pro novou věc a hledá jakýkoliv, i nesmyslný argument pro obhajobu své volby,
c) Nadšenec OR začátečník, co nic jinýho neznáNa první dva z nich mám už po letech celkem silnou alergii...
-
> ani nenabídne interaktivní ladění jako GDB
Mno.. ale Pythoní REPL přece je interaktivní. Docela dobře si dokážu představit MicroPython jako formu hardwarového shellu. Něco jako modernější BusPirate.
Kolikrát jsem si potřeboval vyzkoušet komunikaci s nějakým švábem předtím, než jsem napsal finální driver. Třeba jen pro to, abych viděl, že ty registry nastavuju správně a mohl okamžitě reagovat.. kolečko v C (úprava, kompilace, gdb load, init, breakpointy..) je na prvotní osahání protokolu o dost pomalejší.
-
Všimněte si, že žádná z vámi uvedených odrážek se mě (a mnoha dalších uživatelů) netýká. Zjednodušeno a přeloženo: Říkáte, že pro profesionální nasazení se to nehodí (to bych po tom ani nechtěl) a připouštíte (c)), že bastličům se to může hodit. Takže užití je jasné, ne? Je třeba to ještě rozebírat?
Přemýšlím, zda ty samé argumenty (velký, pomalý, ...) nepadaly při rozšiřování vyšších jazyků na PC.
ČLÁNKY DO MAILU