OT to RTOS or not to RTOS, was: Mereni napeti baterie pomoci AVR

[Michal Gregor]

Pole structur je sice pekny napad, ale v praxi na jednocipu 
nerealizovatelny.
Zkousel jsem napsat jeden program pro tri porty. Na zacatku "vlakna" se 
prepne ukazatel na data aktualniho portu:
switch (Aktualni_Port) {
    case 1:
        Aktualni_Port = 2;
        break;
    case 2:
        Aktualni_Port = 3;
        break;
    default:
        Aktualni_Port = 3;
        break;
}
Vysledek mizivy. Zkuste si to prelozit:

Datovy_Protokol(Aktualni_Port).Soucet += Prijaty_Byte(Aktualni_Port);
Po prekladu bude kod pro tento radek strasne dlouhy a nefektivni, protoze se 
pocita ukazatela na pole atd.

Kdezto:
Soucet += Prijaty_Byte;
Je ve vysledku jen jedna instrukce.

Nakonec mam tri stejne soubory, kazdy pro jeden port. Upravy delam na modulu 
1 a pak to jen prekopiruji. Vsechny globalni funkce a promenne zacinaji 
stejne: Port1_. Takze staci nahradit Port1_ za Port2_ atd.


>2/ podnetom bolo ukazat kolegovi, ktory nie celkom chapal pojmy "RTOS, 
>prepnutie vlakien..." ze je to o dost ine nez "superloop".

V nekolika mailech  jsem psal ze se jedna o jednoduchy "RTOS", pro slozite 
algoritmy a programy nevhodne. V kazdem pripade se z toho da vytahnout 
hodne - mam nekolik programu kde obsluhuji timto primitivnim "RTOS" nekolik 
seriovych portu, lcd, klavesnici, AD a v pohode to stiha.

>Ale to predsa viete Vy sam ako uzivatel toho RTOS lepsie nez my, co ho 
>nepouzivame - samozrejme ze RTOS Vam zacne zavadzat vtedy, ked ten overhead 
>(ci uz pamatovy alebo casovy) je vacsi ako zisk z neho, prip. ak sa na danu 
>ulohu priamo nehodi nejaka jeho metodika. Napr. ak tych vlakien potrebujete 
>pustit povedzme niekolko tuctov.

Ano to je presne ono, dame tam RTOS a nejaky super procesor, ono to bude 
stihat. Ale to vubec nemusi byt pravda. Pokud chete mit zarucenou odezvu 
systemu, musite si s tim stejne pohrat, zmerit casovou narocnost 
jednotlivych vlaken a jejich uloh. A to se dela lepe u vlastnho systemu.
Na PC je to jedno uzivatel pocka  (maximalne chytne nerva a hodi comp z 
okna). Ale jsou aplikace, kde dlouha odezva systemu znamenu preteceni bufru 
UARTu a tim padem ztraceni drahocenych dat.

Michal Gregor




----- Original Message ----- 
From: "Milan" <milger na pobox.sk>
To: "HW-news" <hw-list na list.hw.cz>
Sent: Thursday, January 06, 2011 4:13 PM
Subject: Re: OT to RTOS or not to RTOS, was: Mereni napeti baterie pomoci 
AVR


"Ak je poziadavka dekoder pouzit viackrat, tak si ho napisem ako stavovy
stroj a vsetky jeho stavove premenne ulozim do struktury, z ktorej spravim
pole velkosti danej poctom viacnasobneho pouzitia. Cele je to o sposobe
pisania programu, nieco ako napr. objektove programovanie (nemyslim tym
samotnu metodu, ale ze treba pouzit vhodny pristup ci metodiku)."

Vidim ze nie vsetci pochopili "demo-zadanie", moja chyba, nenapisal som ho
jasne, takze:
1/ bola snaha vymysliet priklad, nieco co nie sme schopni vyriesit bez
jednoducheho RTOS, t.j. nemame dostatok RAM na ulozenie 3x celej spravy ani
na ulozenie stavovych premennych /to som nenapisal jasne ale iba ako "5000
riadkovy algoritmus"/ stavoveho stroja. Musime teda riesit 3 ulohy naraz a
spravy /500B/ dekodovat postupne ako prichadzaju . Aby sme data nestracali,
nejaku RAM na vstupne FIFO, OS apod. mame /1kB/.
Preto ten silny pojem "Neriesitelne" bez RTOS samozrejme.

2/ podnetom bolo ukazat kolegovi, ktory nie celkom chapal pojmy "RTOS,
prepnutie vlakien..." ze je to o dost ine nez "superloop".

3/ povodnym zamerom bolo spomenut riesenie s RTOS,  a tu zrazu ako sme si
pekne pokecali... sice tak trochu sposobom "kto ma vacsieho ..." ale ako
pisete ... ked uz je ten takmer piatok... ;-)

Milan


----- Original Message ----- 
From: "Jan Waclawek" <konfera na efton.sk>
To: "HW-news" <hw-list na list.hw.cz>
Sent: Thursday, January 06, 2011 1:22 AM
Subject: OT to RTOS or not to RTOS, was: Mereni napeti baterie pomoci AVR


>Ja som stanovil podmienku ze nemate dostatok RAM, to znamena buffer pouzit
>nemozte, musite spracovavat data priamo tak ako prichadzaju.
>To znamena ze zadanie tak ako som ho stanovil je bez RTOS neriesitelne.


"Neriesitelne" je rovnako silne slovo ako "prepnuti vlaken nezere zadny
cas".

Ak je poziadavka dekoder pouzit viackrat, tak si ho napisem ako stavovy
stroj a vsetky jeho stavove premenne ulozim do struktury, z ktorej spravim
pole velkosti danej poctom viacnasobneho pouzitia. Cele je to o sposobe
pisania programu, nieco ako napr. objektove programovanie (nemyslim tym
samotnu metodu, ale ze treba pouzit vhodny pristup ci metodiku).


>Pripadne vymyslite zadanie vy tak, aby ste sa nenarobil a ja som to mal
>zlozite.

Ale to predsa viete Vy sam ako uzivatel toho RTOS lepsie nez my, co ho
nepouzivame - samozrejme ze RTOS Vam zacne zavadzat vtedy, ked ten overhead
(ci uz pamatovy alebo casovy) je vacsi ako zisk z neho, prip. ak sa na danu
ulohu priamo nehodi nejaka jeho metodika. Napr. ak tych vlakien potrebujete
pustit povedzme niekolko tuctov.


>Vsetkym nam je jasne ze ak mame nekonecne vykonny HW, nekonecne mnozstvo 
>RAM
>a pod. + nekonecne mnoho programatorov, je riesitelne skoro vsetko za skoro
>nulovy cas...ale s neskutocne nekonecnymi nakladmi. :-)


To nie je celkom tak. V skutocnosti Vam pomahaju uz napisane kniznice (ci
iny vopred napisany software, napr. ten RTOS), nie samotne zdroje - akurat
ze tie kniznice atd., aby boli lahko pouzitelne v roznych situaciach, su
neefektivne.

Naviac Vam velmi pomaha to, ze riesite urcity druh uloh, na ktore ste
zvyknuty - a na ktore aj tie kniznice atd. mate poruke.

... ked uz je ten takmer piatok... ;-)

wek

_______________________________________________
HW-list mailing list  -  sponsored by www.HW.cz
Hw-list na list.hw.cz
http://list.hw.cz/mailman/listinfo/hw-list

_______________________________________________
HW-list mailing list  -  sponsored by www.HW.cz
Hw-list na list.hw.cz
http://list.hw.cz/mailman/listinfo/hw-list