mikrokontroleri od A do Sh

Nisam mogao ranije da odgovorim ali evo sad.
Kod poredjenja AVR i PIC serije mikrokontrolera treba prvo reci koje kontrolere treba porediti sa kojima. Ako uzmemo poredjenja sa linka porede se AVR32 i PIC18F serija. Posto je u pitanju ista RISC arhitektura cpu vecina instrukcija se i kod jednog i drugog kontrolera izvrsavaju u jednom instrukciskom taktu sem instrukcija granjanja gde moze biti i vise od 1 cilkusa. Razlika je jedino u nacinu dobijanja tog insktrukciskog ciklusa. Kod AVR-a jedan instrukciski takt se dobija od jednog takta osilatora dok kod PIC-a od 4 takta. Sad laicki govoreci ispada da je AVR brzi jer radi na manjoj frekvenciji oscilatora a u supstini je jedina prednost zbog manjih radio smetnji i nesto manjoj potrosnji struje u poredjenju sa adekvatnom frekvencijom kod PIC-a. Kod novihijin PIC kontrolera (nanoWATT) koji zamenjuju kontrolere koji se vise nece proizvoditi konstruktori microchipa su ubacili i PLL tako da frekvenciju oscilatora koju delimo na 4 da bi se dobio instrukciski takt mozemo da umnozimo sa 4 i tako dobijemo da 1 takt osilatora bude i jedan instrukciski takt. Ako testovi sa linka ne bi bili tendenciozni trebalo bi porediti kontrolere pod istim uslovima, AVR na 8MHZ sa 8Mhz instrukciskim taktom (8mips) i PIC 8MHz sa 8Mhz instrukciskim taktom (8mips) a ovako ispada da su poredili AVR (8Mhz osc, 8Mhz inst.takt) PIC (20Mhz osc, 5Mhz inst.takt odnosno 5Mhz osc, 5Mhz inst. takt). Sto se tice rezultata, malo su mi cudni jer je velika ralika kod 16Bitnog mnozenja u korist AVR-a odnosno u uslovnom granjanju u korist PIC-a iako bi ti rezultati trebali biti priblizno isti. Isto tako ovi testovi su strogo u sluzbi snage cpu u mikrokontroleru, bilo bi znimljivo kada bi u testovima bili ukljucene i periferije (minimalno vreme AD konverzije kod AVR ~13uS dok kod PIC-a 2,4uS). Jos nesto, Atmel garantije 10K flash upisa i 100K eeprom upisa dok Microchip 100K flash i 1M eeprom, mozda i to nekom znaci kod odabira kontrolera.

sander,

uludo rasprava, jednom ce neki MCU biti bolji, a drugi put drugi, zavisno od aplikacije. Ja sam u diskusiji PIC-AVR neutralan (koristim Motorolu), ali za aplikacije koje nemaju vise od 32 bajta podataka AVR je sampion u brzini. Svi podaci mogu biti u njegovim registrima, a registarske naredbe su dvoadresne i traju jedan ciklus. Citanje podataka u tabelama je kod AVR-a sasvim normalno, direktno se pristupa lokacijama flash-a, a kod PIC-a je to posebna prica daleko od zdrave pameti. AVR ima normalno indirektno indeksno adresiranje (doduse indeks je samo od 0 do 63), dok PIC od toga ima samo imitaciju. AVR moze stavljati podatke na stek i koristiti ih iako su tamo smesteni, PIC to ne moze ni u snu. AVR ima kontinualan i celovit pristup memoriji, dok PIC memoriju cepka na stranice (ljudi sada je 21 vek).

Medjutim, sve to ima svoju cenu, ako je obim podataka veci, AVR za pristup bilo kom podatku u memoriji trosi 4 bajta, Pa ako zelite samo da inkrementirate neki bajt u memoriji, morate da potrosite 10 bajtova koda, katastrofa. Uopste AVR trosi osetno vise flash-a nego PIC, sto se indirektno odrazava na realnu brzinu rada. Zbog problema Harvard strukture sa sirinom koda od samo 16 bitova, AVR nema potpuni skup naredbi za granjanje, dok PIC ima. Iz istog razloga, sve registarske instrukcije nisu primenjljive na sve registre AVR-a, dok kod PIC-a cak i memorijska lokacija ima osobine akumulatora.

Kada sve ovo uzmete u obzir, vidite da je besmislena prica o MIPS-ovima, jer ce AVR i PIC za razlicite programe imati razliciti broj instrukcija, i merodavno je samo vreme potrebno za izvrsenje nekog programskog zadatka.

Po treci put predlazem: napravite u C-u, quick sort algoritam, za recimo niz od 200 bajtova (sa istim inicijalnim vrednostima niza) i kompajlirajte za AVR i PIC, izbrojte generisane bajtove, i izmerite brzinu sortiranja. To vam je najbolji pokazatelj. Ne plasite se da ce vas omiljeni MCU biti losiji, verovatno ce za neke druge poslove biti bolj. I na kraju, zaista mislim da brzine svih 8-o bitnih MCU-ova su dovoljne za aplikacije koje su im namenjene, ostaje samo za ocenu broj bajtova flash-a koji ce potrositi i performanse integrisanog hardvera. Uporedite tajmere, AD konvertore, mehanizam interrupt-a i t. d. jer i to utice na realnu brzinu i trosenje flash-a.

Pozdrav.

To da je uluda rasprava znamo i ti i ja i svi koji se ozbiljnije bave tematikom, zato sam i rekao da je manje vise svejedno sa kojim kontrolerima ces raditi, ali ako pocetniku kazete da je AVR serija kontrolera nekoliko puta bolja od PIC kontrolera da li ce on biti ubedjen da je tako? Zato sam ja i insistirao da se kaze koji konkretno tipovi kontrolera se porede, jer globalno poredjenje bi imalo smisla jedino ako se porede najsnazniji predstavnici a tada (trenutno) AVR nije ni do kolena. Nije ni logicno da ce neki od proizvodjaca mikrokontrolera da dozvoli da bude nadjacan drasticno, zato i svi imaju podjednako "snazne" mikrokontrolere. E sad, stvar je afiniteta kojem ces se privoleti carstvu. Uostalom, ako je kontroler koji koristis mozda i malcice bolji od ostalih na trzistu to ne znaci da ces ti programrski znati da iskoristis tu prednost, isti kontroler a dva razlicita programera/programa za istu stvar tesko da mogu da budu isto dobro uradjena.

Tako je: 'A u rukah Mandusica Vuka svaka puska bice ubojita...'.

Pozdrav.

Evo, napravio sam mali test.
Primenio sam bubble sort algoritam na niz od samo 10 elemenata.

Niz je inicijalizovan sa sa:



A sort funkcija je:



Ako je element unsigned char:
Za MC9S08QE128 (8-o bitni) dobio sam: generisano 51 bajta koda i 1149 ciklusa sto daje vreme od 45.96us
Za MCF51QE128 (32-o bitni, potpuno kompatibilan sa predhodnim, hardver i portovi), dobijeno: 87 bajtova koda i 679 ciklusa sto odgovara vremenu 27.16us.

Element unsigned int
Za MC9S08QE128 (8-o bitni) dobio sam: generisano 88 bajta koda i 2044 ciklusa sto daje vreme od 81.76us
Za MCF51QE128 (32-o bitni), dobijeno: 89 bajtova koda i 688 ciklusa sto odgovara vremenu 27.52us.

Element unsigned long
Za MC9S08QE128 (8-o bitni) dobio sam: generisano 120 bajta koda i 8146 ciklusa sto daje vreme od 325.84us
Za MCF51QE128 (32-o bitni), dobijeno: 89 bajtova koda i 688 ciklusa sto odgovara vremenu 27.52us.

Dakle, sve zavisi kog su vam tipa podaci. Ako dominiraju bajtovi, onda dobitak nije veliki, ali za dvobajtne i cetvorobajtne varijable dobitak je znacajan.

Pozdrav svima!
Evo naidjoh na malo slobodnog vremena da se javim....

Korak,
u pravu si za potrosnju, linearno raste sa frekvencijom. Ja sam to pomjesao sa naponom napajanja (sa kojim potrosnja raste kvadratno) jer sam malo zbrzao. Umjesto da malo razmislim ja sam se oslonio na nesigurnu memoriju gdje sam odnekud iz sjecanja iscupao formulu P=C*Vdd*f^2, a u stvari je f*C*Vdd^2. Prva verzija se ne slaze ni po dimenzijama, ali eto nisam razmisljao nego se prisjecao, sto bi na neki nacin moglo da se protumaci i da je bolje imati jaci procesor nego vise memorije :) Salim se malo, ali nece mi se valjda zamjeriti.

Sto se tice cijene gore navedenog cipa koja je duplo veca od, kako rece, najjacih 8-bitnih cipova, treba imati u vidu da taj navedeni cip ima 144 pina i 256KB flash-a. To je ono sto dominantno odredjuje cijenu, a ne interni hardver. Tako se 16-bitni mikrokontroleri iz te serije (XC164) ali u pakovanjima od recimo 64 pina nalaze po cijeni izmedju 7 i 8 dolara, i to za jedan komad. Nisam siguran da tome moze da konkurise neki 8-bini mikrokontroler. Drugo, ne znam po cemu si stekao dojam da taj cip ima "skroman" interni hardver. Taj hardver ni po cemu ne zaostaje za onim koji imaju ekvivalentni 16-bitni mikrokontroleri ostalih proizvodjaca u istom cjenovnom rangu, pa recimo i Freescale (Motorola). Moglo bi se reci da mu je taj hardver cak i bolji od vecine procesora na trzistu. Gore je hardver samo izlistan, a da bi se ocjenio kvalitet tog hardvera trebalo bi u najmanju ruku barem procitati data sheet. 103 IO pina pruzaju razne mogucnosti, pogotovo sto taj cip ima i konfigurabilni interni kontroler spoljne magistrale te tako moze da radi odjednom sa vise razlicitihi eksternih memorija u adresnom prostoru do 16MB. Cak se i stack i GPS registri mogu mapirati u toj memoriji. A i svi znamo koliko "okolnog" hardvera mogu da ustede slobodni pinovi na mikrokontroleru, tako da je po meni svaki dodatni IO pin mikrokontrolera vredan svakog placenog centa. Zatim, taj procesor ima i "two-stage instruction fetch pipeline" i "five-stage instruction processing pipeline" pri cemu se vrsi i branch target prediction sa jos nekim optimizacijama za sto brze izvrsavanje programa, sto se bas ne srece cesto kod mikrokontrolera u ovoj klasi.
Ali kao sto vec rekoh, ne vidim sta 5-6 dolara gore ili dolje znaci u svemu tome kad se radi o tom "nasem" trzistu, da ga tako nazovemo. Kad se radi o velikim serijama, npr. neka fabrika hoce da napravi milion jeftinih digitalnih rucnih satova, onda je razumljivo zasto ici na minimalisticki dizajn, i tu je ono gdje se jos uvijek koriste i 4-bitni mikrokontroleri, sa svega par pinova. Ja imam jedan flash development tool od Texas Instrumentsa u formi USB sticka u kome je MSP430 F2013 kontroler sa 14 pinova. Kad se odbiju pinovi za napajanje, oscilator, reset... ostane svega par slobodnih pinova, a 16-bitno jezgro unutra ?! Znaci, sve ima neku svoju primjenu i namjenu, i daleko od toga da sam rekao da je 8-bitnim mikrokontrolerima odzvonilo. To nije ni blizu da se desi ni sa 4-bitnim, a kamoli sa 8-bitnim.
Ja sam samo posmatrao stvari iz perspektive jednog projektanta koji radi sam neke izolovane projekte koji se nece proizvoditi u serijama od vise hiljada. Mislim da takav pojedinac na normalnom trzistu ne treba sebi dozvoliti da se danima nateze da li ce ili nece da ugura svoj program u 16K i kako to da postigne. Pa jos da misli i o tome kako da optimizuje neke djelove koda da bi zadovoljio vremenske zahtjeve, pa da neke dijelove pise u asembleru i tako dalje i tako redom. Tako je nekad bilo, cipovi su bili skupi, hardverski resursi uvijek na granici dovoljnog i sl. Ako razmislimo sta su mikrokontroleri nekad trebali da rade i sta danas trebaju da rade, u biti se nista znacajno nije promjenilo. Proces pranja vesa u ves masini od prije 20 god. je manje vise isti kao i danas. Dizanje i spustanje lifta takodje. Poslovanje salterske sluzbe neke banke je manje vise isto kao i prije 20 god. Samo je promjenjeno to sto su cipovi danas 1000 (ovo je samo stilisticka figura, a ne tacan podatak) puta jaci nego prije 20 god. i kostaju 100 puta manje. Programeri PC aplikacija su to odavno shvatili pa poslovanje banke ne realizuju vise u asembleru nego u Java-i, ili cak nekim specijalizovanim softverskim paketima poput SAP-a, ili kako se vec zove i uopste ih ne brine sto bi se takav program mogao izvrsavati na 20 puta slabijim racunarima, samo da su istu stvar pisali u C-u ili Pascalu. Takav je trend i u embedded sistemima. Zasto uzeti neki cip od 2 dolara i pisati u asembleru program za ves masinu, kad mogu da uzmem od 5 dolara i uzivam u blagodetima visih programskih jezika, pa neka je i taj od 5 dolara 100 puta jaci nego sto treba. Mislim, sta znace ta 3 dolara razlike na cijenu ves masine od 500 evra. Valjda i moje vreme i moj zivot imaju neku vrednost majku mu. Silikona ima u neogranicenim kolicinama u zemljinoj kori, a mene nema bas toliko. Uz evaluation board koji sam dobio od Infineona stigao je i neki program, mislim da se zove DAvE, pomocu koga se moze uz par klikova misem dobiti gotov kod za npr. upravljanje jednosmjernog motora ili step motora, kao i automatsko konfigurisanje svih periferija na chipu. Kao sto rekoh, platiti nekog da to radi ispocetka na nekom skucenom procesoru je mnogo skuplje od ovih par klikova misem i procesora od 15-tak dolara. Realno, za upravljanje jednosmjernim ili step motorom je sasvim dovoljan i 4-bitni mikrokontroler, ali koga je to danas briga. U jednoj realizaciji biblioteke funkcija za rad sa grafickim displejem, neko iscrtavanje na graficki display 128x64, treba neki signal drzati neko vreme na aktivnom nivou, par nekih mikrosekundi ne sjecam se bas tacno sta je bilo, a kolega je to cekanje realizovao petljom u kojoj se ponavlja NOP instrukcija! Pitam ga - zasto tako pobogu kad imamo jos potpuno slobodna 2 tajmera?! Kaze on: ionako ima dovoljno preostalog vremena da se sve ostalo na vreme stigne, bolje je da se grije cip nego moja glava. Mislim donekle da je u pravu, ne treba tjerati mak na konac, pod svaku cijenu. Biblioteku je zavrsio za par sati, od cega je pola vremena proveo zabusavajuci. Da smo radili na nekom kontroleru koji je "taman dovoljan" trebalo bi nas petorica da citavu nedelju brojimo koliko ciklusa traje koja rutina da bi postigli da sve radi u zadatim vremenskim granicama, i da po citav dan analiziramo generisani asemblerski kod i trazimo redudanse. I sve to da bismo ustedjeli par dolara. Pa ja cu se radije odreci dorucka jedan dan, i ustedjeti tih par dolara, nego se muciti 7 dana i jos listati datasheet u krevetu pred spavanje. A koliko bi takav rad tek kostao poslodavca? Sta je smisao ustedjeti par dolara na cipu, pa zbog toga potrositi stotine dolara vise na drugoj strani....
Drugo, cijene 8-bitnih cipova nece jos dugo biti "znatno" jeftinije od 16-bitnih, kao sto je uostalom i sa svim drugim stvarima koje imaju noviju verziju. Ko se malo razumije u rad fabrike za proizvodnju cipova zna da je odrzavanje svake linije proizvodnje prilican posao i trosak i da se cijene starih proizvoda vrlo brzo izjednace sa cijenama novih verzija (odnosno, obicno se desi da cijene novih verzija proizvoda padnu na nivo starih, ili cak i ispod, zbog savremenije tehnologije proizvodnje koja se ulaze u nove proizvode, dok stare ostaju kakve su bile), tako da grcevito drzanje za stare stvari tesko da moze donijeti neke koristi u buducnosti.
Korak, u nekoliko navrata si spomenuo to koliko flasha zauzima u prosjeku programska instrukcija i to spominjao kao bitnu osobinu, ali evo ja da dodam da nikad s tim nisam imao problema i da nisam ni cuo da je to neki "veci" problem u praksi. Jednostavno uzmem kontroler sa onoliko flasha koliko mi treba da uopste o tome ne razmisljam. STM danas ima mikrokontrolere sa preko 800KB flasha. Tesko mi je da zamislim razlog zbog koga ne bih tako radio. Ako mozes, napisi svoja iskustva i sta je tu u pitanju?

Sto se tice ovog programa kojeg je korak predlozio za poredjenje performansi, vec sam ranije naveo da se danas za koliko-toliko prihvatljivo poredjenje smatra jedino koriscenje namjenski projektovanih benchmarkova. Ovakvi mali programi u obliku algoritmova za sortiranje, rjesavanja nekih puzzle-ova, mnozenje matrica i sl. su kod poredjenja performansi poznati kao "toy - programs" i generalno se vec odavno smatraju za pogresan nacin za poredjenje, jednako kao npr. i MIPS-ovi.
Cuveni primjer za to je benchmark program matrix300 SPEC komisije sa kraja 80-tih godina koji je mnozio matrice, a 99% vremena u tom programu se trosilo na jednu jedinu liniju koda. Taj program je sluzio neko vreme dok proizvodjaci kompajlera nisu specijalno optimizovali kompajlere da prepoznaje taj benchmark i da optimizuje prevedeni kod bas za taj slucaj. Neki kompajleri su tako dobijali cak i 9 puta brzi masinski kod, ali samo za taj benchmark, ali ne i ostale programe koje korisnik napise. Zbog toga je taj benchmark kao i njemu slicni 1992 i ukinut kao neadekvatan.
Zbog toga ovaj mali program koji je korak predlozio nece bas mnogo pokazati o performansama. Moguce je da jedan procesor 10 puta brze od jednog slozi taj niz, ali da zato npr. 50 puta sporije uradi nesto drugo. Rezultati ce drasticno ovisiti i o koriscenom kompajleru. Generalno poredjenje u svim oblastima je vrlo tesko, a rijetko se i izvodi. Ako je u nekoj aplikaciji dominantan rad sa prekidnim rutinama poredice se takvim benchmarkom, ako se negdje radi stalno seljakanje podataka po memoriji, onda ce taj benchmark biti relevantan za taj slucaj, a ne npr. neko floating point mnozenje koje se npr. uopste ne koristi u datoj aplikaciji.
Mozda jedino "smisleno" i "opste" poredjenje je donekle moguce ako se uporede statistike koriscenosti nekih arhitektura u nekoj velikoj oblasti, kao npr. autoindustriji. Autoindustrija je poznata kao vrlo zahtjevna po performansama mikrokontrolera jer je to oblast u kojoj oni rade u realnom vremenu, zahtjeva se velika pouzdanost, izdrzljivost, a zbog velikih kolicina, zahtjeva se i dobar odnos cijena/performanse (npr. preko 30% cijene danasnjih kamiona otpada na elektroniku! vjerovali ili ne). U autoindustriji prva tri mjesta po udjelu na trzistu drze Freescale, Infineon i STMicroelectronics (koji pravi derivate Infineonove 166 serije). Dakle, u principu imamo 2 vodece arhitekture mikrokontroleara, u mozda najzahtjevnijem trzistu danasnjice po trazenim performansama i kolicinama.
E sad, problem je iz kog ugla se posmatra sve to. Ako svako od nas posmatra iz svog licnog ugla, onda je nemoguce doci do opsteg zakljucka, a sa druge strane opsti zakljucak mozda i nije od neke koristi. Ako neko zivi i radi u Srbiji, onda je npr. PIC za njega dobar izbor: jefina oprema, lako nabavljiva, besplatni kompajleri i drugi alati itd. Sa druge strane Infineon tesko da cete kupiti u Radio Klubu, skoro da i nema besplatnih kompajlera (bar ne nekih znacajnih), oprema nije jeftina itd.... Ali ako neko hoce da se preseli npr. u Njemacku, lakse ce naci posao ako barata sa Infineonom i imace vecu platu..... Dakle, nista nema nekog smisla dok se ne stavi u neki kontekst.

I evo, na kraju da dodam, da sam stekao utisak da je moguce da neko stekne utisak da ja ili neko drugi, ili svi, odabiramo neku platformu i tvrdimo da je ona iz ovog ili onog razloga bolja od drugih. Taman posla da je tako. Ja mislim da nije bas pametno drzati se samo jedne stvari. Ako mi negdje odgovara 8-bitni kontroler stavicu ga, a gdje mi odgovara 16-bitni stavicu i njega. Ako mi negdje odgovara i drugi proizvodjac, uzecu neki cip od njega. Ne vidim sta je tu problem. U mom slucaju bakcem se Texas Instruments-om i Infineon-om, ali ne mogu da tvrdim da su bolji od ostalih (sa izuzetkom PIC-a), jer ostale i ne poznajem toliko dobro da bih mogao dati neko smisleno poredjenje. Znam da se neki lakse nabavljaju od drugih, da je sa nekima laksi pocetak i tome slicno, ali kad se covjek malo odmakne od tih pocetaka, kasnije je manje-vise sve isto, jer da nije tako prezivjela bi samo firma koja pravi ubjedljivo najbolje mikrokontrolere, a sve bi druge propale. TI mi je zgodan zbog male potrosnje, i idealan je za sve sto ide na baterije. Infineon ima zabavan datasheet i programiranje na njemu je labudova pjesma. A ako u obliznjoj prodavnici trenutno ima samo PIC, pa dobro, moze i on. Sigurno bi bilo dobro imati u vidu i ostale, ali ja jednostavno nemam toliko vremena da kvalitetno pratim i to ostalo. Ne pratim vise ni PIC, ali eto imam nesto alata i sjecanja za njega od ranije, pa bih se snasao. Po mom misljenju treba biti otvoren za sve. Prije ili kasnije ce vam doci sef i reci, e od sutra radimo na tome i tome. A zasto: pa eto, one guzonje od gore tako odlucile, niko ne zna zasto. Ili ako nemate sefa, doci ce musterija koja nema nikakvog pojma o cipovima i traziti da se radi bas sa nekim kontrolerom za koji je on negdje, pitaj boga gdje, cuo da je najbolji, i nema sanse da mu se ta ideja izbije iz glave.
Ili, bolje da kazem kako se to do skora govorilo u bivsoj nam, nekad vecoj otadzbini: "Nista nas ne smije iznenaditi!"
A sto se tice C-a, mislim da je o tome potpuno bespredmetno raspravljati. To je sad standard u embedded industriji i ne moze se ignorisati. Mozda poneko i ima vremena da sam razvija svoj prevodilac po svojim mjerilima, ali za vecinu ostale populacije koja se bavi mikrokontrolerima mislim da je to van svake rasprave. Pionirska vremena kompjutera kada se nesto revolucionarno novo moglo napraviti u garazi u kucnoj radinosti su odavno prosla. Jednostavno, mislim da se pojedinac ne moze takmiciti sa velikim korporacijama koje ulazu ogromne pare u razvoj prevodilaca i svega drugog. Ako neko ima takve aspiracije, mislim da je bolje je da se pridruzi nekom timu ili firmi koja to radi, nego da ide "sam protiv vjetrenjaca".
Drugo, u ovoj grani industrije C nije "samo" jezik kojim se isprogramira neki mikrokontroler da nesto radi i gotovo. C je ovdje isto sto i npr. engleski u politici. Postoje milioni stvari osim pisanja programa za mikrokontroler u ovoj industriji koji su uradjeni na C-u, od trenutka projektovanja cipa, pa do pisanja programa za njega na samom kraju, tu su razno-razne biblioteke za simulaciju hardvera, RTOS-ovi i moduli za testiranje itd... Ti mozes da napravis Paskal kompajler za neki FreeScale mikrokontroler, ali gdje cu ja da nadjem sve ostalo za ovaj posao na Pascalu, npr. biblioteku funkcija za recimo tamo neki GLCD kontroler ili neki RTOS. Znaci, opet sve moram da radim iz pocetka. Moze to biti nekom zabavno i zanimljivo itd. ali to je tako samo dok se time zanimas radi zanimacije, a egzistencija ti je obezbedjena sa neke druge strane. Sta da radim ja koji na takav nacin nikako ne mogu da budem konkurentan na trzistu, ako bi mi i za najobicniji uredjaj trebalo ko zna koliko vremena dok to sve sam uradim, a neki klinac hobista uzme gotove stvari sa interneta i zavrsi to za 1 dan. Tamo kod nas u Srbiji ponekad mozes da radis kako hoces, ali ovdje gdje sam ja sada, pri svakom sklapanju ugovora o izvrsenju nekog posla obavezno ima i clan o placanju penala za svaki dan prekoracenog roka, pa ko misli da moze sebi da dozvoli taj luksuz da 3 dana trazi neki bagic u asembleru, ili da razbija glavu kako da sabije program u 16K, ili da izmislja nanovo toplu vodu, neka samo izvoli. Dakle, kao sto sam vec rekao trziste je jedno, a dobre namjere nesto sasvim drugo. Nikad ranije nije bilo tako stegnuto sto se tice vremenskih rokova nego sada. Prvo sto musterija pita nije vise moze li se nesto napraviti i kako i po kojoj cijeni (zbog velike konkurencije zna se da ta cijena ne moze biti bogzna koliko razlicita od ostalih ponudjaca), nego DO KADA mozes to zavrsiti i na osnovu toga obicno bira koga ce da unajmi. Uredjaj treba da zadovoljava zadate performanse, a da li sam ja elegantno pomocu tajmera zadrzao neki pin odredjeno vreme na nekom nivou ili sam vrtio ukrug NOP instrukcije, to je cesto potpuno van fokusa. E sad, nemojte me pogresno shvatiti pa pomisliti da ja smatram da to tako treba i da je tako u redu. Ne, ne radi se o tome, ja samo govorim kakvo je trenutno stanje i da se sve to treba uzeti u obzir. Kako je Korak primjetio, kvalitet softvera opada na racun dostupnosti sve jaceg hardvera. Danas postoje citave horde "nazovi" embedded programera koji su tu stigli iz desktop programiranja, i koji nemaju pojma npr. sta je tranzistor ili margina suma. Ali eto, postoje alati koji omugucavaju i njima da se bave ovim poslom, i sta mi ostali tu mozemo. Jedno je sigurno: ne treba glavom kroz zid, kao ni protiv vjetrenjaca.

Pozdrav.

Odin D.

drago mi je da si detaljno izneo svoja iskustva i iz toga proistekla misljenja o ovoj temi. Mozda sam pogresan utisak stekao o TI MCU-ovima jer si naveo par njih, a ja sam nasumice skinuo tehnicke podatke jednog od njih (ne secam se kojeg jer ga nisam ni memorisao pa ne mogu da pogledam). I ja sam imao iskustvo (nekada) da sef kaze (jer je njemu to kazao njegov sef) da se neki projekat radi sa tim i tim MCU-om. Ali, sef bi obezbedio i razvojni sistem za rad sa novim MCU-om. Sada imam malu firmicu ovde u Nisu i moram sam da odlucujem o svemu. Spomenuo si ugovor i penale, ja to nemam, ali dajem garancije banke, sto je jos gore ako posao ne zavrsim na vreme.

Odavno je poznato da na razvoj softvera odlazi 2/3 vremena razvoja novog uredjaja. Ako se ne moze ubrzati masinsko projektovanje i izrada kucista kao i projektovanje i izrada PCB-a i nabavka materijala, onda je logicno da se vreme moze ustedeti samo na razvoju softvera. Ovo sam znao i pre 15-tak godina kada sm poceo da koristim MCU-ove, pa sam napisao svoj asembler, prvo za HC11, a onda ga preradio i za MC908. Efikasnost pisanja softvera u ovom asembleru je blizu efikasnosti koji pruza C. Ovo ne govorim napamet i pristrasno. Ali to sada nije tema. Medjutim, problem je nastao kod par musterija koje su zahtevale da radim sa drugim MCU-ovima (ATMEL i neki Filipsov 16-o bitni). To sam morao da radim u C-u. Iako sam gadljiv na C, ipak kao opste prihvaceni standard on omogucuje da delove razvijenog softvera koristis na raznim MCU-ovima, sto je velika prednost. Tu se srecem sa problemom da moram da imam C kompajlere za vise MCU-ovima, a to kosta, i pitanje je koliko ce koji biti koriscen. Za velike firme ovo nije problem. Da nevolja bude jos veca, zapazio sam da su se firme koje prave dobre profesionalne kompajlere kao dogovorile i podelile koje ce MCU-ove koja podrzati. Tako, kao da na nivou profesionalnih kompajlera postoji monopol pa su cene prilicno visoke. Skidanje nekih piratskih verzija nije resenje. Dakle, nije cudo sto se mi mali opredeljujemo za jednog proizvodjaca. Ja sam se opredelio za Motorolu, i trenutno radim sa 8-o bitnim MCU-om (MC908), ali razvojni sistem podrzava i 16-to bitni (MC9S12) kao i 32-o bitni. Doduse jos se druzim samo sa 8-o bitnim, jer nisam naisao na problem koji zahteva naki sa jacim CPU-om. Ako sam ja u ovakvoj situaciji, mogu zamisliti koliko je tesko armiji hobista, pa me ne cudi popularnost PIC-a.

Brzina razvoja softvera ne zavisi od toga da li je CPU mikrokontrolera 8-o bitni, 16-to bitni ili 32-o bitni. Ova brzina zavisi od razvojnog alata. Ali ako imamo u vidu da najbolji kompajleri proizvode najmanje 20% duzi kod (referenca je asembler) i vise od toga sporiji program, anda se namece potreba da se koristi snazniji MCU. To snazniji znaci: vise programske memorije i brzi rad. Sto se tice taktne frekfencije ona nije vezana za to koliko bajtni je CPU mikrokontrolera. Brzina dolazi do izrazaja kada se radi sa visebajtnim podacima, u cemu su najslabiji 8-o bitni MCU-ovi. Kada se radi o trosenju flash-a, po pravilu za obradu 8-o bitnih podataka, 8-o bitni MCU generise kraci kod od ostalih. Ali, ako se radi o visebajtnim podacima, 8-o bitni MCU drasticno trosi vise flash-a. Vecina proizvodjaca MCU-ova pokriva pored 8-o bitnih i 16-to i 32-o bitne sto donekle olaksava finansijske probleme ako se vezes za jednog. Ali tu prave problem musterije sa svojim striktnim zahtevima u pogledu izbora MCU-a. Drugi problem je taj da ako izdvojis 3 do 5 hiljada evra za dobar razvojni sistem, to ne ide odmah u trosak firem, vec se u trajanju od 5 godina odbija se po 20% od profita.

Dakle, da zakljucim: voleo bih da mogu da radim na nacin kako si ti opisao, ali imam puno problema da to ostvarim. Ne verujem da iko tako radi u Srbiji, jer oni koji imaju pare bave se trgovinom ili necim sto je u vezi sa tim. Moja firmica ne moze da akumulira toliko para da bi na isplativ nacin mogao da investiram u sve sto mi treba.

Sto se tice brzinskih testova, slazem se, do sada nisam naisao ni na jedan objektivan.

Primere koje sam dao sluze samo da se uoci razlika u obradi 8-o bitnih, 16-to bitnih i 32-o bitnih podataka, a ne da se procenjuje brzina.

Srdacan pozdrav.

@korak

Ne znam zašto si zapeo za:


Pa to nije nikakav argument. S obzirom da se radi o sistemima koji rade "u realnom vremenu" ne sme ni jedan događaj de se "previdi".
Znači u optimalno dizajniranom sistemu(hardverski i softverski) procesor MORA da maksimalno 20-30% svog vremena radi nešto "korisno" a ostatak
vremena "okreće palčeve" i čeka na neki događaj, u suprotnom ako ga naviješ na 70-80% nisi siguran da li će u nepovoljnom slučaju
da eventualno proguta neki karakter sa USART-a ili isuviše kasno startuje ADC ili pri prebrzom okretanju Enkodera propusti neki takt...
Isto to važi i sa Flash. Izabereš onaj procecor gde ćeš po prvoj proceni upotrebiti 10-20% Flash-a, jer nikad se ne zna,
stranka hoće nakon prvog uspešno završenog posla da dodaš još ovu ili onu opciju, ili još gore Meni na više jezika.
I šta onda znači onda tih 20% više Koda(to je onda 12%-24% Flash-a) ili 30% sporije izvršavanje(to je onda 26%-39% procesorskog vremena)
ako jedna s pažnjom napisana rutina za upravnjanje nekog grafičkog displeja nije portabilna i ne možeš da je primeniš na drugom procesoru,
a toliko si vremena utrošio na doterivanju i optimiranju iste.

Pozdrav

branko_g

Nisam zapeo, ali sam izneo poznatu cinjenicu. Zatim, spominjes "argument" naznam za sta. To nije argument ni zasta, vec upozorenje onima koji su programirali na asembleru, da pri prelasku na visi programski jezik moraju da racunaju sa pomenutim "gubicima". Da ne shvatis pogresno, ja sam pobornik visih programskih jezika, ali moras znati kvalitet kompajlera i moras znati koliko efikasan kod generise (brzina i duzina). Ali mozes i napamet da uzmes naj MCU i da ne brines.

Pravio sam dosta testova, bas da bih video sta me ceka kada predjem sa asemblera na C. Evo rezultata jednog.

Uzet je netrivijalni program za izracunavanje MAC sume preko DES algoritma. Ako si upoznat sa kriptovanjem onda znas sta je to. Napisao sam program na Metrowerks Code Warrior C-u za MC908 (nije vazan procesor za sam test). Ovaj kompajler spada u vrhunske i najnovija verzija kosta oko 6000$. Paralelno, prevodeci svaku C naredbu, napisao sam i asemblerski program. Mozda bi asembler bio negde bolje napisan, ali sam se nisam drzao napisanog C programa.

Prvo sam podesio C na optimizaciju po duzini koda i dobio:

C: duzina 3490 bajtova, vreme izracunavanja MAC sume 77.6ms
ASM: duzina 2940 bajtova, vreme 35.7ms
gubitak u duzini 19%, gubitak u vremenu 107%

Sada sam C podesio na optimizaciju po brzini

C: duzina 4460 bajtova, vreme izracunavanja MAC sume 49.7ms
ASM: duzina 2940 bajtova, vreme 35.7ms
gubitak u duzini 52%, gubitak u vremenu 34%

Moji programi ne "vrte palceve". Sve kriticne procedure se pokrecu na interrupt, a ostale se izvrsavaju na osnovu stanja procesa koje je opisano skupom flegova. Stanje procesa se analizira u interrupt-u od 1ms, tako da blagovremeno bude pozvana svaka procedura. E sad, moram da znam koliko koda mogu da obradim u interrupt-u od 1ms. Zato uvek merim trajanje svih interrupt-a i ne dozvoljavam da oni zauzmu vise od oko 50% procesorskog vremena, jer neke stvari moraju da se urade i u glavnoj petlji.

Valjda smo se sada bolje razumeli,

Pozdrav.

Korak,
iz one tvoje gore poruke sada je mnogo jasnije ono sto si ranije pisao, odnosno mogu bolje da razumijem zasto je tvoj stav ovakav ili onakav.
Iako to nisi nigdje eksplicitno napisao, stekao sam utisak da ti u svojoj firmi radis sam, sto bas i nije lako, pa cime god se covjek bavio, a pogotovo to vazi za ovu nasu oblast. Ako sam u pravu, mozda bih se usudio da dam jedan savjet, a to je da ako ima ikakve sanse probas da na neki nacin ukljucis jos nekog da radi s tobom. Ne radi se samo o podjeli poslova, troskova, novca i vremena, vec ima i nekih subjektivnih faktora koji pozitivno uticu na sam posao, jednako kao i ovi materijalni gore pobrojani. Kad se trazi neki bag, nijedan debuger ili ICE emulator ti ne moze toliko pomoci koliko svjez i odmoran partner ili pogled iz drugog ugla. Sa druge strane, mozda ti taj kolega bude nesto slobodniji u svojim pogledima na koriscenje ovaj, hm, softwera sumnjivog porijekla, ako tako mogu da se izrazim, pa smanjite malo troskove poslovanja. Srbija ipak nije Kalifornija, i treba se izboriti za svoje mjesto pod suncem. Nacela koja su korisna u zdravoj sredini cesto nisu ni od kakve koristi u nezdravoj sredini. Limun pijemo kad smo zdravi, a kad se vec razbolimo onda limun ne pomaze, nego penicilin.
Jos bih nesto dodao i za ovu brankovu primjedbu koja ipak nije bez osnova. Naime, asembler danas u 99% slucajeva ne egzistira vise ni kao krajnja nuzda, a kamoli kao neka "referenca". Jedina dva slucaja kad sam ga ja upotrebljavao je bilo kad sam se prvi put u zivotu hobisticki susreo sa mikrokontrolerom (bio je ti PIC16F84) i drugi put iz nekih lab. vjezbi iz jednog predmeta vezanog za embedded sisteme, na jednom fakultetu koji bas nije drzao korak sa ostatkom svijeta, da ga sad ne imenujem, mogao bi neko da se primi na raspravu.
Asembler je nesto sto se danas izbjegava "po svaku cijenu", pa cak i ako to ponekad iziskuje i promjenu citave platforme. Jednostavno, iz mog iskustva, onaj ko je zaduzen da vodi projekat i donosi odluke, mora da ima debelu petlju i dobar razlog da bi odobrio da se nesto radi u asembleru, pa koliko god to mali dio koda bio. Asembler je vrlo problematican za testiranje, a jos je gori za odrzavanje. I onaj ko je to napisao, poslije pet dana nema pojma sta je radio, a kamoli kad neko treci dodje poslije 2 godine da nesto tu doradi ili popravi. Ti troskovi baktanja sa asemblerom su enormni. Vidjao sam slucajeve da su timovi kompletno mijenjali platformu samo zato da bi izbjegli asembler. Npr. odustajali su od cipa na 70MHz i uhodane platforme i alata i prelazili na drugog proizvodjaca i potpuno drugu arhitekturu na 400MHz, da ne bi razmisljali o asembleru.
Ti si naveo neke podatke u usporedbi C-a i asemblera o gubitku procesorskog vremena i memorije. Medjutim, u danasnje vreme ti se troskovi smatraju trivijalnim u odnosu na troskove u ljudskom radu koji se visestruko uvecavaju ako se koristi asembler umjesto C-a. Ja bukvalno za nekoliko desetina minuta mogu u C-u da napisem kompletan program za obavljanje nekog trivijalnog zadatka, npr. otvaranje i zatvaranje garaznih vrata pomocu npr. nekog tastera ili daljinskog upravljaca, sa sve PWM modulacijom za motor. A isto tako brzo mogu da modifikujem isti sistem tako da dodam numericku tastaturu i da se vrata otvaraju ukucavanjem neke sifre, sa sve debounsiranjem tastature. I to bez koriscenja gotovih biblioteka. To bih mozda mogao da uradim, a da cak ni jednom ne moram da bacim pogled u data sheet koriscenog mikrokontrolera, koristeci samo one informacije koje su mi dostupne u razvojnom okruzenju prevodioca. E sad probaj da zamislis koliko bi to sve trajalo u asembleru i o cemu bih ja sve morao da vodim racuna ako bih to radio u asembleru!? I sta bi se desilo ako bih trebao isti sistem da preuredim da se umrezi sa ostatkom elektronike u kuci ili neceg drugog. Ako bih koristio npr. XC164 od 6-7 dolara, koji je za ovaj sistem isto sto npr. i DeepBlue za kasu u samoposluzi, ja bih do mile volje mogao da mijenjam program u tom cipu i da ga kasnije kacim na sta god hocu, preko serijske magistrale ili neke druge koje su integrisane kao periferije u cipu i da prosirujem program i dodajem nove mogucnosti, npr. da otvara 10 vrata mjesto jednih i da istu stvar sa manje ili vise po potrebi modifikovanim zahtjevima prodam 50-torici ljudi bez problema, i bez potrebe da to svaki put radim iz pocetka, iako je to na ovako komotnoj platformi i uz koriscenje C-a trivijalno. Od raspolozivih 128KB flasha na cipu sigurno ce mi vise od 100 ostati prazno, ali sta sad tim!? Ako se uzme u obzir da (govorim za ostatak evrope, ne za Srbiju) plata upravo svrsenog inzinjera ide od 15E/h, pa navise, onda je jasno kako stvari stoje kod izbora mikrokontrolera: da li cemo da izaberemo mali procesor i tucemo dan i noc 15 dana, ili cemo da platimo 10$ vise i da jedan od nas to zavrsi za 2 sata?! Ako npr. pogledas na internetu oglase za posao u kojima se trazi embedded programiranje tesko da ces naci nekog poslodavca ta trazi poznavanje asemblera, dok je C standardni zahtjev koji se toliko podrazumjeva da je ponekad suvisno i da se navodi.
Vec sam ranije naveo gdje asembler danas jos egzistira - velike serije jednog istog proizvoda gdje usteda od par dolara na nekom dijelu hardvera pomnozena sa ogromnim brojem primjeraka donese na kraju neku znacajnu sumu. Drugi primjer je kod nekih krajnje specificnih aplikacija gdje se i najaci procesori danasnjice tjeraju do krajnjih granica svojih mogucnosti, jer ne postoji neka druga opcija. Ima tu jos i raznih drugih slucajeva, ali procentualno su svi zajedno zanemarljivi spram svih ostalih gdje se asembler ne upotrebljava.
Jos na smaragdnim tablicama Hermesa Trismegistusa je zapisano "Kako dolje, tako i gore", sto primjenjeno na ovu nasu oblast znaci da se principi iz ostalih, opstijih grana programiranja prenose ovamo, kao i obrnuto. U ovom konkretnom slucaju pojam "reusability" je poceo da igra sve vazniju ulogu, odnosno da se jednom napisan kod sto je moguce vise kasnije upotrebljava uz sto manje naknadne izmjene i dorade, a to je sa asemblerom skoro nemoguce.

Nadam se da jos neko moze iznijeti neka svoja iskustva ili bar razmisljanja, mali broj ljudi sigurno ne moze dati kompletniju sliku citave situacije.

Pozdrav svim ucesnicima na ovoj temi.

Ovako po mome misljenju svako moze da radi sta god hoce, tj. svako treba da pise u programu koji on zna najbolje i koji mu lezi.

@Odin D.
Vi biste mozda zavrsilili onaj program u Cu za 2 sata, a u Asembleru za 15 dana, to je zato sto poznajete Cu, a gospodin Korak najverovatnije bi zavrsio za kratko vrijeme taj program u Asembleru.

Nemojte misliti da Vam ja sada nesto svima namecem i da pametujem nego samo iznosim svoje misljenje. Ova vasa rasprava je za nas pocetnike veoma korisna i mozemo iz toga puno nauciti. Sa gospodinom Odinom se slazem u potpunosti, tj. mnogo je lakse kupiti skuplju mikrokontrolelr sa boljom konfiguracijom nego petljati se sa nekim i bubati glavu kako smanjiti program, to vazi samo ako ne poznajes Asembler, a ako neko zna njega blago njemu. Asembler je jezik Mikrokontrolere, jeste da ga ja ne znam ali imam cilj da jednom naucim neke njegove osnove. Mislim da ce Asebler otici u zaborav za neke kasnije generacije tj. vjerujem da ce se razviti novi MCU sa mnogo boljom konfifuracijom, i u koje ce komotno moci stati programi, znaci oni ce biti mnogo mali, ali sa velikom brzinom, flesom... Nema sta Asebler gledajuci na ostale programske jezike je najpogodniji za rad MCU, ali cuo sam da ga je mnogo tesko nauciti, da se treba uciti, procitao sam mescini na ovome forumu kako je drug od nekoga koje post-ovao odgovor ucio Asembler 10 godina i da ga jos nije naucio...??sta mislite I ja mogu reci da veoma postujem one koji se opredela za Asembler, ali u isto ih vreme sazaljevam jer pretpostavljam da ce da potrose mnogo truda i vremena, dak i zivaca, jer ima dosta nerazumljivih stvari.

U danasnjem svetu ima mnogo samozvanih programera koji misle da je programiranje kliktanje misom i koriscenje tudjih biblioteka.Asembler je nezaobilazan za kriticne delove programa,za rad u realnom vremenu,pisanje drajvera,kompajlera i sl.Danas niko ne vodi racuna o performansama programa jer se svi razmecu hardverom.Asembler je prirodno okruzenje za MCU-ove i ne treba ga isklkjuciti iz toga jer nudi transparentnost za razliku od visih jezika.Asembler se cesto koristi i za PC programiranje.Kao primer mogu da navedem asistenta na mom fakultetu koji je 7 godina pisao sahovski program na asembleru i koristio nove instrukcije koje nude danasnji procesori.Taj sahovski algoritam je ocenjen kao jedan od najboljih u svetu a pisao ga je samo jedan covek.Takodje i poznata igrica Quaqe 3 je pisana u asembleru.
Moje misljenje je da ako neko zeli da proramira neki MCU mora dovoljno da poznaje njegov hardver i arhitekturu bilo da radi sa asemblerom ili C-om,a ako nekom treba 10 godina da nauci asembler taj mora pod hitno da menja profesiju!

U danasnjem svetu ima mnogo samozvanih autoprevoznika koji misle da je prevozenje stiskanje gasa i koriscenje tudjih izuma. Konj je nezaobilazan za kriticne delove puta, za rad po blatnjavom vremenu, izvlacenje balvana, klada i sl. Danas niko ne vodi racuna o performansama sofera jer se svi razmecu snagom benzinskog motora. Konj je prirodno okruzenje za sofere i ne treba ga iskjuciti iz toga jer nudi transparentnost za razliku od haube kamiona. Konj se cesto koristi i za prevoz putnika. Kao primer mogu da navedem seljaka u mom selu koji je 7 godina prevozio navijace na utakmicu na konju i koristio nove puteve koje su napravili danasnji bageri. Taj prevoz navijaca je ocenjen kao jedan od najduzih u svetu a obavio ga je samo jedan covek. Takodje i poznata alatka "Brazda 3" je pokretana pomocu konja.
Moje misljenje je da ako neko zeli da prevozi neki teret mora dovoljno da poznaje gradju i psihologiju konja bilo da radi sa konjem ili C-amionom, a ako nekom treba 10 godina da pritpitomi konja taj mora pod hitno da menja profesiju!

Malko kasnim ali evo nesto od mene...
U pocetku smo se nadmetali ciji je bolji, mislim na mikrokontrolere koje koristimo, i svelo se na to da je svaki upotrebljiv i da sa svakim se moze zavrsiti posao. Svako je probao da ubedi one druge da je njegova kombinacija dobitna ali niko nije promenio svoje misljenje oko toga. Sad je rasprava o koriscenju asemblera ili nekih od programskij jezika. Cini mi se da ce biti kao i kod kontrolera. Sto se tice mene ja sada najvise radim u C-u ali kao sto je neko pomenuo asembler je za neke stvari nezamenljiv. Dosta puta u C program ubacim asemblerski kod kod nekih kriticnih stvari ali sada nikada ne bih koristio USART u asembleru kad je to mnogo elegantnije u C-u. Svako od vas ili od nas je upravu ali ako treba da kao iskusniji korisnici mikrokontrolera pomognemo pocetnicima onda je svakako najbolje da se prvo malo radi u asembleru jer je to nacin da se svet mikrokontrolera najbolje shvati a kasnije kad su neke stvari jasnije svako ce moci da vidi u cemu je prednost ovoga ili onoga i sta mu najvise odgovara. Odin ima pravo kada kaze da je vreme za zavrsetak programa bitan, za njega i mene jeste jer ga nemamo previse, za one koji ga imaju neigra neku ulogu, mozda im je programiranje u asembleru interesantnije. Kada se vratim na neke stvari koje sam radio sa 16F84 u asembleru, sada ne niko ne bi naterao da to odradim tako, nekada mi je taj kontroler bio sve (davno bese). Sada za svaki projekat odaberem kontroler koji je optimalan za taj posao, hvala bogu Microchip ih ima u svim varijantama i sto se tice broja pinova i kolicine memorije, brzine itd. Jos nesto, svaki prelazak sa jednog programskog jezika na drugi iziskuje prilicno vremena da se njime ovlada ali ako se razmislja da se napravi korak od hobija i neceg ozbiljnijeg onda prelazak na C je najpametniji potez koji se moze napraviti. Naravno poznavanje asemblera je i dalje obavezno, ali sto se pre napravi taj korak kasnije ce se pokazati prava stvar.
Za mnoge pocetnike je (barem kod PIC-a) Basic primamljiv zbog toga sto se recimo lako dolazi do prvih programa (paljenje LED itd) ali to moze da bude losa varijanta za pocetak jer se nema potpun uvid u nacin funkcionisanja mikrokontrolera i mnoge stvari ostaju nejasne kada nesto zapne, narocito kod konfigurisanja periferija, interapta ...
Ako ste pocetnik i imate vremena a nekim slucajem ste iz Beograd ne bi bila losa varijanta da pogledate kurseva koji se nude u www.digitalent.info koji drzi legenda Voja Antonic.

Sander, uvazavam tvoje primjedbe, medjutim, moram ipak malo da pojasnim o cemu se tu radi po mom vidjenju.
Ako se pazljivije procitaju postovi na ovoj temi, zakljucuje se da se u vecem broju javljaju napisi o necemu sto ima malo veze sa onim o cemu pokusavamo da pricamo, odnosno da odredjeni autori ispisuju neke svoje vizije, ne vodeci racuna da li se ovdje o tome radi.
Ljudi se uhvate jedne recenice ili par nekih rijeci, izvuku ih iz konteksta, daju im znacenje koje njima tog momenta odgovara, i onda raspale po tome kako znaju i umiju. Tako mnogi od njih odmah polarizuju tudje izjave i nastoje da sve shvataju crno-bijelo, po ugledu na slicne rasprave na ostalim forumima gdje se npr. pljuje na windows ili linux i gdje jedni tvrde da u windowsu NISTA ne valja, a da u linuxu SVE valja, a ovi drugi isto tako samo suprotno.
Dakle, kako su neki pogresno primjetili, ja nigdje nisam rekao da asembler nicemu ne valja i da ga NIKAD ne treba koristiti. Asembler ima svoje mjesto u svemu tome i ima svoje razloge kada i gdje ga je smisleno koristiti, a vec sam sto puta rekao, vise sam i vrapcima dosadio, da nema smisla da se nesto tvrdi ako se ne stavi u neki kontekst. Dakle, mi mozemo iznositi svoja misljenja da li ima smisla da se asembler upotrebaljava za konkretno problem X, sa Y para i Z vremena na raspolaganju, pri cemu treba da se ostvare W performanse, pri U ocekivanjima za buducnost od tog projekta. Svakako nema smisla raspravljati na nivou "Asembler je zakon" ili "Asembler ni u ludilu". Sve je relativno dok se ne vezemo za neku tacku koju cemo smatrati za referentnu. Isto tako, detaljno poznavanje arhitekture nekog mikroprocesora je NEKAD potrebno, a nekad i ne. Bilo bi suvislo kada bih sad navodio primjere kao u slikovnici za jedan i drugi slucaj, vec sam to i previse radio na ovoj temi. Izgleda da sto se vise covjek trudi da objasni, to se manje onaj drugi trudi da te razumije.
Dalje, sve vrvi i od subjektivnih stavova, koji ne doprinose kvalitetu teme. Naravno da se slazem sa svima onima koji kazu da "svako ima pravo da radi/programira u onome sto sto on misli da je najbolje", ali to nije predmet price ovdje, ako ne navede zasto tako misli, jer isto tako onda ne bih mogao da zamjerim ni nekome ko bi upao na ovu temu i napisao da "svako moze ako hoce da bude vegeterijanac i sjedi citav zivot pod nekim drvetom u Indiji umjesto sto pise program za mikrokontroler, kad to ionako sve nema smisla". Mozda to i jest tako, ali nije za ovu temu, nek otvori drugu. Ja, i jos neki se trudimo da iznesemo neka objektivna razmisljanja, ili da pokusamo da predocimo neku sliku kako mi to sve vidimo, a jos vaznije i svoja licna iskustva, pokusavajuci da to ucinimo sto objektivnijim, kako bi neko treci mogao nesto korisno iz tog da procita, odnosno da i mi nesto korisno cujemo i naucimo. A ako neko zeli da pise o svojim lirskim osjecanjima prema svom procesoru ili jeziku onda bolje da otvori neki blog na npr. myspace.com pa nek tamo o tome pise. Ovo je ipak bolje da ostane koliko-toliko objektivan forum iz koga se moze nauciti i nesto vise od toga ko sta licno voli da jede ili sta je kome simpaticno ili ne.
Vecina ljudi uglavnom daje savjete da je bas najbolje onako kako su oni radili. Izgleda da je mnogima tesko da uvide da je moguce da u tome ima i necega sto nije bas najbolje, a ako i naslucuju onda odbijaju da prihvate. Ja kad nekog pitam za savjet koji stampac da kupim, on mi obavezno savjetuje da kupim bas onaj koji je on kupio. Isto tako i za fotoaparat, automobil, dio grada u kojem treba da nadjem stan i sve ostalo. Tako isto ljudi rade i ovdje na forumu.

Korak je u nekom od zadnjih postova naveo svoja konkretna iskustva, neke cijene, neke informacije iz kojih se moze nesto konretno i zakljuciti o tom njegovom trzistu i shvatiti zasto nesto radi ovako ili onako i koji faktori tu konfiguriraju i to je ok. mada je to trebalo kljestima iscupati od njega :) Neka slika moze da se sklopi, nekom te informacije mogu biti od koristi. Citalac moze da stekne neki dojam o obimu posla, troskovima, zahtjevima musterija (8-bit ili 16-bit ili nesto trece) itd... To je jedan konstruktivan primjer. A sa druge strane npr. glogov_kolac je naveo neki argument kako je neki asistent 7 godina pisao sahovski algoritam na asembleru?! i to je sve. Pa sta to znaci? O cemu on to sad prica? Ko je taj covjek i cime se jos osim tom izjavom dokazuje da je to smisleno? Ima ljudi koji su izvrsili samoubistvo, pa sumnjam da ce se glogov_kolac ubiti ako ja izjavim da je tamo neko izvrsio samoubistvo. Od cega je taj covjek zivio tih 7 godina? Je li to radio zato sto mu je neko placao za to, ili nije imao pametnija posla? Ko je njega cekao 7 godina? Kaze koristio je najnovije mogucnosti najsavremenijih procesora, a prije 7 godina najsavremeniji procesori nisu ni postojali, jer su napravljeni tek prije par mjeseci. Pa nije ovo poljoprivreda, pa da se ore kako se oralo prije 7 godina. Ovdje se stvari mijenjaju na mjesecnom nivou. Po mojoj procjeni, taj ako je skoro zavrsio, onda je poceo negdje sa AMD Duron na 700-900 MHz, koji je u to vreme bio popularan. I cemu onda sad, napokon zavrsen, sluzi taj algoritam, medju najboljim na svijetu? Njegov algoritam na tom procesoru sigurno ne radi brze od istog takvog algoritma pisanom u C++ na danasnjem Pentium-u sa 4 jezgra. I gdje ce on danas da ode da kupi Duron 700 MHz? I koliko mu sad vremena treba da prepravi taj asemblerski program za danasnje procesore? Jos 7 godina? Kad zavrsi vec ce biti neki drugi procesori.... Bilo bi dobro da glogov_kolac pruzi neke odgovore na ova pitanja koja su se sigurno javila i kod drugih citalaca, a ne samo kod mene. Onda bismo mogli da ocjenimo vrednost tog argumetna u citavoj njegovoj prici o asembleru, a ovako to ne znaci nista.

Ja nemam nista da kazem protiv asemblera, poznajem asembler svih mikrokontrolera sa kojima sam radio, i sa asemblerom sam i poceo. Kao sto Sander rece, nekad je to bilo sve. Od poznavanja asemblera i arhitekture mikrokontroleara sam uvijek imao samo koristi, a nikad stete, sto je i logicno.
Skorasnji primjer:
Procesor uzima iz bafera koji se puni preko 100Mbit LAN pakete od 3 podatka, prva dva su informacije koje se dodatno obradjuju u jednoj funkciji ili ne, zavisno od vrednosti treceg podatka.
Pisano u C-u, a kompajliranjem dobijeni asemblerski listing tog detalja: (navodim neki pseudokod, i ne bas sve detalje, bilo je malcice komplikovanije, ali da bih pojednostavnio primjer onda ovako)

load Reg1, A
load Reg2, B
load Reg3, C
jumpif Reg3, DestAddr

A, B, i C se ucitavaju iz memorije. Sta je sad tu u pitanju? Ucitavanje iz memorije traje duze nego izvrsavanje instrukcije u jezgru procesora. Procesor ima pipeline arhitekturu i sve ove instrukcije su vec u jezgru. Problem je sto cetvrta instrukcija izvrsava skok na osnovu vrednosti u registru 3, u koji treba da se ucita podatak iz memorije. To ucitavanje traje duze, i upravljacka logika u jezgru ubacuje cekanje izmedju 3. i 4. instrukcije dok taj podatak (C) ne bude spreman u Reg3. Ova sekvenca se tokom rada izvrsava veliki broj puta i to cekanje akumulira neki delay.
Kompajler, koji inace nije los i u dobrom broju slucajeva zaista prepoznaje ovakve i slicne stvari i vrsi optimizaciju, to ovdje nije uradio.
Ali posto sam ja, odnosno ja i kolega, posto nisam radio sam, poznavao i asembler i detaljnu arhitekturu procesora sa kojim radim, bacili smo malo pogled na asemblerski listing i uradili sledece:

load Reg3, C
load Reg1, A
load Reg2, B
jumpif Reg3, DestAddr

C smo ucitali odmah na pocetku i kad jezgro "zahvati" cetvrtu instrukciju, C je vec odavno spremno u Reg3. Nema potrebe za ubacivanjem dodatnih stanja cekanja.
Pitaju nas, kako vasa procedura obradi 1000 paketa za vreme dok njihova 700?
Neko moze i da poznaje asemblerske instrukcije i da gleda u gornji kod i da iz toga opet ne vidi nista ako ne zna kako to jezgro radi i sta se tacno fizicki desava pri izvrsenju neke instrukcije.
Inace, ovakav slucaj je i skolski primjer vrsenja optimizacije koda na brzinu, i u ovakvom ili slicnom obliku se moze naci u raznim strucnim tekstovima koji se bave time.
Ali da dodam i to, da bismo zaista bili budale da smo sve radili u asembleru, s obzirom na velicinu programa i na to da smo mi radili samo jedan detalj citave stvari, bilo bi nemoguce da se to koordinira sa ostalim dijelovima i kolegama i da se to zavrsi prije nase penzije, a nismo bas u poznim godinama.
Uostalom 99% programa koje mi koristimo na PC-u su pisali programeri koji nemaju apsolutno nikakvog pojma o arhitekturi Pentium4 chipa ili graficke kartice i ostalih djelova, pa ti programi nekako rade i sluze nekoj svrsi. A prije 25 godina ljudi bi se smijali svakome ko bi izjavio da hoce da pise programe za PC, a ne poznaje arhitekturu i asembler za 8086. Nekad bilo sad se spominjalo.
Ja iskreno vjerujem da npr. iz ovog gornjeg primjera neko moze bar malo steci neku ideju, neki mali pixel, zasto i kada asembler, a kada ne. Ako bi i drugi navodili slicne primjere, broj tih pixela bi se povecavao i slika bi postajala razumnija. A ako se samo nesto tvrdi i izjavljuje bez ikakvih primjera i argumenata koji to potvrdjuju, onda zaista nema nikakve koristi od toga, jer su svi pixeli samo crni ili bijeli.

Neznam zasto je ljudima tesko da prihvate da se i ovdje stvari mijenjaju. Neki danasnji rucni satovi imaju vise procesorske snage nego sto su imali prvi moduli koji su se spustali na mjesec. Zar je za ocekivati da se kapaciteti snage i memorije danasnjih procesora mogu iskoristiti asemblerom.
Vec danas nije nista neobicno da mikrokontroleri srednje klase imaju 256KB flash memorije za program. Gruba procjena: ako mikrokontroler ima 16-bitne instrukcije, to mu dodje oko 128 hiljada instrukcija. Ako po stranici papira napisemo po 50 instrukcija, to je program od preko 2500 strana. Da vidim toga ko ce to da radi, a da ne stanuje o trosku drzave u nekom sanatorijumu.

Ko misli da se ozbiljno bavi ovim poslom, treba svakako da poznaje i arhitekturu i asembler onoga sa cime radi, ali isto tako treba da ima pravu mjeru stvari kad se sta upotrebljava, a ne ici iz krajnosti u krajnost. Umorio sam se od citanja postova u kojima dominiraju epiteti tipa "najbolje", "uvijek", "nikad", "apsolutno" i sl. i gdje su ti epiteti ujedno i jedini argumenti neke tvrdnje.
Sve treba uzimati sa zrncem soli i posmatrati stvari u malo siroj perspektivi. U pocetku ove grane industrije asembler je bio br. 1 a sve ostalo iza njega. Sad se nalazimo u prelaznom periodu koji je poceo jos odavno i gdje se pozicije mijenjaju. Normalno je da se u tom periodu i misljena polarizuju, ali je isto tako izvjesno da se u ovoj grani industrije nikad nije vracalo unazad. Ako smo poceli da se odmicemo od asemblera sigurno je da necemo krenuti unazad prema njemu. Malo kasnije C++ ce smijeniti C sa trona, a i njega ce smijeniti Java ili nesto sl. sta vec bude u to vreme. To je sasvim izvjesno. Takva je prirodna evolucija ovog posla. Alati koji iz grafickih algoritama generisu kod za mikrokontroler, danas u povoju, ce u skorijoj buducnosti biti regularna pojava. Ima dosta firmi koji prave programe koji generisu kod iz UML dijagrama. Doduse, to su poceci, ali sve je nekad imalo pocetak. Tako je bilo i sa PLC-ovima i ladder dijagramima.
Moj prvi racunar je bio C64 i tada sam se pitao ocu li ja ikad biti u stanju da iskoristim to sta taj racunar sve moze. A danas njegov procesor, 6502 na nekih 0.5MHz, u 99.9% slucajeva ne bi bio dovoljan za ono sto radim, pa sve i da ga programiram citacem busenih kartica, a ne asemblerom (ovo je ironicno, nemoj sad da neko napise kako citac busenih kartica nije programski jezik).

milovan_regodic je dao komentar o vjestini vladanja asemblerom i da bi korak mozda brze od mene uradio nesto na asembleru. Naravno da je tako, uopste ne sumnjam u to, s obzirom da korak redovno radi sa njim i da mu je to mozda i primarni jezik. Medjutim, mislim da treba da pojasnim da ja nisam pricao o tim slucajevima gdje to poredjenje ima smisla, vec sam pokusao da ukazem na slucajeve u kojim to nema smisla. Da bih to slikovito ilustrovao evo sledeci primjer:
Zamislite da imate gomilicu pijeska od npr. 100 kg koju treba premjestiti sa jednog mjesta 2 metra dalje, na drugo mjesto. Od alata imate lopatu (asembler) i bager (C). Vi sad mozete razmisljati ovako: "Pa dobro, ja sam u dobroj formi, odlicno baratam sa lopatom, mozda je bolje da to caskom uradim s lopatom, nego da palim bager, pa dok se zagrije, pa dok se isparkira, pa dok prebacim pijesak, pa dok ocistim kasiku, pa uparkiram nazad, potrosicu vise benzina nego tereta koji sam prebacio...." Takvo rezonovanje u tom slucaju ima nekog smisla. Plus sto lopata ima jos nekih svojih prednosti: svaki kamicak je pod kontrolom, mozemo da imamo uvid gdje ide svaki kamencic, napravicemo vrlo preciznu gomilicu na drugoj strani, ne moramo da napravimo ni jedan korak viska... dok je bager malo nezgrapan, treba da se vozamo malo napred-nazad dok ne zauzmemo najbolju poziciju, ne vidi se odozgo iz kabine bas svaki kamicak itd.....
A sad zamislite da se ne radi o 100kg nego o 100 kubika pijeska i da se to sve treba prebaciti 200 metara dalje. Sta cete onda da radite, hocete li da razmisljate o lopati? A sta se desava kad narucilac poslije toga dodje i kaze, ja sam se predomislio, ne tamo nego ovamo treba pijesak da stoji? Ili kaze da bi bilo dobro da se taj pijesak malo pomijesa sa nekim drugim krupnije granulacije?
Ja sam se obracao onim ljudima koji misle da se to i danas radi sa lopatom i da je neko negdje raspolozen da to plati.

Evo par poznatih izjava za koje ste sigurno vec culi:

"640K ought to be enough for anybody.", Bill Gates, 1981.
"There is no reason anyone would want a computer in their home.", Ken Olson, predsjednik i osnivac DEC, 1977.
"I think there is a world market for maybe five computers." Thomas John Watson, predsjednik IBM-a.
"Computers in the future may have only 1000 vaccuum tubes and perhaps weigh 1.5 tons." casopis Popular Mechanics.
"One can not programm microcontrollers successfully without assembler." XY sa ES foruma, 2008. Pazite da se ne nadje vase ime ovdje umjesto XY.

Ja mislim da sam dosta pisao o ovome. Ja sam sam u nekoliko postova napisao vise teksta nego svi ostali zajedno u svim postovima. Necu vise reagovati na postove u kojima se radi o onome, sto sam u prethodnim postovima vec dovoljno, po mom misljenju, objasnio, a pogotovo ne na postove one vrste koje sam sada i ranije kritikovao.

Pozdrav svima.
Let the Data Sheet be with you!

_{[Ovu poruku je menjao Odin D. dana 26.01.2008. u 03:07 GMT+1]}

@Odin:
Svaka cast na ovim post-ovima, takodje i ostalima.

Onaj primer sa pijeskom je veoma dobar.

Iskreno ja sam pocetnik sto se tice mikrokontrolere, tako da ja ne mogu da dam dobar komentar.:) Htio sam vas pitati, da li program za mikrokontroler vi pisete u obicnom C ili ima posebam programski jezik C za MCU? Ja sam se opredelio da ucim PIC Basic, al naprocitao sam se post-ova na raznim forumima da je jezik C dobar za MCU, i da se sa njim moze mnogo toga uraditi, on je pretpostavljam za profesionalnu upotrebu??

Ajmo malo nesto konkretno.Pitanje za sve! Sta to cini neki mikroprocesor boljim od drugog (pn spojevi,kvalitet silicijuma?)
ili nesto drugo...ili je stvar u dobrim kompajlerima odnosno skupim? Sam softver ne vredi nista bio on c ili asembler!

Procesori razumeju masinski jezik 01010001 ,Pa tom logikom najbojli programer bi bio onaj koji bi baratao gomilom nula i jedinica a notepad jedini alat.Sto da se mucimo i bacamo pare za razne editore kompajlere kad notepad vrsi posao?

Mene konkretno interesuje da cujem iz vaseg iskustva posto ste imali prilike da se srecete sa razlicitim mikroprocesorima, sta je to sto garantuje stabilnost rada programa,odnosno celog uredjaja baziranog na mikroprocesoru?
Bazirajuci se samo na procesor i softver kao njegov sastavni deo.Ostavite po strani lose napajanje, lose projekte plocica, el-magnetne smetnje..itd.


Veliki pozdrav za sve.

Taman sam pomislio da cu malo odmoriti.....

Sto se tice komentara....
Svako moze da da dobar komentar ako navede zbog cega misli tako kako misli. Ne mora covjek nuzno biti u pravu sa tim sto tvrdi, ali bi svako trebao biti u stanju da barem malo objasni iz cega proizilazi neko misljenje. A svako objasnjenje je korisno; ako je pogresno naucicemo kako ne treba da radimo, a ako je ispravno tim bolje, naucicemo kako treba. Ja se sjecam nekog primjera iz matematike gdje se nizom nekih naizgled logicnih transformacija dokazivalo da je 2+2=5. Iz tog primjera se moglo dobro nauciti gdje se lako prave logicke greske i kako ne treba razmisljati. I pocetnik moze dati komentar o svojim pocetnickim iskustvima, to ne znaci da je taj komentar manje vredan od nekog drugog. Bar ja tako smatram. Niko ne moze dati bolji komentar o pocecima od pocetnika.

Sto se tice C-a za mikrokontrolere....
Kao i svuda, postoje razna rjesenja za taj posao, ali ja necu govoriti o nekim alternativama za koje 99% ljudi nikad nema potrebe da sazna u svom zivotu. Ono sto je uobicajena situacija je da:
1) proizvodjac tog mikrokontrolera sa kojim hoces da radis je napravio i prevodilac i/ili razvojno okruzenje za programiranje na tom mikrokontroleru
2) neka druga firma/firme je/su napravila prevodilac i/ili razvojno okruzenja za programiranje na tom mikrokontroleru
3)obje od prethodne dvije mogucnosti
Ovo vazi kako za jezik C, tako i za druge jezike, npr. Basic, kao sto je PIC Basic za PIC. Medjutim, to ne znaci da za svaki mikrokontroler postoje prevodioci za sve jezike. Basic postoji za PIC, ali se ne srece bas cesto za druge mikrokontrolere.
Medjutim, C postoji za sve uobicajene mikrokontrolere sa kojima 99% ljudi radi.
Te verzije jezika C za mikrokontrolere mogu biti potpuno istovjetne sa standardnim C-om koji se npr. koristi za programiranje na PC-u, ali se mogu i razlikovati u nekim detaljima, u zavisnosti od mikrokontrolera za koga je namjenjen i same svrhe zbog cega je napravljen. U tom pogledu, ta verzija C-a moze imati nesto sto standardna verzija nema, ili mu moze nedostajati nesto sto u standardnoj verziji inace postoji.
U embedded sistemima se mnogo radi sa bitovima i bajtovima, pa npr. mnoge verzije C-a za mikrokontrolere imaju prosiren set tipova, koji pored npr. ugradjenih tipova int, char, float itd., koji postoje u standardnom C-u, imaju jos i tip podatka bit i byte. To npr. ne postoji u standardnom C-u.
Sa druge strane, procesor za koji je napravljen takav C, mozda nije narocito jak i pretpostavka je da se nece koristiti za baratanje nekim slozenim strukturama podataka, pa npr. ne postoje strukture kao tipovi izvedenih podataka, sto postoji u standardnom C-u.
C je jezik ciji je dobar dio realizovan preko standardne biblioteke, koja se obavezno isporucuje uz sam kompajler. Medjutim funkcije za izlaz/ulaz podataka za standardni C su pisane za PC i sigurno ne mogu imati svog direktnog ekvivalenta u mikrokontrolerima. Isto tako npr. u standardnoj biblioteci se nalazi i biblioteka math.h u kojoj su definisane i razne matematicke funkcije, npr. trigonometrijske sin(x) ili cos(x). Ako taj mikrokontroler nije bas narocito "jak" moguce je da ove funkcije ne postoje jer bi to bilo mnogo posla za taj mali mikrokontroler, mozda bi mu to oduzimalo suvise vremena ili mu trosilo previse memorije. Moguce je i da postoje, ali da su jednostavnije nego inace, recimo da rade sa manjom tacnoscu ili sa podacima nekog jednostavnijeg tipa. Ako je blizu pameti, da niko razuman nece uzeti neki tako mali procesor da bi obavljao slozene matematicke proracune, onda je vjerovatno da ce i slozene matematicke operacije biti izostavljene iz te biblioteke, ili cak da ce citava biblioteka math.h biti izostavljena.
U embedded sistemima se cesto radi i sa prekidnim rutinama (da ne kazem uvijek) pa recimo cesto postoji i dodatni nacin definisanja funkcija kojima se one definisu da budu ustvari prekidne rutine. Normalno se funkcija definise sa:

tip_povratne_vrednosti ime_funkcije (lista argumenata) {
tijelo funkcije;
}

npr. funkcija koja vraca kvadrat nekog broja

float square(float x) {
return x*x;
}

i poziva se na uobicajen naziv kako se funkcija vec poziva.

Ali ako je funkcija ustvari prekidna rutina definise se ovako:

void timer0_isr (void) interrupt 0x20 {
....... naredbe koje treba da se izvrse;
}

Dodat je dio "interrupt 0x20". Ova funkcija bice pozvana automatski svaki put kada mikrokontroler primi prekidni zahtjev koji je oznacen brojem 0x20. U ovom slucaju to je prekid koji salje tajmer0, pa je prekidna rutina i dobila ime po njemu, a moze da se zove kako god hoce.

O razlikama izmedju ovog C-a i standardnog C-a se naravno moze procitati u dokumentaciji koja stigne uz prevodilac, u praksi to znaci otvoriti meni Help i procitati sta tamo pise.
Medjutim, ono sto je uvijek isto kod svih tih verzija C-a i standardnog C-a, je da je sintaksa i gramatika jezika uvijek ista, tako da osim tih specificnosti koje su dodate ili oduzete u odnosu na standardni C, ne treba nista novo uciti, sto se tice jezika C.

Dalje, C i profesionalna upotreba.
C je svakako jezik koji se mora dobro poznavati ako se neko misli baviti ovim poslom. Postoje alternativni zivotni stilovi i filozofije, gdje neko moze tvrditi drugacije, ali ja se nadam da nece sad neko otpoceti raspravu o tome, jer ovdje pricamo o 99% ljudi, a ne o onih 1% i isto tako pricamo o 99% radnih mjesta na kojima covjek moze naci posao, a ne o onih preostalih 1%.
Postoje razni razlozi zasto se danas C koristi u tolikom obimu, neki od tih razloga su istorijske prirode, neki cisto prakticne, neki kvalitativne, a neki kvantitativne. U svakom slucaju je tako kako je.
Da bi se neki projekat smatrao profesionalnim, ne mora da bude uradjen u C-u, mozes da ga radis u cemu god hoces ako ce to da zadovolji trazene zahtjeve i da funkcionise korektno. Medjutim, u vecini slucajeva ces ga uraditi u C-u zato sto je on sveprisutan, sto nije slucaj sa drugim jezicima (osim asemblera, ali vec sam pricao o tome gdje se on koristi) kao sto npr. u svakoj mjenjacnici u Srbiji mozes da kupis evre, ali ces tesko naci pezose ili kuvajtski dinar.

Sto se tice toga da li Basic ili C za pocetnika, tu ne mogu da dam neki direktan odgovor. To ne ovisi samo o tome sta se uci, nego i ko uci. Razlicitim ljudima mozda odgovara razlicit pristup. U svakom slucaju, za pocetnika tu ima dosta materijala sa kojim treba da se upozna bez obzira sa kojim jezikom pocinjao. Meni je u pocetku bilo najteze da pokrenem bilo sta da radi nesto, bez obzira da li se radilo o asembleru, C-u ili necem drugom. Mucili su me oscilatori, inicijalizacija procesora nakon ukljucenja, zapetljana konfiguraciona zaglavlja, razne trivijalne stvari koje su bile toliko trivijalne da se nisu cak ni navodile po dokumentaciji, a nisam imao koga da pitam, zasto brojac koji broji koliko puta stisnem taster odbroji do 23 kad ga stisnem samo jednom i milion drugih stvari. Vrlo je vazno da pokusas sustinski da razumijes sta se desava, bez obzira u kom jeziku pises. Da se citaju Data Sheet-ovi i da se pokusa sagledati kako sve to funkcionise, kako jezgro upravlja periferijama, kako se pokrece i zaustavlja npr. ADC, gdje su rezultati, kako doci do njih, kako periferija javlja o nekom dogadjaju, sta to znaci, kako je taj mehanizam realizovan u cipu itd. Sve su to stvari koje ne ovise o jeziku, to je hardver.
Ako si u nekoj mjeri komforan sa Basic-om, mozda je najbolje da nastavis tako i vidis kuda ce te to odvesti. Svakako je bolje da uspijes neku malu stvar u Basic-u, nego da omanes sa nekom velikom u asembleru. Ti mali uspjesi ce ti dati malo podstreka u tom ucenju, a ostale stvari ce i ovako i onako doci uz put. Kad osjetis da ti je Basic tijesan, sam ces preci na C.
Najbolje se uci uz neki primjer. Kad sam ja ucio C i C++ nisam mogao da zapamtim 5 linija koda koje sam upravo procitao i skrenuo pogled sa knjige na neku drugu stranu. Ali mjesecima pamtim stotine linija koda koje sam ja sam napisao za neku konkretnu stvar koju sam radio. Ucenje na primjerima je posebno korisno u ovoj oblasti.

Nadam se da je bilo od pomoci.
Pozdrav.

Da bilo mi je od pomoci, hvala vam.

Pravo je mi je zadovoljstvo kada na forumu mogu da razmenim misljenje sa kompetentnim ljudima o nekoj temi, kao
sada u poslednjih par nedelja. Mislim da se u sustini svi slazemo, ali se izrazavamo na razlicite nacine.
Nedostaje nam konkretnost i cinjenice sto bi posluzilo i drugima koji prate ovu temu.

Odin D. blizu si kada si procenio da radim sam. Da, moja firmica ima samo jednog zaposljenog, to sam ja. Ali sa
jos petoricom kolega saradjujem jer imaju firme registrovane za pruzanje usluga, tako da ih ponekad angazujem za
usluge u razvoju i projektovanju i drugim poslovima. Radim po tenderima, i imam periodican posao, pa iz tog
razloga ne mogu da imam stalno zaposlene.

Ako bi sazeli nase diskusije, onda bi mogli da ih svedemo na nekoliko tacaka:

1. Asembler je najmocniji i najbolji programski jezik za razvoj softvera MCU-a i sa njime se mogu 100% iskoristiti
interni resursi MCU-a.

2. Priblizno isto vreme (algoritam, pisanje izvornog teksta i testiranje) se trosi po jednoj liniji ispisanog
izvornog koda. To znaci da ce se manje vremena utrositi na pisanje softvera na visem programskom jeziku nego na
asembleru.

3. Program napisan na visem programskom jeziku, moze se kompajlirati za razlicite MCU-ove sto dozvoljava da se u
jednom uredjaju lako jedan MCU moze zameniti drugim. Naravno, uz neznatna prilagodjavanja.

4. Nijedan visi programski jezik ne moze da bude efikasan kao asembler. Zato treba ukalkulisati gubitak u brzini i
visak generisanog koda prilikom izbora MCU-a.

5. Programski jezik C je toliko dominantan da je jedini programski jezik viseg nivoa koji se koristi u
profesionalnom programiranju MCU-a.

6. C je nastao kao pomocni jezik za razvoj UNIX-a u AT&T Belovim laboratorijama (Denis Rici 1972). U prvoj verziji
nije imao ni tipove, ali je po zavrsetku razvoja UNIX-a preradjen i postao sastavni deo isporuke UNIX-a. Ustvari,
C je programski jezik srednjeg nivoa, i zato je besmisleno uporedjivati ga sa jezicima viseg nivoa kao sto su
PASCAL i drugi.

7. C je daleko od savrsenog programskog jezika. Oslanja se na linkere razvijene kasnih 50-tih godina proslog veka,
i zbog kompatibilnosti se, u tom smislu, do danas nije nista promenilo. Linkeri su tada bili neophodni jer u
memoriji racunara nije mogao da stane ceo izvorni tekst, pa se sa diska ucitavao deo po deo, i prevodio u objektni
kod, a na kraju je linker povezivao sve objektne fajlove koji su sadrzali objektne kodove. Danas za to ne postoji
potreba. Memorije su velike da mogu da prime ceo tekst programa i da ga prevedu u jednom ili vise prolaza. Greske
koje detektuje linker se ne mogu pozicionirati u izvornom kodu, i samo iskusnom programeru one ne prave problem. C
ne zadovoljava ni jedan od tri kriterijuma koja je postavio 1977 Barron za dobar programski jezik. Dakle, C je
postao to sto jeste diktatom logike profita i uzasavam se pomisli da ce dominirati i u narednim decenijama (valjda
nece). Logika profita koci razvoj softvera, a podstice razvoj hardvera, svedoci smo toga.

8. Upoznao sam nekoliko firmi na zapadu u kojima se ozbiljno i profesionalno programira na C-u. Sve one imaju
grupu za dibagiranje. Na trziste se izbacuje nedovoljno testiran softver a posle toga popravlja i kroz lansiranje
raznih verzija uzimaju pare od korisnika. Po teoriji dokazivanja ispravnosti programa (to nisam nikada radio),
program pisan na C-u (ali isto i u asembleru) nije moguce podvrgnuti dokazivanju ispravnosti. Praksa pokazuje da
broj gresaka u programu pisanom na C-u, podeljeno sa brojem linija koda, skoro isti kao kod asemblera.

Zaklucak: koristite C jer nemate drugi izbor, a asemblerom se samo pomazite tamo gde je kriticna brzina. Postoji
referentna definicija C-a kao standard, sto garantuje njegovu prenosivost sa jenog MCU-a na drugi (uz neznatna
podesavanja nestandardnih prosirenja koja moraju da postoje za svaki MCU). Vecina profesionalnih razvojnih sistema
obezbedjuje automatizam kod ovih podesavanja, pa tako mozete da ih izbegnete samim izborom MCU-a.

Znajuci sve ovo, pre 10-tak godina lutao sam izmedju asemblera i C-a. Asembleri koji su bili dostupni od raznih
proizvodjaca pisani su tako da deluju traumaticno na programera. Koncepcijski svi onu su bili isti, razlikovali su
se samo u asemblerskim iskazima. Asemblerske direktive su uglavnom bile iste i prilicno nelogicne. Sa asemblerom
svi znate kakva je muka izmisljati nazive labelama, voditi racuna o varijablama u memoriji, upravljati sa stekom i
t.d. Zato sam seo i za oko 6 meseci napisao sopstveni kompajler za asembler. U jednoj recenici: to je kao PASCAL u
kojem su PASCAL iskazi zamenjeni asemblerskim iskazima.

Dalji tekst nije za uzrast ispod 16 god. Salim se, ako nekog ne interesuje kako treba da izgleda dobar asembler,
ili smatra da je asembler mrtav, onda ne treba da cita ono sto sam u nastavku napisao.

Da ilustrujem primerima:

Umesto bit0..bit7 zgodno je upisati stvarna imena signala na portu D. Varijable se automatski rasporedjuju u

RAM-u, osim PortD koji sa absolute biva pozicioniran na adresi 8.
A evo kako se koristi:

Poziv procedura (PrvaSmena i t. d.) se vrsi samo navodjenjem imena, a kompajler odlucuje da li je dugacak ili
kratak poziv sa jsr ili bsr.


Deo funkcije MulLong je:

Postoje i makroi:

_if je kompajlerski uslov za prevodjenje jednog ili drugog dela programa.
_ErrorMSG prekida kompajliranje i ispisuje gresku kao da ju je ispisao kompajler.

Labela u makrou ne pravi problem kao u C-u. Ko je koristio C makroe sa labelom zna o cemu pisem.

Makro moze i da vrati vrednost:

Kad se ukljuci makro, formalni parametri (a i b i eventualni result) se zamenjuju stvarnim.
Tako:

result postaje Var4, a Var1, a b Var5. Kod poziva procedure i funkcija, vrsi se prenos vrednosti stvarnih
parametara vrednostima formalnih. Kod ukljucivanja makroa, stvarni parametri (kao objekti) zamenjuju formalne
parametre makroa, sto otvara siroku fleksibilnost pisanja softvera. Cak se mogu ostvariti i neke skromne osobine
objektno orijentisanih jezika.

Makro se moze ukljuciti i sa manje parametara, ali se sa exist ispituje koji postoji. Makro moze da ukljuci drugi
makro, a moze i da pozove bilo koju proceduru ili funkciju.

Vec imam modul sa velikim brojem makroa, i oni dominiraju u mojim programima. Kao da imam visi programski jezik
koji umesto operatora poziva funkcije za svaku operaciju. Naravno, tu su i moduli za komunikaciju, matematiku
(integer i float), rad sa stringovima i t. d.

Sta sam dobio ovim? Evo analiza na bazi modula (include fajla u C-u) napisanog za DES, TDES, MAC (sa DES i TDES)
koji su napisani za C i za ovakav asembler. Pisanje na C-u i testiranje je potrajalo nekoliko dana, a onda sam
odstampao C tekst i po njemu za manje od sata napisao asemblerski tekst. Ako ste obratili paznju, na ovakvom
asembleru to nije tesko, i zato je bilo tako brzo. Asemblerski program je odmah proradio ispravno (vec je bio
ispravan u C-u). Na C-u je fajl imao 626 linija izvornog koda, generisao je kod duzine 3986 bajtova (zajedno sa
tabelama), proizveo 71 bajt varijabli u RAM-u i izvrsavao je MAC izracunavanje za 77.6ms. Asemblerski modul je
imao 1490 linija izvornog koda, generisao je 3436 bajtova koda, potrosio 66 bajta RAM-a i izracunao MAC sumu za
35.7ms.

Vidi se da jedna linija C-a prosecno generise 6.4 bajta koda i izvrsava se za 124us. Asembler je u proseku
generisao 2.3 bajta koda po liniji sa prosecnim trajanjem od 24us. Podatak o vremenu izvrsenja je validan samo za
ovaj primer.

Moze se zakljuciti da sa mojim asemblerom pisem 2.3 puta duzi kod (i otprilike mi treba za to toliko vise remena),
ali kad se radi o algoritmu, strukturi programa i nizu drugih stvari, imajuci u vidu da moj asembler poseduje sve
strukture kao i C, a takodje i sve strukture podataka, za taj deo posla trosim priblizno isto vreme. Ako imate u
vidu da samo fizicko pisanje programa nema veliki udeo u razvoju softvera, onda efikasnost pisanja softvera za MCU
sa mojim asemblerom se priblizava efikasnosti programiranja na C-u. Sa druge strane imam dobitak u duzini koda i
brzini izvrsenja koda.

Naravno, C je nezamnljiv u slucaju kada bih sa MC908 presao na neki drugi MCU. Za taj drugi bi bez problema vazio
vec napisan fajl, dok bi na asembleru on morao da se ponovo pise. Dakle, kako za sada u svojim projektima koristim
uvek MCU iz iste familije, ja taj problem nemam.


Izvijavam se na preopsirnosti. Mozda nekoga ovo ne interesuje, ali sa ovakvim asemblerom priblizio sam se u
efikasnosti pisanja softvera u C-u. Nazalost ima jednu veliku manu, nije prenosiv na druge MCU-ove. Kompajler je
pisan u DELPHI-u i generisanje koda se vrsi u izdvojenom modulu, tako da zamenom tog modula mogu da imam ovakav
asembler i za druge MCU-ove. Ali ko ce to da radi? Uradio sam pre koju godinu ovakav asembler za AVR, ali nije
dovoljno testiran jer nisam nikad koristio taj MCU.

Naravno, nisam napisao samo samo asembler, on je integrisan sa editorom, simulatorom loaderom programa na MCU i
dibagerom.

Jos jednom izvinite na preopsirnosti, ali sam hteo da pokazem da i asembler moze da bude humaniji i efikasniji.

Srdacan pozdrav svima koji sa paznjom prate ovu temu.