gmane.os.atomthreads

Re: Thread entry parameter

Holger Teutsch — 2012-11-02T08:12:14

Kelvin,


On Fri, Nov 2, 2012 at 12:51 AM, Kelvin Lawson <info-59ZnQMRe+eI3a3cF9UA9Cg< at >public.gmane.org> wrote:
Great !


Yes, the full test suite passes.
The most complicated task in porting was to adjust the stack sizes of the
test suite so the stack wasn't overrun *before* stack checking could detect
it 8-) .

Another idea came to my mind then:
What about

   - add a field "POINTER stack_limit" to the TCB. E.g. for an architecture
   with "stack grows downwards" that describes the bottom of the stack.
   - the architecture dependent task switcher could do a rather *cheap*
   overrun check when switching stacks on *each* switch
   - the port can put a magic word there or just compare pointers on its
   own discretion
   - that is much less overhead (and of course a much less rigorous
   checking) than full stack checking but it's frequent
   - these extra fields could be added by a preprocessor macro e.g.
   PORT_TCB_EXTRA_FIELDS. That would avoid permanent overhead for all ports.


Right now the processor

Re: Thread entry parameter

Kelvin Lawson — 2012-11-01T23:51:44

Hi Holger,

Good to hear from you.

I'm currently porting porting atomthreads to a new processor architecture.


Great, I hadn't heard of Venray before but will be reading up on it further.

The target processor is 64bit and unfortunately the entry_param is


Yes, this makes sense. I've added an issue on Github and will try to get
this into the next release.

Does the full test suite pass? Are you interested in submitting your port
to the project? Don't feel like you have to of course, but new
architectures are always interesting so I thought I'd ask :-)

Thanks,

Kelvin.

Thread entry parameter

Holger Teutsch — 2012-10-31T12:08:54

Hi,
I'm currently porting porting atomthreads to a new processor architecture.
http://www.venraytechnology.com/Implementations.htm

Porting went smoothly and the test suite runs. The target processor is
64bit and unfortunately the entry_param is hardwired to 32bit. So it's not
possible to pass a pointer in a clean way.

Wouldn't it be better to define a port specific ENTRY_PARAM_TYPE like
POINTER ?

That could be defaulted to uint32_t, so it won't break existing software.

Regards
Holger

Re: A qustion about atomThreadSwitch

Kelvin Lawson — 2012-09-13T00:17:24

Hi Elvin,

It might be a bit easier to understand with the comments left in:

    if (old_tcb != new_tcb)
    {
        /* Set the new currently-running thread pointer */
        curr_tcb = new_tcb;

        /* Call the architecture-specific context switch */
        archContextSwitch (old_tcb, new_tcb);
    }

    /**
     * The context switch shifted execution to a different thread. By the time
     * we get back here, we are running in old_tcb context again. Clear its
     * suspend status now that we're back.
     */
    old_tcb->suspended = FALSE;

The suspended flag is set to TRUE when a thread is being suspended,
and is set to FALSE when it runs again. This is used as housekeeping,
to keep a track of what suspension state a thread is in.

For any thread that calls into this function, the calling thread
(itself) is old_tcb and the new thread being switched in is new_tcb.
When you return from archContextSwitch() *in the context of the
original calling thread* then the running thread is back to the
origi

Re: Porting atomthread on Arduino Uno

Kelvin Lawson — 2012-09-12T23:23:49

Hi Ashwin,


The scheduler is already called in atomIntExit() after the timer ISR
occurs, and it will not be safe to add the extra call there.

If you would like to send me off-list your changes to the standard AVR
port then I could review them for potential problems.

Thanks,
Kelvin.

Re: Porting atomthread on Arduino Uno

Ashwin Vasani — 2012-09-12T19:48:45

Actually I havn't replaced timer. Here is diff for working  case.

diff --git a/atomthreads/kernel/atomtimer.c b/atomthreads/kernel/atomtimer.c
index 3693295..91eb053 100755
--- a/atomthreads/kernel/atomtimer.c
+++ b/atomthreads/kernel/atomtimer.c
< at >< at > -68,7 +68,7 < at >< at >


 #include "atom.h"

 /* Data types */

< at >< at > -299,7 +299,7 < at >< at > void atomTimerTick (void)
     {
         /* Increment the system tick count */
         system_ticks++;
-
+       atomSched(TRUE);
         /* Check for any callbacks that are due */
         atomTimerCallbacks ();
     }

A qustion about atomThreadSwitch

elvinwds — 2012-09-11T11:29:01

Hi All:

I am a new to RTOS and  have been studying the source code of atomthreads for a while,  and now I have question about the atomThreadSwitch function in atomkernel.c. 

The source code without comments of atomThreadSwitch is :
static void atomThreadSwitch(ATOM_TCB *old_tcb, ATOM_TCB *new_tcb)
    {
           if (old_tcb != new_tcb)
        {
            /* Set the new currently-running thread pointer */
            curr_tcb = new_tcb;

        /* Call the architecture-specific context switch */
            archContextSwitch (old_tcb, new_tcb);
        }

     old_tcb->suspended = FALSE;

   }

My question is about the last line :   "old_tcb->suspended = FALSE". Only when the old thread been scheduled back in, the RTOS can run to here. This means that when the RTOS runs to here , the old thread has been scheduled out, so the state of the old thread can not be suspended, And why have to set the state of suspended false here?


With Regards,
Elvin

Re: Porting atomthread on Arduino Uno

Kelvin Lawson — 2012-09-11T10:49:47

Hi Ashwin,


If you replaced the standard Atomthreads timer ISR with an alternative
one that didn't call the scheduler then that makes sense.

Thanks,
Kelvin.

Re: Porting atomthread on Arduino Uno

Ashwin Vasani — 2012-09-11T03:57:13

Thanks for the reply. Yes timer interrupts are occurring but by default
scheduler is not called. It works by calling scheduler in timer interrupt.
Thanks
AV

16Mhz.
whether
in
function.
is

Re: Porting atomthread on Arduino Uno

Kelvin Lawson — 2012-09-10T23:19:53

Hi Ashwin,

I would confirm that the timer interrupt is occurring. The timer ISR
is in atomport.c (TIMER1_COMPA_vect).

The timer interrupt is working on the ATmegas I have tested, and
indeed some of the automated tests would fail if it were not.

Thanks,
Kelvin.

Porting atomthread on Arduino Uno

Ashwin Vasani — 2012-09-07T19:45:19

Hi All,
       I am new to embedded and have very little experience but I'm very
enthu abt it. Few days back I bought Arduino Uno with 32KB memory and 16Mhz.
Later I found atomthread multi threading RTOS kernel on Internet. By
changing some configuration port file for avr in the kernel I am able
to run main thread (Thanks for excellent documentation).
Even I have ported some cpp files from arduino to kernel and did some
changes in Makefile to run  LED blinking
code in thread context that that too worked :-). I am using default uart
port provided by atomthread and its working.
Even I am using printf for printing on serial port but I dont knw whether
should I use printf or prinf_P but it working.

Even I am able to create multiple threads and I can see all the prints in
those thread. But I am not able to use atomTimerDelay
in threadContex. Thread is going in hang state when I call this function.
Here do I need to do some time call to so ??
Even when thread contex is over then this thread is recreated or board

Re: large memory model...

Kelvin Lawson — 2012-09-05T21:42:49

Hi Vit,

Good to hear from you.

I have not investigated large memory model on STM8 before but it shouldn't
be very difficult. If you have any questions then let me know. A patch
would be excellent if you get round to doing this.

Thanks,
Kelvin.
On 27 Aug 2012 00:33, "Vit STEPANEK" <vit.stepanek-qxv4g6HH51o< at >public.gmane.org> wrote:

large memory model...

Vit STEPANEK — 2012-08-26T23:23:25

Hello,

I would like to port AT for STM8 large memory model. But, if there is anybody, who has accomplished this already, it would perfect.

Many thanks.

Best regards

Vit

Re: CRITICAL sections a possible cause for interruptlatency

Kelvin Lawson — 2010-12-15T23:49:30

Hi Matthew,

Good to hear from you.


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).

If you want to be able to signal tasks from a non-timer ISR then only
locking out the timer interrupt would not be sufficient. Some RTOS
deal with this using a segmented interrupt architecture, whereby the
RTOS structures are only protected from higher-level ISRs - lower
level ISRs can then run with lower latency but to be able to interact
with the RTOS they must defer to a higher-level ISR. This would reduce
the interrupt latency at the expense of some overhead for ISRs which
must interact the RTOS.

Another option is to reduce the periods during which interrupts are
locked out. This is fairly easy to do from the scheduler point of view
by m

CRITICAL sections a possible cause for interrupt latency

Mathew Swaffield — 2010-12-09T17:45:43

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). 

 

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

Re: Stack limitations on STM8

Kelvin Lawson — 2010-11-17T00:28:17

Hi Spencer,


I posed the question to ST and they said the following:

"the stack is a 16-bit register (SPL, SPH), freely updateable. It is
reset at power up and system reset to its default value, that may
later be changed by RTL code with the information from linker, or your
own code."

So according to this response there are no limitations on the stack
locations, which tallies with my own findings so far. I can impose
specific limits to the stack regions in Atomthreads, but according to
ST there are no limits to impose. Are you finding that there is an
issue for you?

Best regards,
Kelvin.

Re: Stack limitations on STM8

Kelvin Lawson — 2010-10-18T20:25:59

Hi Spencer,


I've been looking through the datasheets for various STM8 parts and
see that generally the memory maps mention a particular stack size
(512 bytes in the case of the STM8S105), but there is nothing that
states that the device force some upper bits to particular values,
leaving you with impression that it could just be a suggestion on how
to allocate your memory.

Nevertheless, there is the text in the programmer's reference
"Depending on the product, the most significant bits can be forced to
a preset value", and I found the following in an errata document:
"Stack pointer address compatibility across STM8S105xx family devices
is not currently possible due to the present RAM mapping.". So it
looks a bit like the limitation was not highlighted to those
generating the part-specific documentation.

I was surprised that this has not caused me issues before, however,
given that I have run several threads simultaneously with stack
locations other than that described in the memory map. I decided to
expe

Re: Stack limitations on STM8

Kelvin Lawson — 2010-10-18T20:25:59

Hi Spencer,


I've been looking through the datasheets for various STM8 parts and
see that generally the memory maps mention a particular stack size
(512 bytes in the case of the STM8S105), but there is nothing that
states that the device force some upper bits to particular values,
leaving you with impression that it could just be a suggestion on how
to allocate your memory.

Nevertheless, there is the text in the programmer's reference
"Depending on the product, the most significant bits can be forced to
a preset value", and I found the following in an errata document:
"Stack pointer address compatibility across STM8S105xx family devices
is not currently possible due to the present RAM mapping.". So it
looks a bit like the limitation was not highlighted to those
generating the part-specific documentation.

I was surprised that this has not caused me issues before, however,
given that I have run several threads simultaneously with stack
locations other than that described in the memory map. I decided to
expe

Re: Stack limitations on STM8

Kelvin Lawson — 2010-10-09T11:32:16

Hi Spencer,


I have so far worked on the basis that the following text in the STM8
programmer's reference was true: "The 16-bit Stack Pointer provides
access to a 64K-level Stack.". However I now see that this is
qualified elsewhere as follows: "Depending on the product, the most
significant bits can be forced to a preset value."


It looks like Atomthreads needs to use the CPU part to determine the
location of all stacks. Do you know if there is a table somewhere
which shows the stack locations by part? I have just looked at the
STM8S105 reference manual (the part I used) and the text refers to 64K
stack space without any qualification, other than a diagram which
shows stack at a particular location. This is confusing to say the
least.

Incidentally the core Atomthreads kernel port does not care where the
stack is located. It is up to the application to decide where
everything is located in the memory map, so all you need to do is to
tell the linker where your stacks should live. However as you've
pointed

Re: Purpose of "extern int _stack" in main

Kelvin Lawson — 2010-10-09T11:08:17

Hi Spencer,

This is historical and the line can be removed. It previously used
this to find out the top of the stack from the atomthreads.lkf file
(it is defined as 0x7ff in there), but it now uses the
main_thread_stack[] space. I will remove the line and push to Github.

Thanks,
Kelvin.


On 8 October 2010 21:47, Spencer Russell <srussell-W1KQyhJqDchWk0Htik3J/w< at >public.gmane.org> wrote:

Stack limitations on STM8

Spencer Russell — 2010-10-08T20:52:14

I've been told by both Bruno at Raisonance and our ST FAE that care needs to be taken with the stack pointer on STM8 processors. Apparently the bits 9 and 10 of the SP are fixed at one, so the range of the SP is really 0x600 - 0x7FF.

Is this accounted for somewhere in AtomThreads that I haven't found yet? It would seem that care is necessary as to where you allocate the thread stack arrays to make sure they're within the allowed stack space. (perhaps this is related to my last query about the _stack variable use).

-Spencer