Programujem ATmega8/168/32/644P cca 3 roky. Rozne aplikacie do priemyslu, plno casovani, komunikacii SPI, I2C, hw UART, sw UART, obsluha klavesnic, displayov aj dost rychle veci, meranie teplot, regulacne slucky, archivy do velkokapacitnych zariadeni.
O asembler som ani nahodou nezavadil - nebolo preco. Vsetko v GCC (WINAVR). Vravel som si , ze raz mozno, ale fakt nie je najmensi dovod nieco robit na AVR v asm. Na tie casovania co sa tu tak casto spominaju ako ze je na ne skvely ASM, treba pouzit casovace a udalosti spracovavat pod prerusenim. Sebelepsie casovanie v ASM rychlo rozhodi komunikacia cez prerusenie, alebo presne casove spracovanie AD vstupu pre odfiltrovanie 50/100Hz brumu. RAMky kopec(1/2/4kB), pri dobrom rozvrhnuti aplikacie som nenarazil na problem s pamatou.
Mam kolegov, ktori z historickych dovodov stale pracuju na x51, ako napr 89C4051, 89C52, 89C55, nejaky DALLAS a tak podobne. Na asm nesiahli zhruba od roku 1996. A to komunikuju s citackami kariet, casuju 1-wire komunikaciu, displaye, tlacitka, archivy, skratka vsetko mozne do priemyslu a komercnej sfery. Podla ich slov, jedine C - a to robia na nejakom Kiely z roku 1-2-3. K absolutnej spokojnosti.
Casto sa tu vyzdvihuje znalost ASM - komunita PIC (16Fxxx) tazko moze mat s niecim inym dobre skusenosti - ako nevyhnutna pre dobre pochopenie cinnosti procesora. Tuto dogmu povazujem za podobnu ako tu, ze zem je placata. To absolutne nie je pravda. Pre dobre poznanie procesora treba vediet, ako a kedy nastavit pracovne registre a kedy co ktory bit v registry znamena. To je od instrukcneho suboru uplne nezavisle. Nemusim poznam ako sa mnemotechnicky nazyva ASM instrukcia, ktora nastavi bit v registri pre obzivenie WDT. O to sa postara prekladac. Znalost ASM urcite nie je na skodu, ale ani nahodou nie je nevyhnutna pre plne vyuzitie procesora.
Prave pre ten postrach z predlzenia trvania programu ak je tento pisany v C miesto v ASM ma viedol k tomu, ze v kazdej mojej aplikacii mam kod venovany meraniu dlzky trvania jednotlivych usekov s presnostou na cca 4,34us (u mna cca 64 instrukcne kvantum). Okrem toho si meriam “cas vrtania sa v nose” procesora, ked nema do coho pichnut. Meriam plavajuci priemer a maximum tohto casu. Prakticke vysledky ukazuju vyuzitie procesora zhruba na 8-40%(velmi husta komunikacia 115200Bd,archivacia vyuzivajuca SPI 1MbPS a zber udajov z I2C AD 25kbPS). Nemam preto dovod skusat nieco v ASM. Netvrdim, ze ASM je zly, mozno pre niekoho ako konicek… 
Ale videl som aj nie dobre napisane programy, ked sa pri komunikacii cakalo v slucke na ukoncenie odvysielania/prijatia dalsieho bajtu v komunikacnom protokole. Ale takej prasarni ani 100 ASM nepomoze. Aplikacia musi byt co najviac “vzdusna”, aby jednotlive celky necakali na mieste na vysledky inych celkov a nebrzdili tak cely procesor. Je potom jedno, ci su napisane v ASM, alebo v C. Ak nieco trva 120us a ma sa spustit kazdych 500us, nebudem to davat do slucky s kodom, ktory trva 4.2ms, ale aplikaciu rozvrhnem inym sposobom. Tu principialny rozdiel medzi C a ASM nieje, lebo ak by aj tie casy boli v ASM tretinove, potom mam situaciu 40us a 1.4ms a to takisto do 500us nevmestim.
Aby moj prispevok nevyznel ako zatracovanie ASM. Vobec nie. Su aplikacie, kde ten ASM zmysel ma, ako napr. v realnom case realizovana FFT pri nejakom filtrovani, vektorovom riadeni strojov atd. kde ide o kazdu us. No mp3 prehravac asi na x51 (a ani PIC, ci AVR 8bit) zmysel robit nema. Na 95% beznych aplikacii je C s rychlostou uplne s prehladom.
Jan16 pisal, ze C na 8bit podla neho velky zmysel nema. Musim mu oponovat, C-cko na 8bit velky zmysel ma. Len sa netreba sustredit na procesory s 2kB kodovou pamatou, 36-128B RAM, 2 urovnovym zasobnikom a neskutocne napaditym strankovanim programovej pamate. Tam nema pomaly zmysel ani ten ASM
Programy v C su v textovej forme kratsie a prehladnejsie. C-cko umoznuje abstraktnejsie (niekedy az kubisticky) nahliadat na problem a venovat sa jemu a nie tomu, ako porovnam tento word s tamtym floatom, na ktory mi ukazuje ukazatel do pola ukazatelov v ASM.
C-cko uz pri preklade strazi kopec veci o ktore sa programator nemusi starat, iba je upozorneny, ze toto alebo tamto je bud uplna blbost, alebo je to minimlane podozrive. C-ckove zdrojaky algoritmov (nie ovladanie periferii) su lahko prenositelne medzi roznymi platformami, atd. atd. A to vysledny program nemusi mat 1.5MB kodu. Aj tych 10-20kB je v C pre zaciatocnika napisanych omnoho rychlejsie a prehladnejsie ako v ASM.
Stari bardi maju samozrejme svoje makra a include subory a vsetky tie nastroje, ktore si za mnoho rokov prace spravili, upravili a odladili. Preto sa im v ASM bude programovat urcite rychlejsie, ako uplnemu zaciatocnikovi v C. Ale tento ich svojou produktivitou dobehne a predbehne omnoho rychlejsie ako sa nazdaju.
A na zaver. Aj v C sa clovek moze dobre zamotat a zaprasit a chce to vela studia a prebdenych noci. Tak ako i v ASM. Nic nie je samospasitelne. fifty-fifty.
P.S. Nechcel som apriori hanit 16Fxx, je to dieta svojej doby a volakedy v roku 1993 znamenal velky prielom v technologii, co sme i my vo firme vo velkom uspesne vyuzivali. No co bolo, bolo a dnes by som kazdeho noveho adepta pre pracu s jednocipmi od tejto vetvy urcite odhovaral, lebo su to objekttivne horsie a drahsie procesory ako ine 8bity na trhu. Ak sa mylim, opravte ma, ale na konkretnych prikladoch prosim. Ja len uvediem
16F74 [8kB Flash, 192B RAM, 8b AD, 5MIPS] 157,-Czk
AT89C51RD2 [64kB Flash, 2kB RAM, bez AD, 3.33MIPS] 99,-Czk
ATmega32 [32kB,2kB RAM, 10b AD, 8-16MIPS] 82,-Czk
]To uz radsej ta x51.