Ja len trochu k tomu C-cku.
Casto sa prizvukuje, aky je vysledok v C-cku pomaly a naboptnaly.
Moja cerstva skusenost. Bolo treba spravit delicku signalu z IRC cez 80kHz. To znamena, ze nestacilo iba oba signaly delit ale tiez kontrolovat suslednost oboch signalov. Jedna uroven trvala najkratsie 6.25us. Uz dopredu to bola uloha skor na HW riesenie, ale cez vikend suflik vhodne svaby nevydal, takze bolo treba riesit veci v MCU.
Odhadoval som, ze to bude musiet byt program v ASM, ale najprv pre overenie funkcionality som si ho najprv pre prehladnost spravil v C-cku. Je pravda ze nie na vasich 4 takty trvajucich instrukciach pod poklickou PIC ale na AVR s instrukciou na takt (toto nie je platena 
] reklama, jednoducho kazdy ma to svoje).
Na moje velke pocudovanie, vysledna prelozena slucka (v ktorej sa zaroven pravidelne kompletne nastavovali vsetky periferie kvoli moznej zmene nastavenia kvoli EMC v priemyselnom zarusenom prostredi) trvala 1.84us pri 18.43MHz Xtale. Vysledny hex zaberal 228B. Kazda uroven bola testovana minimalne 3x.
Potom sa vsak ukazalo, ze treba program doplnit este o dalsie ficury. Tie v C-cku trvali 2.82us/284B.
Tak som sa rozhodol, ze to prepisem do ASM lebo kazda desatina mikrosekundy sa ratala.
No a cuduj sa svete, dosiahol som cas 2.78us a progam zaberal 278B.
Suma sumarum, program v C-cku znamenal o 1.4% pomalsi vysledok za cenu 2.15% dlhsieho kodu. Nehovorim o tom, ze program v C je daleko prehladnejsi a udrziavatelnejsi. Nevidim ziaden dovod programovat v ASM. Apropo, toto nie je moja jedina skusenost s porovnanim vysledku v ASM a C-cku. Samozrejme, v tom cesku treba programovat vediet, a napriklad premenne v takto malych projektoch treba definovat ako napriklad
register uint8_t cnt1, cnt2;
prekladac poslusne umiestni premenne do registrov a nerobi zbytocne presuny z RAM a do RAM. Musim samozrejme vediet, kolko tam tyuch registrov je, ale uz si nemusim pamatat, ktore registre mozem vyuzit ako. O to sa stara prekladac.
Preto by som odporucal C-cka sa nebat a naucit sa ho obzvlast pre jeho vyuzitie cez cele spektrum rodin MCU.
Tu si myslim, ze niet co riesit. V inom ako v C (pri pouziti dobreho prekladaca) nema zmysel programovat. Teda samozrejme ak pouzivate take efektivne prekladace ako mame my na AVR (GCC).
Nie je pravda, ze C nejakym sposobom osetruje HW. Pravda je, ze absolutne ziadnym. Ani pri ASM a ani pri C-cku sa bez studia HW nik nezaobide. Aj v C-cku treba pouzit prikazy, ktore zapisuju priamo do vyhradenych registrov jednotlive bity pre nastavenie periferii. To je cela pravda. Mozu sa maximalne vyuzit funkcie, ktore robia nejake prednastavenie bez potreby poznania bitov HW, ale to je uz C-ckova nadstavba, nie samotne a hole prikazy C-cka. Tych staci vediet tak do dvanast, co je menej ako pocet instrukcii PIC-iek.
Prajem krasny vecer a vela uspechov pri tvorbe vlastnych aplikacii.
