Pszemol wrote:
>> Kurcze, nie widze tego. Ale nie widze tez swojej odpowiedzi z wczoraj
>> - ciekawe czemu.
>
> A ja widzę obie :-)

Magia.

>>> 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.
>>
>> Zaciekawilo mnie (bo ja wiem ze Nios czasem przerywa sobie printfy -
>> mi to nie przeszkadza) czemu tak sie dzieje. Popatrzylem na zrodla
>> drivera uart w Nios 9.0 i tam nie ma OSIntExit pod koniec
>> altera_avalon_uart_rxirq().
>
> rxirq() wołane jest z ogólnego handlera przerwania od portu
> szeregowego gdzie jest sprawdzany status register i wywoływane
> są poszczególne procedury skoku do txirq lub rxirq().

Tak, ale nigdzie OS nie jest informowany ze aktualnie obslugujemy
przerwanie... Na poczatku (AFAIR) ma byc OSIntEnter(), a na koncu ma byc
OSIntExit(). Powinno to byc odpowiednio na poczatku/koncu ogolnego
przerwania gdzie sprawdza status register - a nic tam nie ma. Jedyne
odwolania do OSa w tx to flaga ze w txbuf jest miejsce.

>>> 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ć :-)
>>
>> ;-)
>> Jak Ci sie chce to przesledz krok po kroku co fprintf wyczynia i
>> szukaj podejrzanych miejsc. Z doswiadczenia z wczesniejszych wersji -
>> drivery Altery sa niestety troche dodupne jesli chodzi o RTOS.
>>
>> Aha, ja uzywam fifoed_avalon_uart zamiast oryginala - duzo
>> mniejszy bol glowy.
>
> No tak chyba trzeba będzie zrobić...
>
> A tak w ogóle to jak Ty sobie radzisz z obsługą takich debug messages
> z różnych tasków w wielozadaniowym systemie?

Fifoed z 2kb hardware txbuf ;-)
Krzaki wyskakuja rzadko, wiec sie nie przejmuje.
Na rx tez dobrze dac bufor - mocno odciaza procka jak masz troche danych
do odebrania.

> Masz jakiś fajny
> pomysł który chciałbyś tu sprzedać koledze? ;-) Bo właśnie planuję to
> przerobić i chodzi mi kilka po głowie pomysłów ale żaden mi się
> bardzo nie podoba :-)))) Chcialbym przede wszystkim uniknac alokacji
> dynamicznej pamieci, bo to sie wylozy wczesniej niz pozniej...
> Na razie mam statyczne teksty z messages w kodzie taskow ale wrzucam
> je intensywnie do fprintfa aby wypelnic konkretnymi danymi,

Poprobuj sprintf i write - moze bedzie lepiej. Ja tak robie tekstowe
transmisje. ZTCP to port otwieram jako O_NONBLOCK (ale tu tez trza
sprawdzic jak lepiej sie zachowuje z przerywaniem danych - pamietam ze
cos tam bylo).

> wiec potem
> wypadaloby ten strumien gdzies wyslac dalej... Moze sobie
> zrobie jakis fikcyjny port szeregowy ktory zamiast fizycznie znaki
> wysylac bedzie sobie je "kolejkowal" do wyslania przez task #29... hm...

Myslalem o kolejce - duzo mocy zje, albo trzeba by pointery pamietac do
calych messages (a to implikuje pamiec dynamiczna).
Inny problem jest taki, ze bufor musisz miec wiekszy niz max. ilosc
messagow do wyslania, bo inaczej watek bedzie stal i czekal na wolny
bufor tx. Dlatego zaczalem uzywac fifoed uarta - duzo pomaga.


--
Jerry1111