Pszemol pisze:

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