K Jan16: Ked som spomynal programovanie pod Win a Linux, nepisal som o programovani Atmega pod tymito platformami, ale uviedol som ako VYHODU pracovat s GCC, s ktorym sa daju programovat aplikacie pod Win i Linux a nie len pod ARM a ATmega a co ja viem este pod aky zastup procesorov.
Pisal som aj, ze to nieje uplne priamociare a treba este vela veci dostudovat, ale je tu ta perspektiva, aj ked o nu prvoplanovo tazatelovi neslo.
K poznamke co vsetko ma Atmega oproti x51 (inak Sylabs je vyzbrojemy velmi slusne, ale aj za slusnu cenu) so si spomenul na scenu z Monthy Pythonov Zivot Briana na temu “co nam dali Rimania”. 
To ze nie je C ako C, respektive je, ale implementacie prostredia nie su som sa presvedcil, ked som sa snazil program v ICC prerobit pod GCC a iny program z GCC pod ICC aby som si overil efektivitu a rychlost prekladu jednotlivych prekladacov. Po dvoch dnoch som to vzdal. Program v rozsahu 22kB vysledneho kodu hojne vyuzivajuci HW je prepisat pod inu C platformu dost zahul. Samozrejme nejde o samotne prikazy C, ale o tie vseliake pragma, define, kniznice a co ja viem co este, ktore medzi platformami nie su jednoducho prenositelne. Ak sa mylim, opravte ma.
Preto, ak si bude chciet dnes zaciatocnik - v buducnosti odbornik vybrat niektoru z platforiem a udrzovat kod, je dobre si vybrat nieco, co ma pri “jednom” nauceni siroky zaber. A ked vidim to mnozstvo maleho a polamy uz aj lacneho hw s predinstalovanym Linuxom (nemam na mysli PC, ale male dosticky 5x6cm pre zabudovanie do zariadenia), myslim, ze je dobre mat do buducnosti potencial vediet sa rychlo pohybovat i v tejto oblasti.
Vediet ASM nie je zle. Ani pocitat na logaritmickom pravitku. Dodnes to viem, ale v praxi vobec nevyuzivam.
Rozdiel je poznat anatomiu asembleru a rozdiel procesor jednoducho pouzivat.
Na to, aby som mohol pouzivat procesor pre rozne aplikacie, nepotrebujem poznat anatomiu strojovych instrukcii - nemylit si prosim s anatomoiu procesora.
Nikdo predsa nemoze naprogramovat aplikaciu pre jednocip v C bez toho, aby nepoznal jeho moznosti a schopnosti. Neviem (viem, robil som ) ako u inych procesorovych platforiem, ale Atmel ma celkom slusne spracovane datasheety s prikladmi vyuzitia periferii ci v ASM alebo aj v C. Vsetko jasne strucne zrozumitelne, ziadna zahada. Clovek vie, co sa mu v procesore deje. Je fakt, ze ma dost obmedzenu kontrolu kde sa ktora strojova instrukcia v programe nachadza. A co? V PC sa programuje na omnoho “vzdialenejsich” platformach od samotneho HW (a nie len pod Win) a kupodivu to nevadi. Skratka sa treba sustredit na riesenie problemu, nie na dierovanie stitkov
Pre casovo kriticke aplikacie moze byt trochu menej efektivny kod na prekazku. Tam sa samotny ASM velmi hodi a je uzitocny. Poznam firmu kde sa dodnes programuju 386 v ASM a je to velmi renomovana firma.
Ruku na srdce, kolko zaciatocnikov potrebuje riesit casovo (hovorim o riadeni s casovym krokom 1-2us, za tu dobu spravi ATmega 16-32 instrukcii) narocne riadenia? Pravdou je aj to, ze na casovo naozaj kriticke operacie sa nevybera 8bit jednocip, ale dnes uz lacne (150-250Sk) 32bitove ARMy s vykonom cez 60MIPS. Oproti nim je aj ATmega so svojimi 8bit 20MISP pomaly slimak.
Myslim, ze je preto vyhodou, ak procesor robi instrukciu na takt a nie na 12 alebo na 4. Program napisany v C, aj keby bol po preklade 2x pomalsi (co nemusi byt) kvoli menej optimalizovanemu prekladu oproti kodu, ktory by vygeneroval odbornik (v ziadnom pripade nie zaciatocnik !!!)
bude na jednocyklovom procesore 2x rychlejsi, ako vysoko optimalizovany ASM pre procesor s 4taktovym jadrom (to ani nehovorim o rychlosti ASM ak treba pouzit v klasickej 12taktovej x51 MOVX).
Je pravda, ze okrem rychlosti je lubovolny prekladac z vyssieho jazyka tiez narocny na pamat. Cim je optimalizovaniejsia rychlost, tym mozu byt vacsie pamatove naroky. Podla mojich skusenosti 2-3x. Preto je dobre pouzivat procesorovy rad s dobre skalovatelnou pamatou a to ci uz ATmega, ARM7, PIC18 a ine.
Hlavne kvoli pamati by som nezacinal robit v C s procesorom s mensou flash ako 8kb. Hlavne na zaciatku tej pamate rychlo ubuda.
Jednoduche programy typu
for(;
{
a++;
if (a > 5000) zapni_led();
if (a> 10000) {
a = 0;
vypni_led();
}
}
zaberu naozaj par desiatok instrukcii a od programu v ASM sa dlzkou velmi nelisia.
Ale nieco serioznejse, s komunikaciou, obsluhou LCD displaya, tlacitok, AD, DA si vyzaduje naozaj trocha viac pamate. Je to vsak vyvazene kompaktnostou a lepsou udrziavatelnostu kodu. Par instrukcii (C ich ma tusim menej ako PIC16 ) na zapamatanie, polia, ukazatele (aj tie na ine ukazatele), abstraknejsi popis problemu viac vyhovujuci rieseniu ulohy a nie potrebam procesora.
Clovek sa v C moze hlavne viac sustredit na samotny problem a to vydim ako hlavnu vyhodu. Nemusi riesit problemy integer, cardinal, nasobenie delenie. Samozrejme, ze i v ASM sa daju napisat prislusne funckie, ale najprv ich musi zaciatocnik napisat, odladit, odskusat, pripadne sa oboznamovat s uz existujucimi a vediet ako ich zacleni do svojho programu, kym ich moze pouzit. Tato casova strata pri vyssich jazykoch odpada.
Aj pri pisani programu v C sa da brat ohlad na efektivitu ci uz casovu alebo pamatovu a tieto skusenosti su vo velkej miere prenositelne i na ine hw platformy.
Na zaver mam este otazku do plena, kolko typov procesorov jednej platformy je rozumne pouzivat.
Z mojej praxe sa mi javy rozsah nasledovny (za predpokladu, ze vsetky maju vsetky periferie)
z pohladu HW
maly 32pin
stredny 44pin
velky 64pin
z pohladu pamate
8kB
32kB
128kB
Martin
)
. Třeba se najde dobrá duše v Praze a okolí, která mi za pivo procesor pomůže naplnit (??).