printf i wielozadaniowosc (MicroC/OS-II)
Pszemol
priorytet�w i w�tek o ni�szym priorytecie dostaje procesor TYLKO WTEDY
gdy w�tek o wy�szym priorytecie nie ma nic do roboty i czeka na zdarzenie.
W swoim programie wielow�tkowym dorobi�em na szybkiego logowanie
zdarze� w celach debugging i u�ywam "zakazanej" funkcji printf, jako �e jest
ona bardzo wygodna zw�aszcza z parsingiem argument�w typu %d lub %x
w tek�cie... :-)
Spodziewa�em si� jakich� efekt�w zwi�zanych z niereentrantno�ci� tej
funkcji, ale to co dosta�em troch� mnie zaskoczy�o...
Ot� co widz�, to �e na wyj�ciu generowanym przez t� funkcj� fprintf
(strumie� znak�w RS232, "plikiem" dla fprintf jest port szeregowy)
widz� �e w�tek o ni�szym priorytecie wchodzi z butami w lini� tekstu
w�tka o wy�szym priorytecie i wci�cie jest tam, gdzie fprintf robi ten
parsing argument�w %d.
Podam przyk�ady.
Oto niezaburzona linia z tasku o najwy�szym priorytecie (Barrier 0):
"Barrier 0: s:14 M: a8c09, M: b98f, M: 6e71b, M: d14a5, M: 3422e, M: 96ff6,
M: f9d77"
A oto podobna linia z wci�ciami si� od task�w o ni�szych priorytetach
(Barrier 4):
"Barrier 0: s:14 M: c5aa5Barrier 4: handling legacy sensor readings
(time:1607)
Barr 4: Decrement counter (26) for legacy sensor (time:1607)
Barrier task 4, 'unknown' - wait one dev delay increment... (time:1608)
, M: 28521, M: 8b227, M: eddfc, M: 50b03, M: b365c, M: 223b1, M: 66cf0"
Task o priorytecie 3 schodki ni�ej, wci�� si� w �rodek fprintf'a od tasku
o prawie najwy�szym priorytecie i to w miejscu, gdzie sko�czy�o si�
parsowanie argumentu %x i zacz�� text printf'a.
Tu inny przyk�ad, ta sama sytuacja (barrier 7 to task o priorytecie 8):
"Barrier 0: s:09 R: 152ba, R: 78080Barrier 7: handling legacy sensor
readings (time:1613)
Barr 7: Decrement counter (42) for legacy sensor (time:1613)
Barrier task 7, 'unknown' - wait one dev delay increment... (time:1613)
, R: dae06, R: 3db91, R: a091a, R: 36a4, R: 66445, R: c91aa"
Jak wyt�umaczy� takie efekty?
Rozumiem, �e skoro wywo�ania fprintf'a z task�w dotycz� tego samego
portu szeregowego, przekazanego fprintf'owi jako argument nazwy pliku
(globalna zmienna) to mo�e si� co� kiep�ci�, i linie si� b�da przeplata�,
ale nie rozumiem jak taski o ni�szym priorytecie mog�y si� wstrzeli�
z TRZEMA OSOBNYMI WYWO�ANIAMI fprintf'a w jedn� lini� tasku
o wy�szym priorytecie? Przecie� wed�ug filozofii MicroC/OS-II task
bariery 0, w czasie chodzenia sobie po kodzie fprintfa nie powinien byďż˝
przerwany i taski o priorytetach 4 czy tym bardziej 8 powinny grzecznie
czeka� a� fprintf wywo�any przez task o priorytecie 1 uko�czy zadanie
i odda sterowanie systemowi operacyjnemu (nie ma tu wyw�aszczania).
Czy kto� m�g�by mi to wyt�umaczy�?
Zbych
> gdy w�tek o wy�szym priorytecie nie ma nic do roboty i czeka na zdarzenie.
[...]
> Ot� co widz�, to �e na wyj�ciu generowanym przez t� funkcj� fprintf
> (strumie� znak�w RS232, "plikiem" dla fprintf jest port szeregowy)
> widz� �e w�tek o ni�szym priorytecie wchodzi z butami w lini� tekstu
> w�tka o wy�szym priorytecie
[...]
> Czy kto� m�g�by mi to wyt�umaczy�?
�eby to dobrze wyt�umaczy� to trzeba zobaczy� jak to jest
zaimplementowane. Szklana kula m�wi tylko, �e w�tek o wy�szym
priorytecie oddaje czas innym w�tkom, bo czeka na zwolnienie miejsca w
buforze nadawczym RSa. Przy czym nie masz �adnej gwarancji, �e po
zwolnieniu miejsca pierwszy do RSa dobierze si� w�tek o najwy�szym
priorytecie. �eby wiedzie� co si� dzieje to trzeba by na osobnym kanale
wyrzuca� kiedy i jakie w�tki s� uruchamiane.
Pszemol
To jest oczywista oczywisto��, �e w�tek o priorytecie 1 czeka na port
RS i oddaje sterowanie :-) Mnie interesuje jak to si� dzieje, �e w czasie
gdy task 1 odda� sterowanie task 4 lub 7 by� wstanie trzy razy wys�a�
lini� znak�w do RS'a trzema osobnymi wywo�aniami fprintfa...
Tu masz przyk�ad:
"Barrier 0: s:14 M: c5aa5Barrier 4: handling legacy sensor readings
(time:1607)
Barr 4: Decrement counter (26) for legacy sensor (time:1607)
Barrier task 4, 'unknown' - wait one dev delay increment... (time:1608)
, M: 28521, M: 8b227, M: eddfc, M: 50b03, M: b365c, M: 223b1, M: 66cf0"
To wy�ej to by� efekt 4 osobnych wywo�an funkcji fprintf:
task1 (barrier 0) zrobiďż˝ najpierw to:
fprn(probe_out, "Barrier %d: s:%02ld M:%6lx, M:%6lx, M:%6lx, M:%6lx,
M:%6lx, M:%6lx, M:%6lx\r\n",
i w trakcie gdy utkn�� w tej linii czekaj�c na RSa task 5 (barrier 4) zrobi�
to:
fprn(barr_out, "Barrier %d: handling legacy sensor readings
(time:%ld)\r\n",
potem to w zupe�nie innym miejscu kodu:
fprn(barr_out, "Barr %d: Decrement counter (%ld) for probe #%d
(time:%ld)\r\n",
i za moment to:
fprn(barr_out, "Barrier task %d, '%s' - wait one dev delay
increment... (time:%ld)\r\n",
w czasie gdy task 1 wisiaďż˝ sobie i czekaďż˝ na zwolnienie RSa...
Tak czy inaczej musz� przerobi� to aby zosta�o to w kodzie na d�u�ej.
Chyba zrobi� nowy task o najni�szym priorytecie kt�ry zajmie si�
odbiorem tekst�w od task�w roboczych o wy�szych priorytetach
i wstawianiem tych tekst�w do portu szeregowego...
A.L.
wrote:
>
>Jak wyt�umaczy� takie efekty?
>
>
>Czy kto� m�g�by mi to wyt�umaczy�?
JA sie bardzd dawno tym zajmowlem i pod zupelnie inym systeme, a
bardzo dzawno znaczy BARDZO dawno. Ale mialem podobny problem
1. Task o wysokim priorytecie pisze do UART. UART ma wlasny bufor.
Bufor sie przepelnil i taksk dostal notyfikacje. System zawiesil task.
2. Wiec task o niskim priorytecie dostal CPU; w miedzyczasie UART
zaczal oproznaic budor, wiec taks o niskim priorytecie mogl pisac. Po
niedlugim czasie system zauwazyl ze task o wysokim priorytecie czeka
na UART, wiec zasiesil task o niskim priorytecie i ten zaczal pisac do
UART
W efekcie wyszla "sieczka" zlozona z fragmentow informacji z roznych
taskow.
Kluczowe pytanie jes co to znaczy ze printf "zakonczyl" dzialanie.
Powinien raportowac "zakonczenie" dzialania tylko wdedy gdy informacja
zostala rzeczywiscie fizycznie wyslana do klienta.
Nie wiem jak to jest w twoim systemie, ale podejrzewam ze cos takiego
lub podobnego.
Remedium byloby zamkniecie printf w osobnym tasku z wlasnum,
nieograniczonym buforem i potraktowanei calosci jako sekcji krytycznej
A.L.
grg12
> W systemie MicroC/OS-II wszystkie w�tki uszeregowane s� wed�ug swoich
> priorytet�w i w�tek o ni�szym priorytecie dostaje procesor TYLKO WTEDY
> gdy w�tek o wy�szym priorytecie nie ma nic do roboty i czeka na zdarzenie.
>
A aktywny w�tek o niskim priorytecie mo�e zosta� przymusowo "u�piony" na
rzecz w�tku wysokopriorytetowego czy prze��czenie nast�puje tylko je�li
aktywny watek dobrowolnie odda sterowanie (tak by�o w np. win3.1)?
Przypu��my �e w�tek HiPrio pisze sobie co� do bufora ��cza szeregowego,
bufor zostaje zape�niony wi�c w�tek zostaje u�piony do czasu opr�nienia
bufora, w�tek LowPrio przejmuje pa�eczk�, po pewnym czasie pr�buje
zapisa� do bufora ��cza, kt�ry zosta� ju� opr�niony przez obs�ug� portu
szeregowego (jakieďż˝ przerywanie zapewne) - wypisuje swoje i grzecznie
idzie spa�. W tym momencie obudzony zostaje w�tek HiPrio...
Pozdrawiam
GRG
Pszemol
news:25a0$4ac24d00$506cdd75$32...@news.chello.at...
> Pszemol pisze:
>> W systemie MicroC/OS-II wszystkie w�tki uszeregowane s� wed�ug swoich
>> priorytet�w i w�tek o ni�szym priorytecie dostaje procesor TYLKO WTEDY
>> gdy w�tek o wy�szym priorytecie nie ma nic do roboty i czeka na
>> zdarzenie.
>
> A aktywny w�tek o niskim priorytecie mo�e zosta� przymusowo "u�piony"
> na rzecz w�tku wysokopriorytetowego czy prze��czenie nast�puje tylko je�li
> aktywny watek dobrowolnie odda sterowanie (tak by�o w np. win3.1)?
Wysoki priorytet zwykle �pi bo czeka np. na przerwanie od zegara
lub od urz�dzenia zewn�trznego, np. RS232. Czyli masz przerwanie
kt�re przychodzi od RS232 a jeste� w tasku o priorytecie 3 to system
obs�uguje przerwanie i po obs�udze znowu sprawdza gdzie wr�ci�.
Poniewaďż˝ mam dwa taski gotowe, task o priorytecie 1 czekaďż˝ na RS232
a juďż˝ nie czeka, to task 1 powinien dostaďż˝ sterowanie...
Podsumowuj�c, nie dziwi�bym si� �e w linii loga od tasku 3 mam
przerwy i z buciorami wchodzi task 0 czy 1 ze swoim tekstem...
Ja si� dziwi� �e linia od tasku 0 zosta�a przerwana w po�owie
i wszed� w jej �rodek task 3 Z TRZEMA WYWO�ANIAMI fprintf'a.
> Przypu��my �e w�tek HiPrio pisze sobie co� do bufora ��cza szeregowego,
> bufor zostaje zape�niony wi�c w�tek zostaje u�piony do czasu opr�nienia
> bufora, w�tek LowPrio przejmuje pa�eczk�, po pewnym czasie pr�buje zapisa�
> do bufora ��cza, kt�ry zosta� ju� opr�niony przez obs�ug� portu
> szeregowego (jakieďż˝ przerywanie zapewne) - wypisuje swoje i grzecznie
> idzie spa�. W tym momencie obudzony zostaje w�tek HiPrio...
Ja nie widz� tutaj mo�liwo�ci aby z dwu task�w czekaj�cych na
przerwanie od portu szeregowego dorwaďż˝ siďż˝ do RS232 ten
o ni�szym priorytecie i to w po�owie parsingu od fprintfa HiPrio.
Adam Dybkowski
> Rozumiem, �e skoro wywo�ania fprintf'a z task�w dotycz� tego samego
> portu szeregowego, przekazanego fprintf'owi jako argument nazwy pliku
> (globalna zmienna) to mo�e si� co� kiep�ci�, i linie si� b�da przeplata�,
> ale nie rozumiem jak taski o ni�szym priorytecie mog�y si� wstrzeli�
> z TRZEMA OSOBNYMI WYWO�ANIAMI fprintf'a w jedn� lini� tasku
> o wy�szym priorytecie?
Mo�e chodzi o to, �e [f]printf wywo�any z zadania o wysokim priorytecie
jest dzielony na wiele odr�bnych zapis�w do portu szeregowego (w
najprostszej implementacji b�d� to zapisy po jednym znaku) a system
operacyjny w oczekiwaniu na gotowo�� portu do przyjmowania kolejnych
znak�w (zg�aszan� zapewne w przerwaniu portu szeregowego) oddaje po
prostu sterowanie zadaniom o ni�szym priorytecie gotowym do wykonania. W
gruncie rzeczy to chyba lepsze podej�cie (a nu� zadanie o niskim
priorytecie co�tam sobie liczy powoli w tle) ni� aktywne oczekiwanie na
zwolnienie siďż˝ miejsca w buforze nadajnika portu szeregowego. Czasem
przy wolnej transmisji i d�ugim buforze sprz�towym (zale�y od procesora
lub zewn�trznego uk�adu UART) takie oczekiwanie by�oby d�ugie - a tak w
tym czasie procesor mo�e si� zaj�� obs�ug� zada� o ni�szym priorytecie.
Aby unikn�� takiego mieszania si� printf'�w, wystarczy obj�� je
semaforem / mutexem czy co tam masz podobnego w tym systemie.
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wys�aniem do mnie maila usu� cyfry z adresu.
Jerry1111
> W systemie MicroC/OS-II wszystkie w�tki uszeregowane s� wed�ug swoich
> priorytet�w i w�tek o ni�szym priorytecie dostaje procesor TYLKO WTEDY
> gdy w�tek o wy�szym priorytecie nie ma nic do roboty i czeka na zdarzenie.
>
> W swoim programie wielow�tkowym dorobi�em na szybkiego logowanie
> zdarze� w celach debugging i u�ywam "zakazanej" funkcji printf, jako �e
> jest
> ona bardzo wygodna zw�aszcza z parsingiem argument�w typu %d lub %x
> w tek�cie... :-)
Wcale nie jest zakazana.
> Spodziewa�em si� jakich� efekt�w zwi�zanych z niereentrantno�ci� tej
> funkcji, ale to co dosta�em troch� mnie zaskoczy�o...
Bo tu nie chodzi o printf, tylko o reentrancje calej biblioteki newlib.
Z drugiej strony Altera ma to zalatwione, wiec nie rozumiem czemu problem?
> Ot� co widz�, to �e na wyj�ciu generowanym przez t� funkcj� fprintf
> (strumie� znak�w RS232, "plikiem" dla fprintf jest port szeregowy)
> widz� �e w�tek o ni�szym priorytecie wchodzi z butami w lini� tekstu
> w�tka o wy�szym priorytecie i wci�cie jest tam, gdzie fprintf robi ten
> parsing argument�w %d.
Bo nie masz tego jako atomic operation. Jestem na 99% pewny ze jako
atomic jest tylko zrobione wysylanie pojedynczych znakow.
Ma to sens, bo inaczej blokowalbys system na dosc dlugi czas (chyba ze
masz duze fifo - wtedy mozna sie o to pokusic).
> Task o priorytecie 3 schodki ni�ej, wci�� si� w �rodek fprintf'a od tasku
> o prawie najwy�szym priorytecie i to w miejscu, gdzie sko�czy�o si�
> parsowanie argumentu %x i zacz�� text printf'a.
Bo w miedzyczasie byla zmiana kontekstu. Czemu? Bo wyzszy watek czekal
na wyslanie znaku...
> Rozumiem, �e skoro wywo�ania fprintf'a z task�w dotycz� tego samego
> portu szeregowego, przekazanego fprintf'owi jako argument nazwy pliku
> (globalna zmienna) to mo�e si� co� kiep�ci�, i linie si� b�da przeplata�,
> ale nie rozumiem jak taski o ni�szym priorytecie mog�y si� wstrzeli�
> z TRZEMA OSOBNYMI WYWO�ANIAMI fprintf'a w jedn� lini� tasku
> o wy�szym priorytecie? Przecie� wed�ug filozofii MicroC/OS-II task
> bariery 0, w czasie chodzenia sobie po kodzie fprintfa nie powinien byďż˝
> przerwany i taski o priorytetach 4 czy tym bardziej 8 powinny grzecznie
> czeka� a� fprintf wywo�any przez task o priorytecie 1 uko�czy zadanie
> i odda sterowanie systemowi operacyjnemu (nie ma tu wyw�aszczania).
>
> Czy kto� m�g�by mi to wyt�umaczy�?
A jak w priority 0 wstawic OSTimeDly(10), to tez nic innego sie nie
uruchomi? AFAIR driver usart Altery czeka na signal jak ma pelny bufor,
wiec w miedzyczasie inny watek idzie.
--
Jerry1111
Pszemol
news:h9tsp1$pfi$1...@news.onet.pl...
> Wcale nie jest zakazana.
Dlatego uj��em to w cudzys��w :-)
> Bo tu nie chodzi o printf, tylko o reentrancje calej biblioteki newlib. Z
> drugiej strony Altera ma to zalatwione, wiec nie rozumiem czemu problem?
No tak to ma za�atwione �e wcina si� task 4 lub 7 w �rodek linii tasku 1.
> Bo nie masz tego jako atomic operation. Jestem na 99% pewny ze jako atomic
> jest tylko zrobione wysylanie pojedynczych znakow.
>
> Ma to sens, bo inaczej blokowalbys system na dosc dlugi czas (chyba ze
> masz duze fifo - wtedy mozna sie o to pokusic).
Dla dodania t�a do zagadnienia:
Fifo softwareowe jest 64 znaki. Uart pracuje z baud 115200
bez handshake i procesor NiosII-e biega z zegarem 80MHz...
Przerwy w linii od tasku 1 sďż˝ ZAWSZE przy granicy argumentu do
printfa (albo przed %d albo po). Nigdy nie przerywa w trakcie tak
aby urwa�o w �rodku wyrazu czy te� w �rodku zmiennej integer :-)
Dlatego nie bardzo mi si� chce wierzy�, �e kwestia jest w wysy�aniu
znak po znaku - raczej chodzi o parser printfa.
>> Task o priorytecie 3 schodki ni�ej, wci�� si� w �rodek fprintf'a od tasku
>> o prawie najwy�szym priorytecie i to w miejscu, gdzie sko�czy�o si�
>> parsowanie argumentu %x i zacz�� text printf'a.
>
> Bo w miedzyczasie byla zmiana kontekstu. Czemu?
> Bo wyzszy watek czekal na wyslanie znaku...
[...]
> A jak w priority 0 wstawic OSTimeDly(10), to tez nic innego sie nie
> uruchomi? AFAIR driver usart Altery czeka na signal jak ma pelny bufor,
> wiec w miedzyczasie inny watek idzie.
Oczywi�cie ni�sze taski mog� dzia�a� tylko wtedy gdy wy�szy czeka.
To wiem. Natomiast interesuj�ce jest �e przerwa i wci�cie si� niskiego
tasku w liniďż˝ wysokiego jest nie w przypadkowym miejjscu tylko
na granicy argumentu do printfa.
Zbych
> To jest oczywista oczywisto��, �e w�tek o priorytecie 1 czeka na port
> RS i oddaje sterowanie :-) Mnie interesuje jak to si� dzieje, �e w czasie
> gdy task 1 odda� sterowanie task 4 lub 7 by� wstanie trzy razy wys�a�
> lini� znak�w do RS'a trzema osobnymi wywo�aniami fprintfa...
Kto� na pme podpowiedzia� ci, �eby� sprawdzi�, czy prawid�owo ustawi�e�
priorytety w�tk�w. Od siebie dorzuc� tylko pytanie: czy ten system
gwarantuje ci, �e jak bufor RSa b�dzie wolny to w pierwszej kolejno�ci
dobierze si� do niego w�tek o najwy�szym priorytecie? A mo�e kto
pierwszy ten lepszy?
Pszemol
news:h9vmcj$4pm$1...@atlantis.news.neostrada.pl...
> Pszemol pisze:
>
>> To jest oczywista oczywisto��, �e w�tek o priorytecie 1 czeka na port
>> RS i oddaje sterowanie :-) Mnie interesuje jak to si� dzieje, �e w czasie
>> gdy task 1 odda� sterowanie task 4 lub 7 by� wstanie trzy razy wys�a�
>> lini� znak�w do RS'a trzema osobnymi wywo�aniami fprintfa...
>
> Kto� na pme podpowiedzia� ci, �eby� sprawdzi�, czy prawid�owo
> ustawi�e� priorytety w�tk�w.
Nie do ko�ca - on nazwa� mnie debilem :-) i zarzuci� �e task o priorytecie
zero jest najmniej wa�nym taskiem w systemie i z tego powodu - to co
obserwujďż˝ jest jak najbardziej naturalne. Zdemaskowaďż˝ tym w bardzo
niekulturalny spos�b sw�j brak zaznajomienia z systemem MicroC/OS-II.
W ksi��ce autorstwa Jean J. Labrosse "MicroC/OS-II" wydanie
drugie z 2002 roku stoi na stronie 88 jak byk:
"Each task is assigned a unique priority level between 0 and
OS_LOWEST_PRIO, inclusive (see OS_CFG.H). Task priority
OS_LOWEST_PRIO is always assigned to the idle task when
uC/OS-II is initialized."
M�j system jest skonfigurowany w taki spos�b, �e istnieje w nim
32 poziomy priorytet�w bo ustawione jest OS_LOWEST_PRIO=31.
Gdyby wci�� by�y jakie� w�tpliwo�ci co do tego kt�ry task wykona
si� wcze�niej a kt�ry p�niej warto zwr�ci� uwag� na ten fragment:
"To determine which priority (and thus which task) will run next,
the scheduler in uC-OS-II determines the lowest priority number
that has its bit set in OSRdyTbl[]."
> Od siebie dorzucďż˝ tylko pytanie: czy ten system gwarantuje ci,
> �e jak bufor RSa b�dzie wolny to w pierwszej kolejno�ci dobierze si� do
> niego w�tek o najwy�szym priorytecie?
> A mo�e kto pierwszy ten lepszy?
Ten RT system mia� mi gwarantowa�, �e w danym momencie czasu
wykonuje si� ten task spo�r�d task�w gotowych do dzia�ania kt�ry
ma najwy�szy priorytet. Ten warunek dotyczy zar�wno typowego
reschedulingu (funkcja OS_Sched()) jak i reschedulingu po
zako�czeniu obs�ugi przerwania. Na stronie 104 tej samej ksi�zki:
"The conclusion of the ISR is marked by calling OSIntExit(), which
decrements the interrupt nesting counter. When the nesting counter
reaches 0, all nested interrupts are complete, and uC/OS-II needs
to determine whether a higher priority task has been awakened by
the ISR (or any other nested ISR). If a higher priority task is ready
to run, uC/OS-II returns to the higher priority task rather than to
the interrupted task."
A wi�c wci�� nie rozumiem dlaczego w momencie gdy przysz�o
przerwanie od portu szeregowego (bo tylko w taki spos�b mog�o
si� zwolni� miejsce w buforze portu) funkcja obs�ugi przerwania
RS232 nie obudzi�a tasku 0 kt�ry czeka na to miejsce i scheduler
zawo�a� mi do tablicy task 4 lub task 7 zamiast wr�ci� do tasku 0.
To jest w�a�nie ca�a zagadka o kt�rej pr�buj� tu podyskutowa� :-)
jotefka
> To jest właśnie cała zagadka o której próbuję tu podyskutować :-)
Zamiast tracić czas na zagadkę, zaimplementuj własny system kontroli
dostępu do rs232.
Szczególnie ze to używasz do debugowania, wiec pewnie masz jakies
makra i chyba nie wołasz bezpośrednio printfa .
Pozdrawiam
Pszemol
news:38f7bb99-f904-4433...@g23g2000yqh.googlegroups.com...
>> To jest w�a�nie ca�a zagadka o kt�rej pr�buj� tu podyskutowa� :-)
>
> dost�pu do rs232.
> Szczeg�lnie ze to u�ywasz do debugowania, wiec pewnie masz jakies
> makra i chyba nie wo�asz bezpo�rednio printfa .
Bardziej mnie jednak interesuje rozwi�zanie tej zagadki bo mo�e
mieďż˝ to o wiele bardziej szerokie konsekwencje niďż˝ tylko debugger.
W projekcie tym u�ywam sporo port�w szeregowych do innych cel�w...
Pszemol
news:ha06ub$2gk$1...@inews.gazeta.pl...
> Czy ci si� to podoba czy nie problem mo�e wynika� z odwrotnej
> interpretacji
> numeru(!) priorytet�w. To prawda, �e w ksi��ce znajduje si� taki cytat,
> ale
> musisz sprawdzi�, wr�cz w kodach �r�d�owych, jak jest wybierany nast�pny
> task do uruchomienia.
W swoich logach mam bardzo cz�ste przypadki gdy task 0 wchodzi w lini�
od tasku 3, 4, czy 7, ale to mnie akurat nie dziwi�o, bo wiem jak s� u�o�one
priorytety w moim systemie operacyjnym :-)
> Dla pewnego systemu mam do wyboru albo MicroC/OS albo RTOS firmowy. Kernel
> RTOSa firmowego szereguje taski wg. rosn�cych priorytet�w tj. task 60
> wykona
> si� przed taskiem 41. Wg. logiki MicroC/OS powinno by� dok�adnie na odwr�t
> task 41 przed taskiem 60. Niemniej kod aplikacji w �adnym miejscu nie
> zawiera
> translacji priorytet�w (wg. logiki MicroC/OS przy 64 taskach task 60
> powinien
> dostaďż˝ priorytet 4, a task 41 priorytet 23) tak aby dopasowaďż˝ siďż˝ do
> MicroC/OS. Tak wi�c, albo u�ywasz ksi��ki niekompatybilnej z wersj� kodu
> �r�d�owego, albo facet sam nie wie co pisze.
To, �e Ty masz b��dy w programie i nie robisz translacji priorytet�w
u siebie pomiedzy dwoma systemami operacyjnymi nie znaczy wcale
�e wszyscy w ko�o Ciebie s� debilami... :-)
Wi�c proponuj� aby� douczy� si� najpierw zanim ponownie kogo�
nazwiesz debilem. Proponuj� aby� zerkn�� do encyklopedii pod has�em
http://en.wikipedia.org/wiki/MicroC/OS-II i doczytaďż˝ kto jest autorem
tego systemu operacyjnego potem por�wna� z autorem ksi��ki z kt�rej
cytowa�em fragment. Facet na pewno nie wie co pisze - dobre :-))))
Mam nadziej� �e po chwili zastanowienia si� odszczekasz to co tu
napisa�e�, przeprosisz mnie oficjalnie za przezwaniem debilem
i pobiegniesz poprawia� b��dy w swoim programie :-)
> Odszukaj scheduler i sprawd� jak jest naprawd�. To mo�e by� kwestia
> zamiany
> operat�w "<" i ">" w czasie klepania kodu shedulera a system b�dzie si�
> zachowywaďż˝ totalnie niezgodnie z oczekiwaniami. MicroC/OS jest raczej
> prostym
> systemem i nie ma powodu dla kt�rego mia�oby si� mu miesza� w opisywany
> przez ciebie spos�b.
Nie mam �ADNYCH, NAJMNIEJSZYCH nawet w�tpliwo�ci �e w systemie
MicroC/OS-II task o ni�szym numerze priorytetu ma wy�szy priorytet.
Cho�by z tego powodu, �e deklaracja sta�ej OS_LOWEST_PRIO jest 31
i wszystkie inne taski maj� numery priorytet�w mniejsze a jest ich 32.
I to si� wszystko zgadza z tym co napisano w ksi�zce a tak�e tym jak
og�lnie dzia�a m�j kod (z wyj�tkiem of coz zachowania si� funkcji fprint)
Proponuj� aby� Ty upewni� si� najpierw czy nie masz w�tpliwo�ci co
do tego jak s� te priorytety u�o�one zanim komu� znowu zarzucisz
�e jest debilem bo ma inaczej w programie ni� Ty. Moim zdaniem to
Ty masz odwr�cone priorytety w programie, nie ja.
DJ
> Wi�c proponuj� aby� douczy� si� najpierw zanim ponownie kogo�
> nazwiesz debilem.
Mo�e najpierw si� upewnij w 100% �e by�o adresowane do Ciebie zanim
zaczniesz prze�ywa� ;), bo ja odnosz� wra�enie, �e Jan Kowalski mia�
niejakie problemy z wysy�aniem posta w�wczas, i st�d by� mo�e polecia�
tekst "co za debil", kiedy wkurzy� si� na sw�j
pece/newsreader/cokolwiek.
--
DJ
PS. przy odpisywaniu na priv usun antyspamowy wpis z adresu
Pszemol
news:ha0fet$jon$6...@news.dialog.net.pl...
> On 2009-09-30 20:43:08 +0200, "Pszemol" <Psz...@PolBox.com> said:
>
>> Wi�c proponuj� aby� douczy� si� najpierw zanim ponownie kogo�
>> nazwiesz debilem.
>
> Mo�e najpierw si� upewnij w 100% �e by�o adresowane do Ciebie zanim
> zaczniesz prze�ywa� ;), bo ja odnosz� wra�enie, �e Jan Kowalski mia�
> niejakie problemy z wysy�aniem posta w�wczas, i st�d by� mo�e polecia�
> tekst "co za debil", kiedy wkurzy� si� na sw�j pece/newsreader/cokolwiek.
Nie b�de wnika� szczeg�owo co oznacza� ten post...
Gdyby nie chodzi�o o mnie to pad�oby przepraszam, a nie pad�o.
Przynajmniej jeszcze nie.
J.F.
news:h9sobc...@poczta.onet.pl...
> Ot� co widz�, to �e na wyj�ciu generowanym przez t� funkcj�
> fprintf
> (strumie� znak�w RS232, "plikiem" dla fprintf jest port
> szeregowy)
> widz� �e w�tek o ni�szym priorytecie wchodzi z butami w lini�
> tekstu
> w�tka o wy�szym priorytecie i wci�cie jest tam, gdzie fprintf
> robi ten
> parsing argument�w %d.
Nie znam systemu .. ale
-na pewno jest tak jak myslisz ? Moze to wyzszy priorytet sie
wcina, albo takie sa objawy niereentrowalnosci ?
-tak sie zastanawiam .. wyzszy priorytet wysyla bufor [zadania] i
zawisa gdzies na porcie szeregowym. przelaczamy na drugie zadanie,
ktore dochodzi do wysylania, bufor portu zajety .. ale byc moze
zdazylo juz zarejestrowac chec wyslania. I teraz gdzies po
przerwaniu od portu zostanie ten bufor drugiego zadania wyslany ?
> Rozumiem, �e skoro wywo�ania fprintf'a z task�w dotycz� tego
> samego
> portu szeregowego, przekazanego fprintf'owi jako argument nazwy
> pliku
> (globalna zmienna) to mo�e si� co� kiep�ci�, i linie si� b�da
> przeplataďż˝,
> ale nie rozumiem jak taski o ni�szym priorytecie mog�y si�
> wstrzeliďż˝
> z TRZEMA OSOBNYMI WYWO�ANIAMI fprintf'a w jedn� lini� tasku
> o wy�szym priorytecie?
czekaj .. a fprintf nie ma jakiegos bufora roboczego ?
> Przecie� wed�ug filozofii MicroC/OS-II task
> bariery 0, w czasie chodzenia sobie po kodzie fprintfa nie
> powinien byďż˝
> przerwany i taski o priorytetach 4 czy tym bardziej 8 powinny
> grzecznie
> czeka� a� fprintf wywo�any przez task o priorytecie 1 uko�czy
> zadanie
> i odda sterowanie systemowi operacyjnemu (nie ma tu
> wyw�aszczania).
Tylko ze on moze oddac w trakcie printf, wlasnie czekajac na port
szeregowy.
Bez zrodel sie nie dowiesz :-)
J.
Artur M. Piwko
DJ <johnny12-...@poczta.onet.pl> screamed:
>> Więc proponuję abyś douczył się najpierw zanim ponownie kogoś
>> nazwiesz debilem.
>
> Może najpierw się upewnij w 100% że było adresowane do Ciebie zanim
> zaczniesz przeżywać ;), bo ja odnoszę wrażenie, że Jan Kowalski miał
> niejakie problemy z wysyłaniem posta wówczas, i stąd być może poleciał
> tekst "co za debil", kiedy wkurzył się na swój
> pece/newsreader/cokolwiek.
>
Tak czy inaczej odpisał komu odpisał i mógłby coś z tym zrobić...
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:222B ]
[ 08:11:31 user up 12213 days, 20:06, 1 user, load average: 0.50, 0.95, 0.77 ]
In God we trust; all else we walk through.
AK
> "jotefka" <solit...@googlemail.com> wrote in message
> news:38f7bb99-f904-4433...@g23g2000yqh.googlegroups.com...
>>
>> Zamiast tracić czas na zagadkę, zaimplementuj własny system kontroli
>> dostępu do rs232.
>> makra i chyba nie wołasz bezpośrednio printfa .
>
> Bardziej mnie jednak interesuje rozwiązanie tej zagadki bo może
> mieć to o wiele bardziej szerokie konsekwencje niż tylko debugger.
> W projekcie tym używam sporo portów szeregowych do innych celów...
A ten task o wysokim priorytecie nie czeka na jakies zdarzenia czasami ?
Albo moze bierze te same semafory/muteksy co task o niskim priorytecie ?
Jesli tak to moze nastapic 'priority inheritance' - jesli jest to
wspierane przez uCOS - tego nie wiem.
Pozdr
AK
Jerry1111
Ma wspierane, tylko tego nigdzie w printf nie widac. A przerywany jest
jeden printf, wiec cos albo w printf albo w driverze uart sie dzieje.
--
Jerry1111
Pszemol
news:hb2q4s$g77$1...@inews.gazeta.pl...
Task o wysokim priorytecie zawołał printfa i na nic więcej nie czeka.