programski jezici za mikrokontrolere pitanja i odgovori

Stojane, vidim da si zagrejan za podizanje nivoa programiranja na asembleru. Kada sam ja to radio za MC908 prvo sam postavio neke principe kojih cu se drzati:

1. Jezik mora biti sto blizi asembleru, svaki iskaz treba da se prevodi u jednu asemblersku naredbu. Od ovoga se izuzimaju samo neki posebni slucajevi.
2. Nema prevodjenja izraza, svi izrazi su konstantni. To znaci da su svi operandi izraza konstante. Prema ovome, ako se u izrazu nadje varijabla, onda se u konstantnom izrazu ona zamenjuje svojom adresom. Tako izraz GODINA+5 daje adresu varijable GODINA uvecanu za 5. Ako ne bi bilo tako, onda bih usao u vode visih programskih jezika gde bi se sreo sa problemom optimizacije prevoda.
3. Maksimalno izbaciti potrebu za labelama.
4.Uvesti strukture podataka i struktuirati kod.
5. Osloboditi programera svih poslova koje moze da uradi kompajler.

Mozda je najbolje da ti posaljem uputstvo koje sam poceo da pisem. Ono nije zavrseno, niti sredjeno, pa nemoj da zameris. Ako ti je interesantno procitaj ga. U njemu nisam opisao case..of, taj deo sam dodao u verziji uputstva koje pisem kuci.

Ideja sa makroima koji se razlicito ponasaju u odnosu na lokaciju varijable u memoriji i njihovo kasnije objedinjavanje zbirnim makroom je jednostavno odlicna. Sam sam pokusavao izvesti nesto slicno makroima MPLAB asemblera, ali nisam uspeo jer u njemu ne postoji odgovarajuca direktiva za odredjivanje maksimalne vrednosti "SizeOf(a)" parametara.

U relokativnom asemblerskom modu MPLAB-a mogu na primer zadati da se za varijablu GODINA rezervisu dva bajta, ali kasnije uslovnim asembliranjem nema nacina na koji mogu proveriti koliko je bajtova rezervisano. Tako moram koristiti posebne makroe, i pamtiti njihove nazive (interesantno, ali naziv mog makroa za inkrementaciju dvobajtne varijable je incf2b, odnosno, od Vaseg MMA se razlikuje u jednom jedinom slovu).

Isto tako, ukoliko su u makrou definisana tri parametra, sva tri se moraju navesti. U protivnom ce kompajler prijaviti gresku, i nece zavrsiti kompajliranje. Zato ni ne postoji mogucnost testa da li je odredjeni parametar makroa prisutan (kao exist u MMA) ili ne.

Uopste, makroi i direktive originalnog MPLAB asemblera su najslabija strana inace dobrog asemblera. Cak ne postoji nacin unosa visebajtnih vrednosti u makro, osim bajt po bajt. Na srecu, ovo se moze odredjenim (nedokumentovanim) trikovima zaobici, pa je cak moguc i unos labele ili jedne instrukcije kao parametra.


Sajt http://cablemodem.fibertel.com.ar/atferrari/ pod PIC dao mi je ideju o mogucoj upotrebi makroa za testiranje izraza (npr. u IF GODINA < 2008 THEN ili u REPEAT...UNTIL strukturi). Umesto da se deo koda koji ce biti izvrsen u slucaju ispravnog testa ubaci UNUTAR programske strukture (kao incf pa goto instrukcija u dosadasnjim primerima), makro ce u zavisnosti od rezultata testa preskociti (ili ne) sledecu instrukciju. Preskok sledece instrukcije je inace standardan nacin na koji se kod PIC16 serije realizuje grananje. To moze biti lakse za implementaciju u okviru MMA (stavise, mogu se lako napraviti takvi makroi), ali na mestu koje ce biti preskoceno ce se najcesce naci GOTO instrukcija, pa ce takav nacin imati jednu (goto) instrukciju vise, i trajace 3 instrukcijska ciklusa duze (2 zbog GOTO instrukcije i jedan zbog duzeg izvrsavanja preskoka te GOTO instrukcije). Osim toga ostale programske strukture (npr. case of) nece biti moguce lako realizovati na taj nacin. Javite mi da li Vam se takvo resenje cini prihvatljivijim.

Evo na brzinu,
posto 16-tica nema uslovnih granjanja, sem preskoka, moze se uvesti makro za uslovno granjanje, i da se uz pomoc njih ima sve kao i kod 18-tice. Jeste da ce trositi 2 naredbe ali ce funkcionisati. Cak, nisu potrebni ni makroi, moze kompajler to da generise ako se uvedu pseudo naredbe uslovnih granjanja, a sam kompajler ce generisati kod kao i sto bi ga generisao makro namenjen tome.

Na primer (ako ne gresim)

beq labela; //beq je pseudo naredba

bi se prevelo kompajlerom bez problema kao:

btfsc STATUS,Z;
GoTo labela;

Pozdrav.

Ove dve rečenice su u kontradikciji jedna s drugom:

Znači ipak kažeš da postoji način.

Assembler direktno podržava maksimum trobajtne (24bitne) vrednosti:

@korak
U redu. Znaci ubuduce primenjujem takav princip.

@barum
Pazi, stvarno sam prolupao! Medjutim, i u Vasem citatu stoji kljucna rec LABEL. U datasheetu (Assembler/Linker/Librarian User�s Guide) se navodi da oni sluze za prenos sledecih parametara:
section start address
section end address
section size
address
kao i da je upper operand ogranicen na 6 bitova, sto efektno daje 21 bit.

Medjutim, uvek bez problema dobijam svih 24 bitova.

Uopste se ne moze pronaci podatak ili primer da se ovi operandi uopste mogu koristiti za prenos parametara makrou.

Zato je upravo upotreba low, high i upper parametara nedovoljno dokumentovana, jer se eto mogu mnogo prakticnije upotrebljavati i za druge stvari, a ne samo za laksi prelazak strana programske memorije (PAGE) sto im je izgleda osnovna funkcija.

Ipak, moguce je unutar makroa procitrati kompletne 32-bitne parametre, po sledecem:

Pogresio sam kada sam naveo da to (ni prenos labele kao parametra) nije dokumentovano. Ima ga u poglavlju 7 (Macro Language - ko mi je kriv kada retko kada citam priloge). Pre nego sto sam to video koristio sam istu takvu rotaciju, ali nad low, high i upper parametrima.

Ipak, u makro se moze dodati i jedna (ne vise zbog nemogucnosti ubacivanja ENTER karaktera) instrukcija BEZ ZAREZA. Tacnije, moglo bi se ubaciti i vise instrukcija, ali moraju biti odvojene zarezom ili ostalim parametrima. To takodje nije dokumentovano, a moglo bi se iskoristiti.

Nazalost, asembler ima jos mana. Iako je znaci moguce (mada ne i prakticno ispisivati Var >>D'24' & H'FF' bas bi mu falila jedna superupper direktiva) prenositi tridesetdvobitne parametre, iako ih i simulator podrzava, uslovno poredjenje (if direktiva) moze porediti samo oko 28 bitova (nisam tacno proveravao, mozda moze i koji bit vise, ali sigurno ne svih 32 bita).

To znaci da ce uslovno poredjenje ispravno raditi pri
if BROJ == h'F FF FF FF'
ali ne i prilikom
if BROJ == h'FF FF FF FF'.

Naravno i ovo se moze resiti testiranjem trobajtne varijable AND bajta najvece tezine, ali to usporava razvoj programa i cini kod nerazumljivijim nego sto jeste.

Jeste, nacin uvek postoji (ko me uopste tera da koristim makroe), ali ukoliko iziskuje borbu sa asemblerom, cemu sve to.

Ne piše da je upper ograničen već

znači od onog što vrati koriste se samo ovi bitovi u adresnim registrima jer su najviši bitovi neimplementirani u osmobitnjacima.

Piše da služe za prenos navedenih sdresa i to ne isključuje upotrebu ovih operatora za druge potrebe.
U stvari za

treba koristiti operatore sa prefiksima:
scnstart_
scnend_
scnsz_


Da ste proverili sa 32bitnom vrednošću, nešto bi ste saznali o onome ko vam je to rekao.

Direktiva koja fali nije problem:
#define superupper(value) ((value>>D'24') & 0xFF)
i problem rešen.



Hm, otkud to da nema načina?
Evo na primer kako može da se napravi za relokabilni objekt


Jedan makro "to rule them all". :)
a koristio bi se ovako:



ili ako treba veće strukture od 256 bajtova onda
#define SizeOf(var) (((scnsz_high var#v(0)section)<<8) +scnsz_low var#v(0)section)

Edit, za uslovno asembliranje može i samo ovako:





Pozdrav,
Bojan

Cek cek! Za uslovno asembliranje sam sam proveravao! Koliko se secam trebao sam unutar makroa proveriti da li je parametar koji se spolja ubacuje u njega u dozvoljenim granicama, pa sam ga testirao na vrennost 0x00 i na vrednost vecu od 0xFF FF FF FF. Hm ! Pa jeste. Nije ni cudo sto to nisam uspeo proveriti. Za reg > 0xFF FF FF FF bi asembler morao raditi sa vise od 32 bita.

U pravu ste za scnsz_low parametar. Do sada sam (naveden datasheetom i porukom koja se javlja pri koriscenju HIGH operanda u slucaju da je vrednost parametra veca od 0xFFFF) pretpostavljao da deluje jedino nad programskom memorijom. Pa nista. Covek se uci dok je ziv. Hvala Vam sto ste mi prosirili vidike.

@barum
Ne vredi. Ne uspevam ni na koji nacin upotrebiti scnsz_low. Probao sam najjednostavniji moguci slucaj:

i u oba slucaja dobio gresku linkera. Onda sam probao i imenovane code sekcije, pa cak i default imena svih sekcija po linkerskoj skripti i opet nista.
Google mi za upotrebu scnsz_low operacije daje samo dva linka (osim datasheeta). Oba bezvredna.

Ni vas primer sa njom, eto ne radi.

Vas kraci primer (za uslovno asembliranje) naravno radi, ali to nije to. Mogao sam isto tako rucno EQU direktivom definisati velicinu varijable (iako Vas makro za alokaciju svakako ubrzava posao). Ono sto sam svojevremeno hteo je da asembler sam prepozna velicinu odredjene varijable (4 bajta bi bila dovoljna), i da u zavisnosti od velicine rezervisanih bajtova res direktivom uslovnim asembliranjem izvrsavam razlicite kodove (kao primer za inkrementaciju u korakovom kompajleru).

Jeste, moguce je preko EQU, ali opet, Korakov kompajler to po defaultu omogucava, a MPLAB-ov izgleda ne. Upravo zbog toga sam isticao borbu sa asemblerom.

Koristim MPLINK 4.14 pa mi mozda zbog njegove starosti ne radi scnsz_low. Skinucu za par dana novi MPLAB, pa cu probati opet.

Moguće da je verzija u pitanju.
Ja trenutno koristim MPLINK 4.21, 12. Jun 2008., koji stiže sa MPLAB-C18-StudentEdition-v3_21.

Evo u atačmentu i primera koji se kod mene bez greške kompajlira i linkuje.

Edit, evo ovde kažu da 2005 godine isto nije bila naročito nova stvar
http://forum.microchip.com/tm.aspx?m=83637&mpage=1&#83658
i da je on line manual ima još odavno a da nije ubačeno u štampano izdanje (pdf).
I ovaj moj manual (33014J) je iz 2005 godine.
Zanimljivo, gde li im je taj online manual???

Pozdrav svim diskutantima.
Koliko vidim, kolega Korak pravi svoj programski jezik za pic, nesto izmedju asemblera i c. Ako je cilj toga seminarski ili diplomski rad u nekoj skoli/fakultetu to je jako dobro. ako to radi iz cistog hobija i to je jako dobro. ali ako to radi da bi koristio kao alatku za projekte koje naplacuje, to je ekonomski ne opravdano. da bi se napravio asembler (narocito ako ima optimizaciju), linker i simulator potrebno je relativno dosta vremena - recimo da je kolega izvaredan u tome i da ce ceo projekat da zavrsi (zajedno sa testiranjem) za 4 nedelje. to je 150 sati rada. dobar c kompajler se moze kupiti za oko 200-250usd. to znaci da kolega zaradjuje nesto preko 1usd na sat.
jos nesto, danas se jako mali deo koda pise u asembleru. obicno su to rutime za obradu prekida i rutine koje bitno uticu na brzinu rada. razlog za to je opet cena. razviti jedan program u c je mnogo brze nego razviti ga u asembleru, znaci manje kosta.
ja se slazem da je dobro napisan kod u c nesto veci i nesto sporiji od dobro napisanog koda u asembleru. ako kod nije dovoljno brz, jedno od mogucih resenja je uzeti brzi procesor.
u dobra stara vremena kada sam radio u bgd-u i ja sam koristio najjeftinije moguce procesor. razlog za to je bio da je tada rad bio jako jeftin tako da je dodatnih par sati rada na asembleru bilo mnogo jeftinije nego kupovina c kompajlera ili koriscenje brzih, sam tim i skupljih, procesora.
jos dva moguca problema su:
ako kolega korak jednog dana odluci ili bude primoran da portuje svoj kod za procesor drugog proizvodjaca,
ili ako program treba odrzavati ili menjati.

@obrenko,

prerastao sam seminarske radove, diplomske i magistarske, ovo radim kako iz hobija, tako i zbog toga sto nisam jos video dobar asembler. Inace prvi asembler tog tipa sam napisao pre 10 godina za HC11, sada sam ga prepravio za MC908, sto mi nije oduzelo mnogo vremena. Inace, profesionalni C kompajleri ne mogu da se kupe bez par hiljada dolara. To mi je mnogo za jedan tako nesavrsen jezik, bez obzira na njegovu siroku zastupljenost i prenosivost. Nemam potrene za ovim drugim jer koristim samo jednu familiju mikrokontrolera. Naravno bilo bi lepo da mogu koristiti vise familija i da za svaku mogu da odvojim po nekoliko hiljada dolara za razvojni sistem, ali ne mogu.

Osim toga, imam malu firmu koja se bavi proizvodnjom uredjaja sa MCU-ovima, i ja u njoj radim razvoj, a placam usluge drugim firmama koje mi proizvode, pune ozivljavaju, testiraju i asembliraju uredjaje. Tako ispada da imam dosta slobodnog vremena i za ovakve poslove.

Pozdrav.

Pozdrav,

da li si pogledao c kompajler firme CSS (http://www.ccsinfo.com/content.php?page=compilers). Ja sam kupio M verziju (za familiju 16xxx) pre par godina. Cena mu je bila 150usd. radio sam tada neke male projekte za jednu malu firmu. cesto su izbacivali nove proizvode koji su bili bazirani na starim proizvodima. u pocetku sam koristio asembler, a onda sam zakljucio da previse vremena trosim pisuci i modifikujuci kod pa sam presao na c (cisto ekonomski razlozi). Mana kompajlera je sto trosi previse memorije, a dobra strana sto moze da se poveze sa mplab-om i sto znatno ubrzava razvoj program jer ima biblioteke za sve. mislim da imaju demo koji se moze besplatno skinuti (nadam se da imas dovoljno brzu internet vezu).

@obrenko,

nisam. Imao sam prilike da pogledam i testiram Metrowerks CodeWarrior za MC908 i MC9S08, kao i Keil za 8051. Ovaj prvi je ogranicen na generisanje koda od 4KB, a drugi je legalna verzija koju mi je dala neka firma kada sam za nju radio neki projekat. Pogledao sam sajtove proizvodjaca oba C kompajlera. I sta sam video, kao da su podelili trziste, ne postoji ni jedan MCU za koji su obe firme napisale kompajler. Dogovorili se da drze monopol profesionalnih kompajlera i da medjusobno ne konkurisu, zato su im i cene visoke.

Oba kompajlera su po mojoj oceni vrhunska. Optimizacije koje vrse su raznovrsne i slozene. Prevode odjednom vise iskaza optimizujuci kod. Efikasno optimizuju petlje obzirom na brojacku varijablu i t. d.

Ako si pogledao prikaceni fajl, u nekom mom predhodnom odgovoru, koji je nedovrseni uputstvo za asembler koji sam napisao za MC908 mogao si da vidis sta mi je bio cilj. Sa njim radim vec 10 godina (zajedno sa ranijim verzijama) i mislim da sam postigao produktivnost koja se priblizava produktivnosti programiranja u C-u. Mana mu je neprenosivost, ali ja za tim nemam potrebe.

Pozdrav.

Ja mislim da je Motorola vec odavno preuzela Metrowerks, vjerovanto je kasnije potpao pod Freescale kad je doslo do odvajanja, tako da se nije ni cuditi sto ne razvijaju kompajlere za procesore drugih firmi sa kojima je Freescale u konkurenciji.
A Keil je pravio kompajlere za ARM, 8051, XC16x i ST10 procesore, ali cini mi se da je i njih prije par godina kupio ARM, tako da je pitanje sta ce i od njihove proizvodne palete ostati u buducnosti.
Mada, IAR jos ima prilicno sarolik izbor kompajlera:
http://www.iar.com/website1/1.0.1.0/50/1/index.php?

Pogledao sam pazljivije, da u pravu si.
Zahvaljujem.
pozdrav.

Hm! Ipak sam bio u pravu za uslovno asembliranje i maksimalan broj bitova. Danas sam pokusavao da objedinim neke makroe, i naleteo na nelogicnu gresku upravo prilikom uslovnog asembliranja.

Otkrio sam da je nemoguce bilo kakvoj asemblerskoj varijabli testirati 32-bitnu vrednost. Jedino 31-bitnu.

Najpre sam pomislio da je problem do drugacijeg formata zapisa heksadecimalnih brojeva (sa 0x umesto h'), ali greska se reprodukovala i prilikom decimalnih, pa cak i binarnih brojeva.

Onda sam pomislio da bi test uslovnog asembliranja mozda bio moguc dodelom varijable na drugaciji nacin, ali ni to nije pomoglo.

Pokusao sam i da varijabli dodelim dozvoljenu vrednost pa da je saberem sa drugom vrednoscu i tako izazovem prekoracenje 31-bitne granice. Bezuspesno.

Uglavnom, izgleda da je nemoguce u MPLAB-ovom asembleru na bilo koji testirati 32-bitne vrednosti odjednom. Testiranje bi moralo ici preko test (low_high_upper) && superupper.

Varijable ovde nisu problem (njihove vrednosti su ispravno dodeljene sto dokazuje ispravan Var >> D'24' & H'FF' oblik), ali uslovni test eto nije.

Evo testa koji to dokazuje.

Nije greška sa maksimalnim brojem bitova već pretpostavka da su unsigned.
Tip "int" je uobičajeno signed.

Pazi stvarno!

Znaci ako testiram (sa if) jednobajtnu vrednost, ona je unsigned. 2 i 3-bajtna takodje, a samo ako koristim test sa 4 bajta (svih 32 bita) onda je ona signed. E to stvarno nisam ocekivao!

Ovo je nedopustivo za asembler. Unositi predpostavku da je 32-o bitni broj oznacen, u izracunavanju konstantnih izraza, upucuje na to da kompajler izracunava konstantne izraza sa 32-o bitnom tacnoscu. Ja sam u svom kompajleru uveo za izracunavanje konstantnih izraza 64-o bitnu tacnost, bas iz tih razloga.

Medjutim ostaje problem da kada definicete konstantu kompajler mora da joj odredi tip. Ja sam to resio tako da svaki broj bez znaka ima neoznacen tip. No, to ne mora da bude. Na primer:

Konstanta1 = 100;
Konstanta2 = shortint(100);

gde sam uveo eksplicitnu dodelu tipa. Tako i

Konstanta1 = 200000000;
Konstanta2 = longint(200000000);

Konstanta1 je neoznacena, a Konstanta2 oznacena.

Ima u svemu tome puno stvari koje trebaju da se sagledaju pre nego sto pocne da se pise kompajler.

Pozdrav.

Sve vrednosti su istog tipa (int) i kao takve se mogu i videti u SYMBOL TABLE u .lst fajlu.

@korak
"Pretpostavka" nije posebno unesena za asembler, već je jednostavno odraz programskog jezika C u kome je MPASM pisan.