Pszemol wrote:
> 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