NutEnterCriticalLevel

Hello,

this is to continue a discussion with Dušan in public about problems seen
with M68k and critical sections.

>>>>> "Dušan" == Dušan  <[email protected]> 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

-- 
Uwe Bonnes                bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion