Mereni napeti baterie pomoci AVR
Jiri Foldyna
jiri.f na avizo.cz
Středa Leden 5 22:37:41 CET 2011
Obsluha HW se u RTOS většinou neřeší pollingem, ale v přerušení. Jednotlivé
tasky obvykle zpracovávají data z bufferu, podmínkou samozřejmě je, že
zpracování obsahu bufferu trvá kratší dobu, než jeho plnění.
JF
> -----Original Message-----
> From: hw-list-bounces na list.hw.cz [mailto:hw-list-bounces na list.hw.cz]On
> Behalf Of Pajpach
> Sent: Wednesday, January 05, 2011 10:28 PM
> To: HW-news
> Subject: Re: Mereni napeti baterie pomoci AVR
>
>
> No bez toho abych tu chtel jednoho ci druheho napadat, zajima me RTOS:
> jak v RTOS se switch time 5 (10)ms budete ty vzorove tri retezce
> zpracovavat "zaraz" ve trech vlaknech, kdyz nez na jedno
> vlakno zbyde cas
> tak ztrati 10 (20) znaku z te seriovky pri rychlosti 9600bd?
>
> MP
>
>
> -----Původní zpráva-----
> From: Milan
> Sent: Wednesday, January 05, 2011 10:14 PM
> To: HW-news
> Subject: Re: 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.
> Chcel som aby vynikol rozdiel v rieseni.
>
> 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. :-)
>
> Milan
> ----- Original Message -----
> From: "Michal Gregor" <a2x1nptda8 na email.cz>
> To: "HW-news" <hw-list na list.hw.cz>
> Sent: Wednesday, January 05, 2011 9:42 PM
> Subject: Re: Mereni napeti baterie pomoci AVR
>
>
> Moment ty tri porty bezi soubezne? Mate dve moznosti:
> 1) Prijmout zpravy do bufru: potrebujeme 3x 500byte. Plus
> druhy bufer ktery
> se pouziva nez se predchazejici zprava zpracuje to uz mame 3000byte.
> 2) Rozsekat to na jednotlive ulohy, tedy zpracovavat tok dat
> byt za bytem.
> Pak staci par byte na bufer UARTu. Ale delat to u zpravy,
> ktera ma slozitou
> strukturu bych to delat nechtel. Zatim jsem se vzdy vesel do
> nekolika uloh /
> vlakno.
>
> Pokud se pouziva jenom jeden port a ostatni jsou vypnute je
> situace jina -
> nacist 500byte ze zvoleneho portu a zpracovat. Jak jsem jiz psal pro
> slozitejsi algoritmy je asi lepsi skutecny RTOS nebo rovnou
> operacni system
> (Win, linux).
>
> Michal Gregor
>
>
>
> ----- Original Message -----
> From: "Milan" <milger na pobox.sk>
> To: "HW-news" <hw-list na list.hw.cz>
> Sent: Wednesday, January 05, 2011 9:18 PM
> Subject: Re: Mereni napeti baterie pomoci AVR
>
>
> Otazka je skor co je efektivnejsie a vyzaduje menej prace...
>
> Napr. takyto problem:
> Dostavate data zo ser.portu. prichadza sprava na ktoru musite nejako
> reagovat. Predpokladajme, na to aby ste vedel co mate robit
> potrebujete do
> hlbky postupne dekodovat povedzme prvych 500byte. To mame 256^500
> kombinacii. Predpokladajme ze sa vyuziva len mala cast
> moznych kombinacii a
> algoritmus ktory to riesi ma 5000 riadkov a je nenarocny na RAM.
> Dalej predpokladajme ze take ser. porty mate 3 a potrebujete
> ich opracovat
> rovnako, hoci data z nich prichadzaju roznou rychlostou.
> RAM pamet je u malych jednocipov dost obmedzeny artikel,
> povedzme ze zotava
> uz len 1kB. Jednoducho malo na ulozenie 3 celych sprav.
>
> Ja spustim 5000riadkovy algoritmus 3x na 3 ser.porty a kedze
> algoritmus na
> dekodovanie spravy je znamy, cele to rozchodim do 30min.
>
> Zaujima ma ako si poradite vy, ako to vyriesite?
> Pripadne vymyslite zadanie vy tak, aby ste sa nenarobil a ja
> som to mal
> zlozite.
>
>
> Milan
>
> P.S. Samozrejme ze som to cele "pritiahol za vlasy" iba koli
> efektu, ale
> realne zadanie bolo dekodovat asi 50B a algoritmus co to
> riesil mal asi 500
> riadkov. RAM zostavalo 250B.
>
> ----- Original Message -----
> From: "Michal Gregor" <a2x1nptda8 na email.cz>
> To: "HW-news" <hw-list na list.hw.cz>
> Sent: Wednesday, January 05, 2011 8:32 PM
> Subject: Re: Mereni napeti baterie pomoci AVR
>
>
> Ale vysledek je stejny, bezi vice vlaken najednou.
>
> Co je lepsi? RTOS, ktery to resi za programatora, ale sezere spoustu
> prostredku? Nebo program ktery je od pocatku rozdelen a ma
> malou rezii?
>
>
> Michal Gregor
>
>
> ----- Original Message -----
> From: "Milan" <milger na pobox.sk>
> To: "HW-news" <hw-list na list.hw.cz>
> Sent: Wednesday, January 05, 2011 7:48 PM
> Subject: Re: Mereni napeti baterie pomoci AVR
>
>
> Ja o "voze", vy o "koze".
> Vy ste si rozdelil algoritmus na male casti, ktore vo vami definovanom
> poradi vykonavate. To je vsetko. Nijako to nesuvisi s RT OS o
> ktorom hovorim
> ja.
> Rozdiel:
> U mna kazde vlakno dostane definovany cas na riesenie, po nom
> bez ohladu na
> stav, mu je odobrany procesor a ide ine vlakno. Vase casti
> algoritmu sa
> vykonavaju v definovanom poradi, postupne v naprogramovanom
> poradi a pokial
> nejaka neskonci, dalsia sa neriesi.
>
> Ja to riesenie nekritizujem, je to idealne pokial nemam RT OS, akurat
> hovorim o niecom inom....
>
>
> Priklad:
> /*************************************************************
> *****************/
> /* Task 0 'init': Initialize
> */
> /*************************************************************
> *****************/
> void INITIALIZE (void) _task_ INIT
> { //program execution starts here
> os_create_task (EVENT_IFF); //start command task for UART1
> os_create_task (EVENT_TTV); //start command task for UART2
> os_delete_task (INIT); //stop init task (no
> longer needed)
> }
>
> /*************************************************************
> *****************/
> /* Task 2 'EVN_S0': event serial channel 0
> */
> /*************************************************************
> *****************/
> void EVN_IFF (void) _task_ EVENT_IFF
> {
> while (1)
> {
> .
> .
> .
> }
> }
>
> /*************************************************************
> *****************/
> /* Task 3 'EVN_S1': event serial channel 1
> */
> /*************************************************************
> *****************/
> void EVN_TTV(void) _task_ EVENT_TTV
> {
> while (1)
> {
> .
> .
> .
> os_wait (K_TMO, 5, 0); //wait interval:
> 0.025 second
> }
> }
>
>
> Milan
>
> ----- Original Message -----
> From: "Michal Gregor" <a2x1nptda8 na email.cz>
> To: "HW-news" <hw-list na list.hw.cz>
> Sent: Wednesday, January 05, 2011 7:01 PM
> Subject: Re: Mereni napeti baterie pomoci AVR
>
>
> Neberte to doslova! Mam to rozdelene tak aby se nemuselo nic
> ukladat, zadny
> zasobnik, zadne nasilne prepnuti. Rekneme za mi to vezme 10 -
> 20 instrukci v
> asembleru, v Cecku trochu vic je prece jennom dost nenazrane.
> Na malych
> procesorech s par byty RAM a ROM to byla fuska, ale na
> dnesnich "masinach"
> kdy se clovek nemusi bibrat s kazdym bytem je to docela sranda:
>
> S hlavniho programu poustim nekolik vlaken, jedno po druhem:
>
> while(1) {
> G_Vypisy_Uloha();
> G_LCD_Uloha();
> G_Edit_Uloha();
> Uroven_100mS();
> Reaguj_Na_Zmenu_Vstupu();
> Vynuluj_WDT();
> }
>
>
> Jedno vlakno a jeho ulohy:
>
> // Ulohy vlakna Vypisy
> static enum {
> Uloha_Zacatek,
> Uloha_Aktivace,
> Uloha_Over_Bufer,
> Uloha_Vytiskni_Zpravu,
> Uloha_Cekej_Konec_Vysilani
> } Uloha;
>
> Rozdeleni vlakna:
>
> void G_Vypisy_Uloha(void) {
>
> // Úlohy vlákna
> switch( Uloha ) {
>
> case Uloha_Zacatek:
> Zacatek();
> break;
>
> case Uloha_Aktivace:
> Aktivace();
> break;
>
> case Uloha_Over_Bufer:
> Over_Bufer();
> break;
>
> case Uloha_Vytiskni_Zpravu:
> Vytiskni_Zpravu();
> break;
>
> case Uloha_Cekej_Konec_Vysilani:
> Cekej_Konec_Vysilani();
> break;
>
> default:
> Uloha = Uloha_Zacatek;
> break;
> }
> }
>
> Treba vypocet CRC, pocita se vzdy jeden byte zpravy:
>
> //***********************************************************
> static void Spust_Vypocet_CRC (void) {
>
> CRC = 0;
>
> i_Zprava = i_Zacatek_Vypoctu_CRC;
>
> Uloha = Uloha_Spocitej_CRC_Zpravy;
> }
> //***********************************************************
> // Vytvoří CRC zprávy.
> // Výpočet probihá po jednom byte
>
> static void Spocitej_CRC_Zpravy (void) {
>
> // Výpočet CRC
> CRC = G_Pre_Pocitej_CRC_Pc ( G_Kpo_Zprava[ i_Zprava ] , CRC );
> ++i_Zprava;
>
> // Konec zprávy?
>
> if ( i_Zprava > I_KONEC_ZPRAVY_CRC ) {
>
> // Dokončen výpočet CRC zprávy,
> // připočítat dva nulové byty
>
> CRC = G_Pre_Pocitej_CRC_Pc( 0, CRC );
> CRC = G_Pre_Pocitej_CRC_Pc( 0, CRC );
>
> Uloha = Uloha_Uloz_CRC;
> }
> else {
>
> // Výpočet pokračuje
> Uloha = Uloha_Spocitej_CRC_Zpravy;
> }
> }
>
>
> Staci si dobre rozdelit program na jednotlive ulohy a jde to
> samo. A neni to
> tak slozite, spise se program zjednodusuje.
>
> Jasne pokud se bude pracovat treba na vetsim matematickem
> vypoctu, ktery
> zabere stovky milisekund a nepujde rozdelit, tak bude treba
> skutecny RTOS.
>
> Michal Gregor
>
>
>
>
>
>
> ----- Original Message -----
> From: "Pavel Troller" <patrol na sinus.cz>
> To: "HW-news" <hw-list na list.hw.cz>
> Sent: Wednesday, January 05, 2011 5:06 PM
> Subject: Re: Mereni napeti baterie pomoci AVR
>
>
> Zdravím,
> rovněž bych to rád věděl. Operačními systémy se zabývám
> celkem dlouhou
> dobu
> a samozřejmě platí, že čím jednodušší RTOS, tím menší režie
> context switche,
> ale nulová - to nebylo ani v případě Z80 a jeho systému
> zdvojených registrů,
> takže mezi právě dvěma kontexty se dalo přepínat pomocí EXX ;
> EX AF,AF' -
> ale
> i ty byly tuším 6 clocků každá (možná i více), takže ani tam to nebylo
> "žádný čas". U Motoroly se dá použít MOVEM.L pro rychlé
> uložení na zásobník,
> což jsou instrukce právě optimalizované pro podobný případ,
> ale i ty si svůj
> čas vezmou. Jednodušší jednočipáky obvykle nemají žádnou
> hardwarovou podporu
> multitaskingu, takže tam se to musí poctivě uložit tam a zpátky. A to
> nemluvíme
> o realizaci scheduleru jako takového, který, jakmile má být jen trošku
> chytřejší než ten nejblbější round-robin, si taky to svoje vezme...
> Zdraví Pavel.
>
> > To sa rad necham poucit ako prepnut vlakno bez rezie.
> > Pre x51 som si to pisal z polovice sam a:
> > odkladam registre, plnim ich z noveho vlakna, prehadzujem zasobnik
> > /bohuzial u x51 musim menit cely, 128B je strasne malo + reentrantny
> > zasobnik pre funkcie, inak ho staci prestavit/ a nastavim
> novy PC + nejake
> > drobnosti /systemove casovace.../. Odhadom niekolko 100-vak
> instrukcii.
> > Systemovy timer bezi kazdych 5ms. A nasilne prepnutie /ked vlakno
> > neodovzda
> > procesor -Round-robin alebo tak nejako/ je po 2 tikoch t.j. 10ms.
> > A vy vravite "ziadny cas" ??? Poradte co robim zle.
> >
> >
> > Milan
> > ----- Original Message ----- From: "Michal Gregor"
> <a2x1nptda8 na email.cz>
> > To: "HW-news" <hw-list na list.hw.cz>
> > Sent: Wednesday, January 05, 2011 4:11 PM
> > Subject: Re: Mereni napeti baterie pomoci AVR
> >
> >
> > Kdyz se to dobre napise, tak prepnuti mezi vlakny nezere zadny cas.
> >
> > Michal Gregor
> >
> > ----- Original Message ----- From: "Milan" <milger na pobox.sk>
> > To: "HW-news" <hw-list na list.hw.cz>
> > Sent: Wednesday, January 05, 2011 3:20 PM
> > Subject: Re: Mereni napeti baterie pomoci AVR
> >
> >
> > To riesenie s casovacom je taka dobra klasika, to bude
> komentovat hodne
> > ludi.
> > Spomeniem ale riesenie s pouzitim nejakeho RT operacneho
> systemu, kde sa
> > daju zlozitejsie veci, ktore sa neopakuju az tak casto,
> riesit samostatnym
> > vlaknom. Vyhodou je ze nespotrebujete ziadny casovac /teda
> dokopy iba
> > jeden
> > na chod OS/ a aj zlozite algoritmy realizujete efektivne,
> riesite ich
> > akoby
> > samostatne. Nevyhodou to, ze zmysel to ma iba u pomalsich
> opakovani /nad
> > 10ms/ inak su naroky na reziu /prepnutie procesora/ znacne.
> > To len na rozsirenie obzoru, neviem ako AVR ale na x51 a
> ARM to hodne
> > pouzivam, pravdu povediac za poslednych 5 rokov som nemal
> riesenie, kde by
> > v
> > jednocipe nebezali aspon 3 samostatne vlakna...
> >
> > Milan
> >
> >
> > ----- Original Message ----- From: "Michal Grunt"
> <michal.grunt na vynet.cz>
> > To: "HW-news" <hw-list na list.hw.cz>
> > Sent: Wednesday, January 05, 2011 12:43 PM
> > Subject: RE: Mereni napeti baterie pomoci AVR
> >
> >
> > Jeste se v teto souvislosti zeptam. Kdybych chtel merit
> (nebo v podstate
> > delat cokoliv) jednou za x jednotek casu (radove vteriny ci desitky
> > vterin),
> > to se dela pomoci preruseni? Abych nejakou smyckou delay
> nezablokoval cely
> > program. A dela se to tak, ze nastavim ze se bude preruseni
> generovat
> > kazdych x jednotek casu (placnu, preruseni jeste
> nastudovane nemam, treba
> > jednou za 100ms) ja budu v hlavni smycce programu testovat zda se
> > preruseni
> > neprovedlo xy krat a pokud ano provedu pozadovany ukon?
> >
> > ________________________________________
> > Odesílatel: hw-list-bounces na list.hw.cz
> [hw-list-bounces na list.hw.cz] za
> > uživatele Pavel Hudeček [edizon na seznam.cz]
> > Odesláno: 4. ledna 2011 23:58
> > Komu: HW-news
> > Předmět: RE: Mereni napeti baterie pomoci AVR
> >
> > Ano, takto. Hodnoty skoro jakékoli od 1k do 1M, rozumná
> střední cesta je
> > něco kolem 100k. Nebo kdybyste chtěl přejít z vypínače na
> tlačítko, tak i
> > nad 1M, ale možná s tím bude víc práce, neb při velkých
> hodnotách můžete
> > na
> > některých vstupech dojít k různým kalibračním konstantám
> pro různé režimy
> > činnosti MCU.
> >
> > Pak je ještě jedna alternativní možnost, zcela bez ext.
> součástek: Jako
> > referenci zvolíte napájení (předpokládám, že je natvrdo
> připojené ke
> > článku)
> > a multiplexer přepnete na pomocnou referenci (má asi 1,23
> V), změříte její
> > napětí v jednotkách odvozených z napájecího. Pak napájecí napětí
> > vypočítáte
> > opačným postupem, než obvykle :-)
> >
> >> Od: Michal Grunt <michal.grunt na vynet.cz>
> >> Jake zhruba hodnoty tech odporu?
> >>
> >> AD MCU
> >> ____ | ____
> >> Bat --|_R1_|--*--|_R2_|---| gnd
> >>
> >> Takto?
> > _______________________________________________
> > 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
> >
> > _______________________________________________
> > 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
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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
>
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
Další informace o konferenci Hw-list