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