Hlavní navigace

Názory k článku Senzory Martina Malého: Jak rychle a s minimálními náklady prošlapat slepé cesty

Článek je starý, nové názory již nelze přidávat.

  • 7. 6. 2017 9:37

    Stratos (neregistrovaný) ---.torservers.net

    Moje řeč! Bez vývojových kitů a licencí za tisíce dolarů se přece nedá protypovat! Taky se to nedá naučit za běhu! To člověk nejprve jde na pořádnou vejšku a pak se zavře na pár let do bubliny a pak z ní vyjde jako super programátor s úžasnou praxí. Magic! A do té doby se nesmí na mikrochip ani podívat. Ještě by mohl něco užitečného za pár dolarl udělat a něco se naučit!

  • 8. 6. 2017 13:27

    PavelM (neregistrovaný) 2001:718:1001:----:----:----:----:----

    Asi nemá smysl se grafomansky rozepisovat k jednotlivým bodům, ale:
    - Vaše původní výtka směřovala k platformě Arduino, tedy procesory ATMega*, STM32*, apod. K tomu jsem směřoval i svou odpověď.
    - O LED multiplexu v původním příspěvku nebylo nic napsáno, pouze o LED. Předpokládal jsem tedy 7-segmentové číslice, externí registr pro 7-segmentové displaye a jeho využití. A tam překreslování 2x za sekundu bude dostačovat.
    - Buď se bavíme o jednoduchých procesorech a tam nebude ta přesnost opravdu dosahovat ±2ppm toho DS3231 (a tak jsem to opravdu myslel), nebo o procesorech kde je už je interní RTC stejně přítomno (otázkou, v jaké kvalitě) a nemusíme to počítat "ručně".
    - proč musí být za úvodních předpokladů MCU v této aplikaci trvale napájený a ne většinu času v některém z režimů spánku s omezeným odběrem?
    - Na RTT v AT91SAM7X opravdu nenarážím, to jste si tu použil Vy.
    - Mimochodem existují i pieza s integrovaným oscilačním obvodem, tak proč to generovat na procesoru, kvůli ceně?

    Jen na okraj, opravdu si nedovedete představit vykreslování této úlohy v 1 smyčce? Ono konec konců jsme programovali i před vlákny s pomocí věcí jako select() v POSIX C, signály a časovači, a taky to muselo stačit.

  • 8. 6. 2017 17:28

    muf (neregistrovaný) ---.opera-mini.net

    Dost se tady těmi exhibicemi shazujete.
    Vývojové prostředí Arduina si nikdy nedělalo ambice být profi nástrojem. Je to věc pro začátečníky, která jim má dát možnost si osvojit úplné základy a rychle vidět, že hardware podle toho, co napsali něco dělá. Někteří zamrznou u toho, ti schopnější nebo motivovanější půjdou dál - třeba tak, že využijí Arduino bootloader a kód začnou psát pěkně od začátku, aby pochopili makefily, startup, linker script, ...., napíší si třeba vlastní scheduler, využijí knihovny, které dostanou s gcc-avr. Na Arduino Mega třeba rozchodí i JTAG debuger.
    To je cílem a vy to víte.

    Prostě se tady předvádíte....

  • 10. 6. 2017 15:42

    Miloslav Ponkrác (neregistrovaný) 194.213.53.---

    Po zákazu dynamické alokace to pak ale není C++. Dynamická alokace je povinnou součástí C++, a dokonce samotnou součástí jazyka a operátorů (new, delete, ...).

    Selhat může cokoli, nejen dynamická alokace. Selhat může tisíce věcí. Od toho je software, aby s tím počítal.

    Mimochodem, naprogramoval jsem si svůj vlastní real-time operační systém, a použil ho pro ARM s 32 KB RAM. Mám tam 256 úrovní priorit a dynamickou alokaci paměti pro programy. Funguje to dobře. Dynamické alokace jsou hlídána mutexy pro korektní funkci multitaskingu. Není totiž nutné spravovat dynamickou paměť nutně pomocí heapu - můžete být trochu kreativnější, a spravovat dynamickou paměť jakkoli je pro danou situaci vhodné. Dynamická paměť je totiž jen přidělení bloku paměti libovolné délky na žádost programu, cokoli jiného v předpokladech není (tedy ani heapová struktura správy bloků paměti).

    Prostě, pokud programátor umí, pro danou situace vytvoří vhjodné řešení. Pokud neumí, napíše dokument "Misra-C 2012 Dir 4.12" nebo jiný, proč to nejde. Dokumentů, že něco nejde jsem už četl tolik - a jen málo z nich je profesionálních. Většina těchto dokumentů tvoří bastliči, nikoli zkušení programátoři.

  • 9. 6. 2017 9:30

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    Já platformou Arduina myslím jejich SW + procesory AVR. To opravdu není žádná hitparáda a opravdu se to hodí jenom jako hračka. I na prototypování je tam řada omezení.

    Co se multiplexu týká, tak tam jsem neměl potřebu ho zdůrazňovat, multiplex se používá ve většině zapojení a i kdyby šlo o řešení s registrem, vykreslování by měl být z principu (modifikovatelnosti a znovupoužitelnosti) samostatný modul a jeho výměna za jiný (textový LCD, TFT s FT800, SAA1064 na I2C apod.) nesmí ovlivnit zbytek software. A jako takový musí mít dvě rozhraní - pro řízení (init, start, stop, spuštění vykonání) a rozhraní, kterým dostane data ke zobrazení. Jinak se má autonomně starat sám o sebe. Vtip je v tom, aby provedení refreshe s různou verzí modulu a s různým HW neovlivnila ostatní moduly, a to ani časováním. Toho se voláním ve smyčce prostě nedá dosáhnout.

    V případě vestavěných RTC rozhoduje jenom externí krystal, možnost kalibrace a to, jak ji člověk využije.

    No a ohledně napájení, tím se myslí zapojení zdroje mezi Vdd a Gnd. Bez ohledu na to, jestli procesor spí, pracuje, nebo je v RESETu. Aby byl ve spánku, musí být stejně furt napájený. Spánek se řeší tím, že se vypínají osvilátory, nebo se odpojují hodiny od modulů (protože CMOS žere jenom při změnách logických stavů).

    A pieza s oscilačním obvodem jsou fajn, pokud chci jeden tón trvale. V okamžiku, kdy chci pípat, nebo nastavit délku tónu, tak je jedno, jestli frekvenci pro piezo generuju vypínáním/zapínáním pinu, nebo to samý dělám s povolením či zákazem časovače (druhá možnost je levnější a s možností změny tónu). Takže samostatný task, který se stará o přerušování tónu a jeho ukončení.

    A realizaci v jedné smyčce si představit umím. Ale proč by to kdo dělal za střízliva, boha jeho? Máme tady něco po jednom externistovi, co tímhle stylem realizoval firmware. Všechno se ovlivňuje se vším. Zrychlili jsme komunikaci s pamětí, protože to nestíhlo komunikovat po jedné sériovce, na druhé mu to rozdrbalo timeouty apod. Dělá to tak 150 nadávek/hod. Přitom jádro multitaskingovýho OS na MSP430 jsem udělal na cca 300B FLASH + pár desítek B RAM na tabulky časování (a i s dokumentací cca 700LOC v C). To snad není taková daň za komfort a spolehlivost...

  • 9. 6. 2017 9:38

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    Cílem koho?

    Arduina a jeho tvůrců?
    Těch, kdo si doma hrají a učí se?
    Malýho prezentované vize, že lama udělá na Arduinu profi produkt s reusable kódem a založí si na něm živobití?

    Neútočím na ty, co se snaží něco naučit. Jenom zpochybňuju Malýho ideály o růžovoučkým easy světě... Od roku 2002, co se živím vývojem, jsem už viděl až moc zprasenýho kódu od těch, co si mysleli, že znalosti z Arduina stačí na to, aby zaplatili hypotéku.

  • 7. 6. 2017 12:46

    JD (neregistrovaný) 185.50.127.---

    Souhlasim a nesouhlasim zaroven. Delam to jako profesinal uz 20 let takze mam nejake zkusenosti. Vsechny vytky proti Arduinu co jste napsal jsou pravdive. Predevsim absence multitasku a debug jsou to co vadi.
    Jenze Arduino neni na "dospele" aplikace stavene. To je stavene na hrani. Proste pro ten uzas, kdy vezmu malinky LCD/OLED display o on za nekolik desitek minut funguje.
    Jenze mantinel reseni na arduinu musi skoncit nad rozpohybovanou stavebnici. Prikladu, kdyz nekdo zacal psat reseni pro arduino a nedokazal ho opustit je spousta. Vetsinou je to uvnitr silene spatlany kus kodu v dusledku hromady kompromisnich rozhodnuti. Prikladem projektu, ktery nedokazal opustit arduino a podle toho take vypada je Marlin (FW pro 3D tiskarny)

  • 7. 6. 2017 17:01

    JD (neregistrovaný) 185.50.127.---

    Standartne se na dyn. alokaci pouziva heap ve kterem jsou vsechny volne kousky pameti. Slozitost new/delete je stejna a v obou pripadech je to log(n), kde n je pocet volnych bloku pameti, velmi obtizne predikovatelne cislo. A to je slozitost pouze bez uvazovani fragmentace pameti, pouze jednoduchy heap. Hlavni potiz neni samotna casova narocnost, ale jeji nepredikovatelnost. Pak zalezi na tom, co je pro vas povazovane za real-time. Pokud jsou to desitky nebo stovky milisekund tak je to v pohode. Pokud jsou to jednotky az desitky mikrosekund tak neprichazi v uvahu.
    Pak nastava jeste jiny a zavaznejsi problem, kdy thread-safe alokacni funkce v multithredu pridava dalsi slozitost navic, nebo je nutne pouzit na alokacni funkci zamek. Ale v pripade zamku a nutne podpore priority inheriance v RTOS se nasobi potrebny worst-case cas 2x.
    Resenich pouzivanych v real-time je vic. Napriklad alokace pomoci poolu (slozitost 1), ktera je ale pouzitelna jen pro bloky predem zname velikosti, nebo za cenu plytvani pameti. Nebo je to nepouzivat thready ale procesy, kde ma kazdy z nich jiny alokacni prostor. Ale v zadnem pripade se nebavime o 8kB RAM kterou ma nejvetsi ATMEGA256 v arduinu, ale uplne v jinych radech.
    Krome toho musite resit co v pripade, ze alokace selze. Jsou pripady, kdy vam to nevadi, ale casto ten procesor ridi nejaky menic, ktery nesmi zustat v zaseknutem stavu (jinak potrebujete smetacek a lopatku na uklid pouziteho HW). V tom pripade musite mit jistotu, ze akce pro pripad selhani je funkcmi i bez dyn alokace. Takze testovat vsechny mozne kombinace selhani, hodne draha sranda.
    Mimochodem Misra obsahuje zduvodneni zakazu dynamicke alokace podrobneji, doporucuji precist. Jde o Misra-C 2012 Dir 4.12
    Mimochodem pouzit jako nahradu ridici jednotky lednice arduino je dobry napad. Jenze to muzete udelat vy doma, specielne kdyz dokazete resit pripadne selhani. Vyrobce, ktery udela nekolik tisic lednic mesicne to ale udelat nemuze. Proste proto, ze kazda nedokonalost se nasobi poctem kusu a to co se u vas doma projevi jednou za 1000 let pak museji resit diky poctu lednic v provozu kazdy den. Vcetne nebezpecnych situaci jako v pripade lednice muze byt prehrati motoru, kdy v lepsim pripade dojde k preruseni tepelne pojistky.

  • 9. 6. 2017 1:37

    Miloslav Ponkrác (neregistrovaný) 194.213.53.---

    Nemyslím, že se těmi exhibicemi shazuje, ba právě naopak. Někdy mám pocit, že kromě bezbřehého nadšení, a pokřiků wau! wau! - drsně chybí střízlivé uvažování.

    Petr M. patří jenom mezi ty lidi, kteří se - jako vždy marně - pokoušejí sdělit něco profesionálního a seriózního - těmto sluníčkářským nadšencům, kteří vidí jen pozitiva, světlou budoucnost, a všechno bez chybiček. Někdy si říkám, kde berou ty kvalitní drogy, nebo jestli je za to někdo platí.

    Vždy vidím, že když někdo trochu umí, a má trochu zkušeností a ještě k tomu selsky a ktiticky uvažuje - že je nakonec vyštípán. Bude asi tisíctý v řadě, protože pozitivitu i za cenu lží si ničit nenecháme. Je třeba řvát wau! to je úžasný! cokoli jiného není dovoleno.

    Pan Malý mi mimochodem přijde jako člověk, který nic seriózního a rozsáhleji fungujícího v hw nedokázal. On je tu pro to vyvolávání wau! wau! Petr M. sem ideově vysloveně nepatří, on totiž nejspíše něco dokázal, a také ví, co to je nabít si čumák.

    Postupně tak internet opanovávají začátečníci bez zkušeností, ale zato z bezbřehou a slepou dávkou entuziasmu. I já jsem zjistil, že zkušený člověk - programátor či hardwerář se na internetu nepohybuje, co by tam dělal? Nechal si vysvětlovat od nedouků jako muf, že shazuje, protože neskanduje o skvělosti?

  • 10. 6. 2017 15:24

    Miloslav Ponkrác (neregistrovaný) 194.213.53.---

    Konečně někdo, kdo pochopil rozdíl mezi C a C++.

    Pokud není implementován standard C - pak se nejedná o C, ale proprietární nepřenositelný jazyk vzdáleně inspirovaný Céčkem.

    Pokud není implementován standard C++ - pak se nejedná o C++, ale proprietární nepřenositelný jazyk vzdáleně inspirovaný C++.

    Tedy pokud nějakou povinnou část C++ někde zakazují, vyplývá z toho, že se nejedná o C++. Opakuji, nejedná se o C++. Pokud by si tvůrci jazyka C++ hlídali použití názvu jazyka (jako to dělá třeba Ada nebo Java), bylo by to na prohranou soudní žalobu. Zkuste si vzít Adu nebo Javu, řást vynechat a nechat název jazyka! Doporučuji mít pár miliónů dolarů na prohraný soud a pokutu v záloze.

    C++ je totálně odlišný jazyk oproti C - jsou to dva různé jazyky. Na embedded existuje jen velice zřídka, pokud vůbec, C++ (ve smyslu, že vyhovuje standardu C++).

  • 9. 6. 2017 9:32

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    C++ je popsáno ANSI normou. Pokud neimplementuje to, co standard požaduje, není to C++, ale rozšíření C v podobě vlastního dialektu.

  • 9. 6. 2017 10:06

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    "Pan Malý mi mimochodem přijde jako člověk, který nic seriózního a rozsáhleji fungujícího v hw nedokázal. On je tu pro to vyvolávání wau! wau!"

    Tento pocit sdílím. Někdy mám pocit, že zamrzl ve stavu, kdy udělal tři projekty na levelu těch digitálek nadoma a dál měl místo potřeby dalšího učení potřebu exhibovat do světa, že je king a že je to easy.

    Podle toho, co a jak píše, ještě ani v životě neřešil sériovou výrobu (stačí se podívat na zpoždění Turrisu Omnia - a to už měli před tím Turris 1.0 a 1.1 ve výrobě).

    Ono mimo jeho "toyland" existuje plno věcí, který mu zní, jako kdyby byly z jiné reality, třeba six sigma (jinak by nemohl propagovat zkoumání mezí součástek prototypováním na Arduinu), DFM, Lean Manufacturing,... A kdo se tím začne živit, dřív nebo pozděj si o ně rozbije nos.

  • 10. 6. 2017 15:19

    Miloslav Ponkrác (neregistrovaný) 194.213.53.---

    Mistře, nedouk se pozná tak, že v jakékoli kritice vidí jen mlhu před očima a vzkaz "vše je na ho*no", pane mufe.

  • 10. 6. 2017 15:55

    Miloslav Ponkrác (neregistrovaný) 194.213.53.---

    "To mi připomíná, jak jsem byl kdysi nadšený na své přednášce o ESP32 a dělal jsem wau wau. Později mi jeden kolega sdělil, že tímto přístupem vyloženě odrazuju zkušenější mistry v oboru od toho, o čem mluvím, a navíc sebe shazuju do kategorie úplných nýmandů. Prý bych se měl snažit působit seriózněji, tedy zřejmě usedleji, bez přehnaných emocí, protože právě tak vystupují skuteční odborníci."

    Svět funguje tak, že každá dobrá a užitečná věc má své plusy a nedostatky, silné a slabé stránky. Zkažené a neužitečné věci pak mají fakticky spíše nedostatky. Prezentace něčeho stylem "wau wau" je obvykle povrchní, protože se neslučuje s obecnou povahou světa.

    Když děláte elektroniku nebo programování, musíte dělat kompromisy. Některé vlastnosti jdou proti sobě, protože tak praví fyzikální zákony - a je třeba si vybrat. Proto "wau wau prezentace" je automaticky zamlčení té stinné stránky produktu/věci. Protože dokonalý produkt/věc v hmotné světě za současných fyzikálních zákonů v současném vesmíry fungovat nemůže.

    Kromě toho je tu zkušenost, že začátečníci v jakémkoli oboru je obvykle sebejistý, optimistický a všechno je sluníčkové. Profesionál či virtuóz v jakémkoli oboru je většinou nejistý a je si velice dobře vědom mnoha limitů oboru, protože ho znát skrz nasrkz jako vlastní boty včetně omezení, která vidí. Takto jsem už jako student na univerzitě (před 30 lety) perfektně poznával, kdo umí a kdo neumí. Zpětně viděno, nikdy tento test nezklamal.

    Dokonalá věc bez kompromisů je v technice oxymoron, utopie, nesmysl. Nemůže vůbec existovat, protože fyzikální zákony.

  • 7. 6. 2017 15:37

    ja (neregistrovaný) ---.tatrabanka.sk

    Nerozumiem, preco by sa nemohla pouzivat dynamicka alokacia. Urcite nie je dobre, pokial by sa takto alokovalo casto a vacsie bloky, kedze pamati je malo a hrozila by fragmentacia pamate. Ale pokial napriklad dynamicky alokujem pri starte (aj vacsie bloky) a nebudem neskor tuto alokaciu uvolnovat, tak v tom nevidim problem. A taktiez nevidim problem pri alokaciach malych casti pamati, ako napr 2 ci 4 bajty, kedze takto mala pamat sa po uvolneni da znovu bez problemov vyuzit pri tych istych alokaciach, nemalo by sa stat, ze by dosla pamat kvoli velkej fragmentacii, ze by uz nebolo suvisle miesto pre pozadovanu alokaciu.

    Taktiez nevidim problem s vyuzivanim dynamickych veci ako napr virtualne metody v triedach. To, ze si to vyzaduje nejaky cas na reziu, OK, ratam s tym pri navrhu app a pokial to konceptu nevadi, tak nech sa pri tom zdrzi, kolko je potrebne, ale mne to ulahci zivot a sprehladni kod.

    Nie kazdy robi aplikaciu, ktora bude riadit zemegulu, mne sa napr s arduinom dari uspesne riadit chladnicku, ked nam odisla elektronika. Preco by som mal investovat do nejakej drahej dosky, pokial to viem urobit aj s lacnou (spolahlivo to funguje uz skoro 2 roky).

  • 8. 6. 2017 7:43

    Pavel Riedl

    >>...ale chce to ZKUŠENOSTI.
    A protože ty zkušenosti nepadají z nebe, tak se zase kruhem vracíme k Arduinu a jim podobným. Stručně: mohl jste si to sáhodlouhé psaní odpustit.

  • 9. 6. 2017 11:48

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    Ne, snažím se, aby si ZBYTEČNĚ nerozbili čumák na takovým šmejdu. A aby, než začnou, měli představu, do čeho jdou.

    AVRka mají plno chyb na čipu. Navíc Atmel mění revize čipů, nový revize nejsou otestovaný a někdy ani zpětně kompatibilní (před dvěma rokama jsem řešil rozes.. výrobu s AVRkem, kde prostě vyhodili z periferky jeden registr, nikomu to neřekli,... Dělalo se toho nějakých 50k kusů/rok a ani jejich technická podpora neměla informace).

    Navíc harvard je vyloženě "vhodný" pro začátečníky. Jiný šířky sběrnic pro data a instrukce, oddělený adresování,... Už jsem řešil věci, kdy standardní knihovna u kompilátoru překopírovala textový konstanty FLASH do RAM, aby měl jednu verzi putch() a najednou jsem zjistil, že proměnný mají 2,5kB, procesor má 8k RAM, ale volných je 35B. A hurá přepisovat desetiletý soft (tak dlouho to nikomu nevadilo), aby si nakopíroval jenom stringy z aktuální obrazovky. Nebo sranda byla na VŠ, když se nám učitel snažil něco ukázat na AVR, měl ve FLASH tabulku konstant, indexoval po Bytech a ono to bylo prokládaný nulama... Po 20 minutách dobré zábavy jsem mu sice vysvětlil, že to bere jako instrukce a byte zabere dvě adresy, ale kdo to vysvětlí bastlířovi, který to bude řešit tři dny? Atd.

    Je zbytečný začátečníka zatěžovat tímhle, je lepší von Neumann a říct, že od 0 do 0xffff je FLASH, od 0x20000 do 0x23fff RAM a neřešit místo vlastního úkolu takový blbosti, co si může nastudovat, až přejde na debilnější platformu.

  • 9. 6. 2017 23:46

    JD (neregistrovaný) ---.kaznejov.cz

    Ale ano, funguje to. Jenze ze zvoleneho reseni vyplyvaji nektere mouchy.
    Napriklad prekreslovani LCD je tak nejak vyresene az u verze 1.1 a stejne to nekdy neprekresluje. Cteni pulzu z rotacniho enkoderu na ovladani taky neni perfektni (porovnejte jak to funguje jinde).
    10 minut po prvnim spusteni verze 1.1.1 jsem nasel chybu a kdyz jsem ji hledal v kodu, kroutil jsem hlavou. Nasel, opravil a co jim slouzi ke cti, ta chyba byla uznana a opravena asi za 45 minut.

    Netvrdim, ze je to spatny SW. Sam ho pouzivam. Tvrdim, ze neochota opustit adruino paradigma ma svoje dusledky, ktere jsou v projektu videt. Dobre i spatne dusleky. Uznavam, ze to ma svoje vyhody, kdy dokaze SW nakonfigurovat, prelozit a nahrat "kazdy". To je take dulezite, protoze vetsina uzivaletu ma zamereni na 3D tisk, ne na reseni problemu s programovanim.

  • 7. 6. 2017 11:19

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    To jsem ale neřekl. Jenom říkám, že to Malý maluje moc sluníčkově - za pár stovek Arduino a pár shieldů, za měsíc se dotyčný naučí programovat, za další měsíc spíchne aplikaci a za týden ji přehodí na MSP430...

    Prototypovat se dá na čemkoliv, ale chce to ZKUŠENOSTI. Naivní představa, že když se spojí hračka a prázdná hlava, vznikne za půl roku skvělý komerční produkt, je opravdu naivní.

  • 9. 6. 2017 7:10

    thr

    A on snad Marlin nefunguje? Tohle je totiž typické v podobných debatách - odborník (nemyslím ironicky!!!) vysvětlí, proč je řešení X totální shit a vše je špatně. Připouštím, že má pravdu, jenže v reálu se řešení X používá k víceméně plné spokojenosti. Teoretici sice nadávají, ale to lepší řešení Y od nich nikdo nikdy neuvidí...

  • 10. 6. 2017 21:47

    Miloslav Ponkrác (neregistrovaný) 194.213.53.---

    "Takže když se zeptáte dvou lidí jak rozchodit třeba UART na procesoru XY, jeden si nebude jistý ..., tak dle Vaší logiky ten druhý je nezkušený začátečník co všechno vidí moc jednoduše?"

    Mluvil jsem o celých oborech, nikoli o dílčích problémech. To, že někdo na otázku: "Jak se řekne anglicky kolik je hodin?" rychle a správně odpoví neznamená, že umí perfektně anglicky. A tak je to ohledně procesory XY a znalosti UART.


    "Jsem v týmu s člověkem, co o sobě tvrdí, že programuje 10 let, je si nejistý i blikáním LEDkou na GPIO pinu a na otázku termínu kdy předpokládá, že bude hotovo nikdy nedává přímou odpověď. Dle Vaší definice je to profík."

    Opět manipulujete. Mluvil jsem o celém oboru. Mluvil jsem o lidech, kteří svůj obor znají zleva zprava, odshora dolů, a i o půlnoci vám vysypou řešení složitého problému. A takoví jsou si obvykle méně sebejistí, než namachrovaní mladíci či lidé začátečníci.

    S dobou dělání nějakého činnosti to nemá nic společného. Můžete něco dělat 10 let a být se znalostmi/schop­nostmi hůře než jiný za půl roku.


    "Váš způsob hodnocení je jen Váš osobní sebeklam."

    Váš sebeklam je, že umíte chápat psaný text. Zde jste naprosto selhal.

  • 11. 6. 2017 13:10

    JD (neregistrovaný) ---.tmcz.cz

    Ano heap neni na dyn alokaci nutny. Ale znate jiny algoritmus dyn alokace/dealokace bloku libovolne delky, ktery zaroven nema svoje nezanedbatelne mouchy? Ja ne. Ano existuji algoritmy s mensi amortizovanou slozitosti, ale vzdy za cenu horsi worst-case (a to nas v real-time zajima nejvic). Nebo existuji algoritmy typu memory pool (slozitost 1), ale tam je zas nutny predpoklad ze zname alokovane velikosti predem. Nebo existuje algoritmus alokace, bez moznosti uvolnovani pameti, take slozitost 1, pro situace, kde staci alokace pri startu a pamet se neuvolnuje.
    Misra neni dokument "proc to nejde". Bohuzel neni dostupny bezplatne, doporucuji precist.
    PS: RTOS jsem napsal taky (ne jeden). Nic tezkeho to neni, sranda nastane az v situaci kdy musite dokazovat jeho bezpecnost (moznost ohrozeni neciho zivota pri selhani).
    Mimochodem vite, ze jednoduchy RTOS zalozeny na prioritach je schopen plnit funkci jen do necelych 70% zateze procesoru? ( dukaz provedl Liu a Layland roku 1973)

  • 12. 6. 2017 7:04

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    Profesionál se napřed zeptá, co znamená "rozchodit UART". Pak teprve odpoví, protože k odpovědi potřebuje vědět:
    - Jestli píše jenom ovladač, nebo komplet komunikační stack pro nějaký procesor
    - Jestli HW podporuje vše, co je potřeba (omezení max. baudrate, chybějící piny pro HW handshake,...)
    - Jestli pojede pod nějakým OS (interrupt přes dispatcher, vlákno pro komunikaci), nebo se to řeší jinak
    - Jestli je konfigurace daná pevně, nebo ji odněkud načítá,...
    - Jestli si vystrečí se SW, nebo bude potřebovat DMA,
    - Jestli je tam nějaký systém zpracování chyb (parita, framing,....), logování atd.
    - ...

    Pokud někdo řekne "UART mám za 2h" a na nic se neptá, tak je potřeba obvykle ten čas násobit minimálně 20 a doufat, že se vejde.

  • 12. 6. 2017 13:33

    pp (neregistrovaný) ---.tescan.cz

    Od čeho máme specializované periferie jako hodiny reálného času (např. oblíbené a levné DS3231)?


    Mě se nezdá, že by DS3231 byla levná záležitost. To co se dá koupit za dolar přes ebay včetně destičky s podpůrnými obvody dle mých zkušeností nesplňuje specifikovanou přesnost ani omylem. Pokud si s tím člověk hraje a smíří se s tím, že se to za měsíc rozejde o minutu, tak ok.
    A tohle je obecný problém

  • 7. 6. 2017 14:34

    JD (neregistrovaný) 185.50.127.---

    Ano je to tak. Z C++ se v arduinu pouziva snad jen zapouzdreni do trid, nic vic.
    Mimochodem mnoho featur C++ je i bez omezeni arduina na embedded SW nepouzivanych. Vetsinou proto, ze primo nebo neprimo potrebuji dynamickou alokaci pameti a to pri pozadavku na real-time neni jednoduse splnitelny ukol (tradicni heap ma slozitost log(n), kde "n" nezname. Navic napriklad Misra dynamickou alokaci primo zakazuje). A krome toho vytvari retezec tezko testovatelnych podminek co delat pri selhani te alokace.

  • 8. 6. 2017 10:26

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    "S hodně výtkami se nedá než souhlasit, ale zrovna ty hodiny s LCD a budíkem mi přijdou jako příklad trochu mimo."

    Byl to příklad s LED v multiplexu, ne s LCD (aby vyniklo SW řízení a potřeba multitasku).

    Proč by to měla být blbost? Je to hezký příklad, jedna úloha počítá čas, druhá zobrazuje, třetí kontroluje tlačítka, čtvrtá zapíná a vypíná časovač s piezo měničem,... A každý si dokáže reálně představit co a proč to dělá. Narozdíl os super hyper frikulínskýho udělátoru na stavění virtuálních sněhukáků z nestrávených zbytků potravy.

    A i když použiješ externí obvod na počítání času, nebo periferii RTC přímo na čipu, furt tam multitasking zůstává - místo počítání je update zobrazovaných dat.

    "Od čeho máme specializované periferie jako hodiny reálného času (např. oblíbené a levné DS3231)?"

    Zrovna RTC je obvod, co většinou nepřinese přidanou hodnotu, pokud je MCU trvale napájený. A většinou převažují i jeho nevýhody.

    Od toho, aby zvyšovaly cenu? (připočítej plochu desky, odpory a kondíky okolo a vynásob 10k v produkci) Od toho, aby snížily spolehlivost? (víc součástek, víc pájených spojů,...)? Od toho, aby zvýšily spotřebu? (je třeba započítat i proudy I2C s pull-upem, komunikace několik ms vs. inkrement registru a usnutí, v řádu us, spotřeba periferie I2C,...) Od toho, aby se zhoršilo EMC? (mimo čip jsou někdy externí signály krásný antény, i když u 300kHz I2C to není tak kritický)

    Levný RTC je na tom s přesností často hůř, než krystal u MCU a přesný RTC je drahý. Kompromis potřebuje kalibraci.

    "Přesnost RTC, kterou nejsme schopni přímo v jednočipu dosáhnout"

    Pán naráží na RTT v AT91SAM7X? Zatímco skoro všechno jelo na krystal (třeba 10ppm), Real Time Timer byl časovaný RC oscilátorem s přesností tuším 0,1% (je to už pár let, co jsem s tím obvodem dělal). U Atmelu je všechno tak trochu postavený na hlavu.

    Interní RTC třeba u STM32F s externím hodinkovým krystalem a možností kalibrace je zase někde trochu jinde...

    "budík řešený změnou úrovně na pinu, v registrech jsou přímo hodiny, minuty, sekundy, atd."

    Jenomže tady se zase na tom přerušení neušetří nic ve srovnání s porovnáním času při update v jednom procesu. Proti řešení se samotným porovnávacím vláknem se ušetří jedno vlákno, tj. jedna funkce a její registrace.

    Tak jako tak je potřeba při natavení spočítat, kdy to má reagovat. Vlákno, který realizuje pípání, zůstane naprosto stejný...

    Jo pokud by tam nebyl (sw ovládaný a aktivní) displej, tak může externí přerušení probudit spící procesor 1x denně, ne každou minutu. Ale to je tak veškerý přínos.

  • 12. 6. 2017 0:30

    Miloslav Ponkrác (neregistrovaný) ---.infos.cz

    REAL-TIME OPERAČNÍ SYSTÉMY

    "RTOS jsem napsal taky (ne jeden). Nic tezkeho to neni,"

    Napsat operační systém je jednoduchá věc. Jsou daleko těžší problémy k řešení.

    .... qqqqqq .....

    "sranda nastane az v situaci kdy musite dokazovat jeho bezpecnost (moznost ohrozeni neciho zivota pri selhani)."

    To máte pravdu. Jakmile máte dokazovat a certifikovat, je lépe vzít něco certifikované. Ono to selže stejně často, ne-li častěji, než to moje/vaše řešení, ale máte krytá záda. Když selže něco certifikovaného, jste z obliga.

    Nicméně tam, kde skutečně záleží na bezpečnosti, je třeba ji zajistit i jinak, třeba dodatečným nezávislým hw obvodem (bez procesoru), který to zajistí, ať se děje co se děje. Fyzikální zákony a matematická teorie spolehlivosti jsou totiž proti mikroprocesorovým řešením. Navíc když někdo výše tu považoval za neřešitelný i takový stav, kdy dynamický paměť nealokuje blok - pak jistě nedokáže ošetřit tento člověk ani bezpečnost.

    ..... qqqqqq .....

    "Mimochodem vite, ze jednoduchy RTOS zalozeny na prioritach je schopen plnit funkci jen do necelych 70% zateze procesoru?"

    On není schopen plnit funkci vůbec. Protože se dočkáte i takových efektů jako je "inverze priority", apod.

    Nemůžete funkčnost plánovače procesů a úloh v reálném času založit pouze na prioritách. To je nesmysl. Pokud tedy chcete, aby to rozumně fungovalo. Navíc "reálný čas" znamená, že plánovač bere v úvahu i další parametry, jako třeba plánovaný čas spouštění, či statistiky předchozáích spotřebovaných kvant času různými procesy.

    Na druhé straně také záleží na tom, co v konkrétním případě znamená "není schopen plnit funkci".

    Ale zpět. Realtimový systém znamená, že dáváte záruky, že se akce provádějí v reálném čase a nějakém konkrétním čase. Takové záruky (pro univerzálně napsaný raltime) skoro nikdy nemůžete v žádném případě dát na plně zatížený systém.

  • 12. 6. 2017 10:56

    Karel (neregistrovaný) ---.cust.nbox.cz

    "Ne, snažím se, aby si ZBYTEČNĚ nerozbili čumák na takovým šmejdu. A aby, než začnou, měli představu, do čeho jdou."

    Můj názor je, že to není zbytečné, že to je naopak nutné! Čím dříve se člověk spálí, tím lépe pro jeho profesní život. Člověku nejvíce dá, když se snaží překonat překážky, když hledá cesty. V tomhle má AVR výhodu, to je opravdu dost mizerná technologie a člověka to záhy donutí zkusit něco jiného. Prostě dojdou ke stejnému poznání co vy.

  • 12. 6. 2017 11:26

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    I kdyby vyřešili dyn. alokaci, furt to nebude C++, tak s nemá cenu vrtat v detailech ohledne alokace.

    Třeba chybí konstrukce try..catch (a ne, ani zapouzdřená ANSI knihovna setjmp.h není plnohodnotnou náhradou).

    A pak tady máme přetěžování operátorů, templates, standardní kontejnery,...

  • 12. 6. 2017 17:07

    pp (neregistrovaný) ---.tescan.cz

    Záleží na použití.
    Když si člověk hraje s Arduinem, tak jsou čínské "DS323X" docela dobrá volba, jen se od toho nesmí chtít nějaká přesnost. A pro lidi co to mají na hraní nepříchází pájení SMD moc v úvahu. Akorát může být někdo zklamaný, když si zbastlí budíka a bude se rozcházet v řádu sekund za týden (že první iterace budíka vydrží na baterky tři dny je druhá věc, ale co už ...)
    Že součástky z Číny jsou jaké jsou, příklady a knihovny z githubu obsahují chyby začínajících programátorů a návrhy obvodů zcela jistě obdobně je nedůležité. Jen s tím je nutné počítat.
    Stejně to nemá paměť nebo rychlost na to, aby se s tím dalo dělat něco seriózního a pro průmyslové využití se jistě najde něco s lepším poměrem výkonu, ceny, spotřeby nebo tak.

    A s tím prototypováním .... když chcu naprogramovat něco rychle, použiju raději Python, který skoro neumím, napíšu v něm doprasený kód (psát v Pythonu je prasárna samo o sobě), ale nemusím vytvářet ve Visual studiu projekt, řešit jak to slinkovat s libpng pro načtení obrázku a libxml pro načtení xml, nebudu řešit, aby to nespadlo při vadných vstupních datech, nebudu hledět na to, aby to vypadalo, aby se operace daly přerušit, aby se data načítala na pozadí a netuhlo GUI ... nemluvě o dialozích, ukládání nastavení apod. Použití Arduina vidím obdobně. Obojí udělám s plným vědomím, že je to bastl použitelný pro mě v kterém se za rok nemusím vyznat, ale okamžitou potřebu to splní. Narozdíl od autora článku to následně zahodím a napíšu znova, protože budu nejspíš jediný jehož potřeby to splní a komu to udělá radost.

    Ale vysvětlujte někomu, proč vám trvá napsání programu v C++ pětkrát dýl než jeho jednoúčelový skript :-(

  • 7. 6. 2017 18:31

    vbl (neregistrovaný) ---.citationtech.net

    C++ umím a i jsem ho na 8bit použil. Nemám s tím žádný problém. Ale rozhodně ne k tomu, abych tam používal dynamickou alokaci.

  • 12. 6. 2017 0:12

    Miloslav Ponkrác (neregistrovaný) ---.infos.cz

    DYNAMICKÁ ALOKACE

    "Ano heap neni na dyn alokaci nutny. Ale znate jiny algoritmus dyn. alokace/dealokace bloku libovolne delky, ktery zaroven nema svoje nezanedbatelne mouchy?"

    Všechno na světě má svoje mouchy. To je to, co řekl Petr M. a co jsem řekl i já - a sklidili jsme za to horu kritiky. Umění programátora je vybrat a upravit správný algoritmus pro správnou situaci, případně jej vymyslet - to je skutečný programátor.

    Rovněž správa dynamické paměti pomocí heapu má své mouchy. Pro určité situace nevýhody heapové správy dynamické paměti dělají tento algoritmus nepoužitelným.

    ...... qqqqqq ......

    "Ano existuji algoritmy s mensi amortizovanou slozitosti, ale vzdy za cenu horsi worst-case (a to nas v real-time zajima nejvic). Nebo existuji algoritmy typu memory pool (slozitost 1), ale tam je zas nutny predpoklad ze zname alokovane velikosti predem. Nebo existuje algoritmus alokace, bez moznosti uvolnovani pameti, take slozitost 1, pro situace, kde staci alokace pri startu a pamet se neuvolnuje."

    A tady je vidět, že nejste opravdový programátor. V žádném případě nenastává případ, kdy byste potřeboval maximální rozpětí parametrů (paměti, času, ...)

    Představte si třeba, jak jsem začal uvažovat já. Jsem na ARMu, kde adresy paměti musejí být zarovnány na násobek čtyř (tedy i délky paměti). A zároveň jsem na microcontrollerech, které mají 16 až 128 KB RAM - tedy vím, že nepotřebuji algoritmus zvládající dynamickou paměti zvíci megabajtů či gigabajtů paměti.

    Najednou jsem tu měl konkrétní omezený rozsah toho, s čím potřebuji operovat. Strašáky typu "worst case" či časová náročnost dostala konkrétní čísla, stejně jako worst case dostal konkrétní tvar, který případ to je.

    Real time operační systém se umí bez problémů vyrovnat s konkrétními čísly v časové i jiné náročnosti velice dobře. Jakmile operační systém ví, že operace se zvládne do tolika a tolika mikrosekund - není s tím v real time systémech žádný problém.

    A tak bych mohl pokračovat dále a dále. Ale to je tím, že nečtu debilní materiály, proč věci nejdou, ani neoperuji s abstraktními omezeními algoritmů vyčtených ve školních materiálech. Ta omezení mají konkrétní tvary v konkrétních případech - a s tím se dá velice dobře pracovat.

    A to je rozdíl mezi těmi, co dělají wau wau, a mezi střízlivými programátory. Zatímco skutečný programátor chce slyšet plusy i mínusy, protože s tím umí operovat, a umí z toho najít řešení i tam, kde "wau wau programátoři a přednášející a pspisovatelé článků" napíší, že je to nemožné. A tito wau wau borci pak píší i ve frimách dokumenty, proč dynamickou paměť zakázat a i jiné ptákoviny.

  • 12. 6. 2017 6:51

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    Jenže dneska je standardní součástí mikrokontroléru bootloader. Skoro vždyckuy jde nahrát apku po sériovce, ať je to SAM-BA pro ARMy od Atmelu, nebo bootloadery pro H8, STM32,... Byl by omyl tvrdit, že nahrát firmware do Arduina je jednodušší, než na jinou platformu!!! A je nesmysl se jenom z tohoto důvodu spolehnout na Arduino a trpět rozdělení pamětí, 8b na aritmetiku a další omezení.

  • 12. 6. 2017 11:49

    JD (neregistrovaný) 185.50.127.---

    Clovece proc se tady vlastne hadame, kdyz o tom evidentne taky neco vite?
    Napriklad ze resenim inverze priorit je priority inherience ale to take neni dokonale, protoze je nutne zajistit, aby programator procesu s nizzsi prioritou vedel o moznosti, ze mu bude priorita povysena a v te casti nemel zadne zrouty casu (resenim je naprikad zapouzdreni mutexu do zkontrolovane funkce mimo dohled uzivatele a i dalsi metody, ktere ale maji spolecneho to, ze je to spotrebuji lidsky nikoli procesorovy cas)
    Mimochodem, i v pripade 100% vytizeneho systemu lzde dat zaruky, ze se akce provede v realnem case. (Hledejte EDF planovac, zacit knihou Deadline Scheduling for Real-Time Systems EDF and Related Algorithms Authors: Stankovic, J.A., Spuri, M., Ramamritham, K., Buttazzo, G. a pak dalsi studie, jmena lidi se tam dost opakuji, casto na tom nekdo delal doktornatskou praci a okruh lidi ktere se kolem toho motaji je dost uzavreny, takze je tam vzdy nektere ze jmen jako konzultant/opo­nent/spoluautor nebo alespon v citacich)
    Mimochodem o zajisteni bezpecnosti neco vim, napriklad presne vim co se stane, kdyz na otazku auditora "dyn alokaci mate?" odpovite "pro nektere funkce". Ano, lze to, udelat ale testovani a schvalovani je naproste peklo, Proto je u bezpecnostniho SW dynamicna alokace az jako posleni moznost pokud opravdu ale opravdu neni zbyti a za silene kontrolovanych podminek (napriklad pro komunikace a jejich nutnost bufferovani).
    A na "bezpecnost" nestaci ani samostatny bezpecnostni obvod bez CPU. U bezpecnosti jde predevsim o nalezeni bezpecnostnich rizik a jejich eliminaci (IEC61508 a normy ktere ji vykradaji jako EN26262 nebo EN50128 a dalsi). A existuji i rizika, ktere bez procesoru (a hromady matematiky) neni mozne odstranit. Pak se (take) pouzivaji procesory ktere samy o sobe maji certifikace na nezpecnost (napriklad na zaklade ARM Cortex-R nebo Cortex-M ale jen za specifickych podminek definovanych vyrobcem), minimalne 2 ruzne nezavisle systemy a dalsi opatreni.

  • 12. 6. 2017 13:06

    JD (neregistrovaný) 185.50.127.---

    Presne tak. try/catch totiz vedou na dyn alokaci i v pripade, ze samotna vyjimka je definovana staticky. Takze zachycovat na vyjimku selhani alokace je past. Ano jde to, ale je nutne prepsat kus standartnich knihoven a ve vysledku je to stejne jen pro debug.

  • 12. 6. 2017 15:00

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    To je ovšem dobrý postřeh.

    V bývalé práci byl Dallas/Maxim na black listu ne pro kvalitu, ale
    - omezená dostupnost (jediný distributor u nás - HT Eurep. Není skladem, smůla)
    - dlouhá doba dodání (u něčeho dva měsíce nebyly problém)
    - cena (proč platit za originál MAX232 >150CZK, když generika stojí kolem 20-50Kč?)

    Když už RTC, tak něco jako tohle a nakalibrovat si to podle čítače.

    Btw., stejně funguje i RTC v STM32F, jenom to visí na interní sběrnici. A v tomto případě získá člověk v ceně RTC přímo na čipu jako bonus 32b CPU s taktem 48MHz + paměti a pár periferek. Krystal stejný, kalibrace v principu stejná. Tak proč k nějakýmu RTC dávat externí procesor?

  • 14. 6. 2017 10:16

    Trident (neregistrovaný) ---.eurotel.cz

    Ano bohužel na embedded tahle slatanina resici vsechny problémy lidstva pouziva:-/ A bohužel už I v letectvi:-((( Nastesti s prisnymi omezeními programatoru.

  • 18. 6. 2017 19:34

    michal (neregistrovaný) ---.243.broadband10.iol.cz

    Takže kam bych měl tedy od arduina pokračovat? K psaní přímo třeba pro ESP32 a to bez arduino mezivrstvy?
    Díky

  • 7. 8. 2017 11:10

    abc (neregistrovaný) ---.net.upcbroadband.cz

    No, já netvrdím že zde diskutující nemají pravdu, jsem jen občasný amatér a bastlíř... Jen mi připadá zvláštní, kde se tihle superhyperhifi­programátoři vzali na Lupě, aby popravili Martina. Spíš bych je čekal na GitHubu nebo tak někde...

  • 8. 6. 2017 9:25

    PavelM (neregistrovaný) 2001:718:1001:----:----:----:----:----

    S hodně výtkami se nedá než souhlasit, ale zrovna ty hodiny s LCD a budíkem mi přijdou jako příklad trochu mimo. Od čeho máme specializované periferie jako hodiny reálného času (např. oblíbené a levné DS3231)? Přesnost RTC, kterou nejsme schopni přímo v jednočipu dosáhnout, budík řešený změnou úrovně na pinu, v registrech jsou přímo hodiny, minuty, sekundy, atd.

  • 7. 6. 2017 13:44

    vbl (neregistrovaný) ---.citationtech.net

    Arduino "jazyk" není nic jiného, než C++. Takže nevím, proč by rozdím mezi C a C++ měl být pod jeho rozlišovací schopnost.

  • 8. 6. 2017 9:10

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    Ale k Arduinu na hraní, ne k Arduinu v produkci!!!

    Navíc zkušenosti nepadají z nebe jenom tím, že si někdo hraje s Arduinem. Samo o sobě je to prostředí poněkud informačně chudý. Já jsem se pořádně naučil programovat jednočipy až tím, že jsem dělal šest let v korporátu podporu pro zákazníky, kde jsem upravoval emebedded věci dle požadavků marketingu. Do té doby jsem ani netušil, co všechno jsem netušil - a bylo to po pěti letech obživy vývojem.

  • 8. 6. 2017 19:26

    Nemo (neregistrovaný) 79.98.77.---

    Nevrtej do nich, jen ať se nám tu chlapci prsí a ukazujou, kdo dál dočůrá.

  • 9. 6. 2017 11:22

    Karel (neregistrovaný) ---.cust.nbox.cz

    "Petr M. sem ideově vysloveně nepatří, on totiž nejspíše něco dokázal, a také ví, co to je nabít si čumák."

    A to je právě ten jeho problém. On začínal, on si nabil čumák. A teď se snaží, aby jiní nezačínali a nenabili si čumák. Tam, kde teď profesně je, se dostal tím, že to dělal. Všimněte si kolik on sám má negativních zkušeností má s AVR. Ale jak vehementně se snaží přesvědčit lidi, aby AVR nezkoušeli a vlastní zkušenosti nesbírali. Kolik on má zkušeností s levnými mikrořadiči, ale jak se snaží všem zakazovat si s nimi hrát a nutí je používat to nejdražší na trhu.

    Zkrátka se snaží, aby se nikdo nevydal v jeho stopách. Od těhle lidí se začátečník nic nenaučí, s nimi má smysl se bavit jen když už jste na podobné úrovni zkušeností jako oni.

  • 7. 6. 2017 14:08

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    C++ na osmibitu s harwardskou architekturou a pár kilama paměti? Ten byl fakt dobrej...

    (a pokud nechápeš pointu, podívej se, co C++ proti C umí, co ty featury potřebují a jak se to obvykle implementuje)

  • 9. 6. 2017 8:12

    Petr Stehlík

    To mi připomíná, jak jsem byl kdysi nadšený na své přednášce o ESP32 a dělal jsem wau wau. Později mi jeden kolega sdělil, že tímto přístupem vyloženě odrazuju zkušenější mistry v oboru od toho, o čem mluvím, a navíc sebe shazuju do kategorie úplných nýmandů. Prý bych se měl snažit působit seriózněji, tedy zřejmě usedleji, bez přehnaných emocí, protože právě tak vystupují skuteční odborníci.

    Tím nehodnotím ani autora článku, ani Petra M., od kterého si jeho zasvěcené kritiky vždy rád přečtu, i pod svými články. Chtěl jsem jen přidat postřeh stran wau wau a seriózní tvorby.

  • 9. 6. 2017 15:48

    muf (neregistrovaný) ---.opera-mini.net

    Mistře, nedouk se pozná podle toho, že v diskusích nepořvává, jak je všechno na ho*no a že chápe Arduino jako výukový nástroj, přičemž nedělá chytrého úplně nadbytečnými kecy o tom, jak se to nehodí do produkčního výrobku?

    Nebo, že by klidně doporučil začátečníkovi, aby si pohrál s regulací na Raspberry Pi a pochopil díky tomu, jak funguje scheduler Linuxu a proč pro to není úplně vhodný?

    Tak to potom jo. To budu totální nedouk a platí mě za nic.

    Jsem ten poslední, kdo by nějak sluníčkařil, ale nedá mně to, abych nezvolal:
    Všem broukům Pytlíkům zdar!

  • 10. 6. 2017 18:33

    m (neregistrovaný) ---.tmcz.cz

    Takže když se zeptáte dvou lidí jak rozchodit třeba UART na procesoru XY, jeden si nebude jistý protože s tím procesorem příliš nepracoval a druhý vám z hlavy napíše na papír konfigurační parametry toho modulu protože s ním pracuje každý den, tak dle Vaší logiky ten druhý je nezkušený začátečník co všechno vidí moc jednoduše?

    Jsem v týmu s člověkem, co o sobě tvrdí, že programuje 10 let, je si nejistý i blikáním LEDkou na GPIO pinu a na otázku termínu kdy předpokládá, že bude hotovo nikdy nedává přímou odpověď. Dle Vaší definice je to profík.
    Já na výstupu práce vidím opak. Kód je napsaný nechutně, často zbastlený z různých zdrojů. To co po něm stáhnu z Gitu většinou ani nejde zkompilovat nikde jinde než u něj. Testování vlastní kódu pomocí Unit Testů? Haha. Nadepsání hlavičky funkce, co to dělá a proč to dělá? Zapomeň. Psaní komentářů? Nikoliv. Psaní dokumentace? ... Navíc má tendenci hledat zkratky a zprasit kód co nejrychleji, aby prostě fungoval. Ovšem s jeho "dílem" se poté už nechce nikdo zabývat a když tam něco nefunguje, či je potřeba něco rozšířit tak nastávají situace kdy se v tom ani on sám nevyzná a netuší proč to nefunguje či jak to rozšířit, aby se na druhé straně těch špaget něco nerozbilo...

    Váš způsob hodnocení je jen Váš osobní sebeklam.

  • 7. 6. 2017 7:57

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    Malý nezklamal, zase vtipný jako vždy. Jen tak dál, ať redukuje mou konkurenci :D

    "Výhodou Arduina je, že je levné, jednoduché ..."
    ... a nepoužitelné. Protože knihovny pro ně jaou sbastlený tak, že by jeden brečel, a na platformě, co by rozbrečela hned pět lidí najednou.

    Třeba multitasking. I blbý digitální hodiny s LED displejem potřebují multitasking - minimálně počítání času, refresh displeje a kontrolu tlačítek. Přitom počítání času musí jet v přesným načasování (závisí na tom přesnost hodin, jedna z klíčových vlastností), refresh displeje nesmí vypadnout a obsluha tlačítek se musí poprat s debouncingem a nesmí narušit časování,... Když je tam navíc funkce budíku, hned přibude "proces" kontroly času a nějaká akustická signalizace,... Sranduino tohle řeší prostě tak, že se z main() volají postupně moduly, ale kdo zajistí korektní časování úloh? Kdo zajistí jejich priority? Jde to řešit i na AVR, ale kolik Arduino masochistů má páru, jak to udělat?

    Nebo další věc, HAL. Fajn, je hotový, ale pro Sranduino. Vychytávky, co neumí knihovny (třeba přesný časování) si bastlíř ohne tak, že použije časovač a přerušení, ale na 90% to při přechodu na jinou platformu může zahodit - jiný HAL, jiný HW,...

    "Arduino můžete využít ve chvíli, kdy se rozhodnete použít nějakou konkrétní součástku, popřípadě když vybíráte, jakou použít. Můžete si vzorky připojit k Arduinu a vyzkoušet si, jak se s kterou pracuje, jaké jsou její limity, jak složité či jednoduché je uvést ji do chodu…"

    Můžu jenom doporučit pro testování součástek, co jsem vybíral na poslední projekt, třeba fyzickou vrstvu pro Ethernet s připojením po MII nebo displej s paralelním RGB rozhraním a bylo potřeba se podívat, jak má který displej kvalitní obraz. Kua, MII/RMII a 24b LCD jsou přece základní rozhraní...

    "V pozdější fázi můžete zkusit třeba sestavit menší funkční celek s vícero periferiemi, a pak ověřovat, zkoušet, testovat, ladit algoritmy…"

    Ladit programy na něčem, co ani nepodporuje krokování v procesoru? Masochismus 80. let 20. století...

    "A protože Arduino budete programovat nejspíš v C++ (ano, to je ten jazyk, co je schovaný “pod kapotou”, a v něm se píšou všechny knihovny), bude váš kód s trochou péče nejspíš přenositelný i na další platformy – pravděpodobně budete muset upravit některé systémově závislé věci, adresaci periferií apod., ale kostra zůstane stejná."

    Jednak je trošku rozdíl mezi C a C++,ale to je pod Malýho rozlišovací schopností (nomen omen?), druhak podmínkou přenositelnosti a znovupoužitelnosti kódu je vědět, co dělám. Kdyby Sranduainař věděl, co dělá, tak Sranduino nepoužije. Z toho vyplývá, že kód může zahodit.

    "Všechno to, co jsem tu napsal, se dá vztáhnout třeba i na Raspberry Pi. Zejména pokud potřebujete větší výpočetní výkon a složitější logiku."

    Nedá. Kompilovaný jazyk (C na cílové platformě) vs. interpretovaný jazyk (Python, který je v 90% návodů na Raspberry), nevyzpytatelný časování vláken v Linuxu,... Tam je taky srandy kopec.

    "Jo a ještě důležitá poznámka: Když začnete psát pro to Arduino, pamatujte, že jednou se to bude portovat na jinou platformu, tak pište co nejjednodušší a pochopitelný kód, bez triků a hacků, protože jinak si neušetříte vůbec nic, akorát budete nadávat, že “se to celé musí psát znovu a Arduino je k ničemu”."

    Prosil bych ukázku kódu třeba pro obsluhu GSM modulu, který se dá rozjet na Sranduinu i pod FreeRTOSem na Cortex-M, splácaným co nejjednodušším způsobem. Bez triků třeba s časováním úloh, který platforma Arduina nepodporuje v defaultu.

    Přenositelnost je právě v tom "zesložitění" - modularita, wrappery, API, callbacky, mailboxy mezi procesy, synchronizace procesů, weak funkce, abstrakce,... Takže z 90% věci, bez kterých sice program funguje, ale není přenositelný a nedá se dobře udržovat ani rozšiřovat.

    Navíc článek vyzněl tak, že "se člověk naučí programovat za běhu". Nenaučí. Naučí se to nějak poslepovat, ale dlouho trvá, než se naučí vidět úrovně abstrakce a používat je, než si osvojí triky,... A než pozná pasti a nástrahy.