"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

"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

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

Użytkownik "Pszemol" <P...@P...com> napisał w wiadomości
news:h9sobc.3s8.0@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.

do góry

In the darkest hour on Wed, 30 Sep 2009 22:35:46 +0200,
DJ <j...@p...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.

do góry

Pszemol pisze:
> "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...
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

do góry

AK wrote:
> Pszemol pisze:
>> "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...
> 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.

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

do góry