"Jerry1111" <j...@w...pl.pl.wp> wrote in message
news:ha0f1t$cf0$1@news.onet.pl...
> Pszemol wrote:
>> "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 :-)
>
> Kurcze, nie widze tego. Ale nie widze tez swojej odpowiedzi z wczoraj -
> ciekawe czemu.

A ja widzę obie :-)
news:h9vede$eis$1@inews.gazeta.pl jest tutaj:
http://groups.google.com/group/pl.misc.elektronika/b
rowse_thread/thread/69dec27c4f4b27e1/d16af0ab629ffa6
3?hl=en&q=
Inny wątek bo Jan nie umie sobie poradzić ze swoim komputerem.

A Twoja wczorajsza news:h9tsp1$pfi$1@news.onet.pl jest tutaj:
http://groups.google.com/group/pl.comp.programming/m
sg/fdb55229b48bd73f?hl=en

>>> 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?
>
> Bylo o tym w ksiazce, ale kniga w robocie.
>
>>> 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.
>
> 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().

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