"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();
}