Názory k článku Senzory Martina Malého: Když firmy pořizují vývojářům elektroniku „na hraní “

Tak tentokrát zase nesouhlasím. Živím se embedded vývojem cca od roku 2004 a ještě jsem nenarazil na to, že bych na něco použil Arduino. Ale zato jsem narazil na plno problémů s tím, že se Atmel chová jinak, než je specifikováno, nebo že něco není specifikováno. A to i pro brouky, co jsou roky na trhu, stačí změnit revizi křemíku... (od roku 2011 je Atmel na black listu a používám ho jenom na výslovný přání zákazníka proti podpisu, že akceptuje rizika).
Takže i na prototypování je nakonec vhodnější něco jinýho, ideálně cílová platforma. Některý problémy se tak řeší jenom jednou místo 4x. Proč vyrábět shield, když prototyp s reálnou platformou je hotový stejně rychle? Proč hned investovat do HW, když existuje simulace ve VHDL pro číslicovu část, s analogem se dá pohrát ve Spice,... A na SW v C staší vývojový kit, ale s finálním CPU (a to není ani AVR, ani PIC, ani podobný mrzáček).
Navíc jsou věci, co si ani na Arduinu, ani na RPi nenasimuluju, ani kdybych chtěl, třeba včera bylo potřeba ověřit něco ve FreeRTOS na Cortex-M4F odhledně přístupu k NAND FLASH.
A pokud to není na hraní, tak je potřeba se odlišit od konkurence. Tzn. použít lepší (= úplně jiný) řešení, než mají bastlíři v garáži, na to zase neexistuje shield a zase musím dělat HW... To jsou pak opičárny jako použití bipolárních tranzistorů v zapojení SB místo MOSFETů pro snížení standby proudů, několikafázový spínaný zdroje, proudový zrcadla,... Good luck s HW od číňana.

Máte nějaký link na ono jiné chování, než je specifikováno, apod.? Jen by mě to celkem zajímalo. :)

Pěkný bylo, když třeba AT91SAM926x měly pin JTAGSEL, kterým se přepínal JTAG mezi boundary scanem a laděním jádra. Ono to v klidu bylo v 0 s pull downem, podle datasheetu pro přepnutí na boundary scan, měl být pin připojen na +3,3V. jenže interně to mělo diodu na VCORE a člověk si tím do jádra (dle verze obvodu 1,2 nebo 1,5V) poslal 3,3V. BGAčka šly z testeru rovnou na přeosazení.

Ovšem to je nic proti tomu, jak se ATXMEGA3D64 v čidle probouzela. Ona se měla probudit, něco změřit, uložit a zase usnout. S napájením z CR2032 a s požadavkem na minimální životnost. Tu bych i překročil, kdyby probuzení netrvalo podle datasheetu max. 1ms a v reálu netrvalo 510ms, během kterých si vzal 140uA. A to ještě byla klika, že se neměřilo několikrát za sekundu... Projekt byl zralý na odpískání. Dva měsíce jsme to řešili se supportem přímo u Atmelu, než se omluvili, že to netestovali a vyhodili na to erratu.

Zbytek v ~/vyvoj/hwpasti.odt ;)

Berete to(se) moc vazne. Pokud jsem pochopil autora, tak protypovanim myslel, ze nekdo dostane genialni napad, co by slo udelat, pak (vcelku rychle) s pomoci arduina nebo raspi, chuchvalce dratu a existujicich komponent vyvine prototyp a na nem si muze vyzkouset, jak se jeho napad bude chovat v realnem svete. A pokud se myslenka ujme, muze z toho byt finalni produkt.

Je to asi jako kdybyste si nejdriv napsal rychle algoritmus v Pythonu, abyste si overil, ze funguje a jak se chova, a pak kdyz vidite, ze jste na spravne ceste, jej prepsal do C, kvuli finalni rychlosti.

Patřím ke starší generaci. Vyrůstal jsem bez PC a tabletu, s knížkou, a mám dost rozjetou fantazii. Když dostanu nápad, tak nepotřebuju stavět prototyp, abych viděl, jak se něco může chovat. Načrtnu na papír, rozdělím problém na části, spočítám kritický místa na kalkulačce, jednotlivý části vyhodnotím a je jasno. Za chvíli bude potřeba prototyp i na to, aby si někdo ověřil, jestli náhodou do MCU z 1MB FLASH nenacpe binárku velikosti 3,5MB.

Sakra, vždyť je jasný, že spínání pěti stykačů je osm relátek na výstupu OK, že akcelerometr změří zrychlení, do paměti nenearvu víc, než jaká je její kapacita atd.

A když už jde o realizaci, tak Monte Carlo simulace dá data ze simulované produkce 10k ks za zlomek doby, potřebné pro zadrátování jednoho prototypu ze stavebnice s tím, že na prototypu jsou konkrétní hodnoty a nevidím, jak se to bude chovat na mezních hodnotách tolerancí... Nehledě na ekologii, na simulaci není potřeba těžit měď a křemík.

A s fyzickým prototypem je to jako s GUI, dělá se co nejpozděj, protože jak marketing uvidí něco hmatatelnýho, okamžitě prodá nevyrobitelný koncept bez základní funkcionality. A člověk má na dva měsíce víkendový pobyt v kanclu, ay stíhal. Z toho už jsem taky vyrostl.

A protoypování v Pythonu na embedded věci? Představa, jak to přepisuju z Pythonu do FreeRTOSu nebo do POSIX like systému je opravdu zábavná. Proč to dělat 2x, když můžu 1x?

skoda ze Vam nemuzu dat +1000...

Kde ded.kenedy píše niečo o prototypovaní v Pythonu na embedded veci?

Patřím ke starší generaci. Vyrůstal jsem bez PC a tabletu, s knížkou, a mám dost rozjetou fantazii. Když dostanu nápad, tak nepotřebuju stavět prototyp, abych viděl, jak se něco může chovat. Načrtnu na papír, rozdělím problém na části, spočítám kritický místa na kalkulačce, jednotlivý části vyhodnotím a je jasno.

To je bajecne, gratuluji k vasi fantazii. Realny svet bohuzel trpi tim nedostatkem, ze ostatni vam nevidi do hlavy, takze pokud mate nejaky genialni napad, je potreba jej prezentovat vedeni, klientovi, atd. kteri jej musi byt nejak schopni pochopit a uchopit. Bez toho jsou schopni projekt zariznout uz ve fazi napadu. S prototypem se da pracovat mnohem lip.

Sakra, vždyť je jasný, že spínání pěti stykačů je osm relátek na výstupu OK, že akcelerometr změří zrychlení, do paměti nenearvu víc, než jaká je její kapacita atd.

To je presne pripad, kdy pro stromy (dratky) nevidis les (vysledny produkt). Kdyz prijdes se zajimavym napadem za sefem, nebude ho zajimat, kolik tam je relatek, ale k cemu a jak se to bude pouzivat. S prototypem ho presvedcis spis.

A když už jde o realizaci, tak Monte Carlo simulace dá data ze simulované produkce 10k ks za zlomek doby, potřebné pro zadrátování jednoho prototypu ze stavebnice s tím, že na prototypu jsou konkrétní hodnoty a nevidím, jak se to bude chovat na mezních hodnotách tolerancí...

Viz vyse. Pri navrhu noveho projektu nebo produktu jsou mezni hodnoty podruzne. Prioritou je, aby se vubec ostatni tim projektem zacali zabyvat a aby projekt dostalal zelenou pro dalsi vyvoj. Funkcni prototyp je urcite presvedcivejsi nez vykladani vlhku snu a vysledku simulaci.

A s fyzickým prototypem je to jako s GUI, dělá se co nejpozděj,

Presne takto vznikaji ty uzasne nelogicnosti v ovladani cehokoliv, protoze vyvojove oddeleni se boji zeptat uzivatelu, jak danou vec vlastne budou pouzivat, nedejboze, aby jim ukazalo prototyp.

A protoypování v Pythonu na embedded věci?

Pokud se omezujes jen na MCU, tak to opravdu smysl nema. V momente kdy potrebujes udelat koncept toho, jak bude vypadat UI, jak budou treba probihat vizualizace nebo pokud chces delat datovou analytiku, nema smysl placat se s tim tydny v cecku, protoze se to stejne bude predelavat a je lepsi si to sesmolit treba v Pythonu za par hodin.

Proč to dělat 2x, když můžu 1x?

Protoze je to na poprve rychle hotovo a ty si overis funkcnost a muzes to prezentovat, abys dostal zpetnou vazbu a rozpocet a mohls to udelat poradne.

Doporucuji jako cteni: http://www.paulgraham.com/taste.html zejmena pasaz: Good design is redesign.

Jo aha, tady jde o přípravu projektu. Tam ale v embedded světě prototyp nepatří. A proč? protože:

1) Pokud obchodníci vidí, že něco bliká, hýbe se atd., do tří dnů domluví prodej 2000 ks do dvou měsíců, bez ohledu na projekt. Obchodník nerozumí tomu, že jsou to kulisy.
2) Prototyp nedá odpověď na otázky "čí a jakou potřebu to řeší", "kolik je potenciálních zákazníků". To stejný tak jako tak musí člověk odprezentovat. A pokud jsou ty čísla zajímavý, stačí jako studie proveditelnosti ukázat složku se štosem potištěných papírů.
3) Prototyp je zavádějící. Kombinace pravdivých odpovědí na otázky "kolik stál ten HW prototypu" a "kolik bude stát finální produkt" je sebevražda. Nadsadit cenu kitu, kterou si můžou ověřit, podkope mou důvěryhodnost a podstřelit řádově cenu HW je zabití projektu před dokončením, až rupne skutečná cena.
4) Jít s prototypem před startem projektu ven z firmy je sebevražda. Než se vedení rozhoupe, zákazník to stihne zadat konkurenci, která to, co vyneseš ven, prostě obšlehne.

Takže je bezpečnější, i když třeba prototypy pro vlastní potřebu máš, je mít pod zámkem a všechno před startem jenom na papíře. A i tam kontrolovat informace, aby se nedostalo k obchodníkům know-how, protože ti neznají detaily a prásknou cokoliv ve snaze ukázat zákazníkovi, jakou (pro ně) hi-tech technologii používáme. (Takhle jsme v bývalé práci přišli o dva projekty).

Jo, a k UI - není to tím, že vývojáři jsou pod tlakem kvůli tomu, že po spatření prototypu hned zařizovali výrobu nehotové věci a neměli čas to dotáhnout? Na prototypu může vývojář dát třeba nastavování IP adresy jedním tlačítkem v morseovce, pokud mu to vyhovuje, ale měl by mít čas to předělat tak, aby byl zákazník spokojený. Jenomže pod tlakem, aby byl prototyp honem na trhu, se některý věci neřeší (UI, NTP nebo jiný server natvrdo -> závislost na nějaké službě, nastavení firewallu,...).

Když mám v ruce prototyp, jsem na začátku projektu v nevýhodě. Mám už hmatatelný výsledek a neukecám čas navíc.

A technický dluh zůstane... https://www.zdrojak.cz/clanky/technicky-dluh/

Zapomíná se, že práce embaďáka není o tom, napsat kód nebo navrhnout desku. ale má spoustu jiných povinností. Jednou z nich je komunikace s managementem a to bez taktizování nejde.

Pokud je prototyp využíván pro osobní potřebu, tak to opravdu na papíře neudělám.

Pokud chystám konkrétní projekt, tak
1) Vyberu součástky klíčový (procesor, paměť, GPRS modul)
2) Podívám se na traffic, co leze z GPRS, spočítám velikost dat a čas na jejich zpracování.
3) Podívá se na zvolený procesor. Zkontroluju
- rychlost dat vs. použitý rozhraní
- rychlost zápisu do paměti
- rychost jádra a strukturu dat (pro předzpracování v případě potřeby)
- kapacitu paměti
- event. možnost a prostupnost externí paměti
4) Rozhodnu se pro typ UI. Podívám se, jestli je dost pinů na MCU, ověřím kompatibilitu (napětí, proud)
5) Rozhodnu se, jestli a jaká komunikace tam bude pro vyčítání logu.
6) Zkontroluju dostupnost/re­alizovatelnost rozhraní na MCU a rychlsot vyčítání
7) Odhadnu spotřebu dle dokumentace (stačí papír a kalkulačka, první nástřel s přesností pod 30% stejně nebývá)

A hned vidím, jestli má nebo nemá smysl kupovat materiál na prototyp.

Když je to pro šéfa, udělám to 3x, pokaždý s jinou technologií, doplním kalkulaci pro předpokládaný objem výroby (s tolerancí do plusu) a jde se na poradu.

U nás jsme měli loni hackathon - mohli jsme založit týmy po 5 lidech, dostali 5 tisíc na nákup IoT hraček, mentoring a měli jsme pak 5 týdnů na přípravu něčeho, co by bylo prospěšné firmě/klientům/za­městnancům. Přímo se zapojilo tuším 80 lidí, tedy třetina zaměstnanců, další spousta lidí alespoň koukala na výsledky práce a hodnocení. A mnohé projekty byly opravdu pokročilé, včetně třeba machine learning atd. Spousta z nás se díky tomu teď věnuje IoT ve volném čase, kolega si teď dělá zabezpečovačku, já byl od té doby na 3 hackathonech, kde jsem to použil ... určitě doporučuji.

u nas byl hackaton jak je IoT volovina a jak to klienta ani nechteji a dobre jsme se zasmali, kliosi byli radi ze nejsem in za jejich penize a pokecali si nad necim prijemnym

ucastnilo se 100%

Muži na rozdíl od žen si umí hrát celý život. Ze hry mají radost. Každý za hru považuje něco jiného.Muž který si umí hrát, ví, s čím si hrát. Pro většinu mužů je proto práce koníčkem. Někomu stačí arduino, druhému 3D tisk, třetí touží mo novém motoru ve své F1... chudákům nebo mužům bez fantazie postačí klitoris své manželky.

Na klitoris ženám nesahám, mám totiž poruchu osobnosti.

To: ded.kenedy (neregistrovaný) 185.93.63.---
Asi jsi měl štěstí na firmu, kde to fungovalo, jak by to fungovat mělo. Já jsem takové štěstí neměl. Nejen, že mi obchodníci kecali do věcí o kterých neměli ani páru, ale dojednávali věci co se mne a mé práce týkaly a já jsem se o tom celkem běžně dozvídal náhodou nebo i vůbec.