Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Btw jaký používáte logický analyzátor? My jsme si velmi oblíbili Saleae Logic Pro 16.DSLogic Plus (16bit a az 400MHz) jako nejcastejsi zakladni nastroj. Jinak na hrani doma 8bit saleae (ten prvni bez bufferu a kaslat na ten jejich SW, sigrok PulseView je lepsi)
Ad1) Tak ako v inych odboroch, tak aj embedded vyvojar ma specializaciu, a je ich urcite hodne... Pri dnesnej komplikovanosti procesorov (akejkolvek architektury), je takmer nemozne pokryt (casovo/vedomostne) vsetky mozne periferie/sposoby. Proste, niekto je zamerany viac na SW vyvoj v embedded, niekto viac na HW..MCU, ktery ted pouzivame ma pres 20tis stran dokumentace (appnotes nepocitam). Jen popis jadra je nekolik tisic, dalsi tisice periferie.
Ad2) Za 8 rokov praxe nepoznam nikoho kto by sam pokryl nejaky cpu.. mozno tak CortexM0/+ .. pozrite si M4 s DSP alebo M7.. to o A-ckovych/R-kovych ani nehovorim...
Ad3) V 99,5% percentach kodu ktore sme robili, sme pouzivali ciste C.. ma to vela vyhod, napr staticka analyza kodu, unit testy, dokaze sa robit review testu, kodu... zvysnich 0,5% kodu boli optimalizovane ASM sekcie, ale kazda sekcia sa testovala predtym nez sa pouzila... a ajtak sa nasli po rokoch chyby...No prave. Vetsinou to neni treba. V nasem aktualnim projektu je to 99% C, 1% ASM. Vime jak je tezke ten drobek ASM testovat a udrzovat, ale prepsat do C to nejde.
Dnes ma procesor bezne 128/256/512/1024/2048/4096 kb Flasky, alebo obsahuje SD/RAM controller... Tak naco stracat drahocenny cas optimalizaciou niecoho co vo vacsine pripadou nieje ani treba...
Ad3a) V jednej jedinej aplikacii som videl vacsie pouzitie asm.. a to pre automotive motor control.. aj to len pre safety a fastloop (niektore vypocty vo FRAC aritmetike).. inac 95% kodu bolo v C...
Ad4) Na "trhu" je mnozstvo RTOS (https://www.osrtos.com/) takze pisat si svoj vlastny RTOS je vhodny leda tak na prehlbenie znalosti, inac je to strata casu... FreeRTOS je de-facto standard pre male MCU, a to pre vhodnu licenciu, jednoduchu portaciu, pekny memory model a dobru dokumentacku.. a ked nieco nejde tak si firma kupit ten zaklad co predava... support...Pro napsani vlastniho RTOS byly technicke duvody, ktere nemuzu rozebirat (NDA). Z free veci nevyhovovalo nic, takze jsme meli vyrizeny nakup RTOS v radu milionu + dalsi milony rocniho maintainance. A pak stopka z technickych duvodu a resilo se jesli si nechat udelat upravu existujiciho reseni dodavatelem nebo jit vlastni cestou.
Ad5) v CR/AT/DE je dost embedded firiem ktore vedia dobre zaplatit (sam v jednej robimNa stole mam 3 velke monitory a ani tak se to na ne nechce vejit. :-) IDE, hromada otevrenych datasheetu a schemat a par dalsich veci jako logicky analyzator a hned jsou 3 monitory malo. :-). Praca ma bavi, je zaujimava a clovek niekedy dostava takmer infarkt ked debbuguje dosku, pri tom cita schemu, a ma otvoreny RM.
Je to nieco medzi sadizmom, pozitkom, flustraciou a vnutornou vyzvou.
Osobne, embedded svet je velmi zaujimavy, urcite nieje fadny a nudny, komplikovanost je ale velmi vysoka takze to neni pre kazdeho.. Ale zasa, niekedy sa clovek vie pekne vysantit
Drzim palce.
Máte samozřejmě pravdu, chtěl jsem jen ilustrovat, že ASM už není zase tak potřebný, pokud nejde o nějakou specialitu. Většina kódu může být napsaná ve vyšším jazyce a jen kritické části se občas optimalizují ručně. Dnešní překladače jsou kvalitní a vyrovnat se jim není v běžném případě vůbec lehké.Tak to souhlas. Rucni ASM ma vyznam jen na specielni pripady jenze ty se ve svete emmbeded vyskytuji v nenulovem poctu.
CMSIS to umí (ale jmenuje se to stejně podle té instrukceTen priklad s QADD8 byl nevhodny. Lepsi priklad je QADD s vyuzitim Q flagu ve status registru.https://www.keil.com/pack/doc/cmsis/Core/html/group__intrinsic__SIMD__gr.html
A DSP funkcí je taky spoustu připravených: https://www.keil.com/pack/doc/CMSIS/DSP/html/modules.html
Na PC už jsem assembler dlouho nepotřeboval, většina x86 instrukcí má nějaký intrinsic v GCC. Bez podobně vybaveného překladače pro ARM bych nedělal, ani kdyby mě platily zlatem. Mimochodem ta intrukce QADDB8 má intrinsic unsigned int __qadd8(unsigned int val1, unsigned int val2), viz http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491f/CHDECGJB.html . Stačil jeden dotaz do Google.No dobre, QADD8 nebyl nejlepsi priklad. Lepsi je LDREX/STREX, kde uz to tak snadne neni. Nebo QADD, kdyz je zaroven nutne testovat vysledny Q flag stavoveho registru.
Pokud aplikace potřebuje FP výpočty, ať to dělá CPU. Pokud business model neumožňujr CPU s FPU, tak bych se mohl na takovou lowcost práci vybodnout.Pouzity procesor ma FPU jednotku. Jenze tohle byl hotspot v kodu, knihovni funkce potrebuje pres 200 tiku, optimalizovana pro DSP zapsana v C 45-120 podle vstupnich dat a totez optimalizovane rucne v ASM 60-63 tiku. Takova tresnicka na dortu. Proste jsem si to vychutnal, tohle clovek nedela kazdy den, ale v real time aplikaci je nutne mit v tymu nekoho, kdo to dokaze, to byla ta pointa.
Presne. Napsat preemtivni prepinani tasku je sranda. Jenze pak nastoupi nutnost posilat mezi tasky data, nutnost znat presne maximalni delku vypnuti interruptu ve vnitrnich kritickych sekcich kvuli zaruceni doby odezvy a to je stale jen miminko a do dospeleho RTOS priserne daleko.Hmmm, pán je expert a už toho má ve skutečných embedded projektech evidentně hodně za sebou.A ten RTOS taky musí někdo napsat...Myslíš ten primitivní scheduler co přepíná tasky? To ti napíšu za odpoledne.
programy jsou o 10 řádů jednodušší.To uz davno ne. Stovky tisic radku jsou uplne bezne i na mikrokontrolerech (externi knihovny a standartni knihovny prekladace nepocitam, dokonce ani generovane datove soubory). Pro porovnani Linux jadro ma neco pres 25M radek a je jednim z nejvetsich samostatnych projektu na svete.
Proto říkám, že to je náročnější práce než kódění v Javě. Člověk musí být jak elektronik, tak softwarář, izolovaně se to nedá dělat. U návrhu HW člověk musí přemýšlet, jak se to pak bude SW obsluhovat, programátor by měl chápat, proč je HW udělaný tak jak je a využívat toho. Běžnou součástí vybavení pracoviště embedded programátora je i mikropáječka, osciloskop a logická sonda, debugování je o dva řády složitější než v Javě a o řád než systémařina na PC. Často se dělá s čistě proprietárními věcmi, různorodost platforem je podstatně vyšší, je třeba sestudovat víc materiálů, než se do něčeho člověk pustí. Často je třeba uvažovat o omezeních, o kterých se na PC a vyšších platformách dávno neuvažuje, jako limitace pamětí, rychlostí procesoru apod.Proto me prekvapuje, ze to neni placene na urovni jinych IT specializaci. Realita 2018 je takova, ze lepici na foru od IoT resi jak do 6B dat nacpat napriklad 4 teplomery a mezitim stihnou probrat co je HEX kodovani. Bezny absolvent IT oboru netusi co je pointer, odkojeny Javou zna jen referenci. A chtit po nekom jaky dopad ma datova cache procesu, kdyz cerstve zapsana data musim prohnat DMA kanalem, to uz je uplne sci-fi.
Mně osobně to vyhovuje víc, není sice třeba znát monády a podobné výdobytky, ale člověk by měl mít cit pro to, jak se asi co přeloží do strojáku, kolik to zabere bajtů, kolik taktů atp. Ale embedář musí být buď softwarář, který se naučil i elektroniku, nebo elektrotechnik, který se naučil softwarařinu - jak kdo chce. Bez těch přesahů to zkrátka nejde.
Souhlas. Embedded elektronika muze by cokoli od pidiprocesoru ridiciho "blikajici svetelko", pres IoT, kde uz jsou napriklad komunikacni protokoly dost vysoke urovne az po systemy ve kterych neni zabudovany Linux ani videt jak velike je to blokove schema. A jeste k tomu je tu uplatneni pro lidi, kteri dokazi napriklad propojit mobilni aplikaci pres cloud a na druhe strane zemekoule zablikat svetylkem (takze musi znat od vseho kousek)A stran těch znalostí - embedded není IT, to je spíš elektronika.Elektronik nenaprogramuje složitější embedded aplikaci. Je potřeba přesah do sw inženýrství.
Čemu říkáš "naprostá rutina za pár šupů"?V Cechach radove 35-70 (az nejake ty vyjimky). Navic je k tomu nutne znat spoustu veci mimo obor, minimalne jak cist schemata nebo vedet co je hard-real-time (a proc v nem napriklad vicemene ignorovat navrhove vzory jak se pouzivaji napriklad v Jave)
Marxismus je zlo v čisté formě. Absolutní popření křesťanské etiky, takže se tím stává i blbostí, která nemůže fungovat a taky nefunguje, jak bylo za posledních 200 let mnohokrát experimentálně prokázáno.Bezva, vypadla z tebe hypoteza! Je kazde popreni krestanske etiky marxismus?
Freud byl marxista, nemá smysl se jím zabývat, jsou to dávno vyvrácené bludy.To tvoje zaklinani marxismem je vazne posedlost (co to podle tebe vubec je, krome toho ze je to univerzalni strasak?).
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2026 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
