programski jezici za mikrokontrolere pitanja i odgovori

@korak

Kad sam rekao da PIC ima problem sa bankama, nisam mislio da je to nesto sto se neplanski pojavilo, pa sad kao u tom smislu treba nekako da se rjesava. PIC se jeste rodio sa bankama, samo u to vreme nije bio sa flash-om :)
Mislio sam na probleme koje memorijski prostor sa bankama pravi kod pisanja kompajlera i programa, i to je nesto sto je poznato i karakteristicno za PIC (a i neke druge arhitekture sa bankama).

(Za one citaoce koji mozda ne znaju zbog cega se koriste banke (kao sto ni meni nije bilo jasno kad sam nekad davno prvi put uzeo PIC16f84 datasheet, jer tamo nigdje nije pisao razlog tog marifetluka): banke se koriste da bi se povecao adresni prostor bez fizickog prosirenja adresne magistrale. Inace to ne mora biti obavezno uslovljeno hardward arhitekturom, jer hardward arhitektura nigdje ne propisuje kolika mora biti sirina adresne magistrale. Ako se napravi sira magistrala nema potrebe za bankama, ali to ima druge konsekvence sto se tice hardverskih zahtjeva.

Sto se tice kvaliteta tog kompajlera kojeg spominjete, moram da kazem da u mom komentaru uopste nisam imao namjeru da o tome nesto zakljucujem, sto je i nemoguce, jer ga nisam vidio. Jedino na sto sam se ja osvrnuo je opsta primjenjivost kod sireg kruga korisnika, moze i da se kaze npr. komercijalna strana svega toga. Posto se citava prica nalazi na javnom forumu, pretpostavio sam da bi i o toj strani price moglo ponesto da se kaze. A mozda bi i Vi stekli bolju sliku o kvalitetu tog kompajlera, ako biste probali taj Vas kompajler da pustite na trziste, pa da vidite reakcije drugih ljudi. Ovako sve ostaje misljenje jednog covjeka (a posto svi roditelji o svojoj djeci misle sve najbolje, to misljenje se vodi kao subjektivno barem dok ga ne potvrdi jos poneko :). Mozda je moguce da taj kompajler savrseno odgovara Vasim potrebama, ali ako nema nikakve informacije o iskustvima drugih ljudi koliko je to onda relevantno za bilo koga osim Vas?

U ostatku teksta kad sam govorio o kompajleru i bankama mislio sam iskljucivo na optimizaciju rasporeda varijabli po bankama, kako bi se ubrzalo izvrsavanje programa ili maksimalno smanjio broj preskakanja iz jedne banke u drugu, a po mogucstvu da se programer oslobodi razmisljanja o tome.
Ono sto ste napisali uglavnom je samo drugi sintaksni nacin da programer napise istu stvar koju u drugim nekim kompajlerima radi npr. pomocu makroa, a nikakve optimizacije nema. Jedino sto bi se donekle moglo podvesti pod optimizaciju je smjestanje "bliskih" varijbli u istu banku, ali to je trivijalno, to programer ionako moze da radi sa mozgom na ispasi. Znaci, nista znacajno nije skinuto sa grbace programeru, a sto je jos vaznije - ne mora da znaci i da je svaki put to dobro!

Dakle, opet naglasavam, da ne bude zabune: ne komentarisem sintaksu i to da li je ona povoljnija/laksa/citljivija/logicnija/razumljivija...itd. (meni je ionako svejedno, kad se naviknete na nesto nemate tih problema), nego optimizaciju. Ako se radi o citljivosti onda bi najlakse bilo izbaciti naredbe za setovanje banke, vec obojiti blok programa bojom banke u kojoj se radi, a u slicnom tonu i varijable iz te banke, pa ako se negdje boje ne slazu, sve bi se fino vidjelo, ali to bi svi smatrali za neozbiljno... Jos kad bi pogresno koriscene varijable blinkale...
Tih tekstualnih kompajlera ima vec prilicno, tako da je tesko dici glavu iz te poplave, medjutim kad bi neko zapeo da pravi neki graficki programski jezik, ja bih mu svaki dan slao bezrezervni mail podrske...


@Stojan

Ipak imam dovoljno iskustva da ne mislim da se po povratku iz interrupt-a mora ponovo selektovati banka, kao i da ne treba staviti selekciju banke prije svake varijable/registra. (Medjutim, ako se dobro sjecam, PIC16 serija nema bas narocito dubok stack, pa se za programe koji su zahtjevni u pogledu prekida ionako mora softwerski realizovati, pa prica o brzini gubi smisao).
Nesporazum ocigledno nastaje zbog razlicitih perspektiva iz kojih posmatramo problem. Ako razmisljamo o mikrokontrolerskom programu tipa: ugasi neku sijalicu kad dan svane, upali je kad se smrkne, onda ste Vi u pravu. Medjutim u tom slucaju ja ne vidim razlog praviti neki kompajler za pisanje programa tog nivoa. Tih Markovih, Dejvovih, Joe-vih, Perinih, Zikinih kompajlera za PIC ima vec sijaset na internetu.
Ako se ne radi o trivijalnom programu, u 80% slucajeva interupt ce pozivati neku funkciju, a ta funkcija mozda jos ko zna koliko. Uzmite obican senzor pokreta, detekcija pomjeraja nekog objekta ce izazvati interupt koji ce poceti da racuna koordinate pozivanjem trigonometrijskih funkcija iz math biblioteke, pa ce se pozivati funkcije za crtanje na displeyu da bi se to npr. nacrtalo, pa ce se pozivati funkcije za prenos podataka na displey, serijsku vezu sa senzorom i sl.
Ono sto prosjecnog potencijalnog korisnika zanima je sta cete vi da radite sa svime time i kako cete da uskladite vas kompajler sa rasporedom varijabli koje definisu koriscene gotove biblioteke? Hocete li napisati sve standardne biblioteke ponovo ili sta? Meni npr. ne bi ni palo na pamet da za svaki displey koji kupim ja sam pisem biblioteku, ili da pisem sin() i cos() funkcije iznova kad mi zatrebaju, ili da redefinisem funkcije za CAN, USB ili npr. neku drugu vezu. A ako pisem program tipa: kad ukucam ova tri broja brava se otkljuca, inace jok, pa to mogu da radim i u masincu.

Ako se manemo hobistickih projekata, onda vrlo ozbiljne stvari treba rjesiti, a ja pisem ovo jer sam stekao utisak da poneko nije svjestan sta to sve podrazumjeva.

U svakom slucaju, ako neko razmislja o optimizaciji programa u odnosu na memorijske banke moze pogledati dokument prikacen uz ovaj post.

Pozdrav!

U redu, u redu. Nismo se razumeli.

Poduhvat jeste obiman. Tu nema sumnje. Medjutim, ono sto korak pokusava (bar kako sam ja to shvatio) je da napravi kompajler koji predstavlja ekstenziju asemblera, koji ce biti razumljiviji od asemblera, kojim ce se programi pisati brze nego u asembleru, a koji ce ipak sadrzati svu njegovu snagu u pogledu optimizacije i brzine.

U pogledu pisanja biblioteka se slazemo. Ni meni ne pada na pamet da ponovo izmisljam toplu vodu. Ako se koristi LCD ili sinus dovoljan je samo Copy/Paste obicnog proverenog .asm koda i resen problem. Medjutim, to bi trebalo biti moguce i u korakovom kompajleru, sa tom razlikom sto ce biti potrebno dodati deklaracije procedura i selekciju banke.

Tako se kompletna procedura izracunavanja sinusa nalazi u jednom bloku. Ista struktura mogla bi se primenjivati i unutar interapta. Dobro, ovo jeste najjednostavniji moguci model, ali programer bi u njemu mogao grupisati registre tako da se registri vise procedura koje se izvrsavaju u petlji ili linijski nalaze u istim bankama. Definisanjem varijabli unutar procedura upravo je omoguceno njihovo lakse pracenje i (rucno) grupisanje kao na slici 7 sa sedme strane vaseg priloga.

Sigurno i sami uocavate prednost ovakvog grupisanja. Najveci broj programa uglavnom periodicno poziva ovako definisane procedure. Ukoliko vec postoje gotove biblioteke (ili u ovom slucaju procedure) za sav moguci hardver i softver (displej, serijsku vezu, matematicke funkcije...), korakov kompajler bi omogucio brze njihovo povezivanje. Kako to? Pa razumljivije je i brze (bar meni) pratiti program i pisati npr.
if W > 50 then ...
nego direktno u asembleru oduzimati pa testirati Carry flag. Osim toga zbog jasnih granica procedura celokupan program je pregledniji.

Svakako da je ovo moguce (stavise, vec postoji) i u PIC Basic-u, ali kod koji on generise uopste nije optimizovan. Kod njega se pre bas svakog registra selektuje odgovarajuca banka. Ne znam C, ali mi izgleda (sudeci po korakovim postovima) da i on pati od lose optimizacije.

Prilog koji ste postavili pruza odlican metod optimizacije, ali ne bih rekao da je objektivan po svojim rezultatima kada se uporedi sa asemblerskim kodom. Naime, za testiranje je izabran asemblerski kod generisan HI-TECH PICC kompajlerom, a banke registara su nasumice, rucno odabrane. Da je program pisan u asembleru svakako bi se povelo racuna o sto manje prelaza, pa bi i postignuta poboljsanja dobijena optimizacijom bila srazmerno manja. Ipak bi ova optimizacija bila previse komplikovana za implementaciju. Na kraju krajeva najbolju optimizaciju moze pruziti sam programer jer kompajler ne zna koje se procedure trebaju izvrsavati maksimalnom brzinom (za optimizaciju brzine), a koje ne (za optimizaciju koda).

Kako sam ja razumeo koraka je pricamo o kompajleru za 18F seriju i o nacinu za smestaj varijabli. Kao sto sam ranije govorio, 18F serija mikrokontrolera moze direktno bez selekcije banaka da kontrolise donju polovinu banke 0 (128b) i jednu celu banku 1-14 kao i kompletne SFR registre. To je vise nego kompletan RAM kod 16F serije. Ako dodamo i 3 registarska para za indirekno adresiranje koji kontrolisu celi adresni prostor RAM-a i uz njihovo pametno koriscenje velicina memorije kojom bi se brzo pristupalo se u mnogome povecava.
Ako govorimo o 16F seriji tu se stvari malcice komplikuju. Korakova ideja nije losa ali ne znam kako bi se pokazala u praksi. Mozda nije lose pogledati kako su neke stvari resene kod konkurencije i njihovih basic, pascal,c .. kompajlera. U krajnjem slucaju, kompajler bi mogao da odredi koliko koji program ima zahteva prema smestaju varijabli pa da nesto od toga optimizuje a nesto koristi uz menjanje banaka, neki kompromis. Cak i da se pristupanjem varijabli uvek menja banka i to nam zbog brzine pravi problem uvek se moze koristiti kontroler koji ce moci to raditi brze, cena tu ne igra nikakvu ulogu, jedino mozda progrmerova nesigurnost zbog nedovoljnog poznavanja novijih serija.

Odin D.

Uvodjenje banaka ne smanjuje adresnu magistraku. Adresna magistrala uvek mora da odgovara kapacitetu memorije. Valjda shvatas da se kod 16F uz 7 bita adrese dodaju jos 2 bita banke na mestu najvece tezine i tako formira 9-to bitna adresa koja moze da adresira 2KB memorije. Banke su uvedene da bi se smanjila duzina koda naredbe koja sadrzi adresiranje memorije. Harvard struktura moze da maksimalno razvije svoje dobre osobine samo ako je duzina koda naredbi koje baradaju sa memorijom iznosu 24 bita. Dakle flash mora da ima 24-o bitnu magistralu podataka. Ali postoje naredbe kojima ne treba 24 bita, i kod njih je to cist gubitak memorije. Kod 8-o bitnih mikrokontrolera je nadjen kompromis, na jedan nacin kod 8051 a na drugi kod PIC-a. DAkle, to su pravi razlozi.

Stojan Trifunovic je potpuno razumeo moju teznju, i ja mu se zahvaljujem na tome. Ti si preneo diskusiju na neko drugo polje. Govoris o optimizaciji prilikom rasporedjivanja varijabli po bankama. Naravno, to bi bilo najbolje, i to mora da se uradi u visim programskim jezicima, ako se zeli dobar kompajler. Zasto tamo to mora? Pa zato sto su ti jezici standardizovani da bi bili prenosivi. Nije dozvoljeno uvodjenje novih pojmova koji su specificni samo za neki mikrokontroler, deklaraciija varijabli mora biti jedinstvena i otud potrebe za pomenutom optimizacijom. Asembler nije prenosiv i on se pise za konkretan mikrokontroler i dozvoljeno je da se uvode novi pojmovi i strukture da bi on bio sto laksi za programiranje uz povecanje efikasnosti i pouzdanosti.

Izrazavajuci sumnju u ono sto radim vec 20 godina a ne videti to nije bas dobronamerno. Na kraju krajeva, ja radim sa Motorolom i nemam problem sa bankama. Cilj mi je bio samo da svoje iskustvo u razvoju komapajlera (i PASCAL kompajlera) podelim sa drugima, mladjima koji bi dobili ideju da i sami naprave nesto korisnoza svoj mikrokontroler. Mozes se pitati zasto ne govorim o PASCAL kompajleru. Vrlo prosto, C je neprikosnoven za programiranje mikrokontrolera, Napraviti PASCAL za jedan mikrokontroler nema smisla, jer kako cu iskoristiti njegovu osobinu prenosivosti, morao bi da razvijem PASCAL i za druge mikrokontrolere, a to je ogroman posao. Osim toga i C i PASCAL manje efikasno koriste resurse mikrokontrolera od asemblera, drukcije receno nemaju snagu asemblera. Zatim, kada nesto napisano na asembleru, pri cemu koristim i neke dosetke da bi kod bio kraci i brzi, pa to onda napisem na C-u, dobijem deprimirajuci rezultat. Zato sam odlucio da zadrzim snagu asemblera, a njega samog da popravim, koliko je god to moguce kako bi pobiljsao efikasnost pisanja programa i pouzdanost napisanog programa. To sam u speo sa mojim asemblerom za MC908.

U najboljoj nameri zeleo sam da dam neke ideje kako bi se nesto slicno uradilo i za popularni PIC. Dobronamerni ce to razumeti kao pozitivan napor, ali ja ne insistiram, ko nece neka ostane u svojoj ljusturi. Postavio si pitanje da li sam to komercializovao. Moja firma se bavi proizvodnjom raznih uradjaja, a ne razvojnih alata. Medjutim od prve verzije mog asemblera ziveo sam 2 godine (na prelazu 80-90 godine) i oni koju su imali iskustva sa asemblerima bili su odusevljeni, a oni koji nisu imali to iskustvo mislili su da asembleri trebaju da budu takvi. Taj kompajler je bio za HC11.

Vec treci put ponavljam da u asembleru postoje moduli. Vec imam zbirku modula za LCD, USB, RS232, matematiku u pokretnim zarezu, za rad sa stringovima i t. d. Kada mi nesto od toga treba, samo ukljucim modul i koristim vec razvijene i proverene funkcije i procedure.

Ako neko ima zelju da nastavimo caskanje o ovoj temi, ja sam raspolozen za to, ali necu odgovarati onima koji imaju oportuni stav klanjajuci se bozanstvu zapadne tehnologije a nipodastavajuci svaki kreativni napor ovde. Pa, zaboga, ovde se radi samo o idejama koje se mogu implementirati u neki bolji asemblerski kompajler za PIC. Zasto je bolje kada nas mladi strucnjak to radi za neku stranu firmu, a nije dobro ako to radi ovde na svoju ruku (tu ne racunam sebe, ne spadam u mladje). Muka mi je od takvog pristupa jer sam se uverio bezbroj puta u nedorecenim proizvodima ili proizvodima sa zakrpama koji su dosli sa zapada. Koliko sam gresaka nasao u njihovoj tehnickoj dokumentaciji i t. d. Narocito je interesantno kada ime se obratis i ukazes na gresku, dobijas odgovor kao da si idiot.

Pozdrav svima.

@sander

Da vidimo! Sto se tice konkurencije u vidu MPLAB asemblera i njegovog relokativnog moda situacija je sledeca.
Iz glavnog programa koji jedini sadrzi apsolutne adrese reset i interapt vektora pozivaju se svi ostali (relokativni) programi.
Struktura mu je sledeca:

Osim jedine dve potrebne apsolutne adrese (za interapt i reset vektor) linker ce povezati sve ostale CODE delove u celinu, po sopstvenim setovanjima.
Tacke ulaska u potprograme i programe "spolja" moraju se prethodno definisati "ekstern" direktivom. U ovom slucaju to su programi sa labelama _interrupt, _init_hard i _init_soft, bez obzira gde se nalazili. Moguce je pozivati i delove eksternog programa (npr. _init_soft moze biti potprogram unutar fajla sa _init_hard delom).

Registri se mogu definisati ili u ovom fajlu ili pak u eksternim fajlovima, medjutim moraju im biti definisana pripadnost odredjenim blokovima pre nego sto se odredi da li ce im biti dozvoljen pristup spolja. Definisu se unutar UDATA (za sukcesivne adrese), UDATA_SHR (za registre deljene izmedju svih banaka) ili UDATA_OVR (za registre ciji se sadrzaj sme obrisati odmah nakon izlaska iz tog dela programa - fajla, i kasnije iskoristiti za druge programe - fajlove). Svim ovim blokovima moguce je rucno odrediti apsolutne adrese (kao sto je uradjeno za UDATA sekciju), ali moguce je i tu obavezu prepustiti linkeru (iako ce on verovatno - nisam probao za sve varijable izabrati banku 0, sto moze dsovesti do veoma komplikovanog pronalazenja problema).
Izbor odgovarajuce banke i njihova promena znaci u potpunosti su prepusteni programeru.

Oni registri koji se koriste "spolja" moraju biti definisani "global" direktivom. U ovom slucaju to su msec, sec, ali ne i min.

Struktura eksternog fajla je sledeca.


Sto se tice flasha struktura eksternog fajla je takva da su u njoj strogo definisane labele kojima se moze pristupati spolja (_init_hard), dok su sve ostale interne za taj fajl (npr. Petlja), i samim tim nevidljive spolja.

Za varijable je takodje strogo definisano kojima se moze pristupati spolja, kojima ne, i koje su interne za taj fajl i mogu biti ponovo inicijalizovane i koriscene za neku drugu proceduru po izlasku. Ova zadnja mogucnost dosta pomaze (It is an ideal way of declaring temporary variables since it allows multiple variables to be declared at the same memory location. This directive is similar to udata, except that it allows you to reuse data space by "overlaying" one data area on another. It is used for temporary variables, as each data section may overwrite (and thus share) the same RAM address locations.).


@korak

Lakse malo covece! Pa lepo je Odin D. stavio smajlija. A i dao je prilicno konstruktivan pristup implementaciji promene banaka, iako teak za konkretnu implementaciju u okviru kompajlera. Nazalost, kako bi i u tom pristupu trebalo zbog maksimalne moguce optimizacije (code vs speed) definisati koje procedure trebaju biti brze a koje ne, ipak mislim da bi bilo bolje prepustiti programeru brigu oko promene banaka. Razvoj kompajlera bio bi brzi i daleko jednostavniji.
Inace, Odinova ideja sa oznacavanjem varijabli u kodu razlicitom bojom od koda deluje mi neverovatno simpaticno.

@Stojan

Razumeo sam i tebe i Korak-a dobro i OK je to sto ti govoris. Definisati varijable kojim pristupa celi program (globalne) ili samo u okviru procedura (podprograma) je ok ako se one mogu razvrstati tako, sta se desava ako imas vise globalnih varijabli, nizove, stringove ili neke slozenije tipove koji ne mogu zaposesti samo jednu banku, oni se nece moci uskladiti u neki sablon ili u tom slucaju i nece biti optimizacije? Zato sam i napomenuo 18F seriju koja moze to lakse i jednostavnije da proguta. Uvek programer u asembleru moze da sam optimizuje koje varijable staviti gde ali zar sa stanovista programera ne bi bilo lakse da ako to nemora da o tome i ne razmislja i da to kompajler radi za njega.

@korak

pa dobro, majku mu, ja izgleda uvijek ispadam neki dezurni namcor cim postavim poneko pitanje koje ne ide kud i svi turci. Nije u redu odmah proglasavati nekoga nedobronamjernim i zacaurenim ako nema isto misljenje.

No, da kazem nesto o konkretnim pitanjima sa teme, bez uvijanja forme (ali ipak dobronamjerno):

9-bitna adresa i 9-bitna magistrala su babe i zabe. 9-bitna adresa je logicki pojam, a 9-bitna magistrala je fizicki pojam. Ako je kod PICa ta MAGISTRALA 7-bitna kako kazes, sa dodatna 2 bita kojima se programer zamajava se dobija efektivna 9-bitna ADRESA. Da bi se bez banaka mogla imati 9-bitna adresa, onda bi fizicka magistrala morala biti sa 9 linija, odnosno morao bi chip hardverski da se prosiruje. Posto je PIC 8-bitna masina, da bi mogao da radi sa 9-bitnim adresama fizicki, morao bi znacajno hardverski da se mijenja to jest da bude 9-bitni. Zbog toga se koristi implementacija memorijskog prostora sa bankama da bi se hardverska magistrala zadrzala na nivou procesora, iako se adresni prostor povecava iznad mogucnosti 8-bitne aritmetike.
Dakle, BANKE SE IPAK KORISTE DA BI SE SMANJILA FIZICKA MAGISTRALA u odnosu na ZELJENI ADRESNI PROSTOR koji prevazilazi mogucnosti npr. 8-bitne, 16-bitne itd masine.
A to sto si napisao da se koriste da bi se smanjila duzina koda naredbe koja sadrzi adresiranje memorije, to mozda moze biti samo nus pojava kod nekog procesora, ali u principu nema nikakve veze sa koriscenjem banaka i pravi razlog je onaj sto sam naveo gore.
I opet cu da kazem, da to nema narocito veze sa harvardskom arhitekturom. Sve sto harvardska arhitektura podrazumjeva je odvojen memorijski prostor za program i podatke i to je sve. Niko tu ne spominje nikakve sirine naredbe od 24 bita i sl. Harvardska arhitektura se srece svuda od 4-bitnih mikrokontrolera do specijalizovanih grafickih procesora, PC procesora i superskalarnih procesora, gdje su naredbe siroke od 4 pa do 256, pa cak i vise bita, gdje si ti tu iskopao bas sirinu od 24 bita i kako si dosao do nje kao karakteristicne za harvard arhitekturu to mi nije jasno.
Dalje, sa 9 bita moze da se adresira 512 lokacija, a ne 2K, a memorija za podatke je implementirana kao RAM, pa ne vidim kakve veze to ima sa flash memorijom koju navodis. Flash memorija kod PIC16 je za program i tu postoji 13-bitni PC koji adresira 8K mem. lokacija za program (ako se ne varam te lokacije su 14-bitne, odnosno programska rijec je siroka 14-bita), a banke se odnose na memoriju za podatke.

(Samo da napomenem da se pojam "bank" u svijetu hardvera i u vezi sa adresnom arhitekturom koristi u vise razlicitih konotacija, i iz vise razlicitih razloga, ali za ovaj slucaj koristi se u kontekstu koji sam gore napisao. To navodim za slucaj da ne iskopa neko nesto sto se slucajno zove "bank" (npr. kod vektorskih procesora ili za memory interleaving, pa da ide bez potrebe u off-topic.)

E sad sto se tice tih "dobrih namjera" prema mladjim generacijama, koje izgleda kod tebe igraju neku bitnu ulogu kod ocjene kvaliteta kompajlera, onda mogu i ja da kazem nesto o svojim iskustvima.
Dakle, jednog dana ce ti mladjani ljudi da odrastu i u cilju odrzanja svoje egzistencije ce pokucati na neka vrata i reci "Ja sam dosao povodom oglasa za posao...". Kada ih potencijalni poslodavac priupita sa kojim alatima barataju (posto se jezik podrazumjeva to ih nece ni pitati), mislim da nece bas ostaviti narocit utisak ako kazu "Baratam odlicno sa korakovim Pascal-asemblerom". Bez obzira koliko taj kompajler bio bolji standardi su standardi i sa standardima se radi. To je isto kao da dodjete da trazite posao u Londonu, i kazete: "Ja ne znam engleski, ali znam esperanto, to je znate, mnogo bolje." Mozda i jeste, ali posao ipak necete dobiti. A ako neko savjetuje mladjim generacijama da svoje vreme investiraju u nesto sto se nigdje ne koristi, ne uzimajuci u obzir kakve ce to posljedice kasnije da ima na njihov zivot i zaposlenje, onda su po meni te dobre namjere pogresno procjenjene.

Sledece, osvrnucu se jos i na iluziju o samozaposljavanju, red je da malo popricamo i o tome, posto je to jedina oblast u kojoj se, za sada, moze razgovarati o tom kompajleru. Prvo se, svako od nas moze preispitati koliko ljudi poznaje u svom zivotu. Zatim sracunajte otprilike koliko svi ti ljudi imaju uredjaja u kojima su mikrokontroleri (bice ih sigurno vise hiljada), a onda probajte da izbrojite koliko tih uredjaja je napravio neki usamljeni strelac iz komsiluka, pa sracunajte postotak.
Da biste sa diskutabilnim uspjehom poceli da radite u samostalnoj reziji potrebno je da imate odredjeno iskustvo koje ne mozete steci sa razvojnom plocicom od 99 evra koju ste kupili u obliznjoj prodavnici. Time mozete da se zabavljate, ali da hranite porodicu i sve drugo sta uz to ide, tesko.
Ako krenemo da ozbiljan osciloskop kosta minimum 2000 evra, osrednji razvojni sistem 500, ICE takodje minimum par hiljada, ozbiljan softwer takodje, Logic analyzer circa 1000, programatori, moduli, svi ostali alati i oprema, porezi, registracije, milion drugih stvari itd... onda tom mladom covjeku u startu treba minimum 30-tak hiljada za start. A sve to ne znaci nista ako prethodno nije stekao negdje neko iskustvo. I sve su to mali troskovi kad se uporedi sa troskovima probijanja na trziste (razni market-planovi, reklame itd...). U nasim uslovima, takvih nema mnogo.
Znaci, korak, od 1000 ljudi koji ce se baviti mikrokontrolerima, 999 njih ce poceti kao juniori u nekoj firmi, a ako vi bazirate vase savjete na onom jednom koji ce da radi sam i povremeno napraviti automatsko paljenje svjetla za komsijinu garazu ili pumpu za bunar koja se zaustavi kad voda dodje do nekog nivoa, to je onda druga stvar. Ja ne govorim o tom jednom covjeku.
A i od svih tih ljudi koji rade samostalno, 99% njih je prethodno radilo negdje drugo pa tek onda pocelo svoj biznis, sto je takodje vrlo vazna cinjenica u ovoj prici, ali se izgleda cesto precutkuje.
Jeste lijepa iluzija zamisljati da ce svako od nas da sjedi kod kuce, ustaje kad oce i radi kad oce, ceprka nesto sa mikrokontrolerima i to prodaje za velike pare itd... Medjutim, sto se prije rijesite te iluzije to bolje. Ko od vas ima mp3 player ili bilo sta drugo pravljeno kod nekog privatnika iz komsiluka?
Moze se i desiti da nekom upadne sjekira u med, ali to je izuzetak, a ne pravilo.

U svakom slucaju, put koji vi predlazete je po mom misljenju naopak od realnosti. Da se mladi ljudi u startu zamajavaju pisanjem kompajlera za svoje mikrokontrolere, a pri tom tek sto su poceli da rade sa tim, je isto sto i ohrabrivati covjeka koji je dva puta skocio padobranom da pocne konstruisati avione i to ne bilo kakve nego neke koji ne mogu da slecu ni na jednu poznatu pistu u svijetu, ali pri tom trose manje kerozina!
Vecina ljudi koji posjecuju ovu temu su mladi ljudi koji se interesuju za mikrokontrolere, a na tome ce i ostati ako se ne osposobe da dobiju neki posao u toj struci. A to osposobljavanje podrazumjeva dobro baratanje sa standardnim alatima. Nekad ste mogli lako da se zaposlite u nekoj firmi bez narocitih znanja o tome, pa vam daju neke knjige, pa vi kao citate pola godine o tome, pa zapitkujete starije kolege i tako dok ne naucite. Ta vremena su prosla. Danas tako mozete dobiti posao jedino ako vam je blizak rodjak direktor firme, ili je drzavna firma sa platom cirka 200 evra. Ja sam nedavno bio na jednom razgovoru za posao u firmi gdje se radilo sa opremom sa kojom nemam iskustva, ali bih za 15-tak dana mogao da se presaltam, jer su principske stvari valjda iste. Medjutim, pitanje poslodavca je bilo: "Mozete li vi od sutra da se ukljucite samostalno u projekat?". Ja sam rekao da ne mogu, da mi treba najmanje 10 dana, oni mi se zahvalili na razgovoru i rekli da im je zao, da im treba neko odmah. Medjutim, nije stvar u tih 10 dana, vjerovatno znaju i sami da nece naci nikog za tako kratko vreme, ali mislim da mi nisu povjerovali da uopste znam nesto o tome. Vjerovatno su mislili, evo jednog nema pojma, hoce da nas obmane, misli da ce za 10 dana stici nesto da nauci. Eto, tako je to u realnosti kad odrastete, izvjestaj iz prve ruke.

I na kraju, mene u ovoj raspravi uopste ne interesuju bilo cije subjektivne namjere. Ako vi napravite kompajler koji sabere da je 2+2=5, ja cu da kazem da je los. Cak i ako vi kazete da cete sav prihod od prodaje tog kompajlera pokloniti centru za nezbrinutu djecu, ja cu opet da kazem da je los. Nemojte me prozivati za nikakve namjere, jer me to ne zanima. Za mene je ovo tehnicki forum i ja komentarisem samo tehnicke aspekte proizvoda (a jedan od tih aspekata je i upotrebljivost u prakticnom zivotu) i nista drugo.


@Stojane

ako se radi samo o prosirenju asemblera radi lakse citljivosti onda ok. Ja sam se osvrnuo na optimizaciju koriscenja memorijskih banki jer se nesto o tome pricalo u par postova prije moga. Inace sve ostalo receno je samo po sebi jasno i ne zahtjeva neko dodatno objasnjenje. Ipak, moram jos jednom da napomenem da nisam imao namjeru da komentarisem kvalitet predlozenih rjesenja, samo da ukazem na primjenjivost svega toga u prakticnom zivotu.

Sto se tice ovog primjera koji sam okacio u attachmentu, opet mali nesporazum. To sam i naveo kao primjer koliko mali rezultati optimizacije se postizu cak i prilikom koriscenja slozenijih matematickih aparata i algoritama, a ne obratno, da bih pokazao to kao neki dobar metod optimizacije. U tom smislu irelevantno je koji asemblerski kod se optimizuje (hitec-ov ili neki drugi), jer se prikazuje ustvari poboljsanje te optimizacije nekog automatski generisanog asm koda. Da je optimizovan neki rucno pisan asemblerski kod (kao sto bi bio u slucaju korsicenja ovog korakovog kompajlera) poboljsanja bi sigurno bila zanemarljiva, ako ne i negativna. Time sam samo htjeo da skrenem paznju da mozda nema smisla razmsiljati o toj vrsti optimizacije kod pravljenja ovog kompajlera koji je blizak asembleru. Jedino mozda na neki vizuelni nacin povecati preglednost toga. Ali ne mora ni to biti od nekog znacaja. Ne znam koliko ko ima iskustva sa programiranjem mikrokontroelera, ali asembler se mahom koristi za krace i jednostavnije projekte, a kod programa tog obima programer koji to radi ionako sve to ima manje-vise u glavi, pa mu ni te informacije na ekranu u nekoj vizuelno preglednoj formi ne moraju nuzno biti od velikog znacaja (sto se tice tih memorijskih blokova). Medjutim, preglednost koja se postize pisenjem "if W > 50 then" o odnosu na klasicne asemblerske mneomonike je ipak znacajna, sa tim se bezuslovno slazem.
Sto se tice ukljucivanja funkcija iz vec gotovih biblioteka onako kako ste napisali nema problema, ali je problem sto se te biblioteke skoro nikad ne isporucuju sa izvornim kodom, tako da copy-paste otpada. Moze se iz hex ili iz binarnog coda dobiti asm kod, ali dok bi se on prepravio na ovaj pascal-asembler lakse bi ga bilo ispocetka napisati.

Pozdrav!

@sander

Pri odgovorima se ogranicavan na 16F familiju jer nju najbolje poznajem. 18F familiju nisam dovoljno savladao, a i njena poboljsanja nisu mi nesto preterano potrebna.
16F serija nije mnogo zahvalna za stringove, nizove, matrice i ostale "naprednije" strukture. Ja bar pokusavam da ih ako je ikako moguce izbegnem u programima. Za njih je indirektno adresiranje idealno, a tu je PIC16 serija prilicno limitirana.

Ukoliko vec program zahteva vise registara, mogu se bez ikakvih problema u relokativnim programima definisati varijable koje se nalaze u njima UDATA direktivom. Znam i sam da ovo nije dobro resenje za vise podataka nego sto moze stati unutar jedne banke, ali 16F serija je takva, i tu je nemoguce ista uraditi.
Ovo je deo iz linkerske skripte za 16F628 u kome su definisane dozvoljene granice banaka.

DATABANK NAME=gpr0 START=0x20 END=0x6F
DATABANK NAME=gpr1 START=0xA0 END=0xEF
DATABANK NAME=gpr2 START=0x120 END=0x14F

SHAREBANK NAME=gprnobnk0 START=0x70 END=0x7E
SHAREBANK NAME=gprnobnk0 START=0xF0 END=0xFE
SHAREBANK NAME=gprnobnk0 START=0x170 END=0x17E
SHAREBANK NAME=gprnobnk0 START=0x1F0 END=0x1FE

Sa ovakvom strukturom slobodno se moze pisati:

NIZ_BANK1 UDATA 0xA0
niz res .79 ; (od 0xA0 do 0xEF)

Nazalost tako ce se dobiti niz od samo 79 neprekidnih registara. Tacnije, moglo bi i vise, ukoliko se zadje u oblast registara prisutnih u svim bankama.



@Odin D.

Situacija u nasoj zemlji je takva kakva je. Kinezi prave revoluciju dok mi stagniramo. Sigurno nije toliki problem znanje, koliko ostali aspekati (mnogo vece cene elektronike, zastarele tehnologije, porezi na sve i svasta, veze...). Za sada od mikrokontrolera bez obzira na znanje nema zarade. Mozda ce uskoro (za pedesetak godina) biti bolje.
Skoro sam cuo pricu kako je covek trazio posao ali gazda je bio zauzet obavezama, pa je na intervju poslao - svoju suprugu. Sta ce da upita kandidata, kako stoji sa engleskim. Kaze, solidno. Ne, ne moze solidno, vec morate da odlicno vladate njim. Pa dobro, ispitajte me. Ali ja ne znam engleski! Onda je dovela jednog od radnika i trazila da raspravljaju o tehnickim aspektima posla na engleskom. Kako je engleski bio apsolutno nebitan u celoj toj prici, njegovo znanje bilo je jos gore od znanja kandidata. Sve dok nasi poslodavci ne znaju sta hoce, zaposljavace kandidate koji vladaju svim znanjima ovoga sveta sve dok ne sednu za masinu. Mozda je i to dobro. Koliko znaju tako ce biti placeni, sve do bankrota.

Sto se tice banaka, korak pokusava naci najoptimalnije resenje za njihovu implementaciju. Sada ima mogucnost izbora. Moze prepustiti izbor programeru, ili probati da napravi potpuno automatski kompajler po uputstvima iz vaseg priloga.

Koliko sam ja shvatio, zaista se radi samo o prosirenju mogucnosti asemblera, a u cilju poboljsanja njegove preglednosti, smanjenja mogucnosti pojave gresaka i brzeg razvoja programa.

Kazete da se asembler koristi mahom za krace programe. Zasto je to tako? Licno mislim da je odgovor upravo u njegovoj losoj strukturi (tacnije nedostatku ikakve strukture) i teskoj citljivosti. Dzabe komentari kada se najobicnije IF W > 50 mora realizovati kako rekoh oduzimanjem, testiranjem Carry flaga, pa tek onda grananjem. Kada bi se ovo moglo uz dobru optimizaciju koda sakriti od programera, takav program bio bi daleko citljiviji, pa bi bili moguci slozeniji programi uz isto ili manje napora. Drago mi je da se sa ovim slazemo.

Verovatno se nismo razumeli za funkcije iz gotovih biblioteka. Tu nisam mislio na funkcije unutar biblioteke u njenom bukvalnom znacenju (libaries sa ekstenzijom .lib - iako bi se i one mogle disasemblirati) vec na asemblerske (.asm) programe, odnosno potprograme koji mogu (isto kao biblioteke) obavljati odredjenu funkciju (npr. sinus). U tom slucaju postoji gomila izvornog koda unutar Microchipovih AN (Aplication Note) .pdf fajlova. Cak se izvorni kod za vecinu AN moze naci u zipovanim .asm fajlovima. Mislim da je svaki programer koji zeli sebi olaksati rad vec sakupio (bez obzira da li su razvojene ili kopirane) dovoljan broj potrebnih rutina. Uz korakov kompajler samo ce ih ubaciti u zaglavlje procedure.

Moram ipak istaci da mislim da je korak pravilnije shvatio upotrebu magistrale (iako je ocigledno pogresio za 2Kb RAM-a).
Zbog harvardske strukture se unutar jedne instrukcije nalazi i kod i operand. Tako ne postoje dve magistrale (adresna i magistrala podataka) vec (kod PIC16 serije) jedinstvena 14-tobitna magistrala. Konstruktori 16F serije sigurno su verovatno mogli povecati broj bitova magistrale (kao sto su i uradili pri prelasku sa 12 na 16 seriju), medjutim imali su dobrih razloga da to ne ucine.

Svako povecanje broja bitova za adresiranje RAM-a ili flasha moralo bi potrositi srazmerno vecu flash memoriju. Idealno bi bilo kada bi 16F serija imala 16 (umesto 14) bitova po instrukciji. Tako bi kod instrukcije CALL umesto

100 kkkkkkkkkkk bio
100 kkkkkkkkkkkkk , odnosno mogao bi direktno adresirati celih 8Kb flasha.

Isto tako kod CLRF instrukcije bi umesto
0000011 fffffff bio
0000011 fffffffff , odnosno mogao bi direktno adresirati celih 512 registra RAM-a.

Zbog cega se Microchip nije opredelio za ovakvu arhitekturu? Jednostavno, ocenio je da ogranicenje sa bankama i stranama ne predstavlja preveliki problem (nije imao koraka u vidu :) ), a moglo bi se dosta ustedeti na flash-u. Kako?
Sa 14-tobitnim instrukcijama flash bi morao imati 14bitova * 8192instrukcija = 114688 bitskih celija flasha.
Sa 16-tobitnim instrukcijama flash bi morao imati 16bitova * 8192instrukcija = 131072 bitskih celija flasha. Usteda flasha je ocigledna.

Potpuno isti sistem se primenjuje i u 18F seriji. Korak je verovatno imao nju na umu kada je pricao o 24-bitnoj duzini instrukcija.

Mislim da je ovo verovatnije od vase teorije (da nisu mogli promeniti hardver), pogotovu jer je eto u 18F seriji povecan broj bitova magistrale, ali su banke i dalje ostale.

Odin D.

Od svega sto nisam tacno rekao je da se sa 9 bita adresne magistrale adresira 2KB (imao sam ispred sebe jedan 18F sa 2K i napravio omasku). Treba znati razliku izmedju harvard i Fon Nojmanove strukture, pa onda pricati na tu temu. Hardvard struktura je uvedena sa ciljem da se ubrza rad procedora, da se uvede paralelnost u izvrsavanju jedne naredbe i citanju i dekodiranju sledece. Da bi se to postiglo, a cilj je da se to radi za jedan klok ciklus procesora, obe operacije treba toliko da traju. To je odlicna ideja i vrlo znacajna za povecanje brzine rada procesora, a da ne moraju da se ugradjeni elementi u procesor koji rade na nekoliko puta vecoj frekvenciji od one na kojoj radi procesor Fon Nojmanove strukture. Na primer MC9S08 ima klok od 50ns (sva unutrasnja kola moraju da rade sa tim klokom) a prosecno trajanje instrukcije je 150ns. Harvard struktura, ima dakle cilj da ucini da instrukcija radi na tih 50ns, usteda je ocigledna. Medjutim, ako procesor adresira 64KB memorije, da bi harvard struktura dala svoj maksimum programska memorija mora imati najmanje 24 bitnu sirinu. Jedan bajt za kod naredbe i 2 bajta za direktan pristup bilo kojoj lokaciji memorije. Naravno procesori sa vecom memorijom mogu da imaju i siru programsku memoriju. Medjutim, kako je sirina programske memorije ista za sve naredbe, cak i za one koje nemaju parametre, onda se javlja neracionalno koriscenje programske memorije. No, da se ne bi uludo bacali bitovi koji se ne koriste, kod takvih naredbi, dodaju im se jos neke osobine, kao uslovno izvrsavanje i tome slicno.

Druga stvar koju treba znati je da sami vodovi koji povezuju aktivne elementa na cipu zauzimaju znacajnu povrsinu cipa. Zato je problem kako u cip mikrokontrolera integrisati sto vise hardvera i obezbediti prostor za veze koje ce ih povezivati. Sa tog aspekta Fon Nojmanova struktura 8-o bitnih mikrokontrolera ima samo jednu 16-to bitnu adresnu magistralu, jednu 8-o bitnu magistralu podataka i jedan broj kontrolnih signala. Kod PIC-a postoji magistrala za pristup flash-u, magistrala za pristup RAM-u i svim drugim resursima mikrokontrolera, magistrala za pristup steku i magistrala za pristup EEPROM-u. Kao kompromis islo se na kracu sirinu programske memorije. To je dovelo do toga da adresni parametar naredbe kod pristupa podacima u RAM-u bide 7 ili 8 bita. Dakle, jednom naredbom se ne moze pristupiti proizvoljnoj lokaciji u RAM-u. To se moze uraditi sa dve: jednom se saopste visi nedostajuci bitovi (preko 7 ili 8) i to su bitovi koji odredjuju banku ili stranicu (kako ko voli) a sledecom naredbom se saopstava kod naredbe i nizi bitovi adrese. Naravno, uvek postoji mogucnost da se u nekom nizu naredbi pristupa lokacijama sa iste stranice, i nije potrebno uvek saopstavati nedostajuce bitove adrese jer oni ostaju zapamceni na nekom odredjenom mestu (u statusnom registru, ili u nekom posebnom registru). Slican mehanizam se koristi i kod skokova i poziva podprograma.

Dakle, Odine stranicenje memorije niije uvedeno da se suzi adresna magistrala, vec da se suszi sirina programske memorije, odnosno time i skrati naredba, a vidimo kako ona od 12 bita narasta sa svakim novim tipom PIC-a kako tehnologija napreduje i prelazi na sve uze veze (sada je valjda 0.25 mikrona).

Da se osvrnem i na ono sto si pisao, a van teme je, niko ko se ozbiljno bavi ovom tehnikom ne moze da bude konzervativan a istovremeno i uspesan. Iako koristim asembler u kojem sam odstranio vecinu mana koje on kao takav ima, ostala je samo jedna mana i ona je neresiva. To je neprenosivost. Zato svakom pocetniku savetujem da mu glavni jezik bude C, ne zato sto je najbolji, vec zato sto je prenosiv, a kod gazde ce biti u situaciji da cesto menja procesore sa kojima radi.

Inace, radio sam 2 godine za jednu firmu u Minhenu odavde iz Nisa, ali i kod njih par meseci. Svi rade na C-u, a u neobaveznom razgovoru sa gazdom (on srecom nije bio laik za elektriniku) cuh od njega da C programere moze da nadje na svakom koraku, ali one koji programiraju na asembleru nema, a rado bi ih zaposlio. Zasto, saznao sam vrlo brzo. Radili su sa nekim 16-to bitnim mikrokontrolerom (sa siromasnim integrisanim hardverom i spoljasnjim memorijama) izvedenim iz 80C51 i odlicnim razvojnim sistemom XA V3.0 Americke firme TASKING. Njihovi programeri nisu znali da otvore prozor sa prevedenim kodom da vide rezultat onoga sto rade, niti su znali arhitekturu mikrokontrolera. Sta ce im kada to od njih ne trazi razvojni sistem. Elem, posle godinu dana, narucilac ih je tuzio i trazio nadoknadu stete jer je uradjaj koji su razvijali lose radio u nekim specificnim situacijama. Ja sam dobio zadatak da dibagiram softver koji su oni pisali, i odnmah prvo trazio, na njihovo zaprepascenje, datasheet za mikrokontroler. Kao sta ce mi. Brzo sam shvatio da su njihovi programeri vesti na PC-u, da su kupili knjigu za C i naucili ga i sebe prozvali C programerima. A tamo, niko ti ne trazi diplomu, vec te pita sta znas da radis. I sad, on je pokazao da zna da radi, ali softver moze da pokaze da ima gresku i posle vise meseci rada. Vrlo brzo sam video nekoliko ociglednih gresaka koje verijem ne bi napravilo 80% ljudi na ovom forumu. Toliko o stvarnosti, mozda njenom nalicju, prosudite sami.

Dakle, kada bih imao para, i bio prisiljen da radim sa raznim mikrokontrolerima, sigurno bi kupio C kompajlere za sve te mikrokontrolere i tako pisao prakticno jedinstvene C programe bez obzira na kontroler. Ali, kako situacija nije takva, izabrao sam mikrokontroler koji ima veliki broj tipova da moze da pokrije sve projekte kojima se bavim, poboljsao asembler, i to je za mene kao privatnog preduzetnika najbolje resenje sa najmanje para. Drugi, u drukcijim situacijama treba da nadju najbolje resenje u okviru svoje situacije, i ja ne zelim da ih nagovaram. Naprotiv, samo sam zeleo onima koji rade samo sa PIC-om i pri tome su sami sebi gazde da prenesem svoje iskustvo, jer se kod mene pokazalo kao vrlo uspesno. Osim toga zasto bih se opterecivao kada ionako imam previse posla, i zasto bi trosio energiju na polemike gde mi se umesto svojim argumentima suprotstavlja linkovima.

Pozdrav svima,
ako neko misli da je interesantno ovo sto radim neka mi se obrati rado cu saradjivati.

@Stojane

PIC, kao i svaki drugi procesor harvardske arhitekture mora imati adresnu magistralu i magistralu podataka za program, a isto tako adresnu magistralu i magistralu podataka za podatke. To su ukupno 4 fizicke magistrale, a nema ni govora o postojanju jedne jedinstvene magistrale za sve, jer onda bi se sve prednosti harvardske arhitekture anulirale (ona je i napravljena zbog toga da bi se u isto vreme moglo pristupati programskim instrukcijama i podacima).
U flash memoriji se nalazi program. Instrukcije iz te memorije se dovlace u jezgro preko 14-bitne magistrale za podatke (taj 14-bitni podatak se npr. sastoji od 6 bitova kojima se kodira asemblerska instrukcija, 7 bitova npr. za adresu operanda ili slicno, zavisi koja je instrukcija u pitanju, jer kao sto si naveo, kod call ili goto instrukcije samo tri bita koduju operaciju, ostali predstavljaju neki dio adrese i sl., a kod ostalih je drugacije, no to nije bitno). A koja instrukcija ce se dovuci u procesor preko te 14-bitne magistrale podataka iz flash memorije, odlucuje se pomocu adrese koja se salje preko 13-bitne adresne magistrale. Dakle, to su dvije magistrale kojima se dovlace programske instrukcije iz flash memorije u jezgro procesora koji te instrukcije izvrsava. O adresiranju programske memorije brine se PC registar koji je 13-bitni i ima pridruzenu hardversku logiku koja mu omogucava da barata sa 13-bitnim adresama iako je procesor 8-bitni. To je uglavnom da se inkrementira, ili da mu se doda neki broj ili da se upise neki broj (zbog skokova i sl.) Medjutim, taj dio procesora je ipak ogranicene velicine i ne utice znatno na velicinu cipa.

Osim flash memorije ima i RAM memorija u kojoj se nalaze konfiguracioni registri i GPR registri koje program koristi za upravljanje mikrokontrolerom ali i kao memoriju za privremene podatke kojima program operise u toku rada. Naravno, da bi se pristupilo nekom bajtu u toj memoriji, taj bajt je prvo potrebno adresirati preko neke adresne magistrale, a zatim ga i dohvatiti preko magistrale podataka. U ovom slucaju magistrala podataka je 8-bitna, a adresna je valjda 9-bitna. Znaci i tu fizicki postoje 2 magistrale.
E sad, kad se radi o adresiranju te RAM memorije, osim direktne adrese koja moze da se nalazi u samoj instrukciji (kao npr. nizih 7 bitova i jos neki bit iz status registra koji odredjuje o kojoj banci se radi) postoje i razni drugi modovi adresiranja koji se intenzivno koriste ne samo kod mikrokontrolera nego i svih drugih procesora. To su npr. bazno, bazno-indeksno, pa varijacije sa auto-inkrementom, auto-dekrementom i sl. bez kojih se ne moze zamisliti npr. rad sa nizovima, sukcesivna obrada nekog niza podataka u memoriji, premjestanje bloka podataka sa jedne lokacije na drugu i sl. E sva ta izracunanja adresa kod takvih modova adresiranja zahtjevaju odredjeni hardver i razlike u velicini hardvera postaju drasticne izmedju 8-bitne i 9-bitne aritmetike. To obicno znaci da bi se citava arhitektura procesora morala kompletno mijenjati pocevsi od ALU jedinice, pa nadalje, znaci i velicine svih registara, brojaca, dekodera, magistrala itd... Prosirenje sirine flash memorije sa 14 na 16 bita je relativno zanemarljivo spram ovog povecanja koje sam upravo napisao (kod PIC16 cipova koji imaju implementirano svega 2KB flasha, prosirenje od dva bita bi znacilo svega dodatnih 512 bajtova flash memorije, to nije bila neka cifra cak ni u vreme kad je nastao, a kamoli danas, a tada to nije ni bio flash nego eeprom i sl.).
Ja zaista nisam 100% siguran iz kog razloga je kod PIC odabrano da se radi tako (a iskreno da kazem, mrzi me da sad listam data sheetove i bakcem se time), medjutim koriscenje banaka u cilju prosirenja adresnog prostora iznad aritmetickih mogucnosti procesora, a da se pri tome izbjegne hardversko komplikovanje procesora je (bila) uobicajena tehnika kod 8-bitnih procesora. Kazem "bila" jer je to nesto sto se danas uglavnom izbjegava.
Sta se desava sa PIC18 serijom nisam upucen, jer sam nakon PIC16 ja napustio pic i nisam nista dalje sa njim radio. Medjutim, cini mi se da je i PIC18 8-bitna masina i ako hoce da adresira vise od 256 bajtova RAM-a mora da koristi banke ili neki drugi trik, i to je to. Duzina instrukcije, kao sto rekoh moze da utice samo na direktno adresiranje u kom se adresa operanda u RAM memoriji nalazi direktno u instrukciji, a svi ostali nacini adresiranja zahtjevaju ili prosirenje hardvera ili koriscenje banki (i banke su neki vid "prosirenja", samo sto dodatna izracunavanja za ta 2 ili 4 bita nisu implementirana u chipu nego u glavi programera, odnosno, prenose se sa hardvera na softwer, a programer je duzan da sa njima ispravno barata u svom programu).

Sto se tice ovih "gotovih" funkcija koje se mogu pronalaziti u .pdf-ovima i skupljati po nekim dokumentima, mislim da to nije bas najsretnije rjesenje. Te su funkcije izolovane jedna od druge, nekonzistentne po pitanju koriscena varijabli i hardvera itd. Zamisli situaciju da ubacis funkciju koja racuna sinus, a onda ukljucis neku funkciju za serijsku komunikaciju, a one obe definisu neke medjupromjenjive na istoj memorijskoj lokaciji i jedna drugu zakopava. Pitanje je koliko su dokumentovane sve te stvari i koliko je pametno time se baktati. Naravno da se sve to moze sizifovskom metodom izgurati, ali bice potroseno ogromno vreme i trud, a rezultati ce u najbolju ruku biti osrednji.

Moje je misljenje, da ako naumis da pravis kucu, kupi alat i materijal i pocni da je pravis. A ako ti u svrhu pravljenja kuce pocnes prvo da sam pravis mjesalicu, pa da proizvodis cement, pa kopas glinu da bi pekao cigle i blokove i rudu gvozdja da bi dobijao gvozdje za eksere i armaturu itd. iskreno mislim da se tu vise radi o nekim drugim stvarima nego o pravljenju kuce.

Pozdrav.


#EDIT

@korak

Dok sam pisao poruku u medjuvremenu je stigla i tvoja poruka, medjutim mislim da ono sto sam pisao Stojanu o razlogu koriscenja banaka moze da bude i odgovor na tvoju poruku.

Sto se tice harvardske arhitekture:
Poznajem dobro i Von Neumann-ovu i harvardsku arhitekturu i mogu odmah da odgovorim da cilj da se instrukcije izvrsavaju u jednom taktu ili bilo kakve konstantacije tog tipa nemaju nikakve veze za definicijom harvardske arhitekture. Harvardska arhitektura znaci da se program i podaci nalaze na odvojenim mjestima i da im se pristupa odvojeno preko razlicitih magistrala. Poenta svega toga je da moze da im se pristupa istovremeno. Ako se u procesoru trenutno dekodira instrukcija koja zahtjeva neke operande iz npr. RAM-a, ti podaci mogu da se dovlace preko magistrale podataka, dok se istovremeno preko programske magistrale dovlaci sledeca instrukcija u jezgro. Kod Von Neumann-ove to nije slucaj, jer se i program i podaci nalaze u istoj memoriji i pristupa im se preko iste magistrale, tako da sledeca instrukcija mora da ceka dok se ne ucitaju operandi koje je npr. zahtjevala prethodna instrukcija.
A da li ce se instrukcije izvrsavati u jednom, deset ili sto taktova, to je sasvim druga prica. Postoje hiljade i hiljade razlicitih procesora sa setovima instrukcija od kojih se duzina izvrsavanja nekih instrukcija istog procesora razlikuju i vise od 100 puta i traju razlicit broj taktova (a neke su i asinhrone itd.). Naravno, kod mikrokontrolera je to cilj kome se tezi, ali zbog nekih drugih stvari, a ne sto je to filozofija harvardske arhitekture. Ima harvardske arhitekture implementirane i kod CISC i kod RISC a i kod nekih hibridnih setova instrukcija, zatim kod skalarnih i vektorskih procesora itd. i tu nema govora o nekom cilju harvardske arhitekture da se postigne da se sve instrukcije izvrsavaju za isto vreme i to u okviru jednog takta procesora.

Vec si u nekoliko postova naglasio averziju prema "linkovima" i pozivanju na neke autorite van sopstvene glave. Mislim da je to malo pretjerano. Postoje milioni stvari na internetu objasnjeni i dokazani od mnogo kompetentnijih ljudi nego sto sam ja. Ja cu se radije pozvati na te izvore nego tvrditi nesto iz svog nesigurnog iskustva. Bolje je nekom da procita strucan tekst, nego da mu je prepricavam nesto za sta nisam strucnjak. Na kraju krajeva i ja sam vecinu stvari naucio od nekog drugog, i ne pada mi na pamet da nipodastavam izvore na internetu, jer internet nije neka nedefinisana tvorevina nepoznatog porijekla izronila iz magline mlijecnog puta, nego sadrzaj koji su takodje napisali neki ljudi koji takodje mogu nesto znati o mikrokontrolerima. Tako bi se neko na nekom drugom forumu, u americi npr. mogao pozvati na neki tvoj ili moj post, a neko mu odgovori "mani me tih linkova sta tu ima vredno".
Na kraju krajeva, moras priznati da su i motoroline mikrokontrolere napravili tamo neki drugi ljudi na "trulom zapadu od koga dobijamo samo bagovite proizvode", i ove kompjutere na kojima radimo, i softwer itd. Mozda i ti ljudi pisu neke postove, clanke, blogove i svoja razmiljanja negdje na internetu i u najmanju ruku je neprimjereno ih je sve adresirati nipodastavajucim tonom.
Ja cu uvijek savjetovati svakom da aktivno prati bar jedan-dva vodeca sajta embedded svijeta, da bi mogao da vidi malo siru sliku od one koje bi stekao samo na osnovu svojih projekcija. Na kraju krajeva, tamo pisu ljudi koji su izmisljali ove stvari na kojima mi sada radimo.
Ja sam ovo sto sam napisao o razlogu koriscenju banaka naucio iz knjiga koje su pisali ljudi koji su izmislili te stvari, a ne na osnovu mojih licnih zakljucaka. Nije nista lose misliti sopstvenom glavom i donositi sopstvene zakljucke, ali to ne znaci da treba zatvoriti oci i usi za sve druge informacije.
Ovako mi se tvoj stav cini kao da si ti sam izmislio i te mikrokontrolere i kompjuter i sve ostalo i da si se sve sam naucio i da je citav svijet zastranio samo si ti nasao pravi put.

Ovo tvoje iskustvo sa tom firmom je, sta da kazem...ima svacega. Isto kao i onaj moj intervju za posao. Medjutim, ne mogu se stvari generalizovati, ima i takvih firmi ima i drugacijih. Da sam ja dosao popodne, mozda bi bio neki drugi ispitivac, mozda bi sve bilo drugacije....

Da se vratimo na temu. Ako bi kompajler bio samo poboljsanje asemblera odnosno da olaksa rad ljudima koji rade u asembleru, pre svega zbog lakseg pisanja programa sa raznim petljama, grananjima itd. onda bi nacin deklaracije varijabli mogao ostati slican kao i kod asemblera odnosno da programer povede racuna o tome. Mozda bi neka prva verzija i trebala tako da radi pa tek za neke naredne da se uvode poboljsanja. Nisam siguran ali mislim da i PIC Basic nema vise tipova varijabli vec byte i bit sto je najlakse i uraditi u kompajleru i mozda za prvu verziju i ne treba ici na neke slozenije tipove. Ono sto bi trebao svakako da ima vec gotove biblioteke za LCD, USART, I2C, ADC, PWM itd. i tu se uglavnom slazemo. Jos jedna stvar koja mi se cini dobrom, da interupt rutina bude implementirana tako da svaki interapt bude kao posebna procedura nesto slicno su izveli u CCS C kompajleru. Znaci nesto kao :

#int_ad
adc_handler() {
.....
}

pa ako je omogucen interapt onda ce se izvrsti procedura za obradu tog interupta bez potrebe da se pise deo interatpr rutine za snimanje sadrzaja vaznih registara i proveru koji je interapt izazvan kao i za vracanje sadrzaja prilikom izlaska.

Prioritet nekog interapta bi bio odredjen redom definisanja interapt procedura.

OK Odine,

ne mogu da zamislim da je cilj Hardvar strukture bio da se razdvoje memorijski prostori programa i podataka, a pri tome negirati da je konacni cilj bio postizanje vece brzine. Pogledaj AVR, on ima Harvard strukturu 2 nivoa, njegovi registri (32) imaju posebnu magistralu, iako pripadaju RAM prostoru samo da bi mogle da se ostvare dvoadresne naredbe. Citajuci o ovoj strukturi, jasno je naglaseno da je ona jedno od resenja da se poveca brzina procesora. Ti skoro isto zakljucujes, ali zelis da ono sto je isto prikazes kao razlicito, ok.

Kada sam pomenuo linkove, naravno i ja sam mnogo toga naucio sa interneta, a sve sto znam sam naucio i od drugih i iz knjiga. Ali kada polemises sa nekim, ne koristi se navodjenjem linkova, vec ako si naucio nesto sa tog linka iznesi svoj stav kao argument. Dakle, ne nipodastavam ono sto se moze naci na internetu, niti navedene linkove u slucajevima kada pitam nesto na forumu pa mi neko da neki link. Ali ako se upustas u debatu, onda neka to bude iz tvoje glave i sopstvenog iskustva. To je bila moja primedba.

Ako su procedure o kojima sender govori smestene u modulima, onda nece doci do kolizije prilikom deljenja RAM prostora, jer su sva imena u modulu privatna za modul i prilikom kompajliranja bice pravilno rasporedjene varijable u RAM prostoru.

Koliko sam shvatio PIC ima samo jedan interrupt vektor (ispravite me ako gresim) pa tako moze postojati samo jedna interrupt procedura. U njij se ispituju flegovi koji oznacavaju koji se interrupt aktivirao, i na osnovu toga se poziva odgovatajuca procedura. U principu mogu se pozvati sve interrupt procedure, a prva naredba u svakoj ce biti provera da li je njen interrupt fleg aktiviran, i ako nije procedura ce se tu zavrsiti. Ako se ne varam PIC troci malo vremena za ulazak i izlazak iz procedure (podprograma). Tada bi interrupt procedura bila uvek ista, a pisale bi se samo one procedure (koje se pozivaju iz interrupt procedure) koje su potrebne. Nisam siguran da je ovo najbolje, ali mozda neki dobar poznavalac PIC-a moze da komentarise.

Pozdrav

Da se ne bismo stalno vracali na temu...

Ako se namjerava dalje diskutovati na ovu temu i nesto u tom pravcu raditi, predlazem da se otvori nova tema sa naslovom "Razovj kompajlera za PIC" ili kako god vec nadjete za zgodno. Time bi sam naslov teme privlacio ljude koji su zainteresovani za to, pretraga bi davala bolje rezultate, informacije bi se drzale na jednom mjestu itd.
Ovako se ova tematika sa strane ubacuje vec nekoliko puta u teme koje su zapocete zbog sasvim drugih pitanja i postovi koji su pisani o tome su rastrkani po citavom forumu i uopste slaba je vajda od toga, a unosi se zbrka u ostalo. Npr. ova tema je zapoceta pitanjem o programskim jezicima koji se koriste kod mikrokontrolera, a stiglo se do razvoja novog kompajlera za PIC.
Dosta tema na ovom forumu zastrani, mnogo se caska, a malo sta uradi. Moderatori su prilicno liberalni po pitanju ko sta kome kako i gdje odgovara i jednim djelom i to doprinosi sto je forum takav kakav je.

Zbog postova koji se nalaze u neodgovarajucim temama pojavljuje se mnogo beskorisnih "odgovora". Konkretno u ovoj temi gdje covjek pita koje programske jezike da uci, skrenulo se na pricu o novom nepostojecem jeziku i kompajleru, i onda uvijek neko (npr. ja) u svjetlu naslova teme mogu da postavim pitanje "a sta ce ti to". Da npr. nije doslo do ovog skretanja u temi, ja bih mogao dati covjeku konkretniji i korisniji odgovor, npr. uci to i to. Lakse meni, bolje njemu. A da se o ovoj stranputici raspravlja u temi koja se zove "Razvoj kompajlera za PIC", ja tamo ne bih mogao postaviti pitanje "a sta ce vam to", zato sto se tamo o tome i radi. Time bi smo svi ustedjeli na vremenu, da ne odgovaramo na ono sto covjek nije pitao, da oni koji hoce da prave kompajler umjesto sto odgovaraju na moja pitanja rade nesto korisnije po razvoj kompajlera itd.

Ovom forumu je svakako potrebno malo sredjivanja.

Pozdrav svima!

@korak

Pojavljivanje harvard arhitekture jeste bilo zbog povecanja brzine i mogucnosti procesora (kao uostalom i bilo koja promjena u svijetu mikrokontrolera se iz 99% razloga radi zbog toga). Moja je primjedba bila samo na to da harvardska arhitektura to ubrzanje podrazumjeva upotrebom odvojenih magistrala za instrukcije i podatke (dakle brzi protok podataka kroz procesor), a da to ni na koji nacin nije spregnuto sa teznjom da se instrukcije izvrsavaju u jednom taktu. To je sasvim druga prica. Harvardska arhitektura se srece kod svih vrsta procesora (i kompjutera) pa cak i onih kod kojih nema govora o uniformnom trajanju instrukcija, ili cak kod onih koji rade asinhrono. Mozemo imati harvardsku arhitekturu kod bilo kog procesora ili racunara. Mikrokontroler moze da ima i spoljnu memoriju za podatke i program i to je opet harvardska arhitektura bez obzira kakav je sam procesor iznutra. A to kako je u samom procesoru realizovana jedinica za izvrsenje instrukcija i u koliko koraka (fetch, decode, fetch operands, execute....) ili taktova procesora ce to odigravati nije uopste dio price iz harvardske arhitekture.
Teznja da se instrukcije kod mikrokontrolera izvrsavaju sto brze i u jednom taktu je posljedica specificne upotrebe mikrokontrolera gdje ta osobina igra veliku ulogu (zbog sto brzeg i vremenski definisanog odgovora na interrupt i sl.), ali kao sto rekoh, to je stvar implementacije jezgra, ali nije povezano sa harvardskom arhitekturom, osim sto se te dvije stvari cesto zajedno upotrebljavaju u konstrukciji mikrokontrolera, ali ni jedna ne uslovljava onu drugu i odnose se na razlicite stvari.

Nisam najbolje razumio ovo o AVR procesorima, medjutim pretpostavljam da se radi o nekim GPR registrima koju su implementirani na posebnom bloku u chipu, van RAM-a, iako potpadaju pod isti adresni prostor. Ako je tako, onda treba te stvari razlikovati od harvard arhitekture. U vecini danasnjih procesora je implementirana neka tehnika ("trikovi") za ubrzanje rada. Najpoznatija tehnika je npr. cach memorija. To je memorija fizicki bliska jezgru procesora u koju se (obicno po nekom algoritmu) predefinisano ucitavuju programske instrukcije unapred, za vreme dok procesor izvrsava prethodne operacije. A kad mu zatreba sledeca instrukcija, ako je pri tom ona vec u toj cach memoriji on ce je odatle mnogo brze dohvatiti nego iz klasicne programske memorije u kojoj lezi program, cime se postize znacajno ubrzanje. Ta memorija ima jednau magistralu ka jezgru, a drugu ka RAM-u, ali to ne znaci da je u pitanju harvard arhitektura, cim postoji vise od jedne magistrale. Kod mikrokontrolera je uobicajeno tehnika korscenja tzv. shadow registara. To znaci da se dupliraju neki karakteristicni registri npr. razno razni statusni, kontrolni itd. a obavezno i GPR registri. U tim dupliranim registrima je isti sadrzaj kao i u orginalnim. Kad dodje do interupta (ili poziva neke funkcije, zavisi sta hocemo), nema snimanja karakteristicnih registara na stack, vec interupt rutina nastavlja da radi sa shadow registrima. Kad se interupt zavrsi, glavni program nastavlja odmah da radi sa orginalnim registrima (koji su ostali nepromjenjeni jer je interrupt rutina radila sa shadow registrima) i nema potrebe skidanja neceg sa stack-a i sl. Ti shadow registri postoje npr. kod Infineona, ali se sticajem okolnosti zovu memorijske banke (sto naravno nema veze sa ovim bankama kod PIC-a samo je ime isto :)), a osim toga to je i 5-portna memorija, zato sto postoji i 5-stage instruction execution pipeline i razlicite instrukcije mogu u isto vreme da pristupaju tim registrima (neke bi da citaju podatak odatle, neke bi da upisuju, itd.). Osim toga postoji isto jedan set registara dvoportnog RAM-a implementiran fizicki blizu jezgra koji sluzi kad bas treba izuzetno brz pristup memoriji, kao i jos nekoliko razno raznih setova specijalnih registara razlicitih osobina da sad ne nabrajam. Kod zahtjevnijih procesora moze biti npr. i 16 shadow setova, tj. interupti se mogu ugnjezdjivati do dubine 16, a da se nista ne snima na stack.
Razni prozivodjaci imaju razne dodatke u svojim procesorima kojima nastoje ubrzati svoj cip ili mu prosiriti mogucnosti. Ali kao sto rekoh, treba razlikovati te stvari od onoga sto se naziva harvardska arhitektura. U poslednje vreme to vise nije tako lako, jer dolazi sve vise do integracije raznoraznih tehnika u jedan proizvod. Infineo npr. nema ni CISC ni RISC set instrukcija, nego neku mjesavinu koja, kako oni kazu, uzima najbolje od oba svijeta. Ipak se skoro sve instrukcije izvrsavaju u jednom taktu i pored tih CISC petljanija. On ima npr. i Von Neumann-ovu arhitekturu, ali podacima i instrukcijama pristupa istovremeno zato jer ima instruction pipeline. Kad neka instrukcija stigne na red da se izvrsava u procesoru, potrebni operandi za nju su vec odavno ucitani, i ne samo to, vec i nekoliko sledecih instrukcija i njihovi operandi. I sad neko moze reci, to je Von Neumann, instrukcije moraju da cekaju podatke to ne moze biti brze od harvarda. Pa ne moze u sirovoj formi, ali ovdje ima nesto drugo sto mu omogucava da moze, a istovremeno koristi sve prednosti Von Neumann-a (kompaktniji kod i manje rasipanje memorije).
(Navodim primjer na Infenionu jer njega najbolje poznajem, ali sve te stvari postoje i kod ozbiljne konkurencije)

Znaci, vremena se mijenjaju, tehnika se mijenja, o nekim podjelama koje su nekad vazile danas se sve manje moze pricati.

Pozdrav.

Nisam siguran da smo se bas najbolje razumeli. Tacno je da kod 16F serije postoji samo jedan interapt vektor, na programeru je da u interapt rutini snimi sadrzaj vaznih registara, proveri da li je pojedini interapt omogucen i da li je on izazvao interapt, obradi interapt, resetuje interapt flag, vrati sadrzaj vaznih registara i vrati se iz interapt rutine. Ono sto sam ja predlozio je da ono sto se svakako mora uraditi, snimanje, provera idu automatski ako se u programu pojavi procedura za interapt dok bi se procedura tog interapta bavila samo obradom istog (tu se nema sta optimizovati da bi programer morao to svaki put iznova raditi). Ako imamo samo interapt vazan za ADC onda definisemo proceduru za rezervisanom reci int_adc i u okviru nje samo ono sto treba uraditi na pojavu tog interapta. Ako se definise jedna interapt procedura samo se ona proverava, nema potreba proveravati sve. Takodje, moze se uraditi i da korisnik sam definise calokupnu interapt rutinu, recimo koriscenjem rezervisane reci int_user ili neke druge, kada bi se se sve druge int_xxx procedure stavile van snage ili bi kompajler prijavio gresku. E sad ako imamo vise interapta koje obradjujemo redosledom definisanja cemo dobiti koji ce se prvo proveravati (prioritet). Sto se tice ideje oko modula i banaka, ako mislis da ce to ici tako neka bude tako, probaj pa cemo videti kako ce se pokazati u praksi.

To sam i ja mislio dok nisam uporedio sa data sheet-ovima drugih proizvodjaca. Stvar je u tome sto Microchip koristi jeftin marketinski trik u kome pored vremena ulaska u interapt ne stoji referenca na fusnutu u kojoj bi napisali da se pri tom ulasku u interapt nista ne snima automatski na stack (kao kod vecine drugih proizvodjaca). Dok se to pop-uje na stack prosao voz....

Dobro je sto se polako vracamo na temu.

@sander
Ne znam kakva je situacija sa Pic Basicom, ali meni je u PIC16 progamima cesto trebala dvobajtna vrednost. Njenu sintaksu bi najlakse mogli implementirati tako sto se u delu sa definicijama registara definise koliko ce bajtova zauzeti. U relokativnom asemblerskom modu to se radi ovako:
NIZ_BANK1 UDATA 0xA0
godina res .2
duzina res .3
flagovi res .2
sekunde res .1
broj res .4
Na osnovu ovih podataka kompajler bi mogao odmah znati koje je duzine odgovarajuca varijabla. Naravno, svaka postojeca operacija kompajlera (if godina > .2009 (dvobajtna vrednost) then ...; repeat ... until duzina = .2097152 (trobajtna vrednost)) morala bi podrzavati rad sa svim vrednostima (bitskim, jednobajtnim, dvobajtnim, eventualno 3 i 4-bajtnim), sto znaci da ce kompajler morati da sadrzi razne kodove optimizovane bas za taj tip varijabli.
Mislim da je ovo najjednostavnija sintaksa sa polozaja programera. Varijble se definisu samo na jednom mestu, odmah se odredjuje velicina memorije koje zauzimaju, a programer ih koristi kao da su to obicni jednobajtni registri.
Kompajler bi ukoliko programer pokusa uporedjivanje varijabli razlicitog broja bajtova, trebao prijaviti odgovarajucu gresku.

Jos jedan specifican slucaj je testiranje bitova. Kako se u asembleru za to vec koristi ovajanje broja bita od registra obicnim zarezom, mislim da bi programer najjednostavnije koristio ovu sintaksu i za visebajtne varijable. Na primer if W,5 = sekunde,4 then ... za jednobajtne, i if flagovi,3 = flagovi,15 then ... za visebajtne. Naravno trebalo bi odabrati i odgovarajuci izraz za setovane bitove, na primer if flagovi,3 = ON (ili SET) then ...

Znaci, kompajler bi mogao da ima sledece tipove testiranja:
bit definisan nazivom registra, zarezom i rednim brojem bita (pocev od LSB)
bajt definisan nazivom registra
word (dva bajta) definisana nazivom registra, sa tim sto se za njih u definicijama varijabli rezervisu 2 registra
tri bajta definisana nazivom registra, sa tim sto se za njih u definicijama varijabli rezervisu 3 registra
long (4 bajta) definisana nazivom registra, sa tim sto se za njih u definicijama varijabli rezervisu 4 registra

Za testiranje svih ovih tipova kompajler bi morao sadrzati odgovarajuci kod za svaki pojedinacni slucaj. Namerno predlazem nestandardni (za C) oblik varijable od 3 bajta jer bi ceste operacije sa trobajtnim varijablama zauzele manje programske memorije i brzine od cetvorobajtnih, a glavni cilj korakovog kompajlera je sto bolja optimizacija.
Za pocetak, moglo bi se krenuti sa testiranjem samo bitova i celih bajtova, ali bi bilo dobro da korak predvidi i mogucnost eventualne nadogradnje.


@Odin D.

Poznato mi je o cemu pricate (Igrao sam se kao klinac 6510 procesorom Commodora 64) medjutim, rekao sam da se za PIC koristi samo jednu magistrala, (pogresno, slazem se) jer interna struktura PIC-a nije previse bitna za razvoj kompajlera. Koraku je bitno ono sto vidi spolja, a to su svakako samo cetrnaestobitne instrukcije.

Sto se tice gotovih funkcija, Microchip je pored gotovih primera sa projektima predvideo i par AN sa gotovim matematickim funkcijama (u kojima se mogu naci cak i funkcije sa pokretnim zarezom sto je po meni cista perverzija), a koje su upravo namenjene lakoj implementaciji u asemblerskim programima. Nazivi registara definisani su u jednom bloku, i izabrani su tako da budu po nazivu unikatni. Veoma lako se mogu samo iskopirati i ubaciti u odgovarajuci projekat. Precizno su definisane varijable koje trebaju biti dostupne "spolja" za svaku matematicku operaciju, sa primerima njihove primene.

ADC, EEPROM ili RS232 rutine su prilicno jednostavne, i mogu se isto kao i matematicke, veoma lako iskopirati. Za ostale, Microchip je predvideo samostalnu Maestro aplikaciju koja sadrzi sasvim dovoljan broj drajvera, a i na netu se moze naci dosta toga. Bice, naravno tesko sve ovo ubaciti u module, ali mislim da bi vredelo zbog poboljsanja koja bi se dobila mnogo jednostavnijom strukturom jezika.


@korak

Ovako otprilike izgleda standardna interapt rutina za tri interapta:
1. Sacuvaj stanje STATUS i W registra

2. Testiraj flegove i na osnovu njihovog stanja skoci na deo za njihovu obradu (tacke 3, 4 ili 5). Prioriteta nema, iako se mogu definisati unutar ovog koraka (koji fleg ce se prvi testirati).

3. Obrisi fleg1, izvrsi potrebnu operaciju i nastavi od tacke 6

4. Obrisi fleg2, izvrsi potrebnu operaciju i nastavi od tacke 6

5. Obrisi fleg3, izvrsi potrebnu operaciju i nastavi dalje (automatski se nastavlja od tacke 6)

6. Vrati stanje STATUS i W registra

7. retfie (instrukcija za povratak iz interapta)

Ukoliko se bas pogodi da istovremeno nastupe dva (ili vise) interapta, pri prvom pozivu interapta izvrsice se onaj ciji se fleg prvi testira. Onda ce odmah nakon retfie instrukcije nastati sledeci interapt (zbog i dalje setovanog drugog interapt flega) u kome ce se izvrsiti naredni deo. I tako dalje...
Fleg je uvek preporucljivo obrisati odmah na pocetku, kako se ne bi slucajno propustio koji interapt.

Samo da dopunim, dokazano u praksi a i mislim da i microchip tako nesto pominje da kod provere koji je interapt aktiviran ide prvo provera da li je taj interapt omogucen pa tek onda da li je interapt flag za taj interapt aktivan da se ne bi desilo da se obradjuje interapt koji nije omogucen.

To je ipak malo specifican slucaj, i mogao bi se dogoditi jedino da je program tako koncipiran da mu se u jednom delu koristi vise izvora interapta (npr. promenom na RB0 pinu i prekoracenjem tajmera), a da se kasnije jedan od ovih izvora iskljuci.

Zbog cega se to moze dogoditi? Jer se interapt flegovi setuju uvek pri spoljnim uticajima, bez obzira da li je odgovarajuci interapt dozvoljen ili ne. Jedina je razlika sto se onda nece skociti na interapt vektor u slucaju zabranjenog interapta. U tom slucaju, ukoliko je dozvoljen interapt promenom na RB0 pinu, a zabranjen interapt tajmera, prilikom promene na RB0 pinu interapt rutina bi mogla (ukoliko je testiranje flaga tajmera ispred testa RB0 pina - veceg prioriteta) na osnovu flega tajmera zakljuciti da je on izazvao interapt, iako su interapti tajmera ranije zabranjeni.

Problem se moze efikasno resiti kao sto je navedeno prethodnim testom bita dozvole interapta tajmera, ili promenom prioriteta, tako da se uvek najpre testira flag interapta koji se ne iskljucuje u programu.

Da bi se ipak i taj slucaj predvideo, korak bi mogao da interapt proceduru napravi tako da ona jedino snima i vraca sadrzaje registara, a da sve ostalo prepusti programeru.

Jos jedan specifican slucaj predstavlja zabrana svih interapta iz glavnog programa, jer je moguce da ne bude uvek izvrsena, pa je onda potrebno proveriti da li je bit dozvole zaista obrisan, ali to je neka druga prica.

@Stojane

Meni se cini da je u ovom slucaju teznja da se napravi kompajler koji bi trebao sacuvati brzinu asemblera koliko god je to moguce. Koliko ce asemblerski program biti efikasan u najvecoj mjeri zavisi od programerovog umijeca, koje izmedju ostalog podrazumijeva i odredjeno razumijevanje sta se tacno u hardveru zbiva prilikom izvrsenja svake instrukcije. To mu omogucava da ih kombinuje na nacin koji je najoptimalniji. Vec sam ranije na nekoj temi naveo jedan jednostavan primjer (doduse ne za pic) gdje se promjenom redoslijeda naredbi znacajno ubrzava dio koda. Kad covjek radi u asembleru on ima mogucnost da na odredjeni nacin iskoristi neke detalje hardvera ako zna. Ako ne zna, onda nikom nista.
Kada se programski jezik podigne cak i na malo veci nivo od asemblera, programer neminovno gubi kontrolu nad nekim stvarima. Naveden je primjer " if W>50 then..." ili tako nesto slicno. To ce kompajler zamjeniti nizom asemblerskih naredbi, ali je pitanje da li ce taj niz biti optimalan ako se ne poznaju detalji hardvera. Medjutim, primjer nije bas najbolji, bolji je npr. ovaj:
ako ja napisem:

c = a * b;

logicno je da je na programskom jeziku ovog nivoa to isto kao i:

c = b * a;

Medjutim, onaj ko poznaje hardver zna da operacija mnozenja kod 99% procesora nece trajati isto za slucaj

mul 2, 100
i
mul 100, 2

vec se moze razlikovati u trajanju i do npr. 50 puta zavisi koji operand gdje stoji.
I sad ako moj mikrokontroler npr. treba zbog skaliranja da svaku izmjerenju vrednost sa AD konvertora (iz opsega 0 do 256) mnozi npr. sa 2, onda ce meni biti vrlo vazno da li cu napisati "mul AD_conv, 2" ili "mul 2, AD_conv". U jednom slucaju ce mikrokontroler mozda stizati da prebacuje analogni snimljeni zvuk u mp3 u realnom vremenu, a u drugom ce mozda kasniti do neupotrebljivosti. Pitanje je da li ce konstruktor kompajlera voditi o tim detaljima racuna ako ne poznaje detaljno hardver. Naravno, teznja je da ja ne moram svaki put da pregledam generisani asm kod, jer u cemu je onda poenta ovog kompajlera ako opet sve moram da pregledam na nivou obicnog asemblera.

Kvalitativne razlike izmedju razlicitih kompajlera upravo i poticu od toga kako ti kompajleri i koliko efikasno koriste hardver. Meni se desavalo da mi neki programi pisani u C-u ne mogu stati u flash ciljnog mikrokontrolera, a kompajlirani sa kompajlerom drugog proizvodjaca stanu u pola istog flasha.