[En-Nut-Discussion] NutEnterCriticalLevel

[Dušan]

Hi Uwe,

sounds like some smileys appear :-).

After reading your arguments I started to think - wow, why not to have 
our life easier?

But the priority level is one thing, if we forget about it, then we have 
the condition codes inside the status word.
And this must be preserved during interrupt processing.
So the goal is not to preserve priority level only, but to preserve 
condition codes.
And if ccodes, then why not to preserve also priority level :-).

So I think we need to store status word somewhere and a register is an 
ideal place for it.
What about having UseCritical for other platforms empty?*
*

*Dušan*

On 12.1.2018 18:29, Uwe Bonnes wrote:
> Hello,
>
> this is to continue a discussion with Dušan in public about problems seen
> with M68k and critical sections.
>
>>>>>> "Dušan" == Dušan  <dferbas at solarmonitor.cz> writes:
>      Dušan> Uwe, please look in the
>      Dušan> arch\m68k\coldfire\dev\mcf5225\mcf5225_old_i2c.c and arch\
>      Dušan> m68k\coldfire\dev\mcf5225\mcf5225_old_uart.c.
>
> Oops, I did something wrong while grepping.
>
> For both examples, there is no nesting of NutEnterCriticalLevel() with other
> NutEnterCriticalLevel() or NutEnterCritical(). And
> there are no scheduling point in the code (NutSleep, WaitFor...),
> so no other thread can run in the meantime and mess up the interrupt mask
> level.
> Only interrupt code may run. And I asume you don't use
> NutEnterCriticalXXX in your interrupt code :-)
>
> So you always enter with level = 0 into NutEnterCriticalLevel(level) and you
> always exit out of NutExitCritical() again with level 0. I still see no need
> to store the interrupt mask level.
>
> In the two examples above I wonder why you even need
> NutEnterCriticalLevel(level) at all. I think normal Critical section,
> disabling all interrupts would work too. Codes inside the critical section
> seems to be small and the mcf5225 seems to run with > 70 Mhz. Is
> sub-microsecond interrupt response really needed for the peripherals you
> allow inside the CriticalLevel section?
>
>      Dušan> When I think about this, I need to store status word (interrupt
>      Dušan> level) into a register, because this is the fastest way for
>      Dušan> context switching.
>
> Not pushing and poping unneeded item also speeds up things.
>
>      Dušan> Now let me imagine a thread, working with I2C (mostly EEPROM in
>      Dušan> our case), which enters its "thread" critical state (the OS
>      Dušan> critical state is always uninteruptible).  It is interrupted with
>      Dušan> ethernet task, which uses NutEnterCritical itself (maybe we can
>      Dušan> think about allowing pulse inputs and timers to interrupt even
>      Dušan> ethernet thread).  We now store the I2C int level in _savpri
>      Dušan> register and we restore it, when an OS call returns from its
>      Dušan> critical state.
>
> In my understanding, NutOs only switches threads, when the thread active
> yields. NutOs is not prementive!
> Yield happens at scheduling points, but in the guarded code in
> mcf5225_old_i2c.c and mcf5225_old_uart.c there are no scheduling points.
>
>      Dušan> If a thread with USART driver is interrupted in its "thread"
>      Dušan> critical state, the USART int level is stored in a register.
>
> Think about my argument about scheduling points...
>
>      Dušan> ----------------- P.S. As I am writing these emails, I realized
>      Dušan> we have SPI at level 1, which is lower than UART.  So this is
>      Dušan> from times, we were using SPI flash.  Now instead of flash, we
>      Dušan> are using SD card (over 1 SPI).  Do you know, if there is
>      Dušan> something time critical during sending commands to an SD card?
>
> I don't know about timeouts in the SD card sepcification. On cursory tests,
> even bitbanging IO to a SDCard worked.
>
>
>      Dušan> P.P.S. If you want, we can move our discussion about Nut/OS to
>      Dušan> Ethernut mail list?
>
> Done!
>
> Bye
>