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

do góry

In the darkest hour on Wed, 30 Sep 2009 22:35:46 +0200,
DJ <j...@p...onet.pl> screamed:
>> Więc proponuję abyś douczył się najpierw zanim ponownie kogoś
>> nazwiesz debilem.
>
> Może najpierw się upewnij w 100% że było adresowane do Ciebie zanim
> zaczniesz przeżywać ;), bo ja odnoszę wrażenie, że Jan Kowalski miał
> niejakie problemy z wysyłaniem posta wówczas, i stąd być może poleciał
> tekst "co za debil", kiedy wkurzył się na swój
> pece/newsreader/cokolwiek.
>

Tak czy inaczej odpisał komu odpisał i mógłby coś z tym zrobić...

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:222B ]
[ 08:11:31 user up 12213 days, 20:06, 1 user, load average: 0.50, 0.95, 0.77 ]

In God we trust; all else we walk through.

do góry

Pszemol pisze:
> "jotefka" <s...@g...com> wrote in message
> news:38f7bb99-f904-4433-9b1a-6d6c13de57be@g23g2000yq
h.googlegroups.com...
>>> To jest właśnie cała zagadka o której próbuję tu podyskutować :-)
>>
>> Zamiast tracić czas na zagadkę, zaimplementuj własny system kontroli
>> dostępu do rs232.
>> Szczególnie ze to używasz do debugowania, wiec pewnie masz jakies
>> makra i chyba nie wołasz bezpośrednio printfa .
>
> Bardziej mnie jednak interesuje rozwiązanie tej zagadki bo może
> mieć to o wiele bardziej szerokie konsekwencje niż tylko debugger.
> W projekcie tym używam sporo portów szeregowych do innych celów...
A ten task o wysokim priorytecie nie czeka na jakies zdarzenia czasami ?
Albo moze bierze te same semafory/muteksy co task o niskim priorytecie ?
Jesli tak to moze nastapic 'priority inheritance' - jesli jest to
wspierane przez uCOS - tego nie wiem.

Pozdr
AK

do góry

AK wrote:
> Pszemol pisze:
>> "jotefka" <s...@g...com> wrote in message
>> news:38f7bb99-f904-4433-9b1a-6d6c13de57be@g23g2000yq
h.googlegroups.com...
>>>> To jest właśnie cała zagadka o której próbuję tu podyskutować :-)
>>>
>>> Zamiast tracić czas na zagadkę, zaimplementuj własny system kontroli
>>> dostępu do rs232.
>>> Szczególnie ze to używasz do debugowania, wiec pewnie masz jakies
>>> makra i chyba nie wołasz bezpośrednio printfa .
>>
>> Bardziej mnie jednak interesuje rozwiązanie tej zagadki bo może
>> mieć to o wiele bardziej szerokie konsekwencje niż tylko debugger.
>> W projekcie tym używam sporo portów szeregowych do innych celów...
> A ten task o wysokim priorytecie nie czeka na jakies zdarzenia czasami ?
> Albo moze bierze te same semafory/muteksy co task o niskim priorytecie ?
> Jesli tak to moze nastapic 'priority inheritance' - jesli jest to
> wspierane przez uCOS - tego nie wiem.

Ma wspierane, tylko tego nigdzie w printf nie widac. A przerywany jest
jeden printf, wiec cos albo w printf albo w driverze uart sie dzieje.


--
Jerry1111

do góry

"AK" <a...@g...pl> wrote in message
news:hb2q4s$g77$1@inews.gazeta.pl...
> Pszemol pisze:
>> "jotefka" <s...@g...com> wrote in message
>> news:38f7bb99-f904-4433-9b1a-6d6c13de57be@g23g2000yq
h.googlegroups.com...
>>>> To jest właśnie cała zagadka o której próbuję tu podyskutować :-)
>>>
>>> Zamiast tracić czas na zagadkę, zaimplementuj własny system kontroli
>>> dostępu do rs232.
>>> Szczególnie ze to używasz do debugowania, wiec pewnie masz jakies
>>> makra i chyba nie wołasz bezpośrednio printfa .
>>
>> Bardziej mnie jednak interesuje rozwiązanie tej zagadki bo może
>> mieć to o wiele bardziej szerokie konsekwencje niż tylko debugger.
>> W projekcie tym używam sporo portów szeregowych do innych celów...
> A ten task o wysokim priorytecie nie czeka na jakies zdarzenia czasami ?
> Albo moze bierze te same semafory/muteksy co task o niskim priorytecie ?
> Jesli tak to moze nastapic 'priority inheritance' - jesli jest to
> wspierane przez uCOS - tego nie wiem.

Task o wysokim priorytecie zawołał printfa i na nic więcej nie czeka.

do góry

"Jerry1111" <j...@w...pl.pl.wp> wrote in message
news:ha0ka1$pnp$1@news.onet.pl...
>>> 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.

Przy okazji innego problemu z innym projektem pod Niosem
wszedłem sobie debuggerem do kodu i co widzę? Ano INT_EXIT():

/*
* alt_irq_handler() is called by the interrupt exception handler in order
to
* process any outstanding interrupts.
*
* It is defined here since (in the case of nios2) it is linked in using
weak
* linkage. This means that if there is never a call to alt_irq_register()
* (above) then this function will not get linked in to the executable. This
is
* acceptable since if no handler is ever registered, then an interrupt can
never
* occur.
*
* If Nios II interrupt vector custom instruction exists, use it to
accelerate
* the dispatch of interrupt handlers. The Nios II interrupt vector custom
* instruction is present if the macro ALT_CI_INTERRUPT_VECTOR defined.
*/

void alt_irq_handler (void) __attribute__ ((section (".exceptions")));
void alt_irq_handler (void)
{
#ifdef ALT_CI_INTERRUPT_VECTOR
alt_32 offset;
char* alt_irq_base = (char*)alt_irq;
#else
alt_u32 active;
alt_u32 mask;
alt_u32 i;
#endif /* ALT_CI_INTERRUPT_VECTOR */

/*
* Notify the operating system that we are at interrupt level.
*/

ALT_OS_INT_ENTER();

#ifdef ALT_CI_INTERRUPT_VECTOR
/*
* Call the interrupt vector custom instruction using the
* ALT_CI_INTERRUPT_VECTOR macro.
* It returns the offset into the vector table of the lowest-valued
pending
* interrupt (corresponds to highest priority) or a negative value if
none.
* The custom instruction assumes that each table entry is eight bytes.
*/
while ((offset = ALT_CI_INTERRUPT_VECTOR) >= 0) {
struct ALT_IRQ_HANDLER* handler_entry =
(struct ALT_IRQ_HANDLER*)(alt_irq_base + offset);

handler_entry->handler(handler_entry->context, offset >> 3);
}
#else
/*
* Obtain from the interrupt controller a bit list of pending interrupts,
* and then process the highest priority interrupt. This process loops,
* loading the active interrupt list on each pass until alt_irq_pending()
* return zero.
*
* The maximum interrupt latency for the highest priority interrupt is
* reduced by finding out which interrupts are pending as late as
possible.
* Consider the case where the high priority interupt is asserted during
* the interrupt entry sequence for a lower priority interrupt to see why
* this is the case.
*/

active = alt_irq_pending ();

do
{
i = 0;
mask = 1;

/*
* Test each bit in turn looking for an active interrupt. Once one is
* found, the interrupt handler asigned by a call to alt_irq_register()
is
* called to clear the interrupt condition.
*/

do
{
if (active & mask)
{
alt_irq[i].handler(alt_irq[i].context, i);
break;
}
mask <<= 1;
i++;

} while (1);

active = alt_irq_pending ();

} while (active);
#endif /* ALT_CI_INTERRUPT_VECTOR */

/*
* Notify the operating system that interrupt processing is complete.
*/

ALT_OS_INT_EXIT();
}

do góry

Pszemol wrote:
> "Jerry1111" <j...@w...pl.pl.wp> wrote in message
> news:ha0ka1$pnp$1@news.onet.pl...
>>>> 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.
>
> Przy okazji innego problemu z innym projektem pod Niosem
> wszedłem sobie debuggerem do kodu i co widzę? Ano INT_EXIT():

Heh, nie rozumiem czemu tego w debuggerze nie widzialem...
Dzieki ;-)


--
Jerry1111

do góry