POK: vseobecne zasady pre pisanie prerusovacich rutin

ck@cbox.cz ck@cbox.cz
Pátek Září 28 02:38:56 CEST 2007


Sorry, trochu jsem ujel, uz jsem myslel na duplexni komunikaci. Pro tu je potreba po jednom kruhovem bafru pro prijimac a pro vysilac. Kazdy kruhovy bafr potrebuje 2 ukazatele - uk. zacatku, ktery je obhospodarovan procesem odebirajicim data a uk. konce, ktery je obhospodarovan procesem data dodavajicim.
Take jsem nenapsal: Je-li ukazatel konce dohonen ukazatelem zacatku, pak byl bafr  vyprazdnen.¨
CK

<ck@cbox.cz> napsal(a):
> Dobry vecer.
> Jeste jsem zapomnel 
> 1)na zakazovani a povolovani preruseni jednak globalne, jednak od jednotlivych zdroju, 
> 2)na prepinani bank registru pro jednotliva preruseni, pripadne sdileni registru jedne banky vice prerusenimi (C-cko to nastesti vetsinou nedovoluje), 
> 3)dalsi velkou kapitolou je vytvoreni casove zakladny a rozvrzeni preruseni pro bazovy casovac a jednotlive procesy, kterych se to tyka. 
> 4)Nekdy se resi predavani urcitych informaci mezi procesy pomoci jednobitovych promennych (nazyvejme je treba semafory). Ke kazdemu semaforu by mel prisluset pouze 1 proces, ktery ma opravneni ho menit, ostatni procesy ho smi poze cist. 
> 5)Je si treba take uvedomit, ze cim casteji dochazi k preruseni, tim vice casu travi procesor "zbytecne" instrukcemi volani a navratu, ukladanim priznaku, registru a jejich obnovovanim.
> 6)Registry (SFR) chybovych stavu se casto chovaji jinak, nez registry dat periferii
> 7)Pocet vyvolanych preruseni nemusi odpovidat nasi predstave - napriklad vysilac UARTu pri vyslani n znaku prerusi n+1 krat (po kazdem znaku a po vyprazdneni bafru na konci)
> 8)zapis a cteni registru periferii ktere jsou delsi nez slovo procesoru (napr. 16-ti bitovy citac u 8-bitoveho MCU) muze byt hardverove osetren ruznymi vychytavkami od vyrobce, nebo se korektnost udaje musi resit v obsluze
>  
> K tomu bodu 1 - kruhovy bafr. Do procesoru a z procesoru neprichazi bohuzel jen davky dat o delce sirka slova procesoru oddelene "dlouhymi" mezerami, ale rozlicne dlouhe pakety treba uplne bez mezer. Napriklad na kanalu UART pri rychlosti 115200 Bd a delce paketu do 1500 bajtu muzeme na prijimaci ocekavat priblizne kazdych 87 us dalsi znak. Predpoladelme, ze hlavni smycka programu se toci v prumeru za 10 ms a nekde v ni se 1 krat koukneme neprisel-li znak po seriovem kanalu. Vychazi, ze mezi dvema testy muze prijit v prumeru 115 znaku. Rutina pro obsluhu prijimace potrebuje volnou pamet (prijimaci bafr) kam muze data stradat, nez je nadrizeny program odebere a zpracuje. V pripade, ze jsou jednotlive pakety oddeleny dostatecne dlouhymi mezerami, ktere zaruci, ze se stihne predchozi paket zpracovat, pak staci bafr delky maximalniho paketu. Po zpracovani paketu nadrizenym programem se ukazatel na 1. volne misto v bafru opet vrati na zacatek. 
> V pripade, ze nevime kdy mohou prijit dalsi data je sikovnejsi pouzit kruhovy bafr. Je to vyhrazena cast pameti, kterou chapeme jako prouzek papiru, jehoz konce slepime a vytvorime prstenec. To slepeni je v nasem pripade realizovano vhonou manipulaci s ukazateli. Kruhovy bafr potrebuje 4 ukazatele - zacatek a konec (casto konec+1) zdrojoveho procesu, ktery bafr plni a zacatek a konec+1 prijimaciho procesu, ktery data odebira. Kazdy ukazatel po presunu za posledni pametove misto bafru automaticky preskoci na zacatek bafru (automaticky znamena, ze to tak napise programator). Kruhovy bafr by mel byt navrzen takove delky, aby nemohlo dojit k jeho preplneni s ohledem na rychlost jakou je schopen nadrizeny program data odebirat (pri plnem zatizeni procesoru - zrejme budou uzirat cas i dalsi preruseni), jaky je prumerny tok prichazejicich dat apod. Presto se musi resit i pripad preplneni bafru. Muzeme zvolit dve zakladni strategie, pokud ukazatel zacatku je dohnan ukazatelem konce - bud se o nej zarazi a tim padem jsou nova data zahazovana a ta stara stale cekaji na odebrani. Druha strategie naopak uprednostnuje nova data a ta nejstarsi prepisuje - ukazatel zacatku je v tomto pripade odstrkovan ukazatelem konce pri kazdem novem znaku.
> 
> Zdravim CK
> 
>   
> Jan Waclawek <wek@evona.sk> napsal(a):
> > Huh, to je uz "advanced", rozhodne nie "beginner" (ako to povodne bolo 
> > myslene). Ale zvazim, ze sa to tam doplni - jasne oznacene ako "advanced".
> > 
> > Chcel som povedat, dakujem.
> > 
> > wek
> > 
> > PS. Mozete prosim trocha rozviest bod 1?
> > 
> > 
> > 
> > ck@cbox.cz wrote:
> > > Dobry den.
> > > -Pomoci preruseni se casto predavaji cele pakety dat. Ja bych doporucil pouziti kruhovych bafru.
> > > -Mnohe procesory maji prioritni system - na vyssi priority nastavovat rychla kratka presruseni. Take je treba si prostudovat, zda muze dojit k preruseni na stejne priorite u konkretniho procesoru.
> > > -Ma-li procesor pipeline nemusi se na portu hned objevit to, co se tam zrovna zapsalo apod.
> > > -Nektera preruseni reaguji na hranu a obvykle se zapamatovavaji, nektera na uroven a obvykle se nezapamatovavaji
> > > -reakce na preruseni je zavisla na vice faktorech a muze byt i u dost nadupanych procesoru prekvapive pomala
> > > -je dobre udelat si analyzu, kolik procent casu mohou preruseni zabrat, aby se procesor vubec dostal do hlavniho programu
> > > 
> > > Zdravim CK
> > > 
> > > Ladislav Vaiz <spam@nagano.cz> napsal(a):
> > > 
> > >>1) Některé kompilátory (myslím, že něco DOSového od Borlandu) neukládaly 
> > >>registry, které ISR nepoužívala. Pokud se z ISR volala další funkce a ta 
> > >>je měnila, nastal průšvih. Dopsal bych tam něco ve stylu "koukněte, co z 
> > >>toho ten kompilátor vytvořil".
> > >>
> > >>2) Obecně vyhnout se vícebytovým proměnným, pokud to jde. Třeba Herout v 
> > >>knize doporučuje nepoužívat kratší typy než int. To je na 16 a 
> > >>vícebitech správně, na 8bitu ne. V podstatě je tento bod pokryt vašemi 
> > >>(rychlost, vypínání přerušení)
> > >>
> > >>Láďa
> > >>
> > >>
> > >>Jan Waclawek napsal(a):
> > >>
> > >>>Spisal som nejake zasady pre pisanie prerusovacich rutin tak, aby clovek 
> > >>>nedosiel k ujme:
> > >>>http://www.8052.com/faqs.phtml?FAQ=145008
> > >>>
> > >>>Prosim O Komentar.
> > >>>
> > >>>wek
> > >>>_______________________________________________
> > >>>HW-list mailing list  -  sponsored by www.HW.cz
> > >>>Hw-list@list.hw.cz
> > >>>http://list.hw.cz/mailman/listinfo/hw-list
> > >>>  
> > >>
> > >>_______________________________________________
> > >>HW-list mailing list  -  sponsored by www.HW.cz
> > >>Hw-list@list.hw.cz
> > >>http://list.hw.cz/mailman/listinfo/hw-list
> > >>
> > > 
> > > _______________________________________________
> > > HW-list mailing list  -  sponsored by www.HW.cz
> > > Hw-list@list.hw.cz
> > > http://list.hw.cz/mailman/listinfo/hw-list
> > > 
> > _______________________________________________
> > HW-list mailing list  -  sponsored by www.HW.cz
> > Hw-list@list.hw.cz
> > http://list.hw.cz/mailman/listinfo/hw-list
> > 
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list@list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
> 



Další informace o konferenci Hw-list