programski jezici za mikrokontrolere pitanja i odgovori

Ogranicicu se pri odgovoru samo na 16F seriju.
Bitovi za selektovanje stranica RAM memorije nalaze se u STATUS registru. Bitovi imaju oznake RP0 i RP1, a njihova binarna kombinacija direktno odredjuje banku RAM memorije po sledecem:

00 - Bank 0
01 - Bank 1
10 - Bank 2
11 - Bank 3

U jednoj banci ne moze biti 256 bajtova, vec maksimalno 128 (0x7F). Ovo ogranicenje proistice od samo 7 bita za adresiranje RAM memorije, a ono je verovatno uvedeno zbog Hardvarske arhitekture instrukcija.

Indirektno adresiranje RAM memorije postoji, ali i za njega je potrebno selektovati odgovarajucu stranu (IRP bitom STATUS registra) po sledecem:

0 - Bank 0 i Bank 1
1 - Bank 2 i Bank 3

Kada sam u proslom postu pominjao tabele mislio sam na tabele sa fiksnim vrednostima koje se cuvaju u flash memoriji. Flash, nazalost nema mogucnost indirektnog adresiranja, vec joj se moze pristupiti jedino preko trinaestobitnog PC (Program Counter) registra, odnosno PCL (bajt manje tezine) i PCH (bajt vece tezine) registara. Pri tome se PCH bajt (jer nije dostupan direktno) updatuje prilikom bilo kakve softverske izmene vrednosti PCL preko PCLATH registra. Naravno, za svako prekoracenje PCL pri koriscenju tabele ili proracunatog skoka (on W goto), mora se updatovati i PCLATH. Otuda toliko muka oko tabela.
Asemblerske instrukcije skoka na cudan nacin koriste PCH. Na primer GOTO k i CALL k koriste k kao adresu skoka, ali je k (opet zbog Harvardske arhitekture) samo desetobitni (a ne trinaestobitni) pa ce sadrzaj PCLATH biti delimicno promenjen (samo donja dva bita) i zato se njima ne moze skociti preko bloka (page) od 2Kb.

U PIC16 seriji se registri ne mogu sacuvati automatski aktiviranjem interapta, vec se sadrzaj (obicno W, STATUS i eventualno PCLATH) registara mora rucno sacuvati pri ulasku i rucno vratiti pre povratka iz interapta. Jos gore, PIC16 serija nema instrukcije citanja i upisa u stek, tako da je za njihovo cuvanje najprakticnije koristiti adrese 0x70 do 0x7F kojima se moze pristupati iz bilo koje banke.
Svakako da su ovi registri (pored interapta) idealni za prenos parametara procedurama, jedini je problem njihov mali broj.


Za INHX8M format pronasao sam sledece sa help-a MPLAB paketa:

Intel Hex Format
This format produces one 8-bit hex file with a low byte, high byte combination. Since each address can only contain 8 bits in this format, all addresses are doubled.

Each data record begins with a 9-character prefix and ends with a 2-character checksum. Each record has the following format:

:BBAAAATTHHHH....HHHCC

where:

BB A two digit hexadecimal byte count representing the number of data bytes that will appear on the line.

AAAA A four digit hexadecimal address representing the starting address of the data record.

TT A two digit record type that will always be '00' except for the end-of-file record, which will be '01'.

HH A two digit hexadecimal data byte, presented in low byte/high byte combinations.

CC A two digit hexadecimal checksum that is the two's complement of the sum of all preceding bytes in the record.


Example: INHX8M
file_name.hex
:1000000000000000000000000000000000000000F0
:0400100000000000EC
:100032000000280040006800A800E800C80028016D
:100042006801A9018901EA01280208026A02BF02C5
:10005200E002E80228036803BF03E803C8030804B8
:1000620008040804030443050306E807E807FF0839
:06007200FF08FF08190A57
:00000001FF

Super,
u nazivu nisam prepoznao intelov format. Nekada sam radio sa njim i poznat mi je. Dobro je sto si me podsetio.
Interrupt automatski stavlja status registar na stek, pa time i bitove za stranicenje. To je OK. Sta je sa PIC-ovima koji imaju veci RAM i vise stranica. Cini mi se da oni imaju poseban registar za stranicenje. Da li se i ovaj registar stavlja automatski na stek ili se to mora softverski uraditi. Nisam razumeo pravi razlog zasto je stranica ogranicena na 128 bajta.

0x70 do 0x7F je moze da bude dovoljno za prenos parametara, jer bi se duzi podaci prenosili preko pointera koji ukazuje na njih. Ali, moram da vidim koliko je komplikovano PIC-u da radi sa pointerima.

Nezgodno je sto GoTo i CALL nisu relativni skokovi (-1K, +1K) vec apsolutni u okviru istog bloka od 2KB.

No, sada imam malo vremena pa cu pogledati sve ovo detaljnije i prezentiracu neke predloge tebi i drugima na ocenu izvodljivosti.

Veliko hvala.

Ne, interapt ne cuva STATUS (ni ostale registre) automatski niti (bar u 16F seriji) ih moze sacuvati na steku, vec se za njihovo cuvanje i povracaj uglavnom primenjuje sledeci kod:



On se samo iskopira, i to je to. Cela filozofija. Interapti ni ne mogu predstavljati problem (osim ako njihov kod nije duzi od 2Kb) jer se uglavnom stavljaju na pocetku memorije, a pocetak glavnog programa pocinje nakon njihovog kraja.
16F serija ima samo dve specijalne flash adrese, a to su reset vektor (adresa 0x00) i interapt vektor (0x04). Uglavnom se odmah od pocetka interapt vektora postavlja interapt rutina, a na njenom kraju nadovezuje se glavni program. To izgleda otprilike ovako:



Cela 16F serija uopste nema instrukcija za pristup steku. On se spolja ne moze videti, a koriste ga jedino interapt i CALL instrukcija (i naravno, odgovarajuce instrukcije povratka) za cuvanje adrese povratka. 16F serija ima samo 8 nivoa steka.

Harvardski set instrukcija podrazumeva da se unutar instrukcije nalazi kod instrukcije (po kome se CALL instrukcija razlikuje od GOTO), i operand sa kojim se radi (adresa, registar, bajt, bit, odrediste rezultata). Postoje i instrukcije sa vise operanda.

CALL instrukcija izgledala bi ovako:
kod . . operand - apsolutna adresa skoka
100 . kkkkkkkkkkk

Od GOTO instrukcije ona se razlikuje jedino po kodu instrukcije koji je za GOTO 101

Instrukcija povratka iz potprograma RETURN koja nema ikakav operand izgleda ovako:
. . . . kod
00000000001000

Instrukcija za brisanje registra CLRF (upis vrednosti 0x00) izgleda ovako:
. kod . . . operand - RAM adresa
000001 . . fffffff

Ono sto je svim instrukcijama zajednicko je fiksna duzina instrukcija (14 bitova). Kako su za kod CALL i GOTO instrukcija utrosena 3 bita, ostaje ih samo 11 za adresiranje apsolutne adrese. 11 bitova = 2Kb. Sve sto prelazi ovakvu stranicu (Program Counter je trinaestobitni, pa moze adresirati do 8Kb flasha sto je maksimum za 16F seriju) mora updatovati PCH preko PCLATH registra.

Ukoliko se pogleda CLRF instrukcija, primecuje se da je kod instrukcije zauzeo 7 bitova, tako da ih je ostalo samo 7 za adresiranje RAM memorije. 7 bitova = 128 bajtova. Sve preko toga resava se preko banaka (4 banaka * 128 bajtova je maksimalna RAM memorija za 16F seriju).


Za pointere unutar RAM memorije najprakticnije je koristiti njeno indirektno adresiranje. Medjutim, tu veliko ogranicenje predatavljaju banke, jer se RAM ne moze samo tako nadovezati iz jedne u drugu banku. Ovo ogranicenje postoji jer je unutar svake banke pocetni deo (0x00 - 0x1F ili 0x00 - 0x0B u zavisnosti od tipa mikrokontrolera) svake banke rezervisan za registre specijalne namene. Kako se njima direktno upravlja integrisanim hardverskim modulima, kompajler bi za pointere morao ili koristiti neprekidan RAM unutar jedne banke (najbrzi i najoptimizovaniji metod), ili koristiti komplikovanije procedure za virtuelno spajanje ovako izdeljene RAM memorije.

Jos jedna stvar koja je nezgodna kod PIC16 serije je upotreba instrukcija grananja. Naime, one preskacu narednu instrukciju (samo narednu instrukciju, nema relativnog +- skoka) u slucaju da je odgovarajuci uslov ispunjen. To se pak moze resiti upotrebom dve GOTO instrukcije odmah nakon instrukcija grananja, a jos bolje bi bilo da kompajler prepozna ovu situaciju i da u cilju bolje optimizacije koda stavi samo jednu GOTO instrukciju (neposredno nakon instrukcije grananja - onu koja ce biti preskocena ako je uslov ispunjen) i da odmah nakon nje nastavi sa drugim delom (koji se izvrsava ukoliko je uslov ispunjen).

<sub>[Ovu poruku je menjao Stojan Trifunovic dana 24.07.2008. u 23:06 GMT+1]

[Ovu poruku je menjao Stojan Trifunovic dana 24.07.2008. u 23:13 GMT+1]</sub>

U principu 16F serija ima prilicna ogranicenja u poredjenju sa trenutno aktuelnim kontrolerima sto je razumljivo jer tada kada se pojavila potrebe su bile manje tako da ogranicenja nisu smetala. Mnoge stvari su ispravljene 18F serijom ali verovatno zbog kompatibilnosti su ponesto i ostavili za kasnije serije 24F i 32bit serije. Elem, posto je bilo prica o 16F seriji rekoh da malo nesto kazemo i o 18F seriji. Dakle, kod 18F serije takodje RAM memorija je podeljena u banke i to u 16 (0-15) banaka po 256b ali su sve SFR registre postavili u gornjih 128b u poslednjoj 15 banci i kojima se moze pristupati direktno bez potrebe da se dira registar za selekciju banaka BSR. Kako? Ram memoriji se moze pristupati ili preko vec pomenutog BSR registra (selekcija banke) ili koriscenjem Access bank-e tako sto se u instrukciji za pristup naznaci nacin pristupa. Access ram omogucava da se pristupi prvoj polovini banke 0 i drugoj polovini banke 15 bez obzira na stanje BSR registra. Recimo:

movwf f,a - sadrzaj W registra ce se upisati u registar f uz selekciju banke preko BSR registra ako je a=1 odnosno preko access ram-a ako je a=0

Ovim je postignuto da je pristup SFR registrima omoguceno bez dodatnih instrukcija za selekciju banke. Recimo za poredjenje, kod 18F serije se bez preklapanja banaka moze pristupati prvoj polovini banke 0, celoj jednoj banci (1-14) i SFR registrima odnosno nesto vise od cele ram memorije kod 16F serije (384b naspram 368b). Sama selekcija banke je takodje dozivela izmene i sada postoji posebna instrukcija za to:

movlb k - postavlja sadrzaj BSR registra

Dodata je i instrukcija

movff fs,fd - sadrzaj fs registra (12-bitn adresa) kopira u registar fd (12-bit adresa)

Takodje unapredjeno je indirektno adresiranje tako sto FSR registri sadrze 12-bit adresu sto znaci da preko indirektnog adresiranja pristupamo celokupnom memoriskom prostoru bez selekcije banaka. Da stvar bude jos bolja postoje 3 FSR registra: FSR0, FSR1 i FSR2 sa pripadajucim INDF registrma: INDF0, INDF1 i INDF2. To nije i poslednja inovacija kod indirektnog adresiranja, koriscenjem registra POSTINC0, POSTDEC0, PREINC0 i PLUSW0 moguce je pristupiti adresi u FSR-u i po pristupu uvecati/umanjiti adresu ili pre pristupa adresi, adresu uvecati ili joj dodati vrednost u W registru. Dodata je i dodatna instrukcija za upis u FSR registre:

lfsr f,k- u FSR registar f upisuje 12-bit adresu

Stek je takodje doziveo izmene i sada 32 byte veliki sa mogucnoscu da automatski snimi sadrzaj bitnih registara kod interapta (fast stack).

Kao sto vidimo 18F serija je dozivela prilicna poboljsanja u radu sa ram (data) memorijom i nije ni cudo sto je microchip tvrdi da je arhitektura/instrukcije prilagodjene C jeziku.

Cini se da je bolje praviti odmah kompajler za 18F, sa tim sto bi na neki nacin u izvornom tekstu bilo oznaceno da li se koristi 16F ili 18F. Ako se koristi 16F, a pisu se neke naredbe koje ima samo 18F, kompajler ce prijaviti gresku.

Takodje je moguce da kada se napise GoTo ili Call da kompajler vidi koliko je udaljen skok, i ako je on u okviru dozvolenog bloka generise samo naredbu skoka ili poziv procedure. Ako to nije slucaj, on ce dodati i azuriranje registra PCLATH pra skoka.

Ali sta sa uslovnom naredbon skip, koliko, i kako je to definisano, naredbi ona preskace. Predpostavljam da uvek preskace samo jedni. Da li je do tako?

Deklaracija varijabli bi moglabiti ovakva:

var bank 0
lista varijabli

var bank 1
lista varijabli

i tako redom koliko ima varijabli i raspolozivih banaka. Imenu varijable bi bili pridruzeni adresa u banci i broj banke. Ovo bi omogucilo programeru da varijable koje ucestvuju medjusobno u nekim operacijama budu u istim bankama kako bi bilo sto manje preklaoanja banaka.

Ako bi deklaracija bila

var
lista varijabli

onda bi one bile kontinualno rasporedjene i prelazile bi iz banke u banki, sto nije prakticno.

Sinoc sam pogledao seriju 16F, i modul za generisanje koda bi bio dosta jednostavniji u odnosu na MC908 koji ima vose naredbi i 13 adresnih modova.

Cini se da bi izmena bila relativno jadnostavna, ali za to ce mi trebati nesto slobodnog vremena od oko mesec dana zajedno sa testiranjem.

Ovde sam postavio neka pitanja, pa molim da mi odgovorite na njih. Ja cu veceras da pogledam i seriju 18F pa cu izvuci ono sto je razlicito od 16F.

Pozdrav.

Jeste, 18F serija je svakako mocnija, ali bi zahtevala dosta vise rada na kompajleru zbog vise instrukcija i vise adresnih modova.

To za CALL i GOTO je odlicno resenje. Tako programer uopste ne bi brinuo o navedenom problemu. Isto bi se moglo uraditi i za ON W GOTO i za tabele iz flasha (oba nacina koriste skok direktnom izmenom PCL).

Da, uslovna naredba skip (na primer btfss STATUS,Z) preskace samo jednu naredbu (sledecu) ukoliko je uslov ispunjen. U ovom slucaju preskocice sledecu instrukciju ukoliko je Zero flag setovan. Bitno je napomenuti da BTFSS instrukcija ne testira samo Zero flag, vec bilo koji bit unutar bilo kog registra. Slobodno se moze pisati btfss MOJ_REGISTAR,BIT_UNUTAR_REGISTRA.

Oblik ove instrukcije u programu je sledeci:


ili kraci (i optimizovaniji) oblik:


Predlog za deklaraciju varijabli je dobar, sa tim sto bi kompajler morao unapred znati adresu pocetka varijabli (0x0C ili 0x20 u zavisnosti od tipa PIC-a) kako ne bi presao preko registara specijalne namene.

Mislim da bi najprakticnije bilo na pocetku odredjenom direktivom staviti oznaku mikrokontrolera (MPASM asembler za ovo koristi "list pF84" direktivu), a da onda kompajler na osnovu tipa mikrokontrolera (16F ili 18F) odabere set instrukcija, a na osnovu njegove dodatne oznake (84, 872, 877...) odabere podrzane hardverske module i raspored adresa za njihovo upravljanje.

Da, sto se tice razlikovanja 16F i 18F to se mora uraditi zbog prosirenog seta naredbi kod 18F. Bitno je da svi 16F i 18F imaju u okviru svoje podfamilije iste instrukcije. Da li je tako?

Sto se tice ostalog, volim da je sve eksplicitno u izvornom tekstu programa. Sta ako izadje neki novi tip, onda treba apdejt.

Zato bi moglo:

var [0x20..0x7F]
lista varijabli

var [0xA0..0xEF]
lista varijabli

i t. d.

i programer bi, znajuci kakve banke ima mogao za svaki tip PIC- da pravi korektnu deklaraciju

Slicno bi bilo i za kod programa. Kod mene sada postoji:

code[pocetak..kraj]; gde ja upisujem prema tipu MCU-a ove dve vrednosti. Generisanje koda pocinje od 'pocetak'.

Sta mislite o ovome?

Pozdrav.

Asembleski program sa 16F serije se bez dorade moze izvrsavati na 18F seriji s tim da se u programu izbace delovi za selekciju banaka (16F877 i 18F452). Licno sam prisustvovao demonstraciji od strane predavaca na Microchip-ovom seminaru u Beogradu. Prosireni set instrukcija mu dodje samo kao optimizacija odnosno poboljsanje perfomansi/brzine. Recimo, 18F serija ima dodatne instrukcije za grananje:

bc n
bn n
bnc n
bnn n
bnov n
bnz n
bov n
bra n
bz n

koje se mogu postici i preko:

btfsc STATUS,b

ili

btfss STATUS,b

ali im je vreme izvrsavanja krace. Isto tako snimanje sadrzaja vaznih registara priliom opsluzivanja interapt rutine se moze izvesti
kao i kod 16F serije, istim instrukcijama, ili automatski koriscenjem fast registar stack-a.
Znaci da kompajler moze proizvoditi kod i za 18F seriju isto kao i za 16F bez optimizacije ili uz naznaku o tipu mikrokontrolera da radi optimizaciju.
Sto se tice instrukciskog seta on je isti za celu seriju mikrokontrolera, razlika je jedino u periferijama.
C kompajler koji koristim sam dodeljuje memoriske lokacije varijablama ali je takodje moguce varijabli dodeliti fiksnu adresu, mozda bi i o tome trebalo razmisliti.

Jeste. Cela 16F i 18F familija ima u okviru svoje podfamilije potpuno iste instrukcije.

Deklaracija varijabli moze biti takva (iako zahteva da programer bar pri prvom programu za taj tip PIC-a pogleda u datasheetu konkretne podatke), ali ukoliko vec ne zelite (zbog novih podfamilija PIC) da im definisete parametre unutar kompajlera, morali bi u kompajleru predvideti mogucnost definisanja perifernih modula i konfiguracionih bitova koji se koriste bas za taj tip PIC-a. To je pak, malo veci posao. Evo sta se sve treba definisati pre pocetka programa:

Pre svega periferni moduli. Pic16 serija ima sledece:

1. General purpose I/O Revision �DS31009A�
2. Timer0 Revision �DS31011A�
3. Timer1 Revision �DS31012A�
4. Timer2 Revision �DS31013A�
5. Capture, Compare, and PWM (CCP) Revision �DS31014A�
6. Synchronous Serial Port (SSP) Revision �DS31015A�
7. Basic Synchronous Serial Port (SSP) Revision �DS31016A�
8. Master Synchronous Serial Port (MSSP) Revision �DS31017A�
9. USART (SCI) Revision �DS31018A�
10. Voltage References Revision �DS31019A�
11. Comparators Revision �DS31020A�
12. 8-bit Analog to Digital (A/D) Revision �DS31021A�
13. Basic 8-bit Analog to Digital (A/D) Revision �DS31022A�
14. 10-bit Analog to Digital (A/D) Revision �DS31023A�
15. Slope Analog to Digital (A/D) w/ Thermister Revision �DS31024A�
16. Liquid Crystal Display (LCD) Drivers Revision �DS31025A�
17. Parallel Slave Port (PSP) Revision �DS31010A�

sa tim sto i unutar njih ima izmena, izazvanih verovatno nedovoljnim brojem pinova. Na primer ima PIC-eva koji podrzavaju jedino PORTA i PORTB, a ima i onih koji podrzavaju i ostale.

Onda konfiguracioni bitovi:

CP1:CP0: Code Protection bits
11 = Code protection off
10 = See device data sheet
01 = See device data sheet
00 = All memory is code protected
Note: Some devices may use more or less bits to determine the code protect. Presently
there are also some devices that use only one bit (CP0). For these devices the bit
description is:
1 = Code protection off
0 = Code protection on

DP: Data EEPROM Memory Code Protection bit
1 = Code protection off
0 = Data EEPROM Memory is code protected
Note: This bit is used when a device with ROM program memory also has Data EEPROM
memory.

BODEN: Brown-out Reset Enable bit
1 = BOR enabled
0 = BOR disabled
Note: Enabling Brown-out Reset automatically enables the Power-up Timer (PWRT)
regardless of the value of bit PWRTE. Ensure the Power-up Timer is enabled anytime
Brown-out Reset is enabled.

PWRTE: Power-up Timer Enable bit
1 = PWRT disabled
0 = PWRT enabled
Note 1: Enabling Brown-out Reset automatically enables Power-up Timer (PWRT) regardless
of the value of bit PWRTE. Ensure the Power-up Timer is enabled anytime
Brown-out Reset is enabled.
Note 2: Some original PICmicros have the polarity of this bit reversed.

MCLRE: MCLR Pin Function Select bit
1 = Pin�s function is MCLR
0 = Pin�s function is as a digital I/O. MCLR is internally tied to VDD.

WDTE: Watchdog Timer Enable bit
1 = WDT enabled
0 = WDT disabled

FOSC1:FOSC0: Oscillator Selection bits
11 = RC oscillator
10 = HS oscillator
01 = XT oscillator
00 = LP oscillator

FOSC2:FOSC0: Oscillator Selection bits
111 = EXTRC oscillator, with CLKOUT
110 = EXTRC oscillator
101 = INTRC oscillator, with CLKOUT
100 = INTRC oscillator
011 = Reserved
010 = HS oscillator
001 = XT oscillator
000 = LP oscillator

Mislim da bi bilo previse zahtevati od programera da definise svaki od ovih podataka za svaki novi program. Morala bi se predvideti mogucnost standardnog zaglavlja sa svim potrebnim definicijama, pa makar se one prenosile u nove programe copy/paste metodom.

MPLAB asembler sve potrebne definicije cuva unutar standardnog eksternog fajla, koji se u program ubacuje posebnom direktivom (#include <p16F84.inc>). Licno, ne smatram ovakav pristup dobrim, jer otezava programeru razvoj svog stila programiranja (zbog cega PORTA ne bi mogao biti PortA ili A). Vidjao sam npr. zamenu "STATUS,Z" sa "_Z" sto sigurno ubrzava razvoj programa. Ukoliko bi sve potrebne definicije zajedno sa programom bile unutar jednog fajla, kompajler ne bi trazio njegovu definiciju na dva mesta (u p16f84.inc i u program.asm fajlu), vec jedino unutar jednog jedinog .asm fajla. Osim toga, od programera ne bi bilo ista "skriveno".

Kako dobar deo programera (po inerciji i zbog lose snabdevenosti nasih dobavljaca) koristi samo par tipova PIC-a iz cele familije, ne verujem da bi copy/paste metod bio previse komplikovan. Ukoliko vec krenu sa nekim "egzoticnim" (nepoznatim) tipom PIC-a, mogli bi mu sami prilagoditi definicije.

Hvala, na trudu da me sto vise uvedete u materiju.

Sve je OK, ali ja ne volim mnogo 'pametne' programe sa mostvom prozora u kojima svasta podesavam da bi onda komapajler to uzimao u obzir. Kada odstampam izvorni kod ta setovanja se ne vide, pa cak i kada ga citam sa monitora, moram da otvaram prozore da vidim sta je kako definisano. Osim toga, sve takve definicije treba snimiti i vezati za odradjeni projekat. Ja sam pristalica da se sve definicije vide u izvornom tekstu programa i da su na dohvat ruke programera. Moze se stvar olaksati, da se sve to ne pise uvek kada se radi sa istim tipom PIC-a, ako se one smeste u modulu (ne include) gde mogu biti definisane po zelji programera. Taj modul bi bio uklucen na pocetku (pre svih modula) glavnog modula. To ne smatram velikim problemom, narocito zato sto onaj koji se opredelio za asembler, taj sigurno zna anatomiju PIC-a koji koristi. Znam da C kompajleri imaju pristup takav de se sve setuje samim izborom tipa MCU-a. Ako imate legalnu verziju softvera, uvek mozete da apdejtujete svoj kompajler za novi MCU. Ja ne zelim da programer stalno zavisi od proizvodjaca kompajlera. Kada ga jednom nabavi on treba da mu je koristan i za novu tipove MCU-a.

Juce sam razmisljao o jednoj stvari koja mi se cini vaznom. Mislim da su ceste greske kada u asenbleru nehotice upotrebite neku varijablu a pri tome niste prekopcali banku za nju. Da li se varam? Pokusavao sam da nadjem resenje da se to ne dogadja i da obezbedim mehanizam da tu kontrolu drzi kompajler. Evo sta mi je palo napamet:

Napraviti strukturu:

SetBank n do <naradna>;

ili

SetBank n do
begin
lista naredbi;
end;

Lista naredbi bi koristila varijable samo iz banke n. Kompajler bi vodio racuna da se u ovoj strukturi koriste samo takve naredbe, a za one iz druge banke bi prijavio gresku. Ako se koriste vise banaka, na primer dve onda bi bilo:

SetBank n do
begin
lista naredbi; //varijable iz banke n

SetBank m do
begin
lista neredbi; //varijable iz banke m
end;

lista naredbi; //varijable iz banke n
end;

Umesto n i m moze se koristiti preddefinisana funkcija BankOf(imeVar) cime ne morate da pamtite u kojoj je banci koja varijabla. Na ovaj nacin kompajler sa SetBank ukljucuje novu banku, a pamti predhodno setovanu banku. Kada naidje na end svoje strukture, on ukljucuje ponovo predhodno setovanu banku. Mali problem se javlja kada se iz SetBank..do strukture skoci negde, onda kompajler gubi evidenciju o aktuelnoj banci. Zato treba asembler da ima sve strukture (if..then..else, repeat..until, whilr..do, case..of i t. d.) kako bi postala nepotrebna naredba skoka.

Interesuje me sta se desava sa bank registrom (pa cak kada je on i u STATUS registru) kada se pozivaju procedure. Mislim da je ovo sa bankama najvaznije pitanje za pouzdano pisanje softvera jer PIC nema kontinualan memorijski prostor.

Sta mislite o ovome.

Pozdrav.

Vezano za varijable koje su definisane u ram-u. Ako kod definicije upotrebimo 10-bitnu adresu (16F) koja se sastoji iz 2bit za selekciju banke i 8 bitne adrese registra kompajler bi uvek znao da kada pristupa toj varijabli u kojoj se banci nalazi. Ovim bi se omogucilo i da se urade i "include" moduli sa definicijama specificnim za pojedine kontrolere. Recimo nesto kao:

var Port_A: byte @0x005 sto bi znacilo da smo definisali varijablu Port_A na lokaciji 0x05 u banci 0 koja bi ustvari bila na istoj lokaciji registra PORTA

ili

var Tris_A: byte @0x105 sto bi znacilo da smo definisali varijablu Tris_A na lokaciji 0x05 ali u banci 1 koja je na istoj lokaciji TRISA registra.

ili mozda za bit promenljive:

var RA0: boolen @ 0x005,0

da bi kasnije u programu mogli da napisemo:

Port_A:=0;
Tris_A:=0b11111111;

a kompajler bi automatski postavi0 kod za selekciju banke i pristupio varijabli:

bcf STATUS,RP0
bcf STATUS,RP1
movlw 0
movwf 5

Da, ali kompajler nezna koja je stranica trenutno ukljucena i da li treba da je promeni. To je razlog mog predloga.

Za postavljanje varijabli na apsolutnim adresama je obicno:

var
Port_A: byte absolute 0x005
Tris_A: byte absolute 0x105

ovo drugo ne treba tako. Tris_A treba da ima apsolutnu adresa, a kompajler zavisno od tipa PIC-a (velicine stranice) odradjuje broj stranice. Dakle ako je stranica po 128 bajta, treba:

Tris_A: byte absolute 0x85

a kompajler ce da izracuna od 0x85 = 133 sledece 133 div 128 = 1 prva banka, i 133 mod 128 = 5 adresa u banci. Mislim da je ovo konciznije sa aspekta buducih komplikacija.

Pozdrav.

Pauza do ponedeljka.

Da upravu si, zanemario sam da banka nema 256 nago 128 b kod 16F serije.
A sto se tice banke mislim da ce morati uvek selekcija banke sem kod nekih racunskih operacija kad kompajler rezervise deo memorije za to i ne izlazi iz odredjene banke, svako testiranje koja je banka aktivna bi samo usporavala rad.
Ako se secate polemike oko snage pojedinih tipova kontrolera zato sam i insistirao da se pod PIC-em ne podrazumeva 16F, tek kada se otkriju unapredjenja koja 18F serija donosi vidljivo je da je razlika izmedju ove dve serije sto se brzine tice prilicna a kamoli poredjenje sa novijim serijama.

Da potpuni se slazem, treba ici na 18F kao osnovni, a da usput podrzava i 16F.

Pogledaj moj predlog za rad sa bankama, sta mislis o tome?

Pozdrav.

Korak, dobar Vam je pristup. I mene nervira podesavanje po vise fajlova i navigacija po prozorima. Nisam najbolje shvatio sta podrazumevate pod modulima, ali pretpostavljam da ce za nov projekat sa istim PIC i podesavanjima biti dovoljno samo iskopirati modul unutar .asm fajla. Sasvim dovoljno i potpuno pregledno.

MPLAB asembler vec ima "banksel" direktivu koja ce postaviti odgovarajucu banku kada joj se doda ime registra (npr. "banksel TRISA").
Ipak, priznajem da bi bilo zgodnije kada bi kompajler brinuo o ovome. Realno, programer ni ne treba znati gde mu se nalazi koja varijabla, pa samim tim ni u kojoj je banci. Pretpostavljam da bi kompajler mogao da na osnovu liste naredbi unutar:

odredi koji se sve registri tu koriste (opste namene za koje je svejedno, specijalne namene koji su mapirani u svim bankama za koje je takodje svejedno ili pak specijalne namene mapirane samo u odredjenim bankama) i da na osnovu rezultata odredi u koju bi banku bilo najprakticnije staviti koje varijable, kako bi bile optimalno grupisane.

Skok bi sigurno predstavljao problem, ali za sada ne vidim nacina kako bi se mogao resiti, osim kao sto je korak naponenuo strukturom programa koja bi skokove (GOTO) ucinila suvisnim.

U principu raspored registara specijalne namene je takav da se najveci broj uobicajenih operacija moze izvesti unutar banke 0, dok se registri u ostalim bankama dosta redje koriste (uglavnom prilikom pocetne inicijalizacije mikrokontrolera). Tako je moguce koristiti ostale banke jedino u slucajevima kada je to (zbog malo RAM-a u banci 0) neophodno, odnosno ukoliko kompajler proceni da je to neophodno. Svakako bi gore navedeno grupisanje varijabli unutar procedura dodatno olaksalo procenu kompajleru.

Bitovi za odredjivanje banke unutar STATUS registra ostaju onakvi kakvi su bili pre skoka. Znaci, program ce ostati u istoj banci u kojoj je i bio. Skokom se menja jedino Program Counter, a on ne utice na RAM niti na flagove STATUS registra, pa samim tim ni na promenu trenutne banke.

Vidim da se povela prica oko banki, pa da dodam i ja poneku, iako mozda ne bas konstruktivnu rijec.
Dosad vidjeni predlozi zvuce zanimljivo, medjutim meni se cini da je od toga slaba vajda. Logicki posmatrano, gdje god se u programu nalazi neko grananje, to je zato sto se u vrijeme kompajliranja ne moze znati kojim putem ce da krene program u vrijem izvrsavanja, inace grananje ne bi ni bilo potrebno ako bi unapred znali kojim tokom ce program da krene. To znaci da se svejedno prije pristupa bilo kojoj varijabli mora izvrsiti prebacivanje na odgovarajucu banku, odnosno ako se to prepusti kompajleru on mora ispred svake varijable dodati "switching" na odgovarajucu banku, cime se ne dobija nista, a dosta se gubi ako se u ubzir uzme koliko razno raznih interrupt-a i grananja moze da bude u prosjecnoj mikrokontrolerskoj aplikaciji. Napraviti algoritam optimizacije rasporeda tih varijabli po bankama za prosjecno komplikovan mikrokontrolerski program bi bio prilicno zametan posao sa sumnjivim rezultatima (meni vec pada na pamet xx uobicajenih slucajeva gdje nikakva optimizacija ne bi pomogla). Za uspjesnu optimizaciju svega toga bilo bi potrebno i znati sa kojom ucestanoscu (ili vjerovatnocom) ce se neki interupt ili funkcija pozivati i sl. a to kompajler ne moze znati osim ako mu programer ne naznaci, a najcesce ne zna ni programer tacno i tako sve u krug. A ako programer mora i o svemu tome da misli, onda u cemu je smisao toga? Imacemo kompajler koji dobro kompajlira samo sto programer dolazi uvece kuci cetvoronoske. Zatim, za uspjesnu optimizaciju trebalo bi koristiti uvijek neki mikrokontroler koji je najmanje 100-200% jaci od minimalno potrebnog kako bi se raspored varijabli mogao optimalno rasporedjivati po bankama, sto bas i nije neki veseo uslov.
Kada bi se taj problem sa bankama kod PIC-a mogao elegantno zaobici, onda to, jel'te, ne bi ni bio neki problem da se oko njega dize tolika prasina. Valjda bi ga i sam proizvodjac vec nekako rjesio ili bar pokusao da rjesi.

Na kraju se sve svede na to da se kolicina razmisljanja kod programera po tom pitanju ne moze smanjiti. Mozete promjeniti nacin na koji se to radi u odnosu na trenutnu situaciju, ali tesko da ce se nesto olaksati.
I meni pada na pamet, onako na prvu loptu, sijaset razno-raznih "rjesenja" tog problema, medjutim cim se to malo izanalizira dolazi se do onoga sto sam vec rekao: moze se napraviti da se drugacije radi, ali tesko da ce se postici da se manje radi.
Infromacija rezolucije 1 bita (banka 0 ili 1) ne moze se predstaviti sa pola bita. To sto se tonski zapis od 50MB moze sabiti u 3-4MB je samo zato sto nase usi ne cuju vecinu toga iz zapisa od 50MB, ali u programu mikrokontrolera nema informacija koje se mogu zanemariti. Tako bar kaze moja logika.

Ako se neko upusti u pokusaj realizacije ovog neizvjesnog poduhvata, u svakom slucaju trebalo bi prvo dobro da izanalizira sta ga ceka, prije nego izgubi suvise vremena da bi shvatio da je sve bilo uzalud. U svakom slucaju, ako neko ima problema sa matematickom analizom izvodjivosti ovog zadatka, moze da uzme neki uobicajeni program od 2-3 hiljade linija pa da samo za taj konkretan program proba da izvrsi tu optimizaciju banki, pa kad vidi kako bi to islo, onda da vidi da li moze da napise logiku za opsti slucaj i sa kakvim rezultatima.

O komercijalnoj stvari svega toga ne treba ni diskutovati: prvo se treba zapitati ko ce to htjeti kod nas da kupi, kad se uzme u obzir da vecina ljudi koji koriste PIC upravo ga i koriste zbog toga sto se tesko masaju za dzep. A ako razmisljate o firmama kao musterijama, pa mislim da su vam sanse priblizno jednake da ih ubjedite da koriste vas kompajler tome da ih ubjedite da koriste vas operativni sistem umjesto Windowsa ili UNIX-a npr. A u vecini slucajeva jedini kupci i jesu firme. Skoro sam gledao cijene nekih C++ kompajlera i cifre su 5-6 hiljada evra. Mislim da ce 99% hoby korisnika radije da radi na industrijski priznatom kompajleru od 5-6 hiljda evra koga je dzaba skinuo sa rapidshare-a, nego da kupi neki legalan relativno nepoznat kompajler za bilo koliku malu sumu.

No, nedajte da vas obeshrabri moje glediste, ja to zbog toga sto mi bude zao koliko se nekad vremena potrosi na nista, a moglo je za to vreme da se napravi nesto (drugo). Valjda zato sto sam ja uvijek u nedostatku sa vremenom....

Izvinjavam se na ovoj digresiji koja je skrenula malo sa teme, ali mozda nekom moze biti od koristi....
Pozdrav svima.

Ako znate istoriju nastanka PIC-a onda ce vam biti jasno da proizvodjac nije mogao da resi problem sa bankama, jednostavno PIC se rodio sa bankama i to mu je karakteristika. To je zrtva Harvard strukturi koja nema dovoljno siroku magistralu prema flash-u.

Ja sam napravio razvojni sistem koji je na nivou asemblera (i ima njegovu snagu), a po efikasnosti pisanja softvera se priblizava C-u. Nije mi cilj nikoga da ubedjujem u to, jednostavno diskutujemo. Ako sam ja sa tako definisanim jezikom napisao vise stotina hiljada linija pouzdanog softvera koji radi u nekoliko desedina uredjaja, onda to predstavlja neku vrednost.

Da se vratimo bankama. Opsti cilj je da sve ono sto programer ne mora da radi, i nije do programskog zadatka, radi kompajler. Tako programeru ostaje koncentracija na pisanje softvera, a ne da se dekoncetrise zadovoljavajuci cudi mikrokontrolera. Kod PIC-a su to banke i zato o njima pricamo.

Uzmimo za primer 16F87x i definisimo prostor za varijable:


Stavio sam da svaka banka ima definisan prostor rezervisan za nju. To zato jer mi se cini da razni tipov imaju drugaciji ovaj prostor. Programer samo treba da bliske varijable, one koje zajedno ucestvuju u nekim operacijama smesta u istu banku. To nije tezak zadatak. Koriscenje bi izgledalo:



SetBank n do postavlja banku n i ona vazi u celoj strukturi begin..end. Na end se vraca predhodno postavljana banka. Ako iza do nema begin..end, onda se koristi samo jedna naredba iz definisane banke sa SetBank. Vidi se da se strukture SetBank..do mogu da gnjezde. Upotrebom varijable iz neodgovarajuce banke, zahvaljujuci ovakvoj strukturi, dozvoljava kompajleru da prijavi gresku. Greska jedino nece biti prijavljena ako se koristi varijabla iz banke general. Ovo je nesto najjednostavnije sto moze da se uradi, a da se omoguci kompajleru da na prost nacin kontrolise upotrebu i manipulisanje sa bankama na ispravan nacin.

Pozdrav.

@Odin D.

Ima u vasoj analizi par propusta.

Pre svega nije uopste potrebno brinuti o bankama prilikom interapta. STATUS registar snima se sa ostalim, tako da se snima i trenutna banka. Takodje se vraca prilikom povratka. Oni su znaci eliminisani kao eventualni uzrok problema.

Dalje, prebacivanje banke se ne mora vrsiti za svaki registar. Taman posla da bi iko to zeleo tako uraditi. To jeste najlakse implementirati, ali daleko od toga da je to dobro resenje. Takvim pristupom krajnji program bi bio i sporiji i duzi, a to svakako nije cilj. Ukoliko je odredjeni kod (ili deo koda) koncipiran u obliku jasno definisanih procedura (kako je predlozio korak) onda je dovoljno da kompajler odabere odredjenu banku neposredno pre procedure. Svi registri korisceni unutar nje morali bi (zbog vece brzine) biti u istoj banci, a eventualni neophodan prelazak (zbog registara specijalne namene) bi se mogao resiti preko privremenog prelaska i nakon zavrsene operacije povratka.

Onda, grananje. To je verovatno i najveci problem (pogotovu kod 18F serije), ali ipak postoji konacan broj instrukcija kojima se moze realizovati grananje. U 16F seriji to su incfsz, decfsz, btfsc, btfss i bilo koja instrukcija koja direktno menja PCL (npr. addwf PCL,F).

Kako prilikom grananja incfsz, decfsz, btfsc, btfss instrukcijama kompajler pre nego sto dodje do njih zna u kojoj je banci, bez obzira na to gde skocio, nalazice se u potpuno istoj banci. Tako nema vece potrebe za njenom promenom.

Najveci problem moglo bi biti grananje direktnom izmenom PCL registra (cesto korisceno u tabelama ili ON W GOTO operacijom). Medjutim, i njihova struktura mogla bi se standardizovati unutar procedure.

Znaci, ukoliko kompajler zakljuci da nema grananja unutar procedure (instrukcije grananja ukoliko ih ima imaju skokove unutar iste procedure ili uopste nema instrukcija grananja) moze kompletnu proceduru procesirati kao obican linijski kod, a za svaki linijski kod dovoljno je (uz ranije navedene izuzetke) samo jednom izabrati banku.

Optimizacija rasporeda varijabli jeste problem, cak, rekao bih najveci izazov za kompajler. Moguce je da bi resenje bilo da kompajler isproba svaku mogucu kombinaciju banki i izabere onu koja pruza najmanje prelaza, i koja je tako generise najkraci program. Medjutim, ni to nije dovoljno dobro. Kao sto Odin D kaze nekada je brzina bitnija od velicine programa. Kompajler bi onda morao znati i koje procedure treba sto brze izvrsavati, a koje mu nisu toliko bitne, i na osnovu tih informacija dodatno optimizovati program. Prilicno zamrseno.
Mozda bi ipak bilo najjednostavnije izostaviti ovu mogucnost kompajlera i prebaciti vruc krompir programeru. Ako on ne zna kako optimizovati banke, nikakav kompajler mu ne bi mogao pomoci. Vidim da korak u zadnjem postu preferira upravo ovakav metod.

MPLAB na primer ima mogucnost generisanja programa iz vise fajlova (prog1.asm, prog2.asm, prog3.asm...) linkerom. Medjutim, i tu programer bira banke rucno.
Primenjen pristup mi se svidja jer se unutar svakog od tih fajlova definise koje se varijable koriste unutar njega, da li su interne za taj deo programa (fajl) ili im se moze pristupati i spolja, kao i da li se smeju prebrisati njihove vrednosti prilikom poziva neke druge procedure (sto stedi RAM memoriju). Takodje je potrebno definisati i tacku (tacke) ulaska.
Na taj nacin programer mora brinuti o bankama, ali svaki fajl ima standardnu deklaraciju poput zasebne procedure.
Nije mi toliko bitno sto se koristi vise fajlova (stavise, to moze i da smeta) koliko precizna i jasno definisana grupacija svih parametara koji se koriste unutar procedure. To poboljsanje je odmah uocljivo.
Sledece poboljsanje u ovakvom sistemu je sto se ne mora pamtiti adresa pocetka RAM-a i sto se unutar fajla (procedure) moze izabrati da li ce se za varijablu koristiti obican RAM ili onaj mapiran u svim bankama. Programer na osnovu svojih konkretnih potreba moze izabrati resenje.
Jos jedno poboljsanje je mogucnost linkera da brine o rasporedu varijabli i kompletnog programa u memoriji. Moje je da pozovem fajl (proceduru) navodeci njenu labelu, a linker ce se brinuti o ostalom.
Najbolja od svega je mogucnost koriscenja labela sa istim nazivom unutar razlicitih procedura. Ukoliko te labele nisu definisane kao eksterne, nemoguce im je pristupiti spolja.
Ovaj sistem mozda deluje sasvim solidno, i bio bi da mu je linkerska skripta malo "pametnija". Nazalost nije.


@korak

Ovo sto ste do sada pisali odnosi se jedino na linijske kodove (begin end) i kao takvo je sasvim u redu. Reseno je pozivanje, resene su banke. Kako mislite resiti grananje?

U granjanjima tegeba izbeci GoTo, vec implementrirati strukture if..then..else, repeat..until, while..do i case..of. Na taj nacin kod ostaje 'zarobljen' u tim strukturama i moze se omoguciti kompajleru da kontrolise banke. Procedura mora biti definisana kao posebna programska struktura, a ne kao klasican podprogram. Onda se moze, posle poziva procedure, obnoviti ona banka koja je bila ukljucena pre poziva procedure. Na ovaj nacin, procedura moze koristiti razne banke, ali kada se vrati tamo odakle je pozvana, bice aktivna banka koja je to bila i pre poziva procedure. Cela caka je u tome da kompajler zna sa kojim bankama se radi. Na mestu poziva procedure on to zna ako se koristi struktura koju sam predlozio SetBank..do, pa ce biti u stanju da posle poziva procedure obnovi istu banku. Moze se desiti da to niije potrebno, ali kompajler to ne moze znati.

Moduli nisu include fajlovi. To su posebne programske strukture slicne programu samo sto imaju drukcije zaglavlje (unesto program imaju simbol unit) i imaju simbol implementation da bi sve iza ovog simbola bilo privatno za modul.

Iako nisam specijalista za PIC, cini mi se da je sve ovo izvodljivo i da moze biti vrlo efikasno.

Pozdrav.

Mislim da bi jos jedno poboljsanje bilo moguce. Kazete da kompajler ne zna da li mu je potrebna izmena banke ili ne. Kako ne zna, kada mu je unapred definisana?

U ovom slucaju procedura najvece dubine koristi istu banku kao i prethodna. Na osnovu toga kompajler moze lako zakljuciti da nema potrebe za promenom banke prilikom ulaska niti prilikom povratka.

Mnogo veci problem predstavljao bi poziv iste procedure sa dva (ili vise) razlicita mesta. Onda kompajler ne bi znao iz koje banke je pozvana procedura, tako da bi morao izvrsiti prelaz pri svakom pozivu procedure. Tacnije, mogao bi ako bi poredio banku svake procedure nizeg nivoa koja je poziva. Ipak, mislim da bi bilo bolje kada bi se programeru prepustio izbor. 2 instrukcije vise pri pozivu i jos dve pri povratku mozda deluju zanemarljivo, ali sta ako se bas ta procedura koristi u petlji kasnjenja!

Za strukture, npr. IF...THEN...ELSE mislim da bi trebalo najpre definisati sta se testira (bit, bajt, word...) a zatim napraviti posebne algoritme za svaki pojedinacni slucaj, kao i za svaku pojedinacnu operaciju (<, >, =, <=, >=, <> i eventualno logicke operacije). Sve ovo radi bolje optimizacije.
REPEAT...UNTIL struktura mogla bi koristiti iste delove koda za testiranje kao i IF...THEN...ELSE.
WHILE...DO struktura mi nije poznata (sta cu kada nisam ucio Paskal), ali pretpostavljam da je slicna REPEAT...UNTIL strukturi.
CASE...OF struktura bi se najjednostavnije implementirala koriscenjem updata PCL sa ON W GOTO metodom (uz obaveznu proveru i eventualni update PCLATH u slucaju prelaza preko 256b granice).

Sve ovo i meni deluje potpuno izvodljivo. Buduci da vec imam deo optimizovanih i jednostanih algoritama za testiranja (doduse samo za cele bajtove) ocekujte pomoc kada dodjete do konkretne implementacije struktura.