Portál AbcLinuxu, 30. dubna 2025 11:21
Tiskni
Sdílej:
Raketoplán byste tím řídit nechtěl?
Proč ne? Ty krabičky dnes mají mnohem větší výpočetní výkon než měl počítač Apola 11
Pokud je ne jen základ, ale i komunitní duch nastavený špatně, tak se člověk akorát udře a nakonec bude rád za to, že nějaký lepší HW dokáže nabídnout zakrytý kompatibilním API se všemi původními omezeními. Prostě se to sejde na tom nejhorším ze všech prvků...Ale houbelec. Vis jak by Arduino komunita rvala hrdosti kdyby se dozvedela, ze jejich API zacalo podporovat rizeni jaderek (odpurci jadra si dosadi "rizeni solaru/elektro_aut/..."), infuznich pump atd.? Vsichni by ty nove casti API chteli vyzkouset. Komunitni duch jako neco "established" je dezinformace. Komunita bude delat to, co jim IDE/plug&play/HW naserviruje v tom momente, kdy tu danou verzi poprve spusti. Staci zmenit API ( vydat novou verzi IDE/HW/...") a bude okamzite i komunita k nepoznani jina. Nezapomen, ze Arduino komunita je "moderni spotrebni" - tedy zadna ultimatni prenositelnost, nybrz "koupim novy HW vydany dneska a k tomu odpovidajici nove verze IDE/kompilatoru/API/...). Easy peasy, jede se dal.
... No a nakonec zjistíte, že tam kam ten zbytek Arduina odešel, nezůstalo vůbec nic, zůstává jen POSIXOvé API... a třeba návod jak ho použít.Aha, takze zase nic (psala jsem "Hlavne musi clovek prekousnout, ze cilem neni 90+/klidne_100 ale fakt pouze 80/20.").
A hromady knihoven a diskuzí na netu, ze kterých se dá občas vyzobat něco užitečného.
A přesně o tom to je. Není čas přebírat se hromadama hnoje a hledat co je validní a co ne. To je stejné jako s nejrůznějšími programovacími frameworky. Než řešit jejich problémy, je mnohem jednodušší si to zpracovat sám. Chápu, že někomu, kdo generuje tuny identických věcí šetří čas. Jenže zastarávají tak rychle, že pro mne nemá vůbec smysl se jimi zabývat.
Jinak pokud jde o téma blogpostu.
Nejsem student. Pro Pavlovy „krabičky” zajišťuji pouze infrastrukturu, ale to téma rezonuje s tím co si myslím i já. Nevím. Možná ho k sepsání tohoto textu přiměla právě naše debata, kdy jsem žehral na to jak neskutečný oser přináší dlouhodobá údržba nějakého řešení, pokud bylo postaveno na nějakém, ve své době „cool” řešení.
To, jakým způsobem Pavel nutí studenty aby porozuměli tomu co dělají, je podle mne jediná správná cesta jak vychovat budoucí inženýry, co nebudou k tomu co se válí všude možně po internetu přihazovat další kupky zbytečně matoucích informací, které se s každou další novou verzí proprietárního klikacího softu stávají víc a víc neaktuální.
Jinak by neuškodilo, kdyby Pavel ten text udělal nějak rozumně strukturovaný. Kdyby mě to nezajímalo, tak bych to zabalil po prvním odstavci.
Když jsem nastoupil v r. 2008, bylo to jak o kouhoutkovi a slepičce. Proto jsem zvolil k dokumentaci MediaWiki. Dnes patří k nejdéle kontinuálně provozovaným wiki které nejsou udržovány nadací WikiMedia, s tím že po poslední aktualizaci na MW 1.39+ je šance že do r. 2026 nemusím nic moc extra řešit.
Systém OpenIntranet, který jsme s kámošem naprogramovali pro ÚMOb Ostrava-Jih v roce 2003, se rovněž používá dodnes. Byl to vůbec první CMS na světě s podporou WYSIWYG editace stránek. Dodnes překonává sračky typu Drupal či Wordpress svou modularitou a jednoduchostí kódu. A když se tak koukám na ty omalovánky kolem, možná by ho i dnes stálo za to oprášit, ovšem to by musel tenhle krok učinit on, protože jde primárně o jeho kód.
Zhruba stejně starý je systém, který oprašuje další můj kámoš. A to je fakt peklo. Dlouhé roky k tomu nechtěl nikoho pustit a dnes marně loví duši, která by se toho ujala protože šel jinou cestou než my. Dnes si musí přiznat, že ten jeho návrh byl nedomyšlený. Bohužel alternativa neexistuje. Ne že by ji nebylo možné vytvořit, ale stálo by to ranec.
Ad notebooky a OS. Mám tady Sony Vaio s aktuální Linuxovou distribucí a normálně jede. I když dnes by už s tak pomalým strojem každý pohrdal. Jo, to není jak v průběhu 90. let, když kámoš nechal něco na kompu renderovat, šel na šichtu, na pivo a když se druhý den vyhajal, byl obrázek hotový. A to si ještě všichni sedali na zadek z toho, jaké má doma dělo.
Já takové nároky nemám. Mně stačí, když všechno funguje.
Maličkost, že? Bohužel vděku se nikdo nedočká. Lidi velice rychle parchantí a pokud něco funguje po řadu let, aniž by o tom slyšeli, ztrácí pro ně hodnotu. Ale to mi je fuk. Pro mne je podstatné, že když nastane problém, zpravidla není u mne – protože se nic nemění. Usnadňuje to řešení. Bohužel však narážíme na to, že některé problémy číhají i několik let než vyhřeznou a pak se velice těžko se hledá příčina, protože se za tu dobu změnilo milion věcí a je to jako hledat jehlu v kupce sena. Ty věci jsou už prostě tak sofistikované, že už téměř není s kým se poradit.
Fakt si nedovedu představit jak to bude vypadat za dalších 20 let, ale jedno vím jistě. Od toho co používám teď se to moc lišit nebude, protože nic lepšího není. Ostatně, Pavel Píša byl ten, který mne k tomu před těmi téměř 15 lety přivedl. Já to jenom během těch prvních 4 let dotáhl do stavu, který nás zbavil stressových situací. Prubířským kamenem byl rok 2020, kdy jsem využil situace, že byly laborky bez studentů k tomu abych tu infrastrukturu připravil na plně vzdálený přístup. Bohužel jsme zase po dvou letech klidu zpět ve starých kolejích, kdy marně hledám časové okno abych si vůbec mohl dovolit něco vyzkoušet a otestovat. Ale mně to nevadí. Mám i jiné projekty co mě baví.
Ano. Pavel Píša je blázen. Protože chce aby studenti co prolezou jeho kurzy patřili mezi TOP inženýry. A já s ním souhlasím. Na jeho místě bych byl totiž vůči nim mnohem tvrdší. Na můj vkus si je moc hýčká a proto tak těžce nese, když se pak osamostatní a utečou za lepšíma prachama. Má taky svoje mouchy. Někdy je umanutý jako malé děcko a jen velmi těžko připouští, že se hrne do slepé ulice. Ovšem pokud jde o tuhle oblast, moc konkurence nemá. A bohužel ani nástupců.
Doporučuji v tomto směru k přečtení text Johna Hargravea z r. 1923. Už jsem tady o něm psal v roce 2012. Nebyl to žádný inženýr, ale vizionář a ve své době rovněž nepochopený a nařčený později zcela absurdně z inklinace k fašismu.
8.3.2023 21:57
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Ale PWM nemá garantovanou frekvenci, jako že vůbec (hardwarově závislá), a na tomhle procesoru to je cca 250 Hz. Takže nemůžu použít zabudovaný analogWrite.Krátké googlení okamžitě odhalí, že to je často řešený problém a frekvenci lze snadno zvýšit zápisem do jednoho registru.
TCCR5B = (TCCR5B & B11111000) | B00000010; (na AtMega328; na AtTiny bude ten registr asi jiný, zjistíš v manuálu)
Takže co vypadalo jako jednoduchý problém nakonec znamenalo čtení zdrojáků Arduina a studium manuálu, a Arduino mi nepomohlo skoro s ničím.Protože když se tohle pokusíš frameworkem, tak z toho bude další jaderná elektrárna. Nebo jak by se to mělo řešit? Takhle sis to napsal ručně, stejně jako bys to dělal jinde.
pwm -f frequency -c channel1 -d dutyKdyž si to odladíte z řádky, tak si pak zkopírujete operace do svého kódu z https://github.com/apache/nuttx-apps/blob/master/examples/pwm/pwm_main.c Z té diskuze jak to vidím, je Arduino ještě mnohem větší tragedie něž jsem si myslel. Ano NuttX v tomto případě má větší o něco overhead, ale pokud se nejedná o výrobu miliónu systému třeba na battery management, kde i dnes se třeba řeší snížení potřeby Flash z 2 kB na 1 kB tak, že to někdo intrukci po instrukci půl roku ladí (náklady na práci >0.7 Mkč) tak nepatrně dražší procesor pro hobistu není problém. I když mu 500 kč ušetří den trápení, tak to má smysl. Auduino podle přístupu odpovídá někde začátku 80.let... Jinak to kompletní API PWM takto s multichannel at. možná vypadá složitě, ale tam kde potřebujete synchronně nastavit více výstupu na PMSM nebo krokový motpor tak to je potřeba. Jinak my to v pysimCoderu zakryjeme přetažením bločku z knihovny a nastavením frekvence jako parametr. jeho kód je zde https://github.com/robertobucher/pysimCoder/blob/master/CodeGen/nuttx/devices/nuttx_PWM.c Opět je to složitější, protože se nastavuje kanálů více. Jeden kanál by byl něco jako
int set_pwm(int chan, int freq, int duty)
struct pwm_info_s info;
int fd = open(/dev/pwm0, O_RDONLY);
info.frequency = freq;
info.channels[0].channel = chan;
info.channels[0].duty = duty;
if (CONFIG_PWM_NCHANNELS > 1)
info.channels[1].channel = -1;
return ioctl(fd, PWMIOC_SETCHARACTERISTICS,
(unsigned long)((uintptr_t) &info));
close fd;
}
Pokud to pak chce někdo chce používat úplně jako Arduino, tak si tuto funkci může natáhnout z nějaké knihovny... Tu by vlastně nějaký propagátor Arduina mohl napsat, nebylo by to těžké a nešťastníci z tohoto světa by pak mohli své aplikace převést na NuttX a postupně přestat Arduino API používat.
Jinak příklad je neefektivní, PWM se vyplatí otevřít jednou, frekvence se také nastaví jednou a v dalších se vynechá atd...
IOCTL přístup má výhodu, že i při kompilaci NuttXu s MMU to bude chodit stejně. A je to vlastně stejně jako na GNU/Linuxu...
Ale souhlasím, že MBed a ESP-IDF to bbude mít jednodušeji a s menším overheadem. Ale i obecný kód na správu vláken a další bude proti API, které bude dále nepřenositelné. U NuttXu a RTEMSu je často možné až po jednoduchý webový embedded server kód kompilovat s minimálními úpravami jak na BSD. GNU/Linuxu tak RTEMSu a NuttXu....
9.3.2023 12:19
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Pokud má být Arduino trochu obecné API, tak jak je možné že PWM nemá možnost nastavení periody.Protože někdo vymyslel že je to out of scope. (není to nastavení jednoho registru, ale obecná funkce vyžaduje řešení, že různé procesory s různou taktovací frekvencí budou umět PWM jenom třeba pro nějaké konkrétní frekvence, ne?)
Ano NuttX v tomto případě má větší o něco overheadArduino neoptimalizuje na overhead (viz naprosto příšerně pomalé funkce digitalWrite), i když teda teď si nemůžou moc vyskakovat protože se zasekli na AtMegách s 32 KiB flash a 2 KiB RAM. Arduino optimalizuje na vstupní bariéru.
Kdybych měl vymýšlet API které by se mi líbilo, tak bych si představoval něco takového:Ale PWM nemá garantovanou frekvenci, jako že vůbec (hardwarově závislá), a na tomhle procesoru to je cca 250 Hz. Takže nemůžu použít zabudovaný analogWrite.Nebo jak by se to mělo řešit? Takhle sis to napsal ručně, stejně jako bys to dělal jinde.
pwm_out(pin, duty_cycle, hz=256, timer=timer0)
pwm_out_exact(pin, duty_cycle, hz=256, timer=timer0)
set pin as PWM output, implemented by the specified hardware timer.
The pin must be configured for output beforehand, using the pinMode() function.
By default, it uses timer0 that is also used by delay() and similar functions: this won't cause them to malfunction (as the resulting program stores enough information to calculate necessary delays internally), but can cause decrease the available granularity. If this is an issue, use a dedicated timer.
The available frequencies are hardware-specific: the pwm_out() function uses the closest available frequency provided by hardware, the pwm_out_exact() fails if the requesrted frequency can't be configured (the failure is reported when the program is compiled: it is guaranteed to never fail at runtime). Officially supported board packages report the closest available frequency in the error message: we encourage independent implementors to do the same.
Jako určitě to není triviální na naprogramování, ale Arduino není C ani C++, takže můžou do toho jazyka přidat featury které C ani C++ nemá, jako třeba statickou kontrolu platnosti argumentů nebo příčetný makrosystém (tak bych to řešil já: potřebné výpočty by dělalo makro, a to by taky mohlo vrátit chybu etc). Pro každou desku mají podpůrné knihovny, takže technicky by to možné být mělo. Myslím že tohle by bylo přístupné i začátečníkům (díky statické kontrole a rozumným defaultům) a zároveň jim to zpřístupnit i pokročilejší funkce.
Nebo by aspoň mohli mít v dokumentaci odkaz co hledat v manuálu, jak ty timery používají interně a garantovat co se rozbije a co ne když některý překonfiguruju: když jsem to tehdy řešil, tak informace byly "rozbije se delay() a další podobné" a nikde jsem nenašel konkrétní seznam.
Arduino neoptimalizuje na overhead [...]. Arduino optimalizuje na vstupní bariéru.To není tak docela pravda: Arduino optimalizuje na vstupní bariéru jen pro některá použití, a za cenu toho že každá jen trochu složitější věc je celá na tobě. Viz ten můj příklad: nemohl jsem PWMovat softwarově kvůli blbé implementaci analogRead(). Myslím si, že sofistikovanější systém by mohl být přístupný pro začátečníky a přitom zpřístupnit i pokročilejší funkce hardwaru (tj. být přístupnější pro víc lidí).
Pokud má být Arduino trochu obecné API, tak jak je možné že PWM nemá možnost nastavení periody.No a to právě kritizuju. Scope měl být širší. S hromadou HW komunikuje pomocí PWM, a obvykle ten HW má nějaké požadavky na frekvenci.Protože někdo vymyslel že je to out of scope.
Arduino není C ani C++Tohle čtu už poněkolikáté a pořád nevím co si pod tím představit. Já když kompiluju pro AVRkové Arduino, tak to pouští avr-g++ a nic dalšího. To je jejich bundlované avr-g++ nějak brutálně opatchované? Když jsem si trochu četl jejich základní knihovny, tak mi to taky přišlo jako normální C s trošičkou C++.
S hromadou HW komunikuje pomocí PWM, a obvykle ten HW má nějaké požadavky na frekvenci.Já jsem PWM potřeboval 2x v životě, jednou pro topení, kde jsem navíc potřeboval cyklovat pin mezi HI a TRI, takže jsem si to stejně musel dělat softwarově, a jednou pro větráky; v obou případech byla frekvence buřt (byť těch defaultních 450 Hz nebo kolik bylo pro ty větráky málo, bzučely, tak jsem to zvedl popsaným způsobem; pak jsem se ale na PWM vykašlal a jenom přepínám mezi 12V a 24V větví, protože se mi nechtělo řešit EMI, přechodové jevy u mosfetů a kdo ví co dalšího by to způsobilo).
Viz ten můj příklad: nemohl jsem PWMovat softwarově kvůli blbé implementaci analogRead(). Myslím si, že sofistikovanější systém by mohl být přístupný pro začátečníky a přitom zpřístupnit i pokročilejší funkce hardwaru (tj. být přístupnější pro víc lidí).Jasně, bohužel konkurence co se o tohle snažila taky nebyla moc úspěšná, tak je to asi složitější problém než jak to vypadá.
návrh je vrcholem amaterismuJá bych viděl problém v tom, že se na věc díváte z pohledu vysokoškolského pedagoga a z pohledu člověka z oboru, přičemž v obou případech správně docházíte k nesprávnému závěru. Pokud já vím, Arduino měla být hračka pro středoškoláky. Toto připojte do počítače, toto nainstalujte, hurá, programujete mikroprocesor. Vzhledem k tomu, jak se ten ekosystém rozvinul, to zjevně plní dobře. Nemyslím si, že účelem mělo být do posledního MHz využít výkon toho procesoru nebo dělat složitější věci, které potřebují pokročilejší nastavení toho hardware. Tj. ano, neumí to spoustu věcí, bez kterých si vy nedovedete představit práci s MCU, ale to podle mě ani umět nemá. A pokud se pokusíte to doplnit, vytvoříte akorát horší verzi něčeho, co už existuje, přičemž ztratíte to, co Arduino momentálně přináší, tedy jednoduchost pro začátečníka.
Na AVR je tohle o něco lépe, ale vyhovující to, pokud vím není.Jediný problém je při přístupu do programové paměti nad 64kB, tj. nad rozsah 16bit pointeru. To se musí řešit nějak extra (32bit datové typy místo pointerů), jinak stačí __attribute__((__progmem__)). A jinak to, že pointer do flash a RAM ukazuje na jiná data, to je holt vlastnost Harvard architektury, když ten čip nemá kompletní mapování všech pamětí do jednoho prostoru. V součtu žádný velký problém.
Dále každé předání intu mezi IRQ a kódem musím hlídat...To bych bral jako obecný problém vždy, když se pracuje s datovým typem delším, než je nativní. Což u 32bit čipů asi moc často nebude, uznávám, ale - upřímně - u toho osmibitu si člověk z větší částí s těmi 8 bity vystačí.
Co se týče rozumného čipu/kitu pro nadšence a připojení se na nožičky, tak třeba řada PIC32...... podle Wikipedie v dané době neexistovala.
Takže alternativ, které jsou o třídu dále jak v architektuře tak poměru výkon/cena než 25 let staré AVR tu je mnoho.Dneska. Vizte poslední odstavec mého předchozího příspěvku. S MCU dneska taky pracují lidé, kteří se to naučili před dvaceti lety. A dokud jim AVR slouží, tak proč by měli měnit?
Na druhou stranu se nemusí trápit s tím, že zrovna potřebuji dva UARTy a tak druhý na slabém CPU řeším přes emulaci v IRQ za cenu ztráty poloviny výpočetního výkonu atd...Vývoj těch osmibitů se taky nezastavil, takže situace, kdy člověku chybí druhý UART, nastane akorát v případě, že se do ní dotyčný dostane vlastní chybou.
V každém případě argument že k AVR není ekvivalentní alternativa nepřijímám.Reakce výše, alternativy nejsou ekvivalentní, pokud vyžadují náklady na přeškolení.
alternativy nejsou ekvivalentnísouhlasím, po technické stránce jsou lepší
pokud vyžadují náklady na přeškoleníopět souhlasím, ale pokud se jedná o jen trochu vážněji míněný projekt, tak ta znalostní úroveň odpovídající Arduinu je proti jeho ceně zanedbatelná. Pokud se jedná i o nejčisčího hobistu jen s trochou zájmu o obor, tak by ho naopak dozvědět se nepatrně více mělo lákat a pak mu to ušetří čas, viz ten potvrzený CONST a další AVR hrůzy. Potíž je, že mnoho Arduninistů si především z potřeby kolektivní soudržnosti vzájemně potvrzuje, jak je přestup těžký (což v případě nešťastné volby může být i pravda) a zbytečný a tak tento svůj Stockholmský syndrom závislosti vnucují nováčkům. Moje reakce na nadšené vítání Arduino GIGA R1 WiFi je pak především protiváhou na otevření očí těm, kterým Arduino sebere zbytečně čas. A ano, zároveň sbírám a hledám cesty, co ostatní nabízí jako alternativy a sám rád i předám to, co znám a považuji za přínosné a třeba i někde přispěji, aby se ta bariéra snížila. Pokud by se třeba našla skupinka s Teensy 4.x nebo ESP32 a nebo i kombinacemi všeho možného a chtěla si v rámci LinuxDays nebo i jindy udělat workshop, kdy zkusíme, na čem všem nám najede NuttX nebo si zkusit RTEMS na našich deskách se Zynqem nebo něco podobného, tak rád čas investuji. A můžeme z toho udělat zápis, co se ukáže jako rozumné a co má větší vstupní bariéru. Pro studenty pak třeba informace přidám na stránku předmětu Procesorové systémy pro vlastní aplikace. Jinak pro mě i tato diskuze byla dobrá, potvrdila mi, že i sami Arduinisti často vidí ta omezení a nekvalitu návrhu, další přímo popisují, že jeho kód je na zvrácení obsahu žaludku atd... Zároveň se objevily jak nápady na RUSTOvá řešení pro MCU tak odkazy na návody na bare metal. Probraly se nápady na RTOS atd...
po technické stránce jsou lepšíJenže o čistě technické stránce nemluvíme, to je první věc - a druhá je pak to, jestli skutečně jsou univerzálně lepší. Mají lepší technické parametry, to je bez debaty, ale proč jsou lepší? Pro připomenutí: bavíme se o aplikacích, kde osmibit výkonem s rezervou stačí.
ta znalostní úroveň odpovídající Arduinu je proti jeho ceně zanedbatelná.Já mám za to, že už se nebavíme o Arduinu, ale obecně o používání osmibitových MCU.
viz ten potvrzený CONST a další AVR hrůzy.To, čemu vy říkáte potvrzený const a další hrůzy, nejsou žádné hrůzy, ale něco, s čím se dá úplně normálně pracovat. Pro člověka, který to s mikrokontroléry myslí jen trochu vážně, by podle mě skutečně nemělo být problémem zvládnout
const type name PROGMEM = value místo const type name = value. (Navíc podle náročnosti projektu na hardware - konkrétně na RAM - ten atribut lze vynechat, gcc zajistí překopírování do paměti při startu programu.)
nepatrně více mělo lákat a pak mu to ušetří časSkutečně? Lákat budiž. Ušetří čas - pokud ten hobbyista už umí pracovat s AVR procesory a pro jeho následující projekt(y) AVR postačuje, přechod na 32bit je čas čistě ztracený (+/- naučil se něco nového pro radost z toho, že se to naučil, i když to nepotřeboval.)
const type name PROGMEM = value
To často není jen o toto, všechny funkce, které mají být připravené na příjem alternativního ukazatele buď musí existovat ve dvou variantách nebo je nutné přidat režim kompilátoru, kdy ukazatele rozšíří o další byte atd... Jak uděláte strcmp mezi stringem v PROGMEM a v RAM, jak napíšete obecný map, který mapuje tstrring na něco, když většinou ho chcete plnit CONST stringy, ale někdy i nějakým runtime generovaným. Opravdu myslím, že vím o čem mluvím. Ano, používal jsem roku 8051, ale bylo to proto, že jsme procesor za 1500 kč v roce 1992 do zařízení dát kvůli ceně nemohli. Takže jsem si na hraní 68332 kit kopl, ale v práci se trápil s tím assemblerem IDATA, DATA, XDATA, CODE... někde jsem dokázal kód navrhnout i v C a přenositelný až na x86_64, ale přepsání mnoha dalších funkcionality na ARMy a další stálo roky práce. Na rozdíl od i dnešních zaslepenců jsem to již v době psaní v ASM věděl a spíše nebylo vyhnutí. Přitom jsem znal Z80, i stou by to bylo o řád lepší, ale nebyla v integraci s periferiemi, takže 80552 byla z pohledu cílových aplikací lepší volba.
Ale tato doba/cela je 20 let pryč. Tak proč se do ní vracet i když trošku s novějším polstrováním.
Jak uděláte strcmp mezi stringem v PROGMEM a v RAMPodle dokumentace AVR libc bych zkusil
strcmp_P(str_in_ram, str_in_progmem);. Ano, v programu pak ta funkce bude ve dvou variantách, ale má 9 instrukcí, takže se to nejspíš přežije.
Opravdu myslím, že vím o čem mluvímTo asi nikdo nepochybňuje, ale za mě se konkrétně pro AVR zdá přehnaná ta "hroznost".
Tak proč se do ní vracet i když trošku s novějším polstrováním.Vracet se k osmibitům by - pokud dnes platí, že cena procesorů a dostupnost vývojových prostředků jsou srovnatelné pro osmibit i ARM/RISC-V - smysl nedávalo. Když s tím umíte, tak to používejte. Jenže já jsem v diskuzi nikde nenavrhoval, aby se do té doby někdo vracel. Já tady celou dobu tvrdím jenom to, že existují důvody v ní zůstat - nebo přesněji že neexistují důvody přecházet na něco novějšího (pro ty vývojáře, pro které je ten osmibit dostatečný a vámi zmiňované problémy nepociťují.)
Ale pro nováčky je nutné udělat maximum, aby v něm neuvízli.Určitě dělejte, je to vlastně vaše práce
Za mě je nicméně výsledek, kdy nováček začne s osmibity a od té doby si s nimi vystačí, dostatečně dobrý výsledek. (A já si nějaké pokusy s RISC-V dám do TODO - i když asi někam, kde se k tomu nejspíš v životě nedostanu. Kde jsou ty časy, kdy byl čas, že...)
Ty brdo, rekl bych ze v tom assembleru jste si docela uzil.Ano a i když jsem to psal, tak jsem věděl, že je to špatně. A dnes již není žádný ekonomický ani jiný důvod to takto špatně dělat. Uvědomte si, že opravdu vím, co říkám, mars2 má podle cloc Assembly 15689 řádek. Sdílená knihovna pblib 12288. Celé naše projekty na SW51 131072 řádek assembly a 7120 comment a 14379 blank. Jinak motion control knihovnu i sPIDy a vším jsem Vám v C nabídl mnoha verzích. Ta naše je to PXMC, ekvivalent toho 8051 ASM je zde /pxmc_core/pxmc_con_pid.c, verze s nelinearitou pxmc_core/pxmc_con_pidnl.c, to je ekvivalent té další v ASM. A ano i na 32 mc68372 jsem nakonec core algorimnu musel přepsat do ASM, když jsem chtěl z jedné osy přejít na 8. Přece jenom je to CPU s 21 MHz hodinami, 16-bit externí sběrnicí a jen dobře volené 16-bit kódované instrukce se vykonají ve dvou cyklech. Takže jsem z CISCové sady, kde to šlo, vybíral vlastně RISCové instrukce pxmc_bsp/mo_cpu1/mo_fastreg.S regulátor a generování ramp pxmc_bsp/mo_cpu1/mo_fastgen1.S. Knihovna C 11305, halvičky 5044, ASM 1090, celý projekt s nataženými submoduly 50535 řádek (bez komentářů a blanků atd..). Řídí třídění třídění kamínků v precose, naskenoval Langweilův model Prahy, oživil a řídí již asi 20 let studentům robota BOSCH SR 450, kterého vyhodily ze ŠkodaAuto, protože s původní jednotkou nikdy spolehlivě nechodil, po tom, co odkráčely do křemíkového nebe jednotky ke kanadským robotům CRS, tak jednotky určené původně pro 3x slabší motory převzaly jejich funkci a další desetiletí pracují. Josu to již nějaké argumenty, abyste mi věřil trochu více než třeba panu Martinu Malému, který odsoudil před lety naší výuku základu činnosti počítače podle světových učebnic a prohlásil, že máme učit s AVR nebo 8080. Přitom na nich vysvětlit princip přístupu k paměti, adresování, integer operací je o řád složitější. Pan profesor ze Švýcarska nemá čas a potřebu stavět lodě v láhvi a pozorovat hoření bastlů, přispěl k několika systémům podobným Matlabu/Simulinku, je dvorním poradcem firem Maxon a Faulhaber atd... A také ve svém okolí bojuje s novou generací lenochů, kteří do laboratoří místo jím a komunitou vybudovaných znalostí a know how chtějí Windows only řešení za 100x více financí na kterém ty vnitřní principy a skladbu nepůjde předvést, je tajná... Zároveň musí pro své udržení psát články, podávat granty atd... Na blbá řešení nemá čas a není mentálně zaseknutý před 40 lety, i když v té době studoval na ETH Zurrich... Takže asi tak... Jinak ano, maximální latence na Linuxovém jádře bez fully-preemptive podpory je reálně unbounded. Užijte si taková PLC na RaspberryPi. Ono většinou je běžné jádro na propustnost a průměrné latence trochu lepší. Jen za určité kombinace na síti, připojení USB, přepnutí grafického režimu atd.. tam mohou být i sekundy... My se znašíme na všech výše uvedených systémech i na Linuxu řídit motory na milisekundě nebo lépe. LX_RoCoN (stejné 20 let používané PXMC) jede na 4kHz proudové až polohové řízení a přepočty a akumulaci mezi D,Q a ABC jeden synchronně s PWM na 20 kHz na koprocesoru v FPGA. Ale má to vlastně smysl tady někomu vysvětlovat. Snad těm, co mlčí a ví o této diskuzi své. Jinak to co zde odkazuji, je zlomek mých projektů, na základě kterých předávám zkušenosti, zde je přehled z těch otevřených, které jsou registrované na OpenHub.
"s novou generací lenochů, kteří do laboratoří místo jím a komunitou vybudovaných znalostí a know how chtějí Windows only řešení za 100x více financí"Není to i tím, že si (něco jako) ty osmibity nikdy nezkusili? Nového psa starým kouskům nenaučíš
Ano před 30 lety jsme motory řídili z 8051...Řešíme otázku, proč jsou 32bit procesory univerzálně lepší než osmibity. Vaše odpověď je - už poněkolikáté - že jste před třiceti lety něco dělal nějak. Ano, možná to byl úctyhodný výkon, ale v kontextu diskuze v době dnešní, kdy ty osmibity jsou pětadvacetkrát rychlejší jen na počtu instrukcí za sekundu, velmi irelevantní. Ten podsouvající výpad o sledování amatérů, tím jste to také moc nevylepšil. O tom videu jsem se zmínil, protože jsem na něj narazil náhodou a bylo k diskuzi relevantní. Viděl jsem z něj asi dvě minuty - v podstatě tolik času, kdy bylo zjevné, že se problémy očekávatelné u řešení s Arduinem skutečně objevily. No a ten konec... argument autoritou. "Proč jsou ty procesory univerzálně lepší?" "Protože jsem to řekl a mám 30 let zkušeností." To, prosím, není argument, to je pouze ukázka jeho absence. 30 let zkušeností vám jistě nikdo upírat nebude, ale ta didaktická stránka se vám tedy nepovedla ani za mák.
Josu to již nějaké argumenty, abyste mi věřil trochu více než třeba panu Martinu Malému, který odsoudil před lety naší výuku základu činnosti počítače podle světových učebnic a prohlásil, že máme učit s AVR nebo 8080. Přitom na nich vysvětlit princip přístupu k paměti, adresování, integer operací je o řád složitější.Jak se liší princip integer operací u různě velikých integerů? (Odpovím sám: nijak.) Přístup k paměti je v principu také stejný a totéž adresování, pokud se tedy úmyslně nefixujete na to, že jedna paměť není mapována do jiné - což je implementační detail a na principu, o které mluvíte, nemění nic. Jinak vaše argumenty jsou pořád o tom samém. Dělali jsme toto a tamto a na osmibitu to bylo špatně, tak jsou vždycky špatně.
Ale má to vlastně smysl tady někomu vysvětlovat. Snad těm, co mlčí a ví o této diskuzi své.Těm, co s vámi nekriticky souhlasí v tvrzení, že pokud existují nasazení, která osmibitem skutečně neuřídíte, tak pro všechna existující nasazení platí, že ne-osmibit je univerzálně lepší. S tvrzením, které jste nebyl schopen dokázat lépe než "já to říkám"
Zaprvé dokládám, o kolik je psaní složitější na architektury nepřipravené pro jazyky typu C ... předvedl jsem na progmem že tam ty problémy stejně, sice na méně místech, zůstávají.Jenže to je jenom důsledek (vaší) volby. Jazyk C lze na AVR používat zcela plnohodnotně bez jakýchkoliv specialit. Ano, důsledkem bude, že se mi data + const + stack musí vejít do RAM, ale to (že bez přizpůsobení kódu mimo čistý jazyk C často nelze využít všechno, co procesor nabízí) není výlučná vlastnost osmibitů. Kdyby vše šlo napsat v C, nemusí být v kernelu kusy kódu v assembleru. Tj. progmem se mě týká až ve chvíli, kdy chci možnosti toho čipu využít nad to, co mi nabízí C.
Intel se nepoučil a místo 64-bitů pak vymyslel i v 32-módu 36 bitů fyzické adresy.Vzhledem k tomu, jak dlouho poté ještě trvalo vytvořit skutečný 64bit x86 procesor, se jim úplně nedivím.
AVR není až tak hrozné, má ofsetovou adresaci proti 16-bit registru. Ale nemá sečtení dvou 16-bit dvojregistrů. Má alespoň...No ale to přece není relevantní. Jasně, nutně to vede na rozdělení jedné operace na více instrukcí, ale to už je holt starost pro autora překladače - stejně jako když na 32 bit architektuře budu sčítat 64 bit proměnné. Jako programátor bych pak vždycky měl mít na paměti, s jakým procesorem pracuju a jestli není data potřeba chránit proti souběžnému přístupu z více míst, když je něco rozpracované - to taky platí pro MCU i pro velké procesory. Tedy v součtu bych neřekl, že dokládáte - podle mě pouze tvrdíte.
Stejně tak AVR32 byl rozumný krok vpřed, to nevydrželo konkurenci ARMu.Nesouhlas. V teoretické rovině možná krok vpřed, v praktické rovině to nemělo moc šancí na úspěch právě kvůli zavedené konkurenci ARMu a nejspíš si to nikdy nevydělalo aspoň na náklady na vývoj (zajímalo by mě, jaký vliv to pak mělo na to, že Atmel skončil jako majetek Microchipu)
Ale AVR za horizont blikání LEDkou není na místě.To jsme pořád u toho, k čemu bych se rád dobral: proč? Existuje pro toto tvrzení nějaký podklad kromě toho, že kód (který programátor v C ani nevidí) musí některé věci dělat ve dvou cyklech místo jednoho?
Pak člověk vidí ty shieldy, kde periferie s WiFi, Ethernetem nebo čímkoliv jiným má řádově větší výkon, než ta programovatelná část...To bych taky neviděl jako argument proti osmibitu. Jasně, pokud si můžu vybrat jiný čip, který příslušnou periferii má integrovanou, tak je to určitě vhodné zvážit. Ale není to přímo argument proti tomu osmibitu. Grafická karta má také vyšší výkon než CPU (pro grafické operace) a přesto tu netvrdíte, že by všichni měli stavět počítače z grafických čipů. Mít periferie s otevřeným firmwarem by bylo hezké všeobecně, ale to se dostáváme k jinému tématu.
Ale ve výše uvedeném se opravdu již opakuji a vy zase prohlásíte, že to není argument.Ano, když se opakujete, tak já se opakuji. "Důkazní břemeno" pro tvrzení nicméně zůstává na vás.
Co se pak týče výuky, tak nevím o známější světové univerzitě (MIT, Berkley, ...), která by s AVR v posledních 20 letech architektury počítačů učila.Co střední školy? Začít u vysokoškoláků u čipů, které na pochopení potřebují vysokoškolské vzdělání, to bych i bral, tam pracujete s nadprůměrnými studenty. Ale nedokazoval bych na tom, že je něco obecně lepší. ---
Proč má začátečník řešit, jestli je stack pointer 8-bitů, 16-bitů, potřeba řešit typy volání atd.To si nejsem jistý, proč se mě ptáte - podle mě nemá a neměl by, to za něj vyřeší překladač. Pokud nebudu pracovat jen v assembleru samozřejmě, ale pak je požadavek na znalost hardware očekávatelný. Samozřejmě pokud to neměl být nějaký důkaz kruhem, že jediná správná velikost stack pointeru je 32 bitů S typy volání teď bez kontextu nevím, co máte na mysli. Ten odkaz na volby překladače nechápu, gcc pro RISC-V a pro ARM žádné nemá? Jako že si nemusím vybírat, pro jaký čip překládám? To se mi moc nezdá. To, že pro překladač existují automatické testy, které mají podchytit chyby při vývoji, bych považoval za plus a ne za něco, co by se mělo vytýkat nebo považovat za důkaz, že je něco špatně. Analogie: tady jsou různé testy podivností, aby se Linux udržel funkční. (Odkaz na testovací farmy pro linuxové jádro, si domyslete.) ---
A až teď jsem si všiml, že mi vlastně podstrkujete toto prohlášení, to jsem nikde neřekl.Je to zjednodušené znění, ale vyplývá mi to z toho, že AVR je dobré akorát na blikání LED a víc nic - a podobných tvrzení z předchozí diskuze. A z následujícího také:
Já prohlašuji, že pro moderní CPU uvažované do nových aplikací je zásadním požadavkem sada aritmeticko-logických operací (alespoň sčítání, odčítání, logické operace a bitové posuny) mezi dvěma registry a šířka základních registrů taková, aby odpovídala alespoň délce obecného ukazatele, který je schopný adresovat veškerý prostor pro instrukce a data v paměti, stejně jako ukazovat na libovolnou funkci v adresním prostoru. Dále by měla architektura umožnit načtení a uložení registru (stále alespoň o délce obecného ukazatele) na jednu instrukci.A na to nezbývá než se zeptat proč. Proč je tak zásadní mít tak velké registry, aby se do nich vešel ukazatel, aby to rozhodlo o tom, jestli daný čip použít nebo ne. Protože - hledal jsem narychlo - třeba to řízení motorů, které zmiňujete, jsem pro AVR našel. BLDC motor, sensorless řízení za využití periferií plně dostupných v tom čipu (kromě jednoho OZ u "DA" varianty toho AVR.) Jestli dobře koukám, tak jsou zapotřebí nějaké krátké obsluhy přerušení, ale základ běží přímo v hardware (3 fáze, active freewheeling.) Pro ten RISC-V, po kterém koukám, jsem nenašel nic. Teoreticky by podle datasheetu měl něco takového umět, prakticky mi přijde, že s omezeními a na první pohled nevidím, jak by se řešil ten freewheeling (ale datasheet psal někdo, kdo neumí anglicky a dobře zná ten čip, takže to podle toho vypadá - a tedy těžko říct s jistotou.) Proč bych měl při dalším návrhu upřednostit, že ten RISC-V má [ požadavky, které popisujete výše ] a hledat, jestli s ním půjde vyřešit danou úlohu, místo toho, že na AVR vím, že úlohu půjde vyřešit a krátké (oproti pointeru) registry nejsou na překážku...
Mit adresovani a obecne adresni aritmetiku na jednu instrukci je naprosto zasadni vyhoda - od rychlosti, pres usporu bytu a IO, az po subjektivni "eleganci" reseni. Base+offset register pair, nebo PAE a podobne triky sice funguji, ale je to hnus fialovej.Já prohlašuji, že pro moderní CPU uvažované do nových aplikací je zásadním požadavkem sada aritmeticko-logických operací (alespoň sčítání, odčítání, logické operace a bitové posuny) mezi dvěma registry a šířka základních registrů taková, aby odpovídala alespoň délce obecného ukazatele, který je schopný adresovat veškerý prostor pro instrukce a data v paměti, stejně jako ukazovat na libovolnou funkci v adresním prostoru. Dále by měla architektura umožnit načtení a uložení registru (stále alespoň o délce obecného ukazatele) na jednu instrukci.A na to nezbývá než se zeptat proč. Proč je tak zásadní mít tak velké registry, aby se do nich vešel ukazatel, aby to rozhodlo o tom, jestli daný čip použít nebo ne.
errorprone mapovani highmem pametiJestliže chcete tvrdit, že mapování highmem paměti - pokud tímto pojmem označujete adresu uloženou v páru registrů, což je jeho ohýbání do krajnosti - je error prone, bylo by dobré ukázat, jak je to k těm chybám náchylné. Podle mě totiž není, C kód a jeho programátor zcela ignorují, jak a kde jsou adresy uloženy - to je úloha pro překladač. A v assembleru, kdybych tedy chtěl vybočit z používání C, mám registry pojmenované rL a rH, což taky není nijak záludné a náchylné k záměně.
Pokud ve vašem předchozím příspěvku bylo adresování a adresní aritmetika na jednu instrukci naprosto zásadní výhodou, pak velikost registru (ze které vyplývá ne/možnost takovou aritmetiku mít) nutně musí souviset s výkonem. Užitečným výkonem samozřejmě.Samozrejme ze prepocitavani adres nejaky vykon sezere. Pointa je jinde - nezdrzovat se ve 21. stoleti hackovanim osmibitu pro >256 B pameti/aritmetiku kdyz sestnactibit udela tu samou praci efektivneji (a se snazsim debugovanim dumpu, kdyz je potreba).
Podle mě totiž není, C kód a jeho programátor zcela ignorují, jak a kde jsou adresy uloženy - to je úloha pro překladač.Ano, vyssi jazyky to ignoruji. Ovsem ve vyssich jazycich se zase tezko delaji potrebne obezlicky/optimalizace, takze se clovek stejne __asm() nevyhne. Ja mam zkusenost takovou, ze co si v asm nenapisu, to nemam - a cim min prekazek danych architekturou, tim lip. Muj cas straveny resenim adresace je drazsi nez pouziti CPU s dostatecne velkymi registry.
Samozrejme ze prepocitavani adres nejaky vykon sezere.Já si taky myslím, ale psal jste, že velikost registru s výkonem nesouvisí
Ano, vyssi jazyky to ignoruji. Ovsem ve vyssich jazycich se zase tezko delaji potrebne obezlicky/optimalizace, takze se clovek stejne __asm() nevyhne. Ja mam zkusenost takovou, ze co si v asm nenapisu, to nemamBudiž, pokud ten procesor potřebujete dojit na krev, tak ten osmibit asi nebude pro vás. Tím ovšem není dokázána obecná platnost tvrzení, že osmibity jsou k ničemu
Muj cas straveny resenim adresaceMožná by stačilo adresaci neřešit?
Nevím teda, na jakém procesoru jste ji musel jak řešit, ale já s tím neměl problém ani v assembleru.
Řešíme otázku, proč jsou 32bit procesory univerzálně lepší než osmibity.A až teď jsem si všiml, že mi vlastně podstrkujete toto prohlášení, to jsem nikde neřekl. MSP430 (16 bit nebo 20 bit verze) jsem s pochvalou uvedl v textu vícekrát již dávno před touto Vaší interpretací. Já prohlašuji, že pro moderní CPU uvažované do nových aplikací je zásadním požadavkem sada aritmeticko-logických operací (alespoň sčítání, odčítání, logické operace a bitové posuny) mezi dvěma registry a šířka základních registrů taková, aby odpovídala alespoň délce obecného ukazatele, který je schopný adresovat veškerý prostor pro instrukce a data v paměti, stejně jako ukazovat na libovolnou funkci v adresním prostoru. Dále by měla architektura umožnit načtení a uložení registru (stále alespoň o délce obecného ukazatele) na jednu instrukci. Již jen důsledkem je nepřípustnost segmentování a stránkování nějakým dalším pomocným registrem. Stejně tak režim s vypnutým MMU by měl obsáhnout běžným ukazatelem celý fyzický adresní prostor. Toto nesplňuje 8086, AVR, 8051. Naopak splňuje m68k i počátečním omezením na 16x16 na 32 násobením, 16 a 20 bitů MSP430, 16-bitové H8S s 32-bit dvojregistry, SH s 16 bit instrukcemi a 32 i 64 bit architekturou, ARM, RISC-V 64 a malé RISC-V bez stránkování a s SV32... Dále je kritická možnost adresovat v rozumném rozsahu relativně proti registru, struktury, automatické proměnné na zásobníku. Pro větší procesory je kritická podpora dynamických knihoven a tedy podpora relativní adresace proti čítači instrukcí, toto nesplňuje x86 v 32-bitovém režimu, výsledkem jsou problémy s zjišťováním PC přes relativní volání, originální MIPS v prvních verzích je pak ještě větší katastrofa, protože ani relativní volání nemá a k PC se dostat nelze. Kód ještě větší míra ošklivosti a povinné indiskrece volání přes registr, výkonnostní katastrofa... Další důležitý faktor je návrh knihoven a běhového prostředí, to je kritického základu, který mí být vzorem a ne ostudou.
A až teď jsem si všiml, že mi vlastně podstrkujete toto prohlášení, to jsem nikde neřekl.
Pavle, to dělá Bourek běžně. Je to prostě omezený kokot a ty furt s ním jak s máslem.
Kup si plyšáka a jeď s ním na dovču. To ti udělá dobře. Jenom si ho nezapomeň řádně přikurtovat, ať ti neupade z nosiče až s ním pofčíš o závod lesní pěšinou a narazíš. A nebo víš co? Pošli ho raději samotného, ať mu tu dovolenou nekazíš.
Navíc vám to pomáhá, abyste svou umělou inteligenci nemusel trénovat na nových datech.
Těch se od tebe nikdo nedočká pupmpičkáři. S tím se počítá. Protože kde nic není, ani smrt nebere.
Arduino optimalizuje na vstupní bariéru jen pro některá použití, a za cenu toho že každá jen trochu složitější věc...Složitější věc nicméně už není vstup do problematiky, tj. pokud se do ní pouštíte, Arduino splnilo svůj účel, protože vstupní bariéra je překonána. Jde jen o to Arduino včas opustit.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
