"Jerry1111" <j...@w...pl.pl.wp> wrote in message
news:h9tsp1$pfi$1@news.onet.pl...
> Wcale nie jest zakazana.

Dlatego ująłem to w cudzysłów :-)

> Bo tu nie chodzi o printf, tylko o reentrancje calej biblioteki newlib. Z
> drugiej strony Altera ma to zalatwione, wiec nie rozumiem czemu problem?

No tak to ma załatwione że wcina się task 4 lub 7 w środek linii tasku 1.

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

Dla dodania tła do zagadnienia:
Fifo softwareowe jest 64 znaki. Uart pracuje z baud 115200
bez handshake i procesor NiosII-e biega z zegarem 80MHz...

Przerwy w linii od tasku 1 są ZAWSZE przy granicy argumentu do
printfa (albo przed %d albo po). Nigdy nie przerywa w trakcie tak
aby urwało w środku wyrazu czy też w środku zmiennej integer :-)
Dlatego nie bardzo mi się chce wierzyć, że kwestia jest w wysyłaniu
znak po znaku - raczej chodzi o parser printfa.

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

Oczywiście niższe taski mogą działać tylko wtedy gdy wyższy czeka.
To wiem. Natomiast interesujące jest że przerwa i wcięcie się niskiego
tasku w linię wysokiego jest nie w przypadkowym miejjscu tylko
na granicy argumentu do printfa.