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... :-)

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ć?

do góry

"Zbych" <a...@o...pl> wrote in message
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ć :-)

do góry

>
> 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

do góry

"jotefka" <s...@g...com> wrote in message
news:38f7bb99-f904-4433-9b1a-6d6c13de57be@g23g2000yq
h.googlegroups.com...
>> 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 .

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...

do góry

Pszemol <P...@P...com> napisał(a):

> "Zbych" <a...@o...pl> wrote in message
> 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."

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.

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.

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.

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

"Jan Kowalski" <c...@N...gazeta.pl> wrote in message
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.

do góry

Pszemol wrote:
> "Zbych" <a...@o...pl> wrote in message
> 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 :-)

Kurcze, nie widze tego. Ale nie widze tez swojej odpowiedzi z wczoraj -
ciekawe czemu.

> 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.

;-)

>> 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?

Bylo o tym w ksiazce, ale kniga w robocie.

>> 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.

Zaciekawilo mnie (bo ja wiem ze Nios czasem przerywa sobie printfy - mi
to nie przeszkadza) czemu tak sie dzieje. Popatrzylem na zrodla drivera
uart w Nios 9.0 i tam nie ma OSIntExit pod koniec
altera_avalon_uart_rxirq().

> 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ć :-)

;-)
Jak Ci sie chce to przesledz krok po kroku co fprintf wyczynia i szukaj
podejrzanych miejsc. Z doswiadczenia z wczesniejszych wersji - drivery
Altery sa niestety troche dodupne jesli chodzi o RTOS.

Aha, ja uzywam fifoed_avalon_uart zamiast oryginala - duzo mniejszy bol
glowy.

--
Jerry1111

do góry

On 2009-09-30 20:43:08 +0200, "Pszemol" <P...@P...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.

--
DJ

PS. przy odpisywaniu na priv usun antyspamowy wpis z adresu

do góry

"DJ" <j...@p...onet.pl> wrote in message
news:ha0fet$jon$6@news.dialog.net.pl...
> On 2009-09-30 20:43:08 +0200, "Pszemol" <P...@P...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.

do góry

"Jerry1111" <j...@w...pl.pl.wp> wrote in message
news:ha0f1t$cf0$1@news.onet.pl...
> Pszemol wrote:
>> "Zbych" <a...@o...pl> wrote in message
>> 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 :-)
>
> Kurcze, nie widze tego. Ale nie widze tez swojej odpowiedzi z wczoraj -
> ciekawe czemu.

A ja widzę obie :-)
news:h9vede$eis$1@inews.gazeta.pl jest tutaj:
http://groups.google.com/group/pl.misc.elektronika/b
rowse_thread/thread/69dec27c4f4b27e1/d16af0ab629ffa6
3?hl=en&q=
Inny wątek bo Jan nie umie sobie poradzić ze swoim komputerem.

A Twoja wczorajsza news:h9tsp1$pfi$1@news.onet.pl jest tutaj:
http://groups.google.com/group/pl.comp.programming/m
sg/fdb55229b48bd73f?hl=en

>>> 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?
>
> Bylo o tym w ksiazce, ale kniga w robocie.
>
>>> 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.
>
> Zaciekawilo mnie (bo ja wiem ze Nios czasem przerywa sobie printfy - mi to
> nie przeszkadza) czemu tak sie dzieje. Popatrzylem na zrodla drivera uart
> w Nios 9.0 i tam nie ma OSIntExit pod koniec altera_avalon_uart_rxirq().

rxirq() wołane jest z ogólnego handlera przerwania od portu
szeregowego gdzie jest sprawdzany status register i wywoływane
są poszczególne procedury skoku do txirq lub rxirq().

>> 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ć :-)
>
> ;-)
> Jak Ci sie chce to przesledz krok po kroku co fprintf wyczynia i szukaj
> podejrzanych miejsc. Z doswiadczenia z wczesniejszych wersji - drivery
> Altery sa niestety troche dodupne jesli chodzi o RTOS.
>
> Aha, ja uzywam fifoed_avalon_uart zamiast oryginala - duzo
> mniejszy bol glowy.

No tak chyba trzeba będzie zrobić...

A tak w ogóle to jak Ty sobie radzisz z obsługą takich debug messages
z różnych tasków w wielozadaniowym systemie? Masz jakiś fajny
pomysł który chciałbyś tu sprzedać koledze? ;-) Bo właśnie planuję to
przerobić i chodzi mi kilka po głowie pomysłów ale żaden mi się
bardzo nie podoba :-)))) Chcialbym przede wszystkim uniknac alokacji
dynamicznej pamieci, bo to sie wylozy wczesniej niz pozniej...
Na razie mam statyczne teksty z messages w kodzie taskow ale wrzucam
je intensywnie do fprintfa aby wypelnic konkretnymi danymi, wiec
potem wypadaloby ten strumien gdzies wyslac dalej... Moze sobie
zrobie jakis fikcyjny port szeregowy ktory zamiast fizycznie znaki
wysylac bedzie sobie je "kolejkowal" do wyslania przez task #29... hm...

do góry