kolko ozbiljnu?

Ozbilnju od pocetka do kraja.Mozda cu te zarocarati ali od skora se bavim m_controlerima, ali mislim da je dobro mesto da animiramo ljude da vise razmenju informacije...


POZDRAV

Ja bih, kao pocetnik, zeleo da ukratko saznam najbitnije stvari oko mikrokontrolera.
Imacu ja neki predmet u skoli o njima, ali ja nemam zivaca da to docekam i tada skontam. Pretrazivao sam forum i nasao brdo stvari o kontrolerima, ali to su obicno malo naprednija pitanja i jako mi je tesko iskopati nesto za pocetnike.
Prvo da kazem sta do sada znam o njima:
- Programiraju se specijalnim programskim alatima (ne znam kojim)
- Za programiranje potrebna specificna hardverska podrska (plocica, programator)
- Velike mogucnosti primene (to svi znamo)
- Raznovrsne brzine rada i sirina podataka (bita)
E sada ako moze sve ovo malo opsirnije. Koji kontroler preporucujete za prve eksperimente, gde moze da se kupi (naruci), koji softver je potreban i sema programatora.
Ili ako vas mrzi da pisete, napisite samo link ka temi koja se bavi ovim pitanjima (na ovom ili nekom drugom forumu, sajtu) i bicu vam svima zahvalan. Ili da mi preporucite neku dobru knjigu, to je jos bolje.
Znam dosta o elektronici i programiranju (cak i u asembleru) i mislim da cu jako lako skontati osnovne stvari.

Ja sam radio sa AT90S1200 I AT90S3213 Atmel m.c. pa bih mogao da se ukljucim u diskusiju.

Slab sam sa ovom tematikom, mada se eto nesto usavrsavam. U zavisnosti od tvojih predznanja mozda ce ti pomoci tehnicka dokumentacija nekog kontrolera, da vidis tacno kako to radi npr. www.microchip.com

Za pocetnika (predpostavka je da zelis da ulozis vreme ali da nemas mogucnosti da ulozis puno para):
- Uzmi PIC16F84A - potrebnu literaturu naci ces na www.microchip.com
- Programer mozes i sam da napravis (jednostavne seme mozes naci na web-u) (ako treba pomoc javi se ponovo).
- Specijalna alatka za programiranje - ako kupis programer dobijes je uz programer, ako napravis programer alatka se svodi na kontrolu paralelnog ili serijskog porta u zavisnosti gde ti je programer prikljucen.(ako treba pomoc javi se ponovo).
- microchip ima besplatan softver za PIC16F84A (editor, assembler, linker, simulator) mislim da se zove MPLAB ili nekako slicno (vidi na njihovom sajtu).
Mikrokontroleri su interesantan hobi ali i karijera.

Pozdrav,

Hvala vam, poseticu sajt pa ako bude bilo nejasnoca javljam se opet.

Imas domacu grupu (listu) koja se bavi mikrokontrolerima; mozes da joj pristupis slanjem praznog emaila na adresu [email protected].
Za pocetnike preporucujem 16F627 ili 16F628 posto su jeftiniji, a mocniji od 16F84.

Pozdrav.
Sinisha

PIC je mozda pristupacniji ali mislim da je atmel zastupljeniji u aplikacijama

na pr. pogledajte casopis infoelektronika

POZDRAV

Sto se tice ucenja pokusaj da nabavis CD izdanja ***mikroelektronica 2000 i 2001***.Tu mozes da procitas uvodne stvari o 16F84, 16F627, 16F628 i ponekom atmelu...
tu ces videti i kolika ja cena programatora posto se razlikuju u zavisnosti od m_kontrolera.

Na CD_u se nalazi i veci deo sajtova Microchip i Atmel_a korisno, izdanja su mozda starija ali
su od pomoci na pocetku...

Postoje i knjige u izdanju casopisa mikroelektronika sto mozes naci na njihovom sajtu


Pozdrav i drago mi je da sam uspeo da vas animiram...


www.mikroelektronika.co.yu


Keep trying...

Imam obe knjige i cd od mikroelektronike za osnove o pic kontrolerima. Kupio sam ih ocekujuci da cu vise saznati iz klnjiga i na nasem jeziku. Medjutim te knjige ne mogu nista posebno da vas nauce, jer nista ne objasnjavaju.
Sve sto moze da se kupi kod mikroelektronike postoji na internetu besplatno. Meni je licno za pic bio najkorisniji program za simulaciju rada pic mikrokontrolera microsim, firme bubble software. Na zalost sajt im vise ne postoji, kada sam pokusao da vidim da li ima novija verzxija softwera. Program je fenomenalan jer vizuelno objasnjava kako se programira za sta se koriste resursi itd. Mene je odusevio, a ima i deo za simulaciju napisanog programa, kao i vizuelni prikaz toka informacija kroz sam pic

Ajd' da dodam i ja nesto:

Ko hoce da pocne da se bavi mikrokontrolerima nek krene sa PIC-ovima ili Atmelima. Ne bih da forsiram ni jedne ni druge ali stvari stoje ovako:

PIC: Proizvodjac Microchip, lako su nabavljivi u nasim prodavnicama komponenti, gomila primera koje mozete naci na mrezi cine dobru polaznu osnovu za ucenje. Razvojno okruzenje MPLAB je dobro zamisljeno, besplatno, ali uz njega ide samo asembler, a kompajleri su skupi i krekovane verzije se veoma tesko nalaze. Preporucujem HITEC C kompajler i PICBASICPro jer cete za njih naci najvise vec odradjenih primera (mislim da su gotovi primeri nabolji i najbrzi nacin ucenja), mada postoje drugi od kojih su neki i besplatni. Programiranje u asembleru zaobidjite, sto zbog izuzetno redukovanog seta instrukcija to zbog naporne organizacije memorije. Za pocetak je najbolje uzeti 16f876 , sa hardverske strane ima gotovo sve a opet je u relativno malom i zgodnom pakovanju.

Atmel: ovde podrazumevam AVR familiju, 8-bitne RISC procesore. U odnosu na PIC-ove imaju malo manje primera na mrezi (ali i dalje sasvim dovoljno). AVR-GCC je besplatan C komapjler a Bascom je jeftini basic kompajler (mada je i demo verzija upotrebljiva za manje projekte). Programiranje u asembleru je lakse nego kod PIC-a . AVR-i su dosta hardverski mocniji u odnosu na PIC-ove (3-4 puta vise MIPS-a, jednostavnija unutrasnja organizacija, set instrukcija daleko veci, postoji vise vektora prekida a ne samo jedan kao kod PIC-a, za razliku od PIC-a ima upotrebljivi stack...). Dobra polazna osnova mogu biti ATMEGA 8535 ili ATTINY2313.


Programatori za PIC i AVR su relativno jednostavni za samogradnju, a ako hocete gotovo resenje, mikroelektronika prodaje razvojne sisteme koji su vrlo solidni za te pare.

Znaci za ucenje izaberite bilo sta, za ozbiljne projekte AVR-e.

Treba mi mikrokontroler PIC12F629. Pokušavam ga naručit, ali nema ga u katalogu iz kojega ja naručujem (chipoteka), tamo imaju samo 16CXXX, 16FXX i sl... Zna li tko koji mikrokontroler mogu uzeti za zamjenu...hvala...

12F675.

Pozdrav.
Sinisha

Ali nema nijedan koji počinje sa 12F, ima samo 16F, 16C, 16CE i sl.

Treba mi osim lista instrukcija za motorolu (konkretno 68hc11) i prikaz svih intrukcija preko mikroinstrukcija. Da li neko zna gde se takvi dokumenti mogu naći ili koga pitati za iste?

Hvala.

Dobih i ja Atmel AT91eb40a evaluation board ...
Za diplomski ...
Imam i gomilu razvojnih alata, GreenHills, EDGE IDE MentorGraphics, Metrowerks Code Warrior, ARM Development Suite, a Boga mi i IAR.
Ali jos nisam stigao da ih isprobam, tek se upoznajem sa razvojnom plocom i procesorom ...
Onako iz prve, mogu ti reci da su sve ovo trial verzije koje isticu za mesec - mesec i po dana, dok pune verzije kostaju i po 3000$ (npr. EDGE IDE ...)

Ne treba da napominjem da pojma nemam kako sve ovo radi i cemu sluzi ... :)



Uspeo sam, prateci uputstva, da uz ARM Development Suite v1.2 izbildujem i poteram LedSwing primer na datoj ploci ...

Ali ...

Kad sam probao sam da napravim "Hello world" to mi nije poslo za rukom ...

Poceo sam od Empty Project -> ....

A problem se javio kad je od postojeceg projekta, trebalo da napravim bin fajl i da flesujem memoriju ... tj spustim bin fajl na razvojnu plocu.

Ne uspevam da izgenerisem bin fajl ...
Iako pratim proceduru, nikako mi ne uspeva ...
Help ne postoji jer je u pitanju trial verzija ...
Ima li ko iskustva sa slicnim problemom ?

Pozzzzzzzzz

Bas fina tema. ali i vrlo siroka.

Treba razlikovati PIC i AVR koji imaju Harvard strukturu od Motorolinih koji imaju Fon Nojmanovu strukturu. Kada se radi o osmobitnim mikrokontrolerima Harvard struktura nailazi na probleme jer ne moze da maksimalno razvije svoje dobre osobine. Uglavnom zato su performanse kod 8-o bitnih MCU obe strukture priblizno iste. No, Fon Nojmanova struktura podrzava jedinstrven memorijski prostor bez izuzetaka sto cini programiranje u asembleru mnogo laksim.

Za pocetnika nije dobar PIC, zato sto ce mortati da se nauci nekim stvarima koje nisu normalne: zasto da memorija mora da bude stranicena, zasto podaci ne mogu da se drze na steku, zasto tabele ne mogu da se citaju kao normalni podaci, zasti indirektno adresiranje nije uobicajeno i mnogo toga.

AVR je u tom pogledu mnogo bolji, ali zbog Harvard strukture (o cemu mozemo diskutovati detaljnije) on trosi najneekonomicnije flash, skup naredbi mu je sa dosta izuzetaka, a ofset pri indeksnom indirektnom adresiranju je ogranicen na 63.

Najbolji MCU za pocetnike je, na primer, neki od MC908 familije. U njemu je sve 'normalno' i blisko zdravom razumu. Problem je sto je Freescale (Motorola) obratila mnogo vise paznje profesionalcima, a manje hobistima, ne shvatajuci da ce hobisti kada postanu profesionalci nastaviti da rade sa MCU-om kojim su do tada radili. Problem nabavke ne postoji ako imate firmu, cena je cak vrlo pristupacna. Na primer sada jedan moj kolega radi na USB komunikaciji sa PIC18F4550 (32KB flash, 2KB RAM i 35I/O) koji kosta 6.96$ na kolicinu 1..24 kom. Ja to isto pocinjem da radim sa MC9S08JM60 (60Kb flash. 4KB Ram i 51I/O) po ceni 6.12$ za 1 komad, a 5.20$ za 25 komada.

Zbog skupih razvojnih alata za Motoroline MCU-ove, ja sam razvio svoje razvojno okruzenje sa integrisanim editorom asemblerskim kompajlerom, loaderom programa na MCU, dibagerom i simulatorom. Asembler je napravljen u svemu kao PASCAL, samo su PASCAL iskazi zamenjeni asemblerskim iskazima. Tako asembler ima iste deklaracije kao PASCAL (record, array, set..of, procedure i function) kao i makroe. Takodje postoje i programske strukture if..then..else, case..of, while..do i repeat..until. Po ugledu na Turbo PASCAL postoje i modulu. Ovo sam uradio jer su svi asembleri uzasni, a sa ovakvim, svojim, asemblerom efikasnost pisanja softvera je bliza efikasnosti pisanja na C-u nego na klasicnom asembleru. Ako postoji interesovanje o ovome mozemo i detaljnije.

Pozdrav.

Vidim da smo stali sa ovom temom, hajde da okrenemo stvar. Interesantno bi bilo da napisemo sta nam smeta kod MCU-a koji koristimo, i sta bi voleli da je bolje napravljeno i na koji nacin. Pri tome, ko zna neka pohvali neku osobinu koju ima neki drugi MCU.

Da budem prvi:

MC908 ima samo dve vrednosti za preskaler kod WDT-a, dosta nezgodna stvar.

Za razliku od HC11 naredbe koje modifikuju memoriske lokacije (inc, dec, neg, com i t. d.) se odnose samo na nultu stranu, sto jeste dobitak na brzini, ali je ogranicenje u odnosu na memoriju.

Neki tipovi koji koriste kao oscilator 32768Hz, u monitor modu zahtevaju kristal od 4.9152MHz ili duplo veci. To zahteva da interfejs ima generator te frekvencije koja se dovodi na jedan od dva pina za kristal. Srecom tada ne mora da se odspaja kristal od 32768Hz. Podfamilija MC9S08 nema tih problema.

Smeta to sto se nesme zaboraviti jedno pshh na pocetku interrupt procedure i jedno pulh na kraju. Nije tesko to napisati, ali moze da se zaboravi i da napravi stetu ako interrupt procedura modifikuje H registar. Ovo je cena kompatibilnosti sa MC6805???

Svidja mi se kod PIC-a sto i memorijska lokacija moze da se ponasa kao akumulator.

Super je naredba kompariranja sa prenosom kod AVR-a. Zgodna je za uporedjivanje visebajtnih varijabli. Drugi MCU-ovi u toj prilici ne mogu da koriste kompariranje vec oduzimanje.

Ima jos, ako je interesantno.

Pozdrav.

Pa evo da i ja nešto kažem o mojim iskustvima sa mikrokontrolerima.
S obzirom da živim i radim na nemačkom govornom području pokušaću da
opičem kako "živi" jedan jako dobar forum sa isključivom temom
elektronika, mikrokontroleri, programiranje, DSP, dizajn i izrada štamnih pločica...
Strana je www.mikrocontroller.net
To je amaterski forum sa puno pitanja totalnih početnika ali i onih
naprednijih, na koje se vrlo brzo dobije kompetentan odgovor od iskusnih "vukova".
Što se tiče mikrokontrolera i pitanja vezanih sa njima, Atmel AVR je zastuplen sa
otprilike 80%, a ostatak dele Texas Istruments MSP430, ARM, pa PIC što govori za sebe.
Postoji i podforum "zbirka Source kodova" gde programeri prezentuju svoje projekte i programe
koje mogu i drugi koristiti.
Programi su preko 95% !!! pisani na jeziku C, zatim sledi Basic, a udeo programa pisanih na Assembler-u
je zanemarljiv.
Sve to me je i usmerilo da i dalje ostanem pri Atmel AVR procesoroma koje sam
na početku(pre 7-8 godina) programirao na Assembler-u, a od pre 3 godine sam
počeo da koristim WinAVR, "Open Source" integrisano razvojno okruženje
sa GCC C kompajlerom. Moram priznati da je prelazak na C otvorio sasvim novi Horizont
mogućnosti o kojima sam kao programer u Assembler-u mogao samo da sanjam.
Jednostavno umesto da "točak" ponovo otkrivam, uzeo sam da "Source Code" koji stoji
na raspolaganju na mreži, jednostavno analiziram i eventualno prilagodim mom Hardware-u.
Prerađeni Software sam ponovo postavio drugima na raspolaganju da ga mogu koristiti
za svoje potrebe.
Naravno poznavanje Hardware-a procesora koji programiraš je nešto što se MORA
ali sada čitav instrukcioni set i rukovanje Stack-om više nije problem programera
neko C kompajlera što veoma olakšava prve korake u programiranju.
Atmel je razvio za svoj AVR mikrokontroler jedno ibesplatno razvojno okruženje
AVRStudio koje pored Assembler-a ima mogućnost da mu se implementira i C-kompajler(GCC).
Debbuging preko JTAG interface-a je takođe moguć kao i čista Softverska simulacija koda
bez hardvera.

P.S. Još nešto oko dileme za početnike. AVR, PIC ili neki drugi procesor?
Imam utisak da je na našem govornom području uobičajeno generalizovanje kao
Kaladont- a misli se na zubnu pastu.
Tako ist i kod Mikrokontrolera, Ljudi imaju negde u podsvesti da su čuli nešto o
PIC-u pa kad im kažeš automatizacija, oni se odmah uhvate PIC-a, ko da ništa drugo ne postoji.
A alternativa ima taaaako puno, i boljih i savremenijih, sa boljom podrškom i na kraju jeftinijih.

Zamolio bih da mi branko_g da neki statisticki podatak.
Sa AVR-om sam radio samo malo, onoliko koliko mi je bilo potrebno da napisem PASCAL kompajler, a nisam napisao dovoljno koda da bih mogao da izvucem neku statistiku. Ono sto sam primetio je da dosta trosi flash.

Zamolio bih te, ako je moguce, da za neki netrivijalni program duzine 3 do 4 KB izvrsnog koda izvuces koliko ciklusa ima prosecna asemblerska instrukcija (MC908 ima 3) i koliko bajta flasha trosi prosecna instrukcija (MC908 trosi 1.95). Dakle, interesuje me kolicnik broja ciklusa i broja izvrsenih asemblerskih instrukcija, kao i kolicnik broja bajtova programa i broja asemblerskih instrukcija. Ovo su uvek interesantni podaci.

Unapred hvala.

Pozdrav.

PIC je firme Microchip, AVR je firme Atmel. E sad mene zanima je li MCU isto mikrokontroler i koje je firme?

Pa ovako, Atmel AVR, Logičke i aritmetiške operacije kao i data transfer traju 1 ciklus(ADD, ADC, MOV...) izuzev
multiplikacije(MUL, MULS....) koje traju 2 ciklusa.
Branch instrukcije(BREQ, BRNE...) traju 1 ili 2 ciklusa u zavisnosti da li je uslov ispunjen ili ne.
Data Transfer instrukcije koje operišu sa internim RAM-om traju 2 ciklusa(LD, ST..).
Bit i Bit-Test instrukcije(ROL, ROR, LSR...) traju 1 ciklus.
Ja mislim da je to strašno brzo i da malo koji 8-bitni MCU može da im konkuriše po brzini, s obzirom
da nova generacija radi na 20MHz.
Uostalom pogledaj aktuelne Datasheets.

MCU je mikrokontrolerska jedinica, dakle mikrokontroler - bilo koji. Tako mi je lakse da pisem.

Tacno je sto kaze branko_g,
MCU-ovi koje spominje imaju Harvard strukturu, a to znaci jednu magistarlu za flash, a drugi za RAM. (Fon Nojmanova ima jednu magistralu za sve memorijske resurse). Cilj je da dok se jedna naredba izvrsava (a tada se uglavnom radi sa RAM-om) slobodno moze da cita i dekodira sledecu naredbu iz flash-a tako da svaka naredba traji 1 ciklus. Da bi to zaista bilo tako potrebno je da sirina flash-a bude bar 24 bita (bajt za kod naredbe i dva bajta za adresu). Kako bi to mnogo trosilo flash, a 8-o bitni MCU-ovi ne mogu da podnesu taj luksuz, pribeglo se nekom medjuresenju sa sirinom flash-a od 16 bita. Ali postoji niz naredbi (implicitnih) koje zahtevaju samo kod naredbe, dakle 1 bajt, pa ispada da se uludo trosi jos jedan. Naravno da konstruktori MCU-a mogu da iskoriste taj bajt i da naprave slozeniju implicitnu naredbu. To je uradjeno kod AVR-a, kod koga implicitne naredbe obuhvataju 2 registra. Tako je AVR sampion u brzini sve dok je moguce varijable cuvati u njegovih 32 registra. Ako to nije moguce, onda AVR drasticno gubi na performansama. Pocinje da prosto guta flash, a i brzina se smanjuje. Na primer da bi inkrementirali neku varijablu koja je u memoriji, AVR ce za tu prostu operaciju potrositi 10 bajtova flash-a. Kod PIC-a se pribeglo drugom resenju, on stranici memoriju, i dok radite sa podacima koji su na istoj stranici, imate maksimalne performanse. Cim pocnete da radite sa podacima koji su razbacani po razlicitim stranicama RAM-a onda stalno morate da preklapate stranice i da za to gubite bajtove flash-a i MCU cikluse.

Kod Fon Nojmanove strukture (MC908) ovih problema nema. Ali zato nema ni paralelnog izvrsenja i citanja sledece naredbe. Izuzetak su samo implicitne naredbe koje u izvrsenju ne zauzimaju transverzalu, pa se tada cita sledeca naredba. Zapravo, svaka naredba koja kada se izvrsava oslobadja u nekom ciklusu magistralu, koristi se taj ciklus za citanje kodova sledece naredbe. Ovo ne moze da bude efikasno kao kod Harvard strukture, ali smanjuje broj ciklusa prosecne naredbe. Najveca dobit Fon Nojmanove strukture je sto najoptimalnije trosi flash, tacno onoliko koliko je potrebno i ni bajt vise. Bogatstvo nacina adresiranja (8 kod MC908) cini da se realizacija jedne naredbe MC908 realizuje sa dve ili vise naredbi PIC-a ili AVR-a, sto u krajnjoj liniji cini da su performanse sva ova tri MCU-a priblizno iste, uz napomenu da ce MCU MC908 potrositi, za isti netrivijalni program, najmanje flash-a, ako je to nekome vazno. Meni jeste, uvek optimizujem program na duzinu (potrosnju flash-a) jer brzine danasnjih MSU-ova su dovoljne za sve aplikacije.

Pozdrav.

Zdravo. malku da ja smenam temata.
dali mozi nekoj da mi najdi DUMP ili HEX ne e vazno za Lovato auto gas LCS A/1 V05 ER koj koristo PIC16F874A. Programator imam samo mi fali programa t.e. PIC-ot mi se izbrisa.
fala decki.

Razlike izmedju pojedinih kontrolera su realno minimalne osim ako nismo "ludaci" da merimo koliko ce kojih cilkusa pojedni MCU program brze da izvrsi. Ne znam da li je slucajno ali kod poredjenja kontrolera uvek se uhvatite PIC iz 16F serije i nalazite stvari koje nisu "pametno" uradjene. Nove serije PIC mokrokontrolera osim u perfomansama su dobile i na ceni tako da za bolji i jaci kontroler cak i pin kompatibilan sa starim dobijate za neretko i duplo manje para. Recimo 18F serija ima mogucnost da se pristupa ram-u preko selekcije "strane" ili kao jednom prostoru ako se tako selektuje (doduse onda se nema kontrola celog memoriskog prostora ali u 90% slucajeva je dovoljno). Kod 24F serije su isli i dalje tako da osim jedinstvene ram memorije mozete dodeliti deo programske memorije kojim ce se pristipati kao ram-u. Sto se broja ciklusa pojedinih instrukcija tice kod PIC-a je slicno kao kod AVR-a stim sto ima veliki broj kontrolera sa taktom od 40Mhz (48Mhz usb varijante) i internil PLL-om. Ono sto mi je ponekad smetalo je kontrola interapta, 1 interapt vektor kod 16F serije, 2 interapt vektora kod 18F serije (veci i manji prioritet), sto je kod 24F serije za svaki interapt poseban vektor.

Sto se popularnosti kontrolera tice, mislim da su kod nas Microchip-ovi kontroleri najzastupljeniji prevashodno zbog dobre distribucije i zbog dobre podrska od strane Microchip-a i podrske drugih firmi (Mikroelektronika). Recimo, za koji dan dobijam razvojno okruzenje PIC32bit start kit po ceni od ~50$. Konkurencija bi trebalo da se ugleda na Microchip, kada su objavili da su izbaciji PIC32bit seriju ponudili su i kompajlere, razvojno okruzenje i application notes, tako da je nov proizvod vec spreman za koriscenje, da li je tako i sa konkurencijom?

sander, dobre su ti konstatacije.

Ja jedini, izgleda, na ovom nasem malom podrucju radim sa Motorolom. Sve sto si rekao za PIC, dogadja se i sa Motorolom. Familija MC908 je dobila podfamiliju 9S08 koja ima bolje performanse i dosta je jeftinija. U krajnjoj liniji cena obradjenog kvadratnog milimetra silicijuma je svuda ista, dobijes koliko platis. Razlike proisticu samo iz toga sto Motoroa ima Fon Nojmanovu arhitekturu, a svi ostali Harvard. O tome sam pisao, i oni koji to znaju, znaju i koje razlike iz toga proisticu.

Inace i Motorola ima odlicnu i kvalitetnu podrsku. Cak mi se cini (jer sam upoznao podrsku za neke druge MCU-ove) da je ona najkvalitetnija, ali je skupa.

Sto se tice nadgradnje, postoji MC9S08QE128 (128K flash, 8K RAM 70 I/O, 24 kanala 12bita ADC...) i MCF51QE128 sa kojim je pin to pin kompatibilan i ima sve iste unutrasnje resurse, osim sto je CPU 32 bitni slican kao MC68000. Pa ko voli nek izvoli, ali ne znam zasto bi?

Pozdrav.

Od gore pomenutih proizvođača jedino motorola nema besplatan asembler kompajler? Poređenje frekvencije nije merodavno jer AVR na 16MHz radi brže od PIC-a na 24MHz ili slične motorole, kod brzine je najbitnija koncepcija programa i upotrebljeni kompajler.

Mozes li mi reci na koje kontrolere si mislio pod AVR 16Mhz i PIC 24Mhz?

Sto se tice PIC-a ako ne gresim:

16F serija do 6 Mips
18F serija do 12 Mips
24F serija do 16 Mips
24H serija do 40 Mips
dsPIC30F serija do 30 Mips
dsPIC33F serija do 40 Mips

za PIC32bit ???

Za Koraka:

Koji je epilog onog uredjaja za kotrolu 2-brzinskog motora i kocnice?

Mislio sam na 16F ali sustina je u deljenju osnovne frekvencije, 16F osnovnu deli na 4 a AVR tera direkt (broj ciklusa po komandi je opisao branko_g), tako da se ne moze reci da je PIC na 24MHz brzi od AVR na 16MHz i broj megaherca nije merodavan za odredjivanje realne "snage" kontrolera (to je skontao i Intel).

Na ovoj stranici se mogu naci neki rezultati uporedjivanja nekih mikrokontrolera.
http://www.freertos.org/PC/
Samo sam letimicno bacio pogled, tako da nisam detaljno zagledao kako je vrseno testiranje, ali rezultati pokazuju da su npr. AVR i MSP430 na 8MHz brzi od PIC-a na 20MHz i to podosta.
Davno sam jednom bio izjavio u nekom postu da MSP430 ima za klasu bolju arhitekturu od PIC-a, a to je bilo nakon sto sam poslije iskustava sa PIC-om poceo da radim sa MSP430. To iskustvo je bilo pravo osvjezenje. I danas ostajem pri toj izjavi. Izgleda da od svih "performansi" koje se uzimaju u obzir, PIC ima najbolju reklamu, i to bas najvise kod potrosaca hobista, a profi korisnici (mislim npr. na firme koje razvijaju neke uredjaje) skoro da su imuni na to reklamiranje.
Ja nisam nesto istrazivao koliko se koji mikrokontroleri koriste, ali na osnovu mog licnog iskustva, PIC se najvise koristi kod hobista i za raznorazne kucne radinosti. Ne sjecam se da sam ijednom u mom iskustvu sreo PIC na nekom mjestu gdje je trebalo nesto "ozbiljno" da se obavi. Kad u knjizarama naletim na knjige koje se bave PIC-evima, 95% tih knjiga su nivoa "PIC for Dummies" ili za "neupucene" kako se ta edicija obicno prevodi kod nas), sto bas i nije slucaj sa ostalim proizvodjacima. Mislim da i to nesto govori. Isto tako, stekao sam tokom vremena utisak da i ovoj oblasti vazi "koliko para toliko muzike", odnosno, moze neki razvojni sistem za PIC da kosta i 100E, a recimo slican takav za InfineonXC167 i 300E, ali na kraju ipak ispadne da se znanje koje je steceno sa XC167 moze 3x vise naplatiti od onog sa PIC-om. Dakle, nije samo u pitanju koliko fizickog materijala dobijete za te pare kad kupite neki razvojni sistem vec ima tu i drugih faktora.
Ja bih savjetovao svima koji misle da zive od toga da im prvo mjerilo ne bude to da li se nesto lakse ili teze nabavlja po domacim prodavnicama, vec sta se i u kojoj mjeri trosi i trazi u industriji.
U svakom slucaju, PIC nije los za pocetak, moze brzo i jeftino da se zakoraci u svijet mikrokontrolera, i kad se nauce neke univerzalne osnove koje vaze svuda, bolje je preci na neki drugi mikrokontroler, ne zadrzavajuci se dugo na PIC-u. Bar bih ja tako bio radio da mi je bila ova pamet kad sam pocinjao, ili da je bilo nekog da me posavjetuje.

Sto se tice ovih MIPS-ova (Million Instruction per Second), to bas i nije najbolji pokazatelj koliko je neki procesor "brz". Popularna interpretacija ove skracenice je "Misleading Information to Promote Sales".

Evo primjera iz jedne skripte koju sam jos uvijek sacuavao:

6502, 68000 i /370 treba da premjeste 16 bajtova sa jednog mjesta u memoriji na neko drugo.
Za tu operaciju oni potrose ovoliko vremena:

6502 treba 10us
68000 treba 5 us
/370 treba 1us

Kod za 6502 je:

6502: LDX #\$0f
LOOP LDA source, X
STA dest, X
DEX
BPL LOOP; branch if plus (neg flag not set)

Kod za 68000 je:

68000: MOVE \$source, A0
MOVE \$dest, A1
MOVEQ #\$0f, Do ; move quick (immediate)
LOOP MOVE.B (A0)+, (A1)+ ; move byte and inc addr.
DBF D0, LOOP ; decrement and branche if false

Kod za /370 je:

/370: MVC dest(16), source

Kad se sumiraju instrukcije za ovaj posao:
6502: 1+4*16 = 65 instrukcija
68000: 3+2*16 = 35 instrukcija
/370: samo 1 instrukcija

I na kraju kad se racunaju MIPS-evi:

6502: 65/10us = 6,5 MIPS
68000: 35/5us = 7 MIPS
/370: 1/1us = 1 MIPS

Znaci, /370 koji je 10 puta brze obavio isti posao od 6502 ima 1 MIPS dok 6502 ima 6,5 MIPS. Nema smisla razgovarati o MIPS-evima ako se ne uzima u obzir i arhitektura procesora i njene specificnosti. FLOPS-ovi su nesto bolji ali ni oni ne garantuju mnogo kod poredjenja razlicitih arhitektura. MIPS-ove obicno navode proizvodjaci i prodavci cipova kad treba da ih prodaju, ali za bilo kakvo poredjenje izmedju razlicitih arhitektura jedino su mjerodavni specificni Benchmark-ovi koji pokazuju koliko posla odradi neki cip u odnosu na drugi za neko vreme, a ne koliko on internih instrukcija izvrsi za to vreme.


Pozdrav.

Da ali tu svako "krade" od konkurencije i trudi se da ono sto izbaci novo bude za neko vreme bolje od ostalih. Recimo, microchip je ubacio u 18F seriju PLL tako da ako koristis 10Mhz oscilator preko PLL interno podignes clok za 4 puta i dobijes da imas 1 mips po 1Mhz oscilatora pa tako da ovakav kontroler bude brz kao i AVR na 10 Mhz (teoretski).

Sander,
resen je problem sa DC-DC konvertorom za napajanje REC-123.3 (9V..18V -> 3.3V) uz filtrom na ulazu trafoa. Uzgred MIPS-ovi nista ne znace, treba uzeti netrivijalni program i izmeriti cikluse koje ce MCU potrositi (puta trajanje ciklusa je vreme). RISC ima puno MIPS-ova ali malo nacina adresiranja, pa neke operacije ce izvrsiti sa vise instrukcija, zato MIPS-ovi nisu merodavni.

Pricamo samo o 8-o bitnim MCU-ovima, slazem se da MSP430 ima dobre performanse CPU-a koji je 16-to bitni.

Niko, medjutim ne iznosi koliko bajta trosi njegov MCU za prosecnu instrukciju, i koliko ciklusa ona treje (lako je to preracunati u vreme). Po drugi put iznosim podatke za MCU koji koristim (MC9S08): 1.95 bajta po prosecnoj instrukciji i 3 ciklusa po prosecnoj instrukciji, sto na 20MHz daje 6.7MIPS-a. Ali treba imati u vidu da zbor obilja adresnih modova ovaj MCU moze da se meri sa ostali. Test sam izvrsio (pre par godina) za DES, TDES i MAC algoritam, pisan na C-u, za vise mikrokontrolera, rezultat je bio da je MC9S08 potrosio najmanje flash-a, i da je bio za nijansu najbrzi. Naravno to zavisi i od C kompajlera.

Cesto proizvodjaci daju testove u kojima favorizuju svoj MCU. Biraju primere koji odgovaraju njihovim MCU-ovima, pa zato verujem samo svojim analizama.
Odin D je dao jedan primer u kojem MC68000, iako 32 bitni mikroprocesoe prenosi bajt po bajt, a mogao bi po 4 bajta, pa bi njegovo vreme bilo priblizno 4 puta krace, dakle uporedivo sa 370.

Ali, prica o brzini nije vise aktuelna. Svi danasnji 8-o bitni MSU-ovi zadovoljavaju 99% svih potreba. Najvaznije je koliko trose flash, jer vise flash-a veca cena, a da ne pricam o tome ako program ne moze da stane u raspolozivi flash, tada mu je brzina 0 MIPS-a.

Pozdrav.

Tacno je da 68000 jeste 32-bitni, i da ima 32-bitnu internu magistralu, ali ne poznajem najbolje tu familiju, ali iz iskustva sa ostalim procesorima znam da uvijek (ili gotovo uvijek) postoje neka ogranicenja u pogledu smjestanja word-ova (ili double word-ova) u memoriji, npr. da moraju da pocinju od parne ili neparne adrese i tome slicno. Tako da u opstem slucaju vjerovatno ne bi 16 bajtova moglo da se prenese u 4 puta po 4 bajta, izuzev ako se njihov raspored u memoriji slucajno ne poklapa sa gornjim ogranicenjima, a isto tako i odredisne destinacije. Mada mozda i gresim, kao sto rekoh, ne poznam tu familiju. U svakom slucaju, primjer koji sam naveo sluzi samo da prikaze kako MIPS-ovi u stvari ne govore mnogo o performansama i da mogu cak da prikazu potpuno lazne informacije.

Evo trenutno mi je pri ruci jedan Evaluation Board za XC167-32 familiju, pa cu drmnuti samo copy-paste iz datasheet-a. Konkretan mikrokontroler je SAF-XC167CI-32F40F BB - A.

Dakle, evo ga copy-paste:

1 Summary of Features
• High Performance 16-bit CPU with 5-Stage Pipeline
– 25 ns Instruction Cycle Time at 40 MHz CPU Clock (Single-Cycle Execution)
– 1-Cycle Multiplication (16 × 16 bit), Background Division (32 / 16 bit) in 21 Cycles
– 1-Cycle Multiply-and-Accumulate (MAC) Instructions
– Enhanced Boolean Bit Manipulation Facilities
– Zero-Cycle Jump Execution
– Additional Instructions to Support HLL and Operating Systems
– Register-Based Design with Multiple Variable Register Banks
– Fast Context Switching Support with Two Additional Local Register Banks
– 16 Mbytes Total Linear Address Space for Code and Data
– 1024 bytes On-Chip Special Function Register Area (C166 Family Compatible)
• 16-Priority-Level Interrupt System with 77 Sources, Sample-Rate down to 50 ns
• 8-Channel Interrupt-Driven Single-Cycle Data Transfer Facilities via
Peripheral Event Controller (PEC), 24-Bit Pointers Cover Total Address Space
• Clock Generation via on-chip PLL (factors 1:0.15 … 1:10), or
via Prescaler (factors 1:1 … 60:1)
• On-Chip Memory Modules
– 2 Kbytes On-Chip Dual-Port RAM (DPRAM)
– 4 Kbytes On-Chip Data SRAM (DSRAM)
– 6 Kbytes On-Chip Program/Data SRAM (PSRAM)
– 256 Kbytes On-Chip Program Memory (Flash Memory)
• On-Chip Peripheral Modules
– 16-Channel A/D Converter with Programmable Resolution (10-bit or 8-bit) and
Conversion Time (down to 2.55 μs or 2.15 μs)
– Two 16-Channel General Purpose Capture/Compare Units (32 Input/Output Pins)
– Capture/Compare Unit for flexible PWM Signal Generation (CAPCOM6)
(3/6 Capture/Compare Channels and 1 Compare Channel)
– Multi-Functional General Purpose Timer Unit with 5 Timers
– Two Synchronous/Asynchronous Serial Channels (USARTs)
– Two High-Speed-Synchronous Serial Channels
– On-Chip TwinCAN Interface (Rev. 2.0B active) with 32 Message Objects
(Full CAN/Basic CAN) on Two CAN Nodes, and Gateway Functionality
– IIC Bus Interface (10-bit addressing, 400 kbit/s) with 3 Channels (multiplexed)
– On-Chip Real Time Clock, Driven by Dedicated Oscillator
• Idle, Sleep, and Power Down Modes with Flexible Power Management
• Programmable Watchdog Timer and Oscillator Watchdog
• Up to 12 Mbytes External Address Space for Code and Data
– Programmable External Bus Characteristics for Different Address Ranges
– Multiplexed or Demultiplexed External Address/Data Buses
– Selectable Address Bus Width
– 16-bit or 8-bit Data Bus Width
– Five Programmable Chip-Select Signals
– Hold- and Hold-Acknowledge Bus Arbitration Support
• Up to 103 General Purpose I/O Lines,
partly with Selectable Input Thresholds and Hysteresis
• On-Chip Bootstrap Loader
• Supported by a Large Range of Development Tools like C-Compilers, Macro-
Assembler Packages, Emulators, Evaluation Boards, HLL-Debuggers, Simulators,
Logic Analyzer Disassemblers, Programming Boards
• On-Chip Debug Support via JTAG Interface
• 144-Pin Green TQFP Package, 0.5 mm (19.7 mil) pitch (RoHS compliant)

Znaci, instrukcija se izvrsi za 1 takt, tj. za 25ns (za takt od 40MHz). Medjutim, taj podatak vazi za SKORO sve instrukcije, jer ima i nekih koje traju vise od jednog ciklusa. Za postignutu gustinu koda nisam siguran, ali mislim da je prilicno dobra. Arhitektura je Von Neumanova, RISC tipa, ali ne bas cisti RISC, nesto je izmedju RISC i CISC, ali vise RISC nego CISC. Ovaj procesor ima niz razno-raznih optimizacija, koje ubrzavaju izvrsavanje programa, npr. u slucaju instrukcija skakanja ili u slucaju petlji. Ima dosta nekih modula (MAC = Multiply and Accumulate Unit (32/40-bitna jedinica za DSP Data Processing, drasticno ubrzava mnozenje i dijeljenje, realizuje algoritme za digitalne filtre,...), ADU = Addres Data Unit,...) koje prilicno ubrzavaju stvari. Jedna od interesantnih stvari je i PEC (Peripheral Event Controller) koja automatski odgovara na interrupt-ove od periferija i vrsi npr. prenos podataka izmedju periferija ili periferije i memorije, oslobadjajuci time CPU od tih "trivijalnih" poslova. Npr. ako treba da se sempluju podaci sa ADC, moze da se podesi da svaki put kad ADC obavi konverziju, PEC uzme taj rezultat i smjesti ga negdje u memoriju, i da npr. nakon svakih 1000 takvih transfera pozove procesor i obavjesti ga o tome. Za sve to vreme procesor moze neometano nesto drugo da radi, npr. da vrsi neka izracunavanja sa prethodnih 1000 rezultata konverzije. PEC ima 8 kanala. Interrupt sistem je izvrstan, svaka periferija ima jedan ili vise interrupt vektora i odziv na interrupt je prilicno brz. Interrupt sistem ima 16 nivoa prioriteta i 4 nivoa grupisanja. Spoljni interrupt-i se sempluju i detektuju na svaki takt, tj. na svakih 25ns.
Ukratko, ovaj procesor je iz novijih vremena i nije opterecen nekim kompatibilnostima iz davnijih vremena. Sve je projektovano prema industrijskim zahtjevima bez ikakvih rezervi. Npr. prva generacija (jezgro C166 oko 1996. god) je imala PWM unit sa 4 kanala zato sto automobil ima 4 tocka i trebala su 4 kanala za ABS kocnice. Danasnji cipovi imaju nesto vise kanala :). Danas je aktuelna 4 generacija (XC), a sledece godine dolazi 5 generacija.


_{[Ovu poruku je menjao Odin D. dana 30.12.2007. u 01:18 GMT+1]}

Odin D.,
delim tvoje misljenje, i u pravu si da seve vise ima mikrokontrolera koji imaju osobine DSP-a. Oni su po prvilu vrlo brzi, narociti im je brz interrupt mehanizam. Ima i drugih, a ne samo ovaj koji si opisao. Po pravilu su 32-o bitni, a neki imaju i floating point (16 bita eksponent i 16 bita mantisa).

Ali je interesantnija prica o 8-o bitnim MCU-ovima. Na primer, trenutno radim na projektu koji ima 3 MCU-a (50KB, 30KB i 10KB programskog koda) i 90% varijabli su obicni neoznaceni bajtovi. Pri tome se 70% programa odvija u interrupt-u na 1 ms. Ovim hocu, po drugi put da kazem, da svi savremeni 8-o bitni mikrokontroleri zadovoljavaju sve primene (osim digitalne obrade signala) po brzini. Svaki proces ima minimalno vreme za koje treba da se obrade svi podaci i generise ispravan odziv, nista se ne dobija ako imas brzi MCU kojim ces to brze obradjivati. Ostaje, dakle, samo pitanje koliko ce se potrositi bajtova koda. Kada pisem softver, upravo o tome vodim racuna.

Da bi bila konkretna prica, interesantno bi bilo da napisemo neki kratak test program na C-u i da ga kompajliramo za svoj MCU. Voleo bih da znam koliko su efikasni razliciti MCU-ovi i po brzini i po duzini generisanog koda. Ja sam nesto radio pre dve godine, ali se do sada situacija promenila. Ko nema C moze tekst C programa rucno prevesti u asembler, pa bi videli i koliko je neki C kompajler kvalitetan.

Sada bas razmisljam koje bi to operacije trablao da sadrzi test program. Prvo, mislim da ne bi trebalo da sadrzi nesto sto je vezano za interni hardver, i drugo trebao bi da sadrzi ono sto se najcesce koristi.

Pozdrav.

Nadjoh cene za MC9S08QE128 i MCF51QE128 oba su pin to pin kompatibilna sa istim internim hardverom (32 do 80 I/O zavisno od kucista, 128KB flash 8KB RAM, 24 kanala 12bitni ADC...) osim sto drugi ima 32 bitni CPU slican mikroprocesoru MC68000. Cena prvog na kolicinu od 1 do 25 je 7.17$, a drugog na istu kolicinu 7.55$.

_{[Ovu poruku je menjao korak dana 30.12.2007. u 14:00 GMT+1]}

Nisam imao nameru da velicam ovog ili onog proizvodjaca mikrokontrolera nego sam reagovao na poredjenja AVR naspram PIC zbog toga sto takva "globalna" poredjenja niju realna. Ni mips-i ne prikazuju realno brzinu, recimo isti program ce PIC18F serija izvrsiti brze nego PIC16F serija iako su deklarisani kao isto snazni u mips-ima. Svaki proizvodjac na veliko reklamira svoje adute dok nedostatke vesto precutkuje, zato sam i u neku ruku i veran Microchip-u sto oni uglavnom sve dokumentuju i izbacuju redovno errata dokumente. Recimo sto bi neko bio u prednosti ako koristi Atmela (AVR) za neki posao od mene koji cu taj isti posao uraditi sa PIC-om. Zbog brzine?
Zbog upotrebljenog flash-a? Ako mi je potrebna brzina i kolicina flash-a odabracu kontroler koji to zadovoljava, recimo umesto 16F ili 18F serije koristicu 24F ili 24H seriju sa potrebnom kolicinom memorije. Ako je i to malo koristicu dsPic33F ili PIC32bit. Ono sto je bitno da koristim iste razvojne alate (ICD2+MPLAB) i da svaki odabrani kontroler mogu nabaviti preko Microchip-ovog dilera za ove prostore za vreme ne duze od 15 dana (cesto ih imaju na lageru pa je moguce dobiti ih odmah). Jos nesto, nikada nisam imao slucaj da mi je za neki program zafalilo malo memorije i da jeste uvek imam pin kompatibilan sa vecom memorijom, hvala bogu Microchip ima varijanti i varijanti. A koliko mi je svaki mips i bajt flash-a u mojim projektima bio potreban dovoljno govori podatak da sam u svojim projektima do sada koristio samo 10F, 12F, 16F i 18F serije kontrolera.

Sto se tice poredjenja na linku koji je dao Odin takodje nije realno, za druge ne znam ali PIC18F452 microchip ne preporucuje za nove projekte jer ga izbacuje iz proizvodnje zamena mu je 18F4520 cini mi se. Jos je dato konkretno da AVR radi na 8Mhz koja je i maksimalna brzina na kojoj moze raditi dok je kod PIC-a 20Mhz odnosno polovina od maksimalne. To mi nije realno poredjenje, ako je microchip dao da je potrebno 4 cilkusa oscilatora ja jedan instrukciski ciklus dok je kod AVR-a jedan ciklus oscilatora 1 instrukcijski ciklus a pri tome maksimalne brzine rada su 40Mhz i 8Mhz, prvog vozimo upola manjom brzinom dok drugi punom. Da li bi bilo pravednije da su poredili zamenu za 18F452 (18F4520) na 8Mhz sa ukljucenim internim PLL (4x)? Po dobijenim rezultatima po meni dobijamo da je AVR i PIC pod istim uslovima podjednake "snage".

'Ajde da probam i ovde!
Imam PIC12c508a, imam hex file skinut sa interneta, imam AllPic programator, imam IcProg software za programiranje. Moze li neko da mi objasni sta sve treba da uradim da bih isprogramirao ovaj PIC? Hvala na pomoci!

sander,
dobro si rekao da ta globalna poredjenja nisu realna, ali nisam bas najbolje razumio sta pokusavas da kazes sa ovim megaherzima. U testu stoji da neki uC rade brze na 8MHz nego PIC na 20MHz. To sto taj PIC moze da radi i na 40MHz opet ne znaci nista u njegovu korist. Taj AVR iz te serije moze na max. 8MHz, ali ima i drugih varijanti iz te serije koji rade i na 16MHz. Znaci da su stavili taj drugi, PIC-u ne bi pomoglo ni tih 40MHz. Medjutim, ni to na kraju krajeva ne znaci nista ako se ne stavi u neki kontekst.
Mozda je bolji primjer kada se postmatra ista stvar realizovana na razlicitim platformama. Npr. Apple-ovi racunari na 600MHz su bili istih ili boljih performansi od Intel-ovih na 1,5GHz. Znaci radi se o istoj stvari - kucnom racunaru, i tu ima smisla da se kaze da je jedna arhitektura bolja od druge.
U navedenom testu radi se o istom RTOS-u koji je pokrenut na razlicitim platformama i dao je razlicite rezultate. Znaci, razlike postoje. Tebi i meni moze biti svejedno koji mikrokontroler cemo da upotrebimo za podizanje i spustanje garaznih vrata ili upravljanje ves masinom, ali nekome ko treba da napravi npr. dzepni navigacioni sistem ce to biti vrlo vazno. Tada vidis da postoji velika razlika izmedju 8MHz i 16MHz, jer potrosnja cipa raste sa kvadratom frekvencije (ako se dobro sjecam, a cini mi se da je tako). Tako ce ona realizacija sa 16MHz da potrosi baterije 4 puta brze od one na 8MHz.
MSP430 je i pravljen namjenski za upotrebu u portabilnim uredjajima i optimizovan je na malu potrosnju. U mom kalkulatoru je ARM procesor koji moze da radi na 203MHz ali je fabricki podesen na oko 75MHz zato sto mu baterije na 203MHz ne bi trajale ni 2 dana. On moze da mi na 203MHz izracuna neki integral za 1ms i potrosi bateriju za 2 dana, a moze da ga izracuna i na 75MHz za 3ms i da mu traje baterija 15 dana. Meni te 2ms ne znace nista jer ionako to ne mogu da primjetim, ali ako mi baterije traju 13 dana vise, to primjetim itekako. Ali ako bi na 75MHz racunao integral 5s i iscrtavao display 10s, to bih takodje primjetio. Znaci, negdje je vazno da procesor radi na sto manje megaherca, a da ipak na toj brzini sto vise posla obavi.
U nekom drugom slucaju, gdje potrosnja nije limitirajuci faktor, neke druge performanse ce da presude, ali koje, to zavisi od slucaja do slucaja i ne moze se uopsteno tvrditi sta je bolje ili gore, bez stavljanja u odredjeni kontest.
Dakle, PIC moze za tebe, shodno tvojim potrebama i mjerilima biti najbolji izbor, i ja to ne sporim, niti bih mogao sve i da hocu.
Jedino sto ja mogu, ali i to sa rezervama, da iznesem, je da u poslednje vreme trend ide ka koriscenju "jacih" procesora cak i za vrlo jednostavne aplikacije. Razlog tome je sto cijene cipova idu konstantno na dolje, a cijena programerskog rada na gore. Poslodavcima je isplativije da plate cip 50$, a da jedan programer zavrsi programiranje istog za 2 dana u C++, nego da kupe cip od 5$ a da deset programera zbijaju kod 10 dana u asembleru, jer ce ga tih 9 dana razlike u programiranju kostati mnogo mnogo vise nego 45$ razlike u cipu. A kad dodje do debagovanja onda se tek vidi koliko para i vremena kosta debagovanje u asembleru illi C-u, a koliko u C++ ili Java-i. Isto tako je skuplji programer koji programira u asembleru i koji je u stanju da razumije sta pise u datasheet-u nego onaj ko programira u Java-i i bleji u datasheet ko ja u zakon o poreskim obveznicima.
Kada se radi o velikim serijama, gdje ce uredjaj biti proizveden u npr. 10 hiljada ili 100 000 primjeraka, ili vise, onda se vodi racuna o cijenama cipova, jer na tu kolicinu to moze imati znatnu ulogu. Medjutim, cak i tada, ako uredjaj nije trivijalan, mora se uzeti u obzir ispravljanje gresaka, nadogradnja, nove verzije i tome slicno, a sve je to mnogo lakse raditi ako je cip dovoljno jak tako da postoji dovoljno preostalog slobodnog prostora za te manipulacije. A ako je upotrebljeni cip iskoriscen do maksimuma, onda se ne moze iskoristiti prethodni rad i nadograditi stara verzija, nego se mora opet poceti ispocetka, a to sve opet kosta. Kao primjer za to moze da posluzi informacija od jednog mog poznanika koji radi u jednoj firmi sto pravi liftove. Oni naravno rade liftove raznih velicina, "visina" i ostalih performansi, ali je mikrokontrolerski sistem u osnovi isti za sve liftove, bez obzira da li je to mali spori lift sa jednim vratima u stambenoj zgradi od 4 sprata ili 3 velika brza lifta sa po dvoja vrata u velikim poslovnim zgradama od 15 spratova. Jednostavno im se ne isplati da za svaku zgradu ispocetka projektuju kontrolni sistem sa minimalnim hardverom koji zadovoljava potrebe te zgrade. Jednostavnije, brze i jeftinije im je da ukucaju potrebne parametre u postojeci sistem, nego da svaki put projektuju sve iz pocetka. A posto su im svi sistemi isti, i odrzavanje je kudikamo lakse i jeftinije nego da imaju vise razlicitih platformi.
Dakle, kvalitet arhitekture i svega ostalog sto nama kao projektantima nesto znaci, nije jedini, pa cak nije ni najvazniji faktor kod izbora platforme. U IT industriji kolo vode menadzeri a ne inzinjeri, kako mnogi pogresno misle.
Ako ste imali iskustva sa neispravnom tehnickom robom elektronske prirode koja je pod garancijom, sigurno ste primjetili da ce proizvodjac radije da vam posalje odmah novi uredjaj nego da i pokusa da servisira stari. To je zato sto je obicno sam uredjaj jeftiniji nego rad strucnog lica koji ce da popravlja stari.
Korak je rekao da su mu interesantniji 8-bitni mikrokontroleri, ali ja bih rekao da su upravo 16-bitni, da ne kazem i 32-bitni danas interesantniji. Razlog, kao sto rekoh, sve nize cijene i sve vece mogucnosti. Ako se dobro sjecam, Korak je nekad ranije pitao da li ima smisla da implementira floating point u svoj prevodilac za 8-bitne uC. Za mene, to pitanje bi imalo smisla prije 15-tak godina, ali danas mislim da nema smisla. Svuda ima 16-bitnih uC-ova sa DSP podrskom, po cijenama koje se katkad i ne razlikuju od ostalih 16-bitnih ili 8-bitnih uC-ova. Zasto bi neko trosio vreme na citanje pratece dokumentacije koja ide uz sve to i vodio racuna o posljedicama toga, kad mogu da prodjem bez svega toga za par centi vise? Dobre namjere su jedna, ali zakoni trzista sasvim druga stvar.
Ako se malo zainteresujete da otkrijete sta je najskuplje u racunaru, vidjecete da je to elektro-mehanika, dakle konektori, prekidaci, kablovi i njihovo montiranje i ostale zezancije na koje se malo misli, a da su sami cipovi ustvari najjeftiniji. Znaci, jeftiniji i manji procesor obicno ne znaci da se sve na kraju da ispadne jeftinije, ako jeftiniji procesor podrazumjeva i jos neke elektromehanicke dodatke kojih ne bi bilo da je koriscen jaci procesor.
Ja sam se nekad davno registrovao na Texas Instruments sajtu, pa mi i dan danas redovno stizu mail-ovi koji me obavjestavaju o novim cipovima: mp3 koder/dekoder cija se cijena vec izrazava ne u dolarima, nego u centima, sijaset cipova za obradu slike, wireless itd, da ne nabrajam dalje. Jednostavno, izgleda da je danas najgluplje sto covjek moze uraditi je sjesti za racunar i poceti sve "izmisljati" ispocetka. Dakle, poznavanje i pracenje STANJA TEHNIKE je vrlo vazna stavka, moze vam ustedjeti mnogo vremena, a time i para.
Ja kad pocnem da razmisljam o realizaciji necega, uvijek probam da vidim da li to vec negdje postoji, ako ne onda krecem "odozgo", tj. od nekog objektno orjentisanog jezika visokog nivoa, u mom slucaju C++, i nekog procesora pogodnog za njega. Ako tako ne moze, onda idem na C i skromniji procesor, a asembler samo u "nuznoj samoodbrani" sto bi se reklo (a to se, zaista, odavno nije desilo). Meni licno na prvom mjestu po znacaju je "preostalo vreme nakon rada za namirivanje zivotnih potreba". Na kraju krajeva, ima i ljepsih stvari u zivotu od citanja datasheetova i kuckanja po tastaturi, sto se ne bi reklo, gledajuci koliko sam sada teksta otkucao :). No, vreme je dakle i za druge stvari....
Pozdrav narode, citamo se za par dana. Sve najbolje u novoj 16-bitnoj (2008) godini!
2016-te cemo valjda pricati o 32-bitnim uC-ovima....

Odin D.
Ne kazem da nisi u pravu, mada si naveo jedan pogresan podatak. Potrosnja MCU-a (i svakog digitalnog kola) raste linearno sa frekvencijom, cak su u tehnickoj dokumentaciji dati i podaci da se ona moze sracunati za svaku frekvenciju.

Kada sam forsirao 8-o bitne MCU-ove, mislio sam pre svega na trenutnu situaciju kod nas. Oni su u centru interesovanja najveceg broja ljudi.
Spomenuo si primer liftova, sticajem okolnosti poznajem tu materiju. U softveru za njnih 90% je jednobajtnih varijabli. Od MCU-a za ovu primenu, trazim da ima puno I/O linija, makar dve komunikacione linije i dovoljnu brzinu kako bi se znacajan deo programa mogao obaviti u interrupt-ima. Naravno bitno je da ima dovoljno flash-a. Ali opste je poznato da 8-o bitni MCU trosi manje flash-a nego 16-to bitni ili 32-o bitni. Ovde su izuzetak 8-o bitni MCU-ovi sa Harvard strukturom koji trose vise flash-a nego sto bi trebalo. Ako pratis proizvodjace 8-o bitnih MCU-ova videces da stalno izbacuju nove sa sve bogatijim internim hardverom, sto smanjuje potrebu za spoljnim. Ocito je da proizvodjaci MCU-ova (a oni proizvode kako 8-o bitne, tako i 16-to bitne i 32-o bitne) ne misle da je proslo vreme 8-o bitnih MCU-ova. Znas da na silicijumu najvise prostora trose: RAM, flash, veze pa tek onda ostalo. Sa sadasnjom tehnologijom problem je da se napravi jeftim MCU sa puno flash-a i RAM-a. Ovo je preduslov da 32-o bitni (ali i 16-to bitni) mikrokontroleri razviju svoju punu snagu. DSP su posebna klasa, za njima postoji velika potreba u telekomunikacijama i tu nema drugog resenja osim onih koje si naveo.

16-to bitni MCU koji si naveo ima skroman interni hardver, a upravo to je glavna osobina i razlika MCU-a od mikroprocesora. Pri tome vidim da je on duplo skuplji od najsnaznijih 8-o bitnih MCU-ova.

Kada sam napustao HC11 MCU, dvoumio sam se izmedju MC908 i MC912 (16-to bitni MCU) i zakljucio sam da je isplativije raditi sa MC908 (iako je MC912 potekao od HC11). Presudili su prakticni razlozi, ja znam da je vise bolja, a ako je manje dovoljno onda je to najbolje. Neka neko kaze da li mu je, i u koliko posto slucajeva, bilo nedovoljno 60 KB flash-a.

Jednom sam citao nesto kao tehnicki zahtevi za projektante prvog 16-to bitnog mikroprocesora 8086. Tada se mislilo da je za program vise nego dovoljno 64KB, pa uz 4 segmentna registra rezonovali su ovako: jedan segment za podatke, jedan za kod, jedan za stek i jedan ekstra segment za svaki slucaj. Setite se da je Iskara imala racunar (valjda se zvao Partner, ne zamerite ako sam zaboravio ime) koji je sa Z80 i 128KB memorije pod CPM-om (mislim da se tako zvao taj operativni sistem) vodio kompletno saltersko poslovanje mnogih banaka. Slazem se, tada su racunari bili skupi, dugo je trajao razvoj softvera, ali je i sam hardver bio skup. Imam utisak, da se na racun sve snaznijeg hardvera, pise sve losiji softver. Kada kazem losiji mislim na obavezne bagove i sve manju efikasnost. Glad za profitom cini svoje. Medjutim kada se radi o uredjajima za vojsku i druge potrebe raznih vlada, stvar se menja iz korena, ne zali se vreme za razvoj dobrog softvera. Sudbina nas ostalih je da prihvatimo C kao glavni alat (iako se oslanja na linkere razvijene 50-tih godina proslog veka), da nikad neznamo da li je generisani kod ispravan (jer to nije moguce dokazati za C poznatim naucnim metodama) i da se mucimo sa greskama, narocito onim koje prijavljuje linker. Ja na to kazem: ne hvala.

Inace mislim da je AVR ipak bolji MCU od PIC-a. Da bi bili objektivni probajte, na primer da sortirate niz od 200 bajtova po rastucem nizu (on neka je inicijalno po opadajucem), pa dajte rezultat: broj bajtova programa, broj bajtova zauzetih u RAM-u i broj ciklusa. Neka sortiranje bude po najprostijem bubble sort algoritmu. Ovo ce vise vredeti od 1000 napisanih reci.

Pozdrav.

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.

Aj da i ja bacim neku u vezi upotrebe kontrolera, kompajlera i njihove efikasnost. Kao prvo, svako ko iole ima nameru da se ozbiljno bavi ovom rabotom i ne zna za koji kontroler da se odluči, neka izabere onaj za koji misli da mu se najviše sviđa. Ovo kažem iz više razloga, bilo koji je bolji nego ni jedan, isto kao i bicikl, kada naučite da terate mali lako možete preći na višebrzinski ili onaj sa štanglom (zavisi opet od dužine nogu).
Moja priča počinje 85-86 i zx spektruma, naravno u upotrebi je bio basic a asembler je bio samo za "izabrane". Prve programe sam pisao u bejziku ali ni blizu nisu bili brzi kao tamo neke "fabričke" igrice. U međuvremenu su neki časopisi počeli objavljivati listinge pisane u asm-u. Tada je na scenu stupio "Z80 tools" i moji prvi koraci u pisanju (prekucavanju) polu-razumljivog koda. Nije bilo interneta, pdf-a i raznih tutorijala. I taman kada sam počeo da kontam komande, pređem na Amigu1200 (motorola 68hc020 32bit) i program "max asembler" na nemačkom?! Naravno, dižem ruke od asm. programiranja (izvini Korak) :).
Sad se vi pitate čemu sve ovo gore pišem, a odgovor je jednostavan: nemam pojma!

Da ne bude da sam džabe krečio uradio sam jednostavan test nekih kompajlera, svi su komercijalni osim jednog. U pitanju je AVR familija kontrolera a programi (kompajleri) su: BascomAVR (bejzik), FastAVR (bejzik), CodeVisio (C) i WinAVR (C). Ovaj zadnji je gcc što će reći besplatan. Test program je jednostavan, for (next) petlja 0 do 255, vrednost se šalje na neki port a u okviru petlje sabiranje dve 16-bitne varijable. Rezultati su sledeći:

FastAvr: 390 byte, trajanje jednog ciklusa 5uS
Bascom: 770 byte, --------------------- 9uS
CodeVisin: 940 byte, ------------------- 5.2uS
WinAvr: 533 byte, -------------------- 1.5uS

Test kontroler mega16 na 8MHz.

Asembler nisam uvrstio u konkurenciju jer bi zbog autorove optimizacije i jednostavnosti programa bio "nedodirljiv" u oba pogleda (duzina hex koda i brzine).
Upotreba makroa u asembleru drastično smanjuje vreme pisanja programa i uz to poboljšava čitljivost istog. Svakome preporučujem da proba napisati asm program za omiljeni kontroler, mnogo toga se može naučiti o samom hardveru kontrolera.
Sa druge strane C je veoma rasprostranjen što ne mora značiti da je najbolji (VHS je pobedio BETA sistem bez obzira što je ovaj drugi bolji) a asembler i dalje ostaje privilegija "underground raje".

To nešto sumljam da je moguće, petlja od 0 do 255, vrednost šalje na port i još nešto sabira?
To je nemoguće.
Mora da je kompajler nešto "optimirao"
Jesi li pogledao .asm listing?

Merenje se odnosi samo na jedan prolaz kroz petlju ili promenu na najnizem pinu. Nije bitno vreme kao vreme vec odnos medju kompajlerima.

_str_

Volim konkretne podatke.

Isto sam uradio sa CodeWarrior za MC9S08 i dobio sam:

potroseno 38 bajta flash-a;
vreme jednog prolaza 2.25us

Pozdrav

Interesantno, rekoh ajd da probam sa PIC-om i CCS C kompajlerom, rezlutati isti kao kod Korak-a: 38byta flash-a, 2,25us prolaz za 8Mhz ins. clock, cudno da AVR potrosi najmanje 390 byta. Ali ako se vratimo na rezultate koje je dobio _str_ ispada da je WinAVR najbolje resenje za programiranje AVR familije mikrokontrolera, a da li je tako? Da li se ocena nekog kompajlera moze svesti samo na test neke petlje ili prava snaga dolazi do izrazaja kod optimizovanih biblioteka za rad sa periferijama, spoljnim svetom .... na kraju krajeva i sa pouzdanoscu dobijenog koda (proizvoda kompajliranja). Mozda bi ovo uporedjenje moglo da sugerise da je C bolja varijanta od BASIC-a, posto se program u C-u brze izvrsava. To nije sprecilo niti ce spreciti ljude da programiraju kontrolere u svojim projektima recimo u Bascom-u ili PIC Basic-u niti znaci da ti uredjaji rade losije od slicnih uradjenih u drugim programskim jezicima. Ono sto je najvaznije u svemu ovome je da se poznaje mikrokontroler (hardware) sa kojim se radi kako bi svestan svih vrlina i mana mogao da odradis postavljeni zadatak a orudje kojim to postizes moze ali i ne mora da bude odlucujuce. Takoje, neko je pomenuo da zavisi i od afiniteta koji cemo programsi jezik koristiti, tu se nadovezuje cuvena programerska dilema oko potrebe koriscenja GOTO instrukcije, ima je i u C-u ali se retko ili gotovo nikada ne koristi. Mozda i zavisi, afiniteti mogu doci kasnije, ali mi se cini da je stepenica zvana "asembler" nezaobilazna.

Samo da primetim: AVR ubedljivo najvise trosi bajtove flash-a za iste softverske probleme u odnosu na druge MCU-ove.

Pozdrav.

To je paušalna ocena, zavisi od kompajlera i Start-Up koda koji on proizvede.
Napravio sam sledeći minimalni program:


Procesor je ATmega8, kompajler GCC(WinAVR), optimizacija 1.
Generisani kod je dugačak 102 bajta.
Startup kod postavlja interrupt vektorsku tabelu, inicijalizuje Stack, briše deo memorije...
Uostalom pogledal asm listing:

Gore sam naveo duzinu generisanog hex koda a ne zauzeće flash-a koje je naravno manje.

(jedna ispravka od ranije, nije 68HC020 nego 68EC020)





_{[Ovu poruku je menjao _str_ dana 31.01.2008. u 17:04 GMT+1]}

Za duzinu generisanog koda (ako je C u pitanju) ne racunajte generisani startup kod.

Da AVR generise vise bajtova koda od ostalih 8-bitnih MCU-ova nije pausalna ocena vec dokaziva istina. Samo u jednom slucaju je on najefikasniji MCU: a to je za male programe koji imaju malo varijabli koje mogu sve da stanu u njegove registre. Cak i da se pisa program u asembleru utrosak programske memorije ce biti osetno veci. Primer: uvecaj zaq 1 proizvoljnu memorijsku lokaciju. PIC, 8051 i MC908 to rade jednom naredbom uz utrosak 2 ili 4 bajta najvise. AVR-u treba 4 bajta da unese podatak u registar, 2 bajta da inkrementira vrednost podatka i 4 bajta da je vrati u memorijsku lokaciju, to je ukupno 10 bajtova. Mozemo dokazivati isto i na drugim primerima, i isto ce biti jer direktan pristup proizvoljnoj adresi trosi 4 bajta. No i pored toga mislim da je AVR bolji od PIC-a zbog drugih dobrih osobina.

Pozdrav.

E onda moj kod sa PIC-om i CCS C kompajlerom za nekih 10b kraci.
Ovo sa AVR-om mi se nedopada. Ako je uvek potrebno da se generise 100b sta bi mi ostalo za program za mcu slican 6-pinskom PIC10F200 sa 0,375Kb flasha i 16b RAM-a.

Za Korak-a:

Ako ti nije problem opisi u par reci zasto mislis da je AVR bolji, vidim da si radio i sa PIC-ovima pa bih voleo da cujem tvoje misljenje.

Uopste nije tacno da je AVR-u potrebno 100 bajtova inicjalizacije. Prvih 3-20 bajtova (zavisi od velicine kontrolera) otpada na interapt vektore i jos nekoliko (~10 ) za deklaraciju steka. Za neku mini varijantu sabrati 3 i 10.
Jedina stvar kod AVR-a koja mi malo smeta, a Korak je dobro primetio, jeste nemogucnost direktne manipulacije varijablama smestenih u SRAM. Na srecu to je ublazeno kratkim vremenom izvrsavanja komandi uz nesto povecanu potrosnju flash-a, a na raspologanju stoje 32 registra opste namene i ~130 efikasnih komandi.
A sto se tice glupog primera koji sam gore naveo pisan u asm-u bi mogao biti dug 15 bajtova sa vremenom prolaska kroz petlju 750nS @8MHz.
Imali neko brzi :)

Kada kazem bolji, ne mislim mnogo bolji.

1. AVR moze da stavlja varijable na stek, i stek mu je ogranicen samo velicinom RAM-a. PIC to ne moze.
2. AVR ima dvoadresne naredbe kada manipulise podacima koji su u registrima. To znaci da jednom naredbom moze da nekom registru, naprimer, doda sadrzaj drugog registra.
3. AVR ima kontinualan pristup RAM memoriji bez stranicenja. Doduse, za to trosi 4 bajta koda.
4. Tajmerska jedinica mu je bolja.

AVR ima i neke mane koje nema PIC. A takodje PIC ima neka bolja resenja od AVR-a. Trebalo bi mnogo vise pisati da bi se sve objasnilo.

Medjutim, ako se programira na C-u, kompajler vodi racuna da PIC bez obzira na nedostatke vezane za stek i stranicenje memorije generise kod tako da programer ne oseca ove nedostatke. Rezultata ce biti malo veca potrosnja RAM-a, ali zato manja potrosnja flash-a.

Ipak se sve ocene vrte u okviru ukusa i navika programera.

1. Moze i PIC18F serija sa instrukcijama PUSH i POP. Stek je velik 32 bajta stim da je omogucena implementacija software-skog steka koji je ogranicen velicinom RAM-a.
2. Ako je puko kopiranje sadrzaja postoji instrukcija MOVFF kojom je moguce sadrzaj bilo koje lokacije dodeliti bilo kojoj drugoj lokaciji u RAM-u (12bit adresa, 4Kb RAM) bez selekcije bilo kakve memoriske banke, ako je neka racunska operacija u pitanju onda mora preko W (working) registra.
3. Kod 18F serije RAM-u se pristupa ili preko acces ram-a ili kroz banke (zbog kompatibilnosti sa 16F serijom). E sad, to je u necemu prednost (manje zauzetog flash-a) a negde nije, ako je potrebno raditi sa vecom kolicinom RAM-a.
4. Kod 18Fserije postoje 5 tajmer modula koja mogu raditi samostalno ili uz neku od periferija, sta je to sto ti deluje bolje kod AVR-a?

Ono sto je interesantno je da je microchip poboljsavao mnogo stosta iz predhodnih serija a zadrzavao kompatibilnost, recimo kod koji je pisan za recimo 16F877 prebacen na 18F seriju promenjen izbacivanjem BANKSELECT macroa u asembleru. Inace pojavile su se novije verzije kontrolera PIC18 povecane brzine 16Mips-a.

sander,

Ocenjujem da su nijanse u pitanju:

1. Ali stek od 32 bajta je skoro neupotrebljiv za podatke. Ja uvek rezervisem za stek 100 bajtova. Softverski stek je OK, ali on moze na svakom MCU da se implementira (gde mora) nije automatski i mora da se opsluzuje.

2. Nisam mislio na MOV vec na aritmeticke i logicke operacije.

3. Vazi samo za mov (4 bajta), pa ako mislis da tako mozes da postavis podatak u zeljenu stranicu, potrosices 16 bajta za long podatak (4-o bajtni)

4. Da, ima nekoliko tajmera, razlicitih konfiguracija koji se mogu koristiti u razlicitim modovima. Ja radim za Motorolom i tamo su tajmeri najbolje reseni: MC908 ima po pravilu 8 i vise (zavisno od pakovanja naravno) istih tajmerskih kanala podeljenih u dve tajmerseke jedinice. Svako kanal moze biti input capture, output compare ili PWM sa centralnom modulacijom ili on/off fiksne frekvencije. Slicna je i tajmerska jedinica AVR-a. Ali ovo ne mora da bude presudno u aplikacijama u kojima se ne koristi mnogo tajmera.

To sto microchip stalno poboljsava svoje MCU-ove govori da su predhodni imali neke mane u odnosu na konkurenciju, ko zna, mozda ce posle 18Fxx doci 20Fxx 8-o bitni MCU.

Da se uozbiljim: mane koje ja vidim stvaraju probleme prilikom asemblerskog programiranja (mora da se vodi racuna o mnogim stvarima), ali ako se radi sa C-om onda problemi prividno nestaju, sa njima se bori kompajler.

Inace i AVR ima mana:
1. Vec sam napisao da je skupo proizvoljano direktno pristupanje memoriji: 4 bajta koda;
2. Ne postoji potpuni skup naredbi za uslovno granjanje;
3. Indirektno indeksno adresiranje samo sa ofsetom do 63;
4. Sve registarske naredbe nisu primenjljive na sve registre i t. d.

Pozdrav

Evo i primera pisanog za at90s1200, najmanjeg predstavnika avr familije i mnogo toga moze stati na 1K flash-a. Ko ima proteus moze raspakovati i zip.

_str_

Ja sam napisao: ako su sve varijable AVR-a u njegovim registrima, onda je on sampion medju MCU-ovima. Ti si bas taj primer naveo, takav program ne postoji u praksi. Napisi primer tako da su umesto r7:r8 i r17:r18 varijable u memoriji na proizvoljnim lokacijama, pa da vidimo. Takav je slucaj u realnom programu.

Pozdrav.

Siguran sam da ovakvi programi postoje i da rade u praksi jer primer je pisan za kontroler koji ne poseduje SRAM. A kod ovih drugih stvari stoje drugacije. Za sabiranje varijabli smestenih u sram, potrebno je 14 taktova i tada primer od ranije ima vreme 2.25uS, prilicno ujednaceno?!

_{[Ovu poruku je menjao _str_ dana 03.02.2008. u 23:39 GMT+1]}

Ako hoces da cepidlacis, OK,

Primer ne postoji u praksi jer ko bi vrteo beskonacnu petlju u kojoj se nesto izracunava i ne moze da se koristi van nje (osim interrupt-a ali sumnjam da si na to mislio).

Primer rada sa registrima mora ispred da sadrzi punjenje tih registara, jer po resetu imaju neodredjenu vrednost ili 0 (ne znam), a takodje i vracanje rezultata u memoriju. Slucaj aplikacije kojoj su dovoljna samo 32 bajta nisam nikada radio i, osim prilikom nekih proba, ali to nikada nisu bili pravi programi.

Napisi ti pravi kompletan primer pa da vidimo onda situaciju. Sto ne uzmes algoritam za sortiranje?

Pozdrav.

Malo sam pogledao instrukciski set kod AVR-a i ono sto mi se cini na prvi pogled je da kao sto Korak kaze da ako su varijable u registrima racunske operacije radi brzo, verovatno najbrze od svih 8bit mcu na trzistu ali kao sto Korak rece nije verovatno da u programu imas samo toliko varijabli. Kod 8bitne matematike je razlika mala, dok kod operacija sa 16 ili 32bitnim varijablama zna da bude prilicna. U varijanti sa vise varijabli (zauzimaju vise od 32 byte) koja je najrealnija usporava drasticno u odnosu na mali broj varijabli koje se sve mogu smestiti u registre (kao i povecanje potrosnje flash-a za to). Kod PIC mikrokontrolera je filozovija drugcija, postoji 1 Wreg (working registar) i SFR (namenski registri) i GPR (registri opste namene) sa kojima su moguce racunske operacije sa Wreg. SFR i GPR registri su podeljeni u memoriske banke od po 256byte stim sto kod 18F serije bez preklapanja banaka moguce je pristupati svim SFR registrima i 96 + 256 byte GPR registrima sto je prilicno upotrebljivije za podatke od AVR-ovih 32. U tom slucaju PIC ce brze odraditi racunske operacije od AVR-a kao i kod pristupa RAM-u i varijablama u istoj memoriskoj banci. Prednost AVR-a bi ponovo dosla kod varijabli pozicioniranih u razlicitim bankama sto je u principu malo verovatno. Kod PIC-a instrukcija za mnozenje se izvrsava u jednom taktu dok AVR-a u 2. Kod instrukcija za granjanje PIC je u prednosti sto su dokazali i testovi pomenuti u ovom topiku. Saberi oduzmi opet mu to dodje manje vise na isto, stim ako je potrebna neka veca brzina racunanja i sa vecom kolicinom 16-bitnih ili 32-bitnih varijabli bio bih mazohista da to radim sa 8-bitnom 18F serijom kod cak i jeftinije alternative 24F, 24H, dsPIC30 i dsPIC33. Koja je alternativa za AVR, da li postoje 16-bit i dsp AVR kontroleri? Nemojte samo da mi pomenete 32-bit AVR koji se moze videti samo nacrtan i sa preliminarnim podacima.

A sto se tice toga da su prethodne serije imale manu, naravno da su imale ali to tada bilo sasvim OK. Tada nije bilo kontrolera sa USB ili Ethernet periferijama recimo tako da je kolicina rama zadovoljavala tadasnje potrebe. Microchip je razvio novo jezgro koje je tada bilo konkurentno sa tadasnjim intelom i motorolom, atmel je koristio intelovo jezgro za svoje kontrolere (kao i mnogi drugi) tako da je imao vremena da razvije jezgro prilagodjeno novim zahtevima. Lako je suditi sa danasnjeg stanovista kako su neke stvari bile ogranicene tada. Primera radi pic16f serija ima 35 instrukcija, pic18F 75 dok AVR ima 130. Mislim da je Microchip namerno prestao sa ozbiljnijom nadogradnjom 8-bitnih kontrolera i napravio prelaz ka 16-bitnim a sada i ka 32-bitnim jer se 8-bitni i dale dovoljno dobro drze sa konkurencijom.

_{[Ovu poruku je menjao sander dana 05.02.2008. u 18:11 GMT+1]}

Bice da si stekao krivi dojam.

Mozda sam stekao pogresan utisak, ali nametnuo si ga ti. Dokazujes ono sa cime se i ja slazem, zato pokazi nesto drugo sto je blize realnim situacijama u netrivijalnim programima.

Pozdrav.

Ma ne dokazujem ja nista, iznosim neke tehnicke stvari za pocetnike ili drugacije receno obrađujem temu iz jednog ugla. Nije mi bila namera da omalovazavam druge kontrolere ali ne mogu pisati o njima kada ih ne koristim u praksi. Iznošenje tehničkih podataka nipošto nije cepidlačenje.
Nadam se da sam bar nešto razjasnio.

pozdrav

OK _str_,
nemam ni ja nikakvu zlu nameru.

Do sada sam promenio nekoliko mikrokontrolera u radu (4) , ne probao vec projektovao uredjaje sa njima. Zbog toga me mnogo interesuje kakve rezultate danasnji MCU-ovi daju u resavanju softverskih zadataka razlicitih klasa. Ocekivao sam da das neki netrivijalni primer. Sigurno si napravio neki program od par kilobajta koda, pa bih voleo da znam koliko je linija izvornog koda napisano, koliko je bajta izvrsnog koda generisano, i kojom se brzinom to izvrsavalo. Jednostavno ta saznanja volim da imam, ne da bih dokazivao kako sam ja najpametniji jer radim sa ti i tim MCU-om, vec pratim sve sto se dogadja na tom polju i rado cu preci na drugi MCU kada naidjem na osetno bolji. Kada su se pojavili MCU-ovi sa flash-om kolebao sam se izmedju MC908 i AVR-a, i za malo je prevagnuo prvi.

Nadam se da si shvatio moje motive.

Pozdrav.

Potrbna mi je pomoc oko jednog zadatka.

Realizovati sistem za kašnjenje uključenja mašine.
Mašina po ukljucenju ne radi 10 sec a zatim se uključuje trajno dok se ne pritisne taster Stop.
Pritiskom na taster Stop u toku ukljucenja masine ciklus se prekida i mašina se uopšte ne uključuje.

PORTB.0 Pogon mašine
PORTA.0 Start mašine
PORTA.1 Stop mašine


Zadatka treba da uradim u asembleru, tj. u MPLAB IDE.

Svaka pomoc je dobrodosla.

Program je relativno jednostavan. Evo ga za PIC16F84 i sa eksternim pull-up otpornicima.

Inace, zgodnije bi bilo korišćenje PORTB registra za tastere zbog integrisanih pull-up otpornika .

Hardver je sledeći

; XT oscilastor od 4MHz
; RA0 - ulaz Taster STOP sa eksternim pull-up otpornikom od 10k prema masi
; RA1 - ulaz Taster START sa eksternim pull-up otpornikom od 10k prema masi
; RA2 - n.c.
; RA3 - n.c.
; RA4 - n.c.

; RB0 - izlaz pogon
; RB1 - n.c.
; RB2 - n.c.
; RB3 - n.c.
; RB4 - n.c.
; RB5 - n.c.
; RB6 - n.c.
; RB7 - n.c.

Ovde bi trebalo koristiti goto umesto call, jer ce ovako puci stek. U datom primeru nista nece smetati call, jer ionako kad program dodje do te tacke vise nista ne treba da radi, ali treba napomenuti. Dakle

Hvala za resenje zadatka.

Imao sam neku ideju za resavanje, a posto sam pocetnik i nisam bas naucio komande, nisam umeo da ispisem ceo program.

Hvala jos jednom.

Molim Vas treba sto pre da uradim jedan zadatak u asembleru koji se realizuje pomocu mikrokontrolera PIC16F84 a nisam bas nesto radio do sada u asembleru. Molim vas ako neko zna neka pomaze. Sto pre. Hvala unapred.

Zadatak glasi:


Pritiskom na tastere pomerati upaljenu Led diodu na izlazu. U zavisnosti od toga koji se taster pritisne pali se prva leva ili prva desna Led dioda do diode koja je upaljena. Dioda koja je bila upaljena gasi se. Pomeranje prve Led diode (PORTB,0) udesno pali poslednju Led diodu (PORTB,7). Pomeranje poslednje Led diode (PORTB,7) udesno pali prvu Led diodu (PORTB,0).. Zadatak realizovati pomoću mikrokontrolera PIC16F84 na asembleru.
PORTB Prikaz
PORTA.0 Pomeranje ulevo
PORTA.1 Pomeranje udesno



Ako neko moze da pomogne neka me kontaktira na mail [email protected]
ili neka napise ovde

potrebna mi je pomic oko resavanja zadatka u asembleru koji se realizuje pomocu mikrokontrolera PIC16F84


Zadatka treba da uradim u asembleru, tj. u MPLAB IDE.

Svaka pomoc je dobrodosla.


zadatak glasi ovako

Realizovati sistem za uključenje i vremenski ograničen rad neke mašine. Mašina po ukljucenju radi 10 sec a zatim se isključuje. Pritiskom na taster stop ciklus se u svakom trenutku može prekinuti.

PORTB.0 Pogon mašine
PORTA.0 Start mašine
PORTA.1 Stop mašine


hvala unapred odgovore mozete slati na mail : [email protected]

Ne znam da programiram u asembleru ali u programu Pic Basic-u ovo zvuci veomaaaa lagano za uraditi.. I kakva je ovo navala za resevanja vasih seminarskih radova, morate se i vi malo potruditi. Pokusajte napisati program, pa ako nece da radi postavite ga ovde, pa ce vam mozda neko resiti i pomoci Vam. Ne ocekujte da vam neko radi seminarske, a vase je samo Copy, Paste, a posebno ne u asembleru...
pozdrav

Nije ni u asembleru neki problem. Ovo mogu biti osnovni algoritmi, a dalje krenite sami. Internet je pun raznih primera i uputstava.

@sasha_kg

1. Podesite U/I pinove (hardver) i inicijalno logicko stanje RB0 pina (pogon).

2. Cekajte u praznoj petlji dok se ne pritisne START taster na RA0 pinu.

3. Po pritisku START tastera ubacite pauzu od 10S. Da se ne bi bespotrebno mucili proracunima takta mozete koristiti program PicLoops sa mog sajta ili http://www.piclist.com/cgi-bin/delay.exe link.

4. Cekajte u praznoj petlji dok se ne pritisne STOP taster na RA1 pinu.

5. Na kraju programa postavite mrtvu petlju.

U programu nema potrebe za debouncingom tastera, jer se ionako samo jednom testiraju.


Uostalom, nije li malo iznad vec odgovoreno na isti takav zadatak?

@TRAJKO41

Budite precizniji prilikom opisa. Pretpostavljam da bi recenica "Pomeranje prve Led diode (PORTB,0) udesno pali poslednju Led diodu (PORTB,7)." trebalo da glasi "Pomeranje prve Led diode (PORTB,0) ulevo pali poslednju Led diodu (PORTB,7).".
U tom slucaju algoritam bi trebao izgledati ovako:

1. Inicijalizacija U/I pinova (hardver) i inicijalno ukljucenje jedne LED na PORTB.

2. Test tastera sa debouncingom. U zavisnosti od tastera LEVO i DESNO skociti na tacke 4 ili 6

3. Povratak na tacku 2

4. Pritisnut taster LEVO. Proveriti da li je LED dosla do bita 0 (npr. sa btfss PORTB,0) i ako jeste postaviti na PORTB stanje b'00000001'. Ako nije, bcf STATUS,C pa RLF PORTB,F

5. Povratak na tacku 2

6. Pritisnut taster DESNO. Proveriti da li je LED dosla do bita 7 (npr. sa btfss PORTB,7) i ako jeste postaviti na PORTB stanje b'10000000'. Ako nije, bcf STATUS,C pa RRF PORTB,F

7. Povratak na tacku 2.


U zavisnosti od strucnosti profesorke mozete se provuci i bez debouncinga.
Takodje je preporucljivo da se rlf i rrf instrukcije umesto nad PORTB izvrsavaju nad njegovim shaddow registrom, ali (opet u zavisnosti od strucnosti profesorke) mozda nece biti potrebno.

Vise o debouncingu i shaddow registrima imate na http://www.ganssle.com/debouncing.pdf i http://www.piclist.com/tecHREF/readmodwrite.htm .

I nemojte molim Vas postovati isto pitanje na razlicitim mestima unutar istog foruma.

Mozda ce nekome biti interesantno:

Stojan Trifunovic je naveo link: http://www.piclist.com/tecHREF/readmodwrite.htm koji opisuje RWM probleme kod PIC-a kada se RWM tip naredbe primeni na port koji je konfigurisan kao output, a ciji su pinovi (ili pin) kapacitivno optereceni. Ja sam pogledao hardver I/O pinova svih danas popularnih 8-o bitnih mikrokontrolera i video sam sledece:

Kada je port konfigurisan kao output, a vi primenite naredbu citanja porta, bice procitana stanja na pinovima porta. Dakle, iako je port konfigurisan kao output, vi mozete da citate stanja na njegovim pinovima, ali se pretpostavlja da su to stanja koja su upisana u registar output podataka porta. Ovo je OK, ali ako neki pin ima kapacitivno opterecenje, onda ce upisom jedinice u taj pin, napon na pinu sporo rasti, tako da u trenutku citanja mozete dobiti log. 0 iako je pin setovan na log. 1. U nekim slucajevima ovo moze da izazove nepredvidljiv rad vaseg programa. Ovakvu konfiguraciju I/O pinova imaju PIC, AVR i 8051 bazirani MCU-ovi.

Naravno, zainteresovao sam se da isto to vidim i kod motorolinih MCU-ova. Konfiguracija I/O pinova je ovde malo drugacija. Kada se pin (ili port) konfigurise kao output, onda se prekida veza linije za citanje stanja na pinu od pina, a povezuje se direktno na izlaz registra output podataka. Treba reci da kod svih MCU-ova izmedju ovog registra i pina postoje tranzistori. Dakle, kada je pin konfigurisan kao output, a primeni se citanje porta, bice procitan registar output podataka, a ne stanje na pinovima. Zato opisani problem ne postoji kod Motorole.

Uvek je interesantni zaviriti u neki detalj anatomije MCU-a.

Pozdrav svima koji prate ovu temu.

Da, tako je to, ali samo za starije PIC serije. Kod PIC18 serija (i narednih) ovog problema nema.
Resenje za starije serije je jednostavno. Sve operacije koje bi se normalno izvrsavale nad portovima, izvrsavaju se nad njihovim shaddow registrima, a onda se njihovo stanje samo kopira u portove.

Dobru praksu predstavljaju redni otpornici na U/I pinovima (ne samo zbog ovog problema), ali najbolji su ipak shaddow registri.

Interesantno je da je poznavanjem i koriscenjem RMW problema moguce koristiti odredjene hardverske trikove.
Na primer ukoliko se kondenzator direktno poveze na U/I pin (ili preko rednog otpornika za vece kapacitivnosti) prema masi, pa se zatim pin konfigurise kao izlazni sa logickom 0, kondrenzator se isprazni do 0V. Onda se na pin dovede logicka 1, i vreme koje protekne do ocitavanja logicke 1 na njemu direktno zavisi od RC konstanre. Tako se moze lako napraviti jednostavan (ali ne previse precizan) merac kapacitivnosti ili otpornosti.
To je u nekom semama (npr. na www.romanblack.com ) primenjeno za detekciju pritisnutosti vise tastera samo jednim pinom.

Pozdrav ljudi!

Evo samo da jevim i da pitam u vezi zadatka koji sam postavio, a koji je uradjen, ali nije bio do kraja (nije bilo sve definisano u tekstu zadatka, pa sam ja neksto dodao).

Tekst zadatka:
Realizovati sistem za kašnjenje ukljucenja mašine. Mašina po ukljucenju ne radi 10 sec, a zatim se ukljucuje trajno dok se ne pritisne taster Stop. Pritiskom na taster Stop u toku ukljucenja masine (ili u bilo kom trenutku), ciklus se prekida i mašina se uopšte ne ukljucuje.

PORTB.0 Pogon mašine
PORTA.0 Stop mašine (bilo je RA1)
PORTA.1 Start mašine (bilo je RA0)



Asisitent mi je rekao da stavim i u pauzu:
movlw D'173'
movwf BrojacA
i
movlw D'237'
movwf BrojacB
da kad prvi BROJACA dodje do 0, u sledecem prolazu bice 0-1 a to ce biti 255 i opet ce poceti ispocetka.
Bez toga, pauza bi bila mnogo duza od 10 sekundi. (Ovako je pauza oko 10,43 sec. Merio sam na faxu)
Isto vazi i za BROJACB.

Meni nije jasno sta je: D'173', D'237', D'51'.
Jel to decimalan broj?

Nacrtao sam algoritam za ovaj program, ali ne znam da li je tacan.
Skenirao sam, ali ne znam da kako da postavim sliku na sajtu.
Ajde neka mi neko kaze kako da postavim sliku na sajtu.
Unapred hvala.

Hvala milovan_regodic.
Uploadovao sam sliku tako da ako neko moze da pogleda i da mi kaze da li sam ispravno uradio algoritam?
pozz

_{[Ovu poruku je menjao stefic_kg dana 27.06.2008. u 13:58 GMT+1]}

@stefic_kg, dole gde imas izmenu za post koji si posto-ovao imas "upload uz poruku" tu klikni pronadji fajl na HD-u i postuj.
P.S drugi put pise, pobrkao forum :)

Stefic-u : Da li su tasteri vezani u Pull-up ili Pull-down kombinaciji. Pull-up ti je kombinacija u kojoj je otpornik jednim krajem vezan za +Vcc a Pull-down gde je jedan kraj otpornika vezan za minus pol ili GND !

Tek kada ovo kažeš ima smisla komentarisati kod koji si postavio mada i ovako bi se mogao dati komentar. Što se mene tiče ja ću sačekati da nam kažeš o kojoj vezi tastera se radi !

Pozdrav !

Nisam siguran, ali mislim da je pull-up, mogu da proverim.
Neznam zasto ti to treba da bi video da li je algoritam dobar?

Inace zadatak radi dobro, samo me interesuje da li sam dobro uradio algoritam.

Pozz

Steficu iako zadatak radi ( tako si rekao ) on nije dovoljno dobro napisan a evo i zašto. Kada se piše kod u bilo kom programu teži se tome da taj kod bude napisan u što manje linija jer će ostati više mesta za ostatak koda ako ga ima a i sam program će se brže izvršavati. U kompleksnim programima to jeste problem ako se programira u asembleru i verovatno uvek postoji nešto kraće mada sve zavisi i od logike kojim si krenuo u pisanje koda. Konkretno u tvom zadatku je evidentno napisano previše koda pa mi malo čudno da to asistent toleriše a evo o čemu se radi :

Napisao si :



Komentar na prethodni kod : Kada imaš ovakvu situaciju da na oba porta treba da postaviš stanja koja odgovaraju logičkoj nuli onda nema svrhe pisati 4 linije koda. Kada si na početku ovog koda napisao da je :
movlw 0x00 a to znači da u W - Working ili radni registar ubacuješ sve nule. Kada si to jednom uradio onda nema potrebe da pišeš i drugi put istu naredbu jer je u W registru još uvek stanje koje si "stavio" na početku. Poenta, je da će sadržaj W registra biti promenjen tek ako je u njega upisano nešto drugo a sve dotle zadržava stanje koje si postavio.

Kraći kod bi mogao da bude kao :



A još kraći kod koji bi obavljao istu funkciju bio bi ispisan u samo dve linije a to je :




Postoji još kraći kod s obzirom na uslove zadatka. Rečeno je da je na PORTB.0 vezan motor a na PORTA su tasteri a pošto je to tako onda nema svrhe postavljati PORTA na nulu jer je motor vezan na PORTB pa samo njega i treba uzeti u obzir pa onda deo koda od 4 linije može da se zameni sa :



ili ako baš ciljaš na PORTB.0 jer je konkretno na taj izlaz vezan motor može da se napiše :




Takođe deo koda koji si napisao :




može kraće da se napiše kao :




i naravno deo koda na kraju koji si napisao kao :



može kraće da se napiše kao za jednu programsku liniju kao :



Nadam se da mi ne zameriš ovim konstatacijama, ali vas moraju učiti da napišete funkcionalan i što kraći kod. Opet ponavljam ovde se to jako dobro vidi ali u komplikovanijim zadacima može da se nađe koja linija više nego što bi trebalo a da to možda ostane neprimećeno.

Pitao si :


Odgovor je : Da to je decimalan broj odsnosno decimalni brojevi !


Da li ti je algoritam dobar ?

Pa nisam baš siguran na čemu se kod vas insistira, tako da ja algoritam ne bih komentarisao ako mi ne zameraš !



_{[Ovu poruku je menjao Slavenko dana 03.07.2008. u 12:48 GMT+1]}

Komentari sa ovim krace napisanim kodom su potpuno ok.
Trenutno mi nije potrebno, ali u svakom slucaju hvala sto si mi skrenuo paznju na to, da u narednim programima, program bude optimalnije napisan.
pozz

Mislim da algoritam nevalja. Koristiš blok za ulaz i izlaz da obeležiš labele. Svaki put inicijalizuješ portove. Samo kada je stop DA moguće je upaliti mašinu. Kad je stop NE nakon pauze ideš na gašenje. Na dnu, nakon UKLJUČI_MAŠINU račvaš tok u multitasking !?

Evo mog malog primera za rešenje ovog zadatka s tim što sam se potrudio da udesim tačno 10 sekundi. Nisam isprobao pošto nemam pri ruci neki 16F.






Pozdrav,
Bojan

Bojane,

"Koristiš blok za ulaz i izlaz da obeležiš labele." - Dobro ovo vidm da ne valja.

"Svaki put inicijalizuješ portove." ---> ??? ne razumem sta nije u redu osim da moze krace da si napise kao sto rece Slavenko)

"Samo kada je stop DA moguće je upaliti mašinu." (kada je bit 0=0 nastavi sa ispitivanjem START prekiraca)
"Kad je stop NE nakon pauze ideš na gašenje." ( zaso nakon pauze, kad on odmah vraca na Iskljucenje programa)



Na dnu, nakon UKLJUČI_MAŠINU račvaš tok u multitasking !? ---> ??? ne razumem, mozes malo da pojasnis.

Evo nešto opširnijeg objašnjenja.



Potrebno je izdvojiti inicijalizaciju, deo koda gde se pinovi portova postavljaju kao ulazni ili izlazni, i to izvršiti samo na početku. Ovo kako radi nije potpuno pogrešno samo je po malo suvišno. U stvari, program lepo ima labelu Start nakon inicijalizacije ali ti za start ideš na početak algoritma. Trebalo bi da se one dve povratne putanje ulivaju nakon bloka inicijalizacije. I šta znači kad kažeš "rezerviše mesto u memoriji". Da li shvataš da bi to značilo da svakim prolazom rezervisanje bez oslobađanja na kraju pojede svu memoriju. Znam da nisi tako mislio ali moglo bi se tako protumačiti. Čak šta više deklaracije i definicije nemaju mesto u algoritmu. Algoritam bi trebao biti apstrakcija koju realizuje program bez suvišnih detalja kao recimo čitava gungula oko petlje za pauzu. Ona bi u algoritmu trebala da se apstrakuje sa par blokova od kojih jedan opisuje kako se meri period(umanjivanjem tri osmobitna brojača) i drugim koji pokazuje reakciju na izuzetak kad se pojavi slučaj pritisnutog tastera.




Pogledaj crtež. Imaš testiranje za stop na dva mesta. Prva rečenica je za gornji druga za donji slučaj.
Za ova dva mislim da si samo zamenio oznake za DA i NE grane na nacrtanom algoritmu. U stvari sad sam ponovo gledao sliku i video kontradikciju između "testira STOP" i jednakosti ispod.
Tok NE zapravo znači "DA STOP" i istovremeno "NE, RA0 nije jednako 0". Znači potrebno je preformulisati izjave iznad i ispod crtice u bloku da budu u saglasnosti, tj. da kad se prati tok recimo NE to bude kada je NE odgovor na oba pitanja. Ili ostaviti samo RA0=0 a obrisati "testira STOP".





na dnu slike ti se tok račva i jedan kraj završava u KRAJ a drugi se vraća gore. Našalio sam se i to nazvao multitaskingom. Ovaj algoritam jednostavno ne bi trebao da ima specijalnu labelu KRAJ.




Nadam se da sam bar malo uspeo da dočaram čemu se teži u teoriji. U praksi se međutim sreće sve i svašta, algoritmi sa ezoteričnom notacijom, bezglavi i bezrepi kad se na brzinu rešava problem. Čak i neartikulisane žvrljotine sa nekoliko identifikatora i brojeva u nepoznatom zapisu koje i sam autor kad kasnije pogleda nema pojma šta su ali su jednom odradile posao. Samo dobar algoritam ima trajnu vrednost jer može da uštedi vreme potrebno za razumevanje. Loši algoritmi čak mogu da unesu dodatnu zabunu i prouzrokuju čistu štetu. Zato uvek treba težiti dobroj praksi a prezirati svaku aljkavost.



Pozdrav,
Bojan

OK, sad mi je jasnije.

Evo ispravio sam prvi algoritam.

Nisam menjao ono kod taestiranja STOP, nego sam pored dodao objasnjenje za NE (STOP je pritisnut) i DA (STOP nije pritisnut).
Malo kontradiktorno ali mislim da je sad malo jasnije.

Labela KRAJ neka bude tu. Nista ne smeta.

pozz

Da li moze neko da mi pomogne u resavanju zadatka.

Tekst zadatka glasi:



Napisati algoritam i program:
Pritiskom na tastere pomerati upaljenu Led diodu na izlazu. U zavisnosti od toga koji se taster pritisne pali se prva leva ili prva desna Led dioda do diode koja je upaljena. Dioda koja je bila upaljena gasi se. Pomeranje prve Led diode (PORTB,0) udesno pali poslednju Led diodu (PORTB,7). Pomeranje poslednje Led diode (PORTB,7) udesno pali prvu Led diodu (PORTB,0).. Zadatak realizovati pomoću mikrokontrolera PIC16F84 na asembleru.
PORTB Prikaz
PORTA.0 Pomeranje ulevo
PORTA.1 Pomeranje udesno

ja sam resavao i uradio sam nesto ali asistent kaze da to jos uvek nije to i da treba jos da se doradi

evo ii kod koji imam


#include p16f84.inc ;inicijalizacija procesora koji ce se koristiti
processor 16f84

; inicijalizacija
LED equ 0x0C ; Definisanje promenjive u kojoj se čuva podatak koja LED je uključena
org 5

bsf STATUS,RP0
movlw .3 ; Pinovi RA0 i RA1 su definisani kao ulazi a
movwf TRISA ; a ostali su konfigurisani kao izlazni
clrf TRISB ; Svi pinovi PORTB su konfigurisani kao izlazni

bcf STATUS,RP0

movlw B'00001000' ;Jedna dioda mora da bude uključena na početku programa da bi se
; vršilo pomeranje ja sam izabrao da to bude LED koja je priključena na RB3

movwf LED ; Dakle po uključenju programa dija LED na pinu RB3
movf LED,W
movwf PORTB

start
btfsc PORTA,0 ; Da li je uključen taster za pomeranje u LEVO ?
goto Levo ; Jeste, skoči na Labelu za pomeranje u levo !
btfss PORTA,1 ; Nije, a da li je uključen taster za pomeranje u DESNO ?

goto start ;Ponovno na testiranje dok nešto ne bude stisnuto od ova dva tastera !

rrf LED,f ; Uključen RA1 i pomera se trenutni sadržaj LED varijable u desno pamti novo stanje opet u

movf LED,W
movwf PORTB ; LED varijabli i sve to prikazuje na izlazu PORTB u smislu kretanja uključene diode u desno

goto start ; Posle pomeranja idi na početak da vidiš koji taster će sada biti aktiviran !

Levo
rlf LED,f ; Pomera sadržaj varijable LED u levo za jedno mesto pri tome gaseći prethodno stanje i
movf LED,W
movwf PORTB ; prikazuje njen sadržaj na PORTB

goto start ; Vraća se na početak programa za novo testiranje tastera !
; konfiguraciona rec
__config B'11111111110001' ; nema zastite koda, powerup dozvoljeno,
; wd iskljucen, xt oscilator


end ; kraj programa



treba mi i algoritam a nemam pjma kako se radi. Platicu ako treba samo ako program radi i ako je tacan algoritam.Hvala

Mislim da nema potrebe da u promenljivoj cuvas polozaj LED koja je upaljena. Ako pri inicijalizaciji upalis diodu (PORTB=b'0001000') i kada ocitavanjem tastera ustanovis koji je taster pritisnut odradis samo :

za levo

RLF portb,f
BTFSC status,C
RLF portb,f

za desno

RRF portb,f
BTFSC status,C
RRF portb,f

Da ne bi ova tema prerasla u resavanje zadataka ajde da je vratimo na pravi kolosek.

Malo sam uporodjivao instrukciski set AVR-a pa evo da iznesem neka zapazanja. Koliko mi se svidja ideja sa 32 radna registra toliko mi se ne svidja brzina rada sa SRAM-om i sa FLASH-om. Ako sam dobro shvatio, RAM-u se moze pristupiti direktno instrukcijama:

LDS Rd,adresa i STS adresa,Rr (trajanje 2 ckl.) bez obzira na velicinu implementiranog RAM-a.

e sad, dosta napadan koncept PIC mikrokontrolera RAM izdeljen u bankama (18F serija, 16F nije uporediva sa AVR-om) bi RAM-u pristupio:

movlb banka 1 cik.
movf adresa,w 1 cik.

znaci u najgorem slucaju pristup RAM-u je podjednako brz stim sto PIC to moze i krace ukoliko je dovoljno 384b RAM-a preko opcije access bank.

Drugo, za indirektni pristup RAM-u kod AVR-a su zaduzeni registarski parovi (X, Y i Z odnosno registri koji ih grade). To je OK ali mi se ne dopada sto indirektni pristup RAM-u traje 2 cik. Naprimer:

LDI Rd,K 1 cik.
LDI Rd+1,K 1 cik.
LD Rd,X 2 cik.

ukupno 4 cik.

Kod PIC-a za indirektno adresiranje se koriste registri FSR0, FSR1 i FSR2. Na primer:

LFSR FSR0,adresa 2 cik.
MOVF indf0,W 1 cik.

ukupno 3 cik.

To ne bi bilo nesto da se pristupa 1 mem.lokaciji sta ako je potrebno procitati neki string iz RAM-a i recimo ispisati na LCD. Za string od 16 karaktera 16 cik. Kad smo vec kod LCD-a za ispis 16 karaktera imacemo i dodatnih 32 cik. zbog sporije manipulaciju sa bitovima I/O registra dvociklusnog trajanja instrukcija SBI i CBI za setovanje ili resetovanje bitova.

SBI P,b 2 cik.

Kod PIC-a:

BSF PORTx,b 1 cik.

Nisam siguran kako bi setovao ili restovao bit u nekoj varijabli ali pretpostavljam ovako, neka me neko ispravi ako gresim:

LDS Rd,adresa 2 cik.
SBR Rd,bitovi 1 clk.
STS adresa,Rr 2 cik.

Kod PIC-a:

MOVLB banka 1 cik.
BSF adresa,b 1 cik.

ili samo:

BSF adresa,b,a 1 cik (koristeci access bank)


Sto se tice Flash-a situacija je slicna kao kod RAM-a. Primer:

LPM Rd,Z 3 cik. (adresa je u Z, 16-bitna, 64Kb)

Kod PIC-a:

TBLRD * 2 cik. (adresa je u registrima TABLAT ( 5 bit) i TBLPRT (16 bit), ukupno 21 bit, 2Mb).











_{[Ovu poruku je menjao sander dana 12.09.2008. u 23:43 GMT+1]}

@sander,

moja osnovna zamerka AVR-u nije brzina, vec potrosnja flash-a.

Inace, AVR je sampion u brzini ako je dovoljno 32 bajta za sve varijable programa.

Indirektno adresiranje moze biti sa ofsetom. Ako imas neki niz, od bajtova, sa adresom prvog elementa niza na adresi Niz, i zelis 20 element, onda ti treba:

ldi Ry, Niz.0; // visi bajt adrese niza, Ry i Ry+1 je Ry dvobajtni registar
ldi Ry+1, Niz.1; // nizi bajt vadrese niza
ldd Rn,Y+20; // gde je ofset = 20; 0 <= ofset <= 63

za ovo je potrebno 3 ciklusa.

Ako se kopiraju dva niza iste duzine:

ldi Ry, Niz1.0;
ldi Ry+1,Niz1.1;
ldi Rz, Niz2.0;
ldi Rz+1,Niz2.1;
ldi R16,SizeOf(Niz1); //trosi 10 bajta programa

Ponovo: //petlja trosi 7 ciklusa i 8 bajta programa
ld R17,Rz+;
st Y+,R17;
dec R16
brne Ponovo;

Ili ako oba niza pocinju na adresama manjim od 64:

ldi Ry,SizeOf(Niz1);
eor Ry+1,Ry+1; //Ry+1 je nula; trosi 4 bajta programa

Ponovo: //petlja trosi 7 ciklusa i 8 bajta programa
ldd R17,Y+Niz2-1;
std Y+Niz1-1,R17;
dec R17;
brne Ponovo;

Takodje je moguce prebaciti stek pointer u neki od indeksnih registara i tako praviti dinamicke lokalne varijable na steku. Ovo je vrlo zgodna stvar.

No, ostaje moja primedba da AVR trosi mnog flash-a, i pri tome ima mali ofset kod indirektnog indeksnog adresiranja.

Primera radi evo kako izgleda kopiranje nizova kod MC9S08.
Izvorni kod


i prevod:


Ovaj kod trosi 9 bajta memorije, a petlja traje 9 ciklusa. Ako su nizovi proizvoljno u memoriji, onda ce duzina koda biti 11 bajtova a trajanje petlje 11 ciklusa. Ovaj kod vazi za bilo gde smestene nizove (cak jedan moze biti i u flash-u a drugi bilo gde u RAM-u). Jedino ogranicenje je da je duzina niza manja od 257 bajtova, inace bi kod morao biti malo modifikovan. Obzirom na strukturu MC9S08 i takt CPU-a koji iznosu 50ns, trajanje petlje je 450ns odnosno 550ns.

Ako uzmemo u obzir da je malo verovatno da oba niza kod AVR-a pocnu na adresama manjim od 63, onda je prvi primer AVR-a uporediv sa primerom za MC9S08. Proizilazi:

AVR: 18 bajtova i trajanje petlje 7 ciklusa (700ns)
MC9S08: 11 bajtova i trajanje petlje 11 ciklusa (550ns)

U odnosu na AVR, sa MC9S08 se stedi 38.9% u duzini koda i 21.4% u trajanju petlje.

Ovi odnosi nisu presudni, oni to postaju kada je faktor odnosa 2:1 ili gori. Postoje mesta u programu gde AVR postize bolji rezultat pa se moze govoriti samo o razlikama u nijansama.

Voleo bih kada bi neko napravio slicnu analizu za PIC.

Pozdrav.

Ovaj deo koda:

ldi Ry, Niz.0; // visi bajt adrese niza, Ry i Ry+1 je Ry dvobajtni registar
ldi Ry+1, Niz.1; // nizi bajt vadrese niza
ldd Rn,Y+20; // gde je ofset = 20; 0 <= ofset <= 63

ako je po data sheet-u traje 4 cik. Kod PIc-a bi to bilo ovako:

LFSR FSR0,adresa 2 cik.
MOVLW 20 1 cik.
MOVF PLUSW0,W 1 cik.

nisam ranije pominjao ostale registre za indirektno adresiranje jer sam hteo da ih pomenem kod poredjenja vezanih za stack.
Dakle, pored FSR0, FSR1 i FSR2 registra koji sadrze adrese i njihovih pratecih registra INDF0, INDF1 i INDF2 postoje i dodatni registri:

POSTDEC - pristupa se lokaciji na koju pokazuje FSR pa se potom FSR umanjuje 1
POSTINC - isto to samo sa uvecanjem za 1
PREINC - prepristupa lokaciji na koju ukazuje FSR, FSR se uvecava za jedan pa se tek onda pristupa lokaciji
PLUSW - prvo se sadrzaj W registra doda FSR registru (-127 do 128) pa se tek onda pristupa lokaciji na koju pokazuje FSR

Dakle deo koda za copiranje dva niza bi bio:

LFSR FSR0,adresa1 2 cik, 2 byte
LFSR FSR1,adresa2 2 cik. 2b
MOVLW SizeOF(niz1) 1 cik. 1b
MOVWF brojac,a 1 cik. 1b
loop: MOVF POSTINC0,W,a 1 cik. 1b
MOVWF POSTINC1,a 1 cik. 1b
DECFSZ brojac,F,a 1 cik. 1b
GOTO loop 2 cik. 2b

Sto ce reci, inicijalizacija 6 cik i 6 byte, prolaz 5 cik. 5 byte. Maksimalna frekvencija instrukciskog takta kod 18F serije je 16Mhz mada su u najavi i nove verzije sa 20Mhz. Sto bi znacilo da:

AVR: 18 bajtova i trajanje petlje 7 ciklusa (700ns)
MC9S08: 11 bajtova i trajanje petlje 11 ciklusa (550ns)
PIC18F: 11 bajtova i trajanje petlje 5 ciklusa (313ns) za 16Mhz oscilator + 4xPLL ili 48Mhz oscilator bez PLL

Naravno, ovo poredjenje ne znaci nista jer je samo delic onoga sto MCU radi i verijujem da bi svaki od pomenutih u realnoj aplikaciji bili priblizne brzine ali izgleda da samo AVR ne bi bio slican po utrosku flash-a.

Vezano za stack. Stack kod 18F serije je velicine 32byte sto je konstatovano kao malo, ali ako se koriste registri za indirektno adresiranje moglo bi se reci da problem malog stack-a moze biti resen software-ski. Sad, PUSH i POP insktrukcije kod AVR-a takodje traju 2 cik., PUSH i POP instrukcije kod PIC-a traju 1 cik. kao i smestaj promenjlivih preko software-skog stack-a. Koja je onda tu upotrebna prednost AVR-a?
Dalje, kod AVR-a svaki interupt ima svoj vektor dok kod PIC-a postoje 2, sa nizim i visim prioritetom. Licno, mislim da je to dovoljno za gotovo sve aplikacije, malo je verovatno da je potrebno vise interapta koji moraju da se obrade sto je pre moguce. Takodje, inzinjeri Microchip-a su ubacili fast return stack koji sluzi za automatsko cuvanje sadrzaja STATUS, W i BSR registra (sto nije bi slucaj 10F, 12F i 16F kod kojih se to moralo rucno raditi) ako se na interapt rutinu skoci pomocu CALL adresa,s i vrati RETURN s komandom.

Jos jedno zapazanje, kod AVR-a od 135 instrukcija samo se 57 izvrsavaju iskljucivo u 1 cik.,24 u 1 ili vise cik, dok se ostale izvrsavaju u 2, 3 i cak 4 cik. Kod PIC-a od 75 instrukcija 41 se izvrsava iskljucivo u 1 cik., 18 u 1 ili vise cik, dok se ostale izvrsavaju u 2 cik.

Desio se lapsus vezano za radni takt PIC18F serije.

18Fxxxx - max.40Mhz (ili 10+4xPLL) odnosno 10Mhz instrukciski takt (10Mips)
18FxxJxx - max.48Mhz (ili 12+4xPLL) odnosno 12Mhz instrukciski takt (12Mips)
18FxxKxx - max.64Mhz (ili 16+4xPLL) odnosno 16Mhz instrukciski takt (16Mips)

Sto se tice verzije sa instrukciskim taktom od 20Mhz (80Mhz oscilator ili 20Mhz+4xPLL), ranije je bilo nekih najava ali sada nisam mogao da nadjem nista o tome na Microchip-ovom sajtu, verovatno nece biti nista od toga bar u skorije vreme.

PIC18F4550 serija ima Fclk=48MHz pa se može reći da i obična PIC18F podfamilija ima Fcy do 12MHz.

Da mislim da su svi USB PIC-ovi max. 48Mhz ako je u pitanju obicna 18F serija.

@sander.
napisao si da instrukcije zauzimaju 1 ili 2 bajta, valjda si mislio na dvobajtne reci, sto znaci 2 ili 4 bajta.
Da li sam u pravu?

Pozdrav.

Da greska, izvinjavam se, u pitanju je word (dvobajtna rec). Malo sam na brzinu pisao post a kako nisam ranije imao priliku da prebrojvam utrosenu memoriju a posto se pominjali bajtovi desio se lapsus.

Da, predpostavio sam da je omaska.

ali ipak AVR trosi vise flash-a. Recimo za inkrementiranje jedne variijable u memoriji on ce za unos vrednosti te varijable u registar potrositi 4 bajta, za inkrementiranje 2 bajta i za vracanje u memoriju 4 bajta, sto je ukupno 10 bajtova. To je cesce njego kopiranje nizova, cak mnogo cesce. Dakle, kad god AVR radi sa memorijom, a to ce morati, cak i za programe srednje slozenosti, potrositi osetno vise flash-a od PIC-a.

Sto se brzine tice sva tri MCU-a koja smo pominjali su tu negde, cak i dovoljno brzi za vecinu aplikacija. Dakle ostaje, za mene vazan faktor potrosnja flash-a. To ce vaziti dok god radim sa 8-o bitnim mikrokontrolerima, mada i oni sada imaju i po 128KB flash-a.

Pozdrav.

Ima jos jedna lepa stvar kod 18F serije koja se vrlo razlikuje od 16F serije, W registar je mapiran u RAM memoriji na lokaciji FE8h (WREG) tako da su neke instrukcije moguce sa W koje su ranije bile moguce samo sa SFR ili GFR registrima. Recimo pomenuti primer je moguce uraditi i:

LFSR FSR0,adresa1 2 cik, 4 byte
LFSR FSR1,adresa2 2 cik. 4b
MOVLW SizeOF(niz1) 1 cik. 2b
loop: MOVFF POSTINC0,POSTINC1 2cik. 4b
DECFSZ WREG,F,a 1 cik. 2b
BRA loop 2 cik. 2b

18b duzine i 5cik. prolaz

MOVFF instrukcija vrsi kopiranje sadrzaja sa jedne adrese na drugu (adresa je bilo koja u RAM-u 4Kb), adresa moze biti i bilo koji registar pa i POSTINC0 i POSTINC1 kao u ovom slucaju. Ogranicenje je da se ova instrukcija ne moze koristiti na PCL, TOSU, TOSH i TOSL registrima.

Bas lepo.

Znaci FSR0 i FSR1 su dvobajtni registri, da naredba MOVFF sadrzaj sa adrese u FSR0 prebacuje u adresu koju sadrzi FSR1 i da ih inkrementira za 1.
Ako je tako, i uz ono sto sam primetio kao razliku izmedju 16-tice i 18-tice, nema razloga da bilo ko koji koristi PIC uopste razmislja o 16-tici. Ne treba ni pocetnike navoditi da sa 16-ticom pocinje. Pocetnik je pocetnik i jednako su mu nepoznata oba, pa je bolje odmah da radi sa onim sto vredi.

Kakva je situacija sa indirektnim indeksnim adresiranjem, kad je indeks konstanta i kad je indeks variijabla?

Pozdrav.

Jeste, FSR je dvobajtni i sadrzi adresu lokacije u RAM-u.

Citanjem sadrzaja INDF registra mi ustvari citamo memorisku lokaciju na koju pokazuje FSR bez promene FSR registra.
Citanjem sadrzaja POSTDEC registra takodje citamo sadrzaj mem.lokacije na koju pokazuje FSR ali se po citanju FSR umanjuje za 1
Citanjem sadrzaja POSTINC isto kao kod POSTDEC stim sto se po citanju FSR uvecava za jedan
Citanjem sadrzaja PREINC registra prvo se FSR uvecava za jedan pa se onda pristupa mem.lokaciji na koju pokazuje FSR
Citanjem sadrzaja PLUSW registra prvo se FSR dodaje vrednost u W reg (-127 do 128) pa se onda vrsi citanjem mem. lokacije u FSR reg.

Ovo sve vazi i za sve FSR registre i njihove pripadajuce INDF, POSTDEC, POSTINC, PREINC I PLUSW registre.

MOVFF instrukcija kopira sadrzaj bilo koje mem.lokacije u bilo koju mem.lokaciju u RAM-u. Kako su svi registri mapirani u RAM-u ako bi stavili:

MOVFF POSTINC0,POSTINC1

ustvari bi dobili da sadrzaj sa lokacije na koju pokazije FSR0 kopiramo na lokaciju na koju pokazuje FSR1 sa post incremnt-acijom i FSR0 i FSR1 registra.

Posto MOVFF instrukcija zauzuma 4b i izvrsava se 2 cik. to isto se moze uraditi sa

MOVF POSTINC0,W,0
MOVWF POSTINC1,0

koje ce takodje zauzeti 4b i izvrsiti se u 2 cik.

Osim standardnih 75 instrukcija neki mikrokontroleri 18F serije (18F8722), svi 18FxxJXX i 18FxxKxx serije imaju i prosiren instrukciski set za jos 8 novih instrukcija koje se mogu koristiti ako se konfiguraciski bit XINST setuje.
Nove instrukcije su:

ADDFSR f,k - dodaje vrednost k (0-63) vrednosti FSR-u f (0-2)
ADDULNK k - dodaje FSR2 registru k (0-63) zatim izvrsava RETURN puneci PC sadrzajem TOS-a.
CALLW - Poziva potprogram koristeci W registar
MOVSF [Zs],Fd - Sadrzaj lokacije FSR2+Zs(0-127) upisuje u registar Fd (12 bit adresa)
MOVSS [Zs],[Zd] - Sadrzaj sa lokacije FSR2+Zs(0-127) se upisuje u lokaciju na koji pokazuje FSR2+Zd(0-127)
PUSHL k - k (0-255) upisuje na lokaciju na koju pokazuje FSR2, zatim se FSR2 umanjuje za 1
SUBFSR f,k - Isto kao ADDFSR sem sto se umesto sabiranja vrsi oduzimanje
SUBULNK k - Isto kao ADDULNK samo sa oduzimanjem

Setovanjem ovog bita se i vecina standardnih instrukcija menja tako sto se koriscenjem access ram-a umesto pristupa adresi 0-5Fh ta vrednost tretira kao offset vrednosti pointera FSR2. Recimo:

BSF 90,2,0 - kod standardnog instrukciskog seta setovao bit 2 u registru na adresi 90 preko access ram-a
BSF [90],2 - kod prosirenog instrukciskog seta bi setovao bit 2 registru na koji pokazije FSR2 uvecan za 90

Prednost 18F serije u odnosu na 16F seriju u nekim stvarima su neverovatne. Recimo pomenuto kopiranje sadrzaja 1 niza u rugi bi potrajalo prilicno u odnosu na trajanje kod 18F serije. Treba imati na umu da kada se 16F serija pojavila ni zadatci koje je trebala da obavlja i nisu bili toliko zahtevni kao danas. Dobro se ta serija drzi i dan danas sa svim svojim nedostatcima. Tvoja konstatacija kod odabira koje mcu, koristiti 16F ili 18F je stvarno na mestu, ni po cemu nema razloga ne odabrati 18F pogotovu sto su prepravke programa sa 16F minimalne a i odrzana je pin kompatibilnost.

Dakle, glupo je pocinnjati sa PIC-om a da to nije 18-tica.

Malo je neobicno da ofset, kod indirektnog indeksnog adresiranja, ide u opsegu -128..127. Mislim da negativni ofset (indeks) nece nikada da se koristi, ili bar ja ne vidim kada bi se koristio. Mozda je to zbog stranicenja memorije, pa indeks ne moze da bude veci od 127? Kako se ponasa MCU kada adresa (pocetak niza+indeks) predju granicu memorijske stranice, ja mislim da ce tro dobro raditi jer su u FSR registrima dvobajtne adrese. Ako je to tako, onda stvarno ne vidim razlog zasto indeks ne ide od 0..255.

Bilo bi lepo da za neki program duzine oko 3 do 5 KB das podatak koliko ima asemblerskih naredbi i koliko je bajta flash-a potroseno. Imacemo podatak koliko u proseku jedna asemblerska naredba 18-tice trosi flash. Ja sam to izmerio za MC908 i to je 1.95 sto se moze zaokruziti na 2. Malo mi je komplikovanije bilo da izracunam trajanje prosecne instrukcije, pa sam dobio vrednost oko 3 ciklusa. Za PIC ce to biti lakse, svaka 2 bajta traze 1 ciklus, osim naredbi skoka, i mozda jos nekih, ne znam.

Pozdrav.

Izvinjavam se sto sam mozda dosadan sa ovim poredjenjima AVR i PIC mikrokontrolera, mozda nekima moze biti od koristi da izvuku nekave zakljucke.
Gledajuci ona pomenuta poredjenja mikrokontrolera sa http://www.freertos.org/PC/ probao sam da test sa sabiranjem dve 16 bitne varijable (1 test) izvedem u asembleru oba kontrolera pa evo zapazanja:

Zadatak testa je sabrati dva neoznacene 16 bitne varijable i rezultat smestiti u trecu 16 bitnu varijablu 20 puta:

Kod AVR-a u idealnom slucaju, sve varijable su u 32 registra u R0, R2 i R4 su nizi bajtovi dok su u R1, R3 i R5 visi bajtovi 16 bitnih brojeva:

LDI R6,20 1 cik.
loop: MOVW R5:4,R1:0 1 cik.
ADD R4,R2 1 cik.
ADC R5,R3 1 cik.
DEC R6 1 cik.
BRNE loop 2 cik.

sto ce reci da sabiranje traje 1+6x20 cik. sto sa oscilatorom od 8Mhz (inc.cik=125nS) iznosi 121 cik. x 125nS = 15,125uS.

Za slucajeve da se varijable nalaze u RAM-u vreme izvrsenja se drasticno menja:

LDI R6,20 1 cik.
loop: LDS R0,Broj1 2 cik.
LDS R1,Broj1+1 2 cik.
LDS R2,Broj2 2 cik.
LDS R3,Broj2+1 2 cik.
ADD R2,R0 1 cik.
ADC R3,R1 1 cik.
STS Broj3,R2 2 cik.
STS Broj3+1,R3 2 cik.
DEC R6 1 cik.
BRNE loop 2 cik.

sto daje 1+17x20 odnosno 341 x 125nS = 42,625uS. Ako uporedimo testove sa neta ispada da program u C-u sa dodatkom setovanja i resetovanja pina nekog porta radi brze nego deo prezentovanog asemblerskog koda, 40,4uS naspram 42,625uS. Kako?

Sad to isto kod PIC-a:

Opet najidealnija varijanta, sve varijable se nalaze u jednoj banci:

MOVLW 20 1 cik.
MOVWF brojac 1 cik.
loop: MOVF broj1,w 1 cik.
ADDWF broj2,w 1 cik.
MOVWF broj3 1 cik.
MOVF broj1+1,w 1 cik.
ADDWFC broj2,w 1 cik.
MOVWF broj3+1 1 cik.
DECFSZ brojac,f 1 cik.
BRA loop 2 cik.

sto iznosi 2+9x20 odnosno za 8Mhz instrukcijski takt 182x125nS=22,75uS u odnosu na 15,125uS kod AVR-a.

U najnepovoljnijem slucaju kada su varijable pobacane po razlicitim bankama program bi izgledao:

MOVLW 20 1 cik.
MOVWF brojac,a 1 cik.
loop: MOVLB banka_broja1 1 cik.
MOVF broj1,w 1 cik.
MOVLB banka_broja2 1 cik.
ADDWF broj2,w 1 cik.
MOVLB banka_broja3 1 cik.
MOVWF broj3 1 cik.
MOVLB banka_broja1 1 cik.
MOVF broj1+1,w 1 cik.
MOVLB banka_broja2 1 cik.
ADDWFC broj2+1,w 1 cik.
MOVLB banka_broja3 1 cik.
MOVWF broj3 1 cik.
DECFSZ brojac,f,a 1 cik.
BRA loop 2 cik.

sto iznosi 2+15x20 odnosno 302x125nS = 37,75uS u odnosu na 42,625uS kod AVR-a. Kako je malo verovatno da je 32 reg. dovoljna za smestaj varijabli dok sa druge strane je sasvim realno da varijable sa kojima se vrse aritmeticke operacije budu u jednoj banci ili ako je 384 bajta dovoljno za smestaj varijabli (max. ram kod 16F serije je bio 368b) onda o nekoj superiornosti AVR-a nema ni govora.

Mozda bi neko od kolega koji radi sa AVR-om mogao da proveri gore date primere, mozda sam negde pogresio, ne radim sa AVR-om, moze biti da sam neku instrukciju kod AVR-a prevideo.

Uopste nisi dosada. Dosadne su prazne price bez cinjenica.

Nisi prebrojao bajtove koje zauzimaju ovi test programi u flash-u, sto je za mene vazan podatak. Isti test sam napravio za MC9S08 pa bi sve to tabelarno izgledalo:


Nisam siguran da li sam dobro izbrojao bajtove za AVR i PIC, pa neka me neko ispravi ako sam pogresio.

Nekako mi razlike ne izgledaju bas drasticne. Doduse ni primer nije reprezentativan za sticanje neke konacne slike o performansama.
Kod PIC-a, i ako se ne varam i kod AVR, masinski ciklus je 4-o fazni gde svaka faza, za ovu takt periodu, ima trajanje od 31.25ns. MC9S08 ima jednofazni masinski ciklus, ali naredbe se izvode u jednom ili vise masinskih ciklusa.

Pozdrav.

_{[Ovu poruku je menjao korak dana 22.09.2008. u 13:47 GMT+1]}

Molio bih te ako mozes da postavis kod u oba slucaja za MC9S08 i u kojim slucajevima bi isao najbrzi kod a u kom sporija varijanta. Jos jedanput da napomenem, kod PIC-a sam dao kod i za najsporiju varijantu koja na srecu u 99% slucajeva nece biti primenjena jer je malo verovatno da ce brojevi nad kojima se vrsi operacija biti u razlicitim bankama.
Napravio sam gresku kod koda za AVR, LDI instrukcija koristi samo registre 16-32. Mislim da si pogresio za velicinu koda kod AVR u najbrzoj varijanti kao sto sam ja u jednom od predhodnih postova, 6 word-a odnosno 12 bajta. Ideja da proverim neke od testova je zato sto mi u njima nesto ne stima, recimo kopiranje bloka memorije i njihovo poredjenje, to sigurno PIC to radi sigurno brze (vec samo objasnjavao) a kod njih je 863uS naspram 3,3ms, sto je mnogo mnogo je, tako da ona moja vec recena konstatacija stoji da su testovi tendeciozno radjeni da favorizuju pojedine mikrokontrolere.

Evo koda:

Za najbolji slucaj, kada su sve varijable na nultoj strani:

i prevod:

u najgorem slucaju su sve varijable van nulte strane, ali je izvorni kod isti, pa dajem samo prevod:


I ja sam napravio gresku, u srednjim zagradama je trajanje naredbe u ciklusima, i vidis da skok na pocetak petlje traje 4 ciklusa, a ja sam racunao 3 (po inerciji jer svi uslovni skokovi toliko traju, ali ovaj je skok sa dekrementiranjem). Zbog toga dodaj po 20 ciklusa za trajanje izrazeno ciklusima, i za vreme dodaj 1us iz istog razloga.

Pozdrav.

Tragajuci na internetu za programima koji mogu da posluze kao validan test MCU-ova, nisam nasao nista sto bi mi bilo prihvatljivo. Ali sam nasao nesto sto predstavlja analizu koriscenja pojedinih iskaza, struktura i tipova u nekom netrivijalnom programu. To ne mora da odgovara svakom programu, ali je neki prosek. Ova analiza se ocito odnosi na vise programske jezike, pa je pitanje kako bi se to preslikalo na asembler.

Pozdrav.

Iskusne kolege koja je razlika izmedju AT89S52 i AT89C51 ?

Interesantno pitanje:

-Šta se desilo sa čovekom koji je započeo ovu temu daleke 2004-e godine?
-Pitanje se odnosi na to dokle je dogurao sa mikrokontrolerima ili je odustao od svega?

Izvinjavam se za off!!!

Potrebna mi je pomoc oko programiranja gore navedenog mikrokontrolera ako neko zna i ima slobodnog vremena da mi pomogne nije problem i za neku razumnu cenu jer svacije vreme vredi... inace program treba uraditi u programu mplab 8.30 a zadatak je:

Napraviti demonstraciju RS leča
porta,0 R ulaz
porta.1 S ulaz
portb.8 Izlaz

hvala unapred!!!

Imam problem oko jednog zadatka u asembleru,slicaj je zadatku koji vec uradjen na nekoj strani pre,vezan je za rad masine,ako ne zna i ima vremena da mi pomogne bio bih mu zahvalan.Zadatak glasi :Realizovati sistem za uključenje i vremenski ograničen rad neke mašine. Mašina po ukljucenju radi 15 sec a zatim se isključuje. Pritiskom na taster stop ciklus se u svakom trenutku može prekinuti.
PORTB.0 Pogon mašine
PORTA.0 Start mašine
PORTA.1 Stop mašine

Gde je tebi zapelo? Daj da vidimo šta si do sada uradio i gde imaš problem.

Pozdrav.
Sinisha

Jel to kod Taranovica sa Masinskog fakulteta u Kg-u

Zapelo na samom startu,nisam bio jednom-dva puta i nista posle nisam skapirao,sve to izgleda lako ali ja ne znam komande.Kod Taranovica nego sta
.Ja imam deo od zadatka sto je neko radio ovde samo sto tu masina NE RADI 10 sek pa se tek onda ukljucuje,evo kako ide:list p=16F84 ; Definiše mikrokontroler
#include <p16F84.inc> ; Definiše nazive registra

__CONFIG _CP_OFF & _WDT_OFF & _PWRTE_ON & _XT_OSC

cblock 0x0C
CounterA
CounterB
CounterC
endc

errorlevel -302

ORG 0x00 ; Definiše početak programa

movlw 0x00
movwf PORTA ; Podešavanje Portova
movlw 0x00
movwf PORTB

bsf STATUS,RP0
movlw b'00000011'
movwf TRISA ; Podešava ulazno izlazne pinove
movlw b'00000000'
movwf TRISB
bcf STATUS,RP0

Start
btfsc PORTA,1 ;Testira START prekidac
goto Start

;PIC Time Delay = 10.038348 s with Osc = 4.000000 MHz

movlw D'51'
movwf CounterC
movlw D'237'
movwf CounterB
movlw D'173'
movwf CounterA
loop decfsz CounterA,1
goto loop
decfsz CounterB,1
goto loop
decfsz CounterC,1
goto loop ;pauza od 10 sekundi

movlw b'00000001'
movwf PORTB ; uključuje mašinu

Poc
btfsc PORTA,0
goto Poc ;Testira STOP prekidač

; Prekidač je pritisnut

movlw b'00000000'
movwf PORTB ;Isključuje mašinu

Pet
call Pet ;Mrtva petlja

end ; kraj programa



Samo treba da se iskljuci pauza i da se startuje masina na START dugme...fala Bogu ja ni to ne znam,ako znas pomagaj.
Sinisha hvala unapred !

Razlika izmedju AT89S51 i AT89S51 je jedino u tome sto prvi ima prekide 0 i 1, a drugi 1 i 2.

^^wtf!??!


a koja je razlika ovde uopste??
i jedno i drugo je AT89S51

i ko je uopste pitao (i kada) koje su razlike izmedju ko zna cega?

zna li neko kolko MHz procesor poseduji ovi mikrokontrolere ?
18F2550
16F84A
16F628A
12F675

Posetis sajt http://www.microchip.com i poskidas datasheet-ove za kontrolere koji te zanimaju, u njima sve pise.

znam no ne sam video korisna informacija, evo sta pise CPU Speed (MIPS) 5. Sta je to 5? MHz ? meni treba MHz

mips = million(s) instructions per second

u mhz (khz) ti je brzina takta - to gledas kod oscilatora, postoje interni i postoje eksterni, a i to pise u datasheet (ako ima interni), ako nema u sebi oscilator, kupis u prodavnici neki (ne bilo koji, pise ogranicenje u datasheet-u)

Potreban mi je kod ukoliko neko ima za pic18f452 u mikroc-u za ad konverziju (za 2 kanala)??? Da li neko ima, i kako mi mozete pomoci... Unapred zahvalan...

u primerima koji idu uz mikroc imas primer ...

ako odes u help, takodje imas primer

Da li neko zna da mi malo opsirnije napise o primeni mikrokontrolera u elektricnim merenjima?

Generalno, ne pisemo seminarske i diplomske

Nije ni za diplomski, ni za seminarski.... :-D I to nije odgovor na moje pitanje.

Da.

E, to je odgovor na moje pitanje! :-D Hvala.

Da li mi neko može pomoći oko mikrokontrolera EM78P156ELP.

Koristi se na 5.1 speakers PHILIPS SPA2600/00.

P.S. Problem sa kontrolom jačine zvuka (uopšte), ne reaguje (uvijek nizak nivo zvuka)!

Problem sa mikrokontrolerom (mijenjao kristal)!

Unaprijed zahvalan!

Evo ti pomoci

gargamel011 pitao je što se desilo sa likom koji je pokrenuo ovu temu kako kaže daleke 2004 godine.E pa ovako zadnji put je nesto napisao na ovu temu 5.2.2006.Znači odustao.

pozdrav svima. tema je super i voleo bih da ovladam mikrokontrolerima. da li bi mogli da mi preporucite neku literaturu koja objasnjava stvari slicno kao "biblije".
nema veze ako je to vise knjiga.
pozz....

Od Stojana Trifunovića" PIC16f84 Uputstvo za rukovanje" i izdanje mikroelektronike" PIC Mikrokontroleri"

kako da je skinem?

Pošalji mi mail.

Jel ima neko iz Novog Sada da bi odrzao jedan kurs o mikro kontrolerima PLATIO BI NARAVNO!???