Paypal | 13 Mar 19:54 2014
Picon

Your account has been limited until we hear from you

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<title></title>
<style type="text/css">
.style1 {
	color: rgb(38, 143, 210);
}
.style2 {
	color: rgb(51, 51, 51);
}
.style3 {
	font-size: x-small;
	color: rgb(170, 173, 180);
}
.style4 {
	color: rgb(16, 70, 123);
	font-size: small;
}
.style5 {
	font-size: 7pt;
	color: rgb(170, 173, 180);
}
.style6 {
	color: rgb(16, 70, 123);
}
.style7 {
	text-decoration: none;
(Continue reading)

Kelvin Lawson | 16 Dec 00:49 2010

Re: CRITICAL sections a possible cause for interrupt latency

Hi Matthew,

Good to hear from you.

> It seems that there are some large chunks of code and in quite a few places
> that are encompassed by the CRITICAL_START and CRITICAL_STOP macros.
>
> This is a concern as it means that any interrupts that come in could have a
> potentially unacceptable delay before they are processed (interrupt
> latency).
>
> From what I can tell the CRITICAL sections are to protect the moving of the
> TCBs from one queue to the next.
>
> Is there a better way of protecting this or designing out the issue of
> protection?
>
> My current thoughts are to change the CRITICAL_START and CRITICAL_STOP to
> only mask the scheduler timer interrupt therefore allowing the other
> interrupts to be processed, can you see a problem with this?
>
> But I’m also hoping to find a better solution that requires even less
> interrupt downtime.

The critical sections allow RTOS structures to be safely modified by
ISRs, for example moving TCBs on to queues as you identified. The
problem with disabling only the timer interrupt is that it would
prevent other (non-timer) ISRs from interacting with the RTOS (for
example incrementing a semaphore to signal from an ISR to a task).

(Continue reading)

Mathew Swaffield | 9 Dec 18:45 2010

CRITICAL sections a possible cause for interrupt latency

Hi All,

 

I’ve been porting atomThreads for use on an MSP430X but I have some concerns regarding the CRITICAL sections.

 

Currently I’ve copied what has been done in the existing ports where the global interrupt flag is disabled and reinstated where necessary.

It seems that there are some large chunks of code and in quite a few places that are encompassed by the CRITICAL_START and CRITICAL_STOP macros.

This is a concern as it means that any interrupts that come in could have a potentially unacceptable delay before they are processed (interrupt latency).

 

From what I can tell the CRITICAL sections are to protect the moving of the TCBs from one queue to the next.

Is there a better way of protecting this or designing out the issue of protection?

My current thoughts are to change the CRITICAL_START and CRITICAL_STOP to only mask the scheduler timer interrupt therefore allowing the other interrupts to be processed, can you see a problem with this?

But I’m also hoping to find a better solution that requires even less interrupt downtime.

 

Best regards

Mathew

Kelvin Lawson | 1 Jun 21:05 2010

Re: Port to 32 bits architecture and context switches

Hi Romain,

Good to hear from you.

> I'm an embedded software and research engineer in Switzerland and I'm
> currently working on a project involving a ultra-low power CPU/SoC.
> This chip has a 32 bits architecture and common peripherals found in
> many other architectures (timers, UART, vectorized interrupts,...) and
> some more advanced features (DMA, RF radio, ...).

Sounds very interesting.

> We already have a working toolchain (GCC, binutils, ...) for that
> architecture as well as a working libc (newlib). We can currently
> develop bare-metal/standalone applications but we would really
> appreciate to have a small-footprint RTOS also running on it. Googling
> around AtomThreads sounded a well suited alternative (compact, easy to
> port, ...). I carefully read the online documentation and comments in
> sources but some questions remain open for moment. Perhaps you can
> clear some of them ?
>
> * 32 bits architecture
> AtomThreads is currently officially supported on AVR and STM8
> platforms. Both of them are 8 bits architectures. I read that a
> Cortex-M3 port is on road or at least planed. I didn't find any
> obvious reason why AtomThreads could not run on a 32 bits architecture
> and assume that ( provided that I correctly implement the architecture
> specific functions :-) ) AtomThreads would run correctly on 32 bits
> arch. Did you already try to run AT on a 32 bits CPU (even a
> "quick&dirty" port) ? Are there any caveats to take into consideration
> ?

I did some early work on a Cortex M3 port (STM32) but put it on hold
briefly to add support for the IAR STM8 compiler. That support is
almost complete so I should get back onto the Cortex M3 port shortly.
Meanwhile I have heard that others are working on Cortex M3 and ARM9
ports.

I expect that a 32 bit architecture port would require no changes to
the core kernel, except that thread stacks are not forced to 32-bit
alignment. I was planning to add a macro to atomport.h (something like
ATOM_STACK_ALIGN) which could be set differently for each
architecture. The atomThreadCreate() function could then apply a
fix-up if badly aligned stack pointers are passed in.

Other than this I don't see any other likely issues with 32-bit
architectures, but I have yet to get one going myself.

> * context switches
> I'm still not sure I understood correctly how context switches really
> work especially how they return back to the "scheduled in" thread. I
> read Kelvin's explanations in his post to the list on 7 Apr 23:15
> (http://permalink.gmane.org/gmane.os.atomthreads/9) but I'm still a
> bit confused ...
> If I understand correctly archContextSwitch is *always* called from
> atomThreadSwitch() and this independently of the type of context
> switch (cooperative: atomTimerDelay(), or preemptive: through timer
> interrupt handler). Therefore archContextSwitch will *always* return
> through atomThreadSwitch() and then roll-out the call tree saved on
> stack when the thread was scheduled out. Is that correct?

Yes that is how it has worked out on the two architectures currently
completed (AVR and STM8), however it is unlikely to be the best way to
do it on all architectures (for example there is specific support for
operating systems in Cortex M3 that would not match the scheme used on
those ports). There may be slight changes required to the kernel for
such architectures.

FYI the general scheme with AVR and STM8 is that because
archContextSwitch() is always called from C code, it does not need to
save scratch registers (those registers which the compiler does not
expect to be preserved by a called function). This works out quite
nicely on AVR and STM8, limiting the number of registers which need to
be saved for cooperative context switches (where a thread schedules
itself out). It can work out that only a subset of registers end up
being saved on the thread's stack. For preemptive switches (caused by
any interrupt, not just the timer tick) all of the registers need to
be saved.

One of the convenient features of the AVR and STM8 that helps toward
this is that the port can use standard RET-type assembler instructions
to exit archContextSwitch(), whether entered via an ISR or thread.
This is not going to be the case on all architectures.

I wrote some of this up at the following page in case that helps,
otherwise let me know if you have any questions:
http://atomthreads.com/index.php?q=node/8

> * nested interrupts
> As far as I read nested interrupts are currently not supported by the
> current AtomThreads design. My SoC could support nested interrupts but
> in a first step I will disable this feature by disabling interrupts on
> each interrupt handler entry and activate them back at the end of the
> handler. Do you have any hints on nested interrupts support ? Did
> already one of you try to run AT with nested interrupts enabled ? I
> know that these low-level details are really architecture dependent
> but any input is welcome.

I don't expect nested interrupt support to be complicated, but I
haven't yet implemented it. I have been focusing on adding support for
a wide range of architectures before moving on to adding more advanced
functionality. Once a 32-bit architecture is complete I expect to
verify nesting supporting then.

Keep me posted on how you get on, I will be happy to help out wherever I can.

Best regards,
Kelvin.

> Thanks for reading and have a nice day!
>    Romain
>
Romain Bornet | 28 May 10:53 2010
Picon

Port to 32 bits architecture and context switches

Hi Atom fans, hi Kelvin

I'm an embedded software and research engineer in Switzerland and I'm
currently working on a project involving a ultra-low power CPU/SoC.
This chip has a 32 bits architecture and common peripherals found in
many other architectures (timers, UART, vectorized interrupts,...) and
some more advanced features (DMA, RF radio, ...).

We already have a working toolchain (GCC, binutils, ...) for that
architecture as well as a working libc (newlib). We can currently
develop bare-metal/standalone applications but we would really
appreciate to have a small-footprint RTOS also running on it. Googling
around AtomThreads sounded a well suited alternative (compact, easy to
port, ...). I carefully read the online documentation and comments in
sources but some questions remain open for moment. Perhaps you can
clear some of them ?

* 32 bits architecture
AtomThreads is currently officially supported on AVR and STM8
platforms. Both of them are 8 bits architectures. I read that a
Cortex-M3 port is on road or at least planed. I didn't find any
obvious reason why AtomThreads could not run on a 32 bits architecture
and assume that ( provided that I correctly implement the architecture
specific functions :-) ) AtomThreads would run correctly on 32 bits
arch. Did you already try to run AT on a 32 bits CPU (even a
"quick&dirty" port) ? Are there any caveats to take into consideration
?

* context switches
I'm still not sure I understood correctly how context switches really
work especially how they return back to the "scheduled in" thread. I
read Kelvin's explanations in his post to the list on 7 Apr 23:15
(http://permalink.gmane.org/gmane.os.atomthreads/9) but I'm still a
bit confused ...
If I understand correctly archContextSwitch is *always* called from
atomThreadSwitch() and this independently of the type of context
switch (cooperative: atomTimerDelay(), or preemptive: through timer
interrupt handler). Therefore archContextSwitch will *always* return
through atomThreadSwitch() and then roll-out the call tree saved on
stack when the thread was scheduled out. Is that correct?

* nested interrupts
As far as I read nested interrupts are currently not supported by the
current AtomThreads design. My SoC could support nested interrupts but
in a first step I will disable this feature by disabling interrupts on
each interrupt handler entry and activate them back at the end of the
handler. Do you have any hints on nested interrupts support ? Did
already one of you try to run AT with nested interrupts enabled ? I
know that these low-level details are really architecture dependent
but any input is welcome.

Thanks for reading and have a nice day!
    Romain


Gmane