[En-Nut-Discussion] Re: [btnode-development] Re: Nut/OS goes Real-Time?

[Matthias Ringwald]

Hi Lukas,

thanks for your information. Do you guys up there have even more  
stuff in the pipe?

> We found out by tracing the interrupts with a 'KO' that it is possible
> that other Interrupts/Critical Sections still can block UART1  
> interrutps
> for quite a long time, leading to the overrun problem.
>
> We then hacked the Nut/OS UART interrupts such that the normal  
> indirection
>
> Interrupt SIGNAL -> CallHandler() -> InterruptHandler()
>
> is reduced to
>
> Interrupt SIGNAL
>
> by copy/pasting the interrupt handlers directly into the SIGNAL
> definitions :)
>
> The overhead of calling two functions in an interrupt handler seems to
> be quite big:
>
> Interrupt UART1_RXCOMPL:
> Measured execution time as normal Nut/OS NUTSIGNAL Interrupt: 43.6 us
> Measured execution time as direct SIGNAL: 24.4 us
>
> This actually halfed(!) UART interrupt execution time and seems to  
> solve
> the overrun problems.

wow. did you try going for 115 kB on the BT UART?

Hm. I'm wondering a bit, if 2 calls really result in 20 us (on 7.3 Mhz)
as this would be around 140 Operations. BUt it is good if it works.

> This could be done for all interrupts quite easily reducing every
> interrupt execution by ~20us, however, the flexible Nut/OS interrupt
> registration mechanism gets lost...
At least for BTnut, the IRQs for UART can be fixed without lack
of generality, I'd say.

>
> I attached a patch file that applies to current Nut/OS CVS HEAD
> containing our quick & dirty changes for those that are interested.
> -- URL : http://lists.ee.ethz.ch/p/uart_interrupt.patch

I've had a look at the patch. Maybe the // in ivetctXX.c is not
necessary, if those IRQs are not registered using NutRegisterIrqHandler.


>
> Actually, we've found that there are still some longer Critical  
> Sections
> around. E.g. there is the Critical Section in NutEventPost() which  
> took
> up to 80 us in my test run, although I don't know why.

Are you using curren Nut/OS HEAD?
Did you use timers (i.e. NutTimerStopAsync might be called?)
Still I don't see how this should sum up to 80 us.

Did you found more/other long Critical Sections?

Let's use a calculator. For 230 kB, we would get one byte every 34 uS,
so it wouldn't be possible with default IRQ handler. ouch. At 115 kB,
with 68 uS, at receiving or sending should work, both at the same time
would break. So, half duplex might be useful: Don't send while  
receiving.
I guess investigation into why the RX handler takes that
time would be interesting. And there is still my uart block read
implementation, which bypasses the ringbuffer and also checking for
overruns. It should decrease the 24.4 us even further.


cheers,
Matthias