Searching \ for '[PIC] FreeRTOS for PIC18 is behaving strange...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'FreeRTOS for PIC18 is behaving strange...'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] FreeRTOS for PIC18 is behaving strange...'
2009\06\12@231003 by solarwind

picon face
Isaac gave me some code to start off with for a simple FreeRTOS project.

Here's a screen shot of MPLAB, just so you can see my setup.

http://img196.imageshack.us/img196/529/mplab.png

The problem is: my code is not executing as I'd expect. Basically, I
have two simple tasks. Here is the source code:

main.c - http://pastebin.com/f6aa9b4e5
FreeRTOSConfig.h - http://pastebin.com/ff59f805

And here's the RS232 output:

http://img34.imageshack.us/img34/8796/termite.png

What I expect: "abcd" and "wxyz" should be printed out. They may be
printed out part way like this: abwxcdyz, but I expect that everything
should be printed out.

What's happening: "wx" is the only thing being printed out.

Any ideas as to why this is happening?

-- [ solarwind ] -- http://solar-blogg.blogspot.com/

2009\06\13@021854 by Marcel Birthelmer

picon face
Are you sure your "puts"/UART routines are threadsafe? I would suggest doing
"putc('w'); putc('x'); ..." instead of "puts("wxyz");".
Regards,
- Marcel

On Fri, Jun 12, 2009 at 8:09 PM, solarwind <spam_OUTx.solarwind.xTakeThisOuTspamgmail.com> wrote:

{Quote hidden}

> -

2009\06\13@022758 by solarwind

picon face
On Sat, Jun 13, 2009 at 7:18 AM, Marcel
Birthelmer<.....marcelb.listsKILLspamspam@spam@gmail.com> wrote:
> Are you sure your "puts"/UART routines are threadsafe? I would suggest doing
> "putc('w'); putc('x'); ..." instead of "puts("wxyz");".
> Regards,
> - Marcel

I am not sure. They are the routines provided by the C18 library. I'm
just using them (blindly). I'll go ahead and try your method instead.

2009\06\13@023546 by solarwind

picon face
On Sat, Jun 13, 2009 at 7:18 AM, Marcel
Birthelmer<marcelb.listsspamKILLspamgmail.com> wrote:
> Are you sure your "puts"/UART routines are threadsafe? I would suggest doing
> "putc('w'); putc('x'); ..." instead of "puts("wxyz");".
> Regards,
> - Marcel

Ok, it seems to be working now.

This is the updated code:

void Task1(void *params) {
       while(1) {                
               _usart_putc('a');
               _usart_putc('b');
               _usart_putc('c');
               _usart_putc('d');
               delay1s();
               i++;
       }
}

void Task2(void *params) {
       while(1) {                                
               _usart_putc('w');
               _usart_putc('x');
               _usart_putc('y');
               _usart_putc('z');
               delay1s();
               j++;
       }
}

Why did the puts()/printf() not work? How would I get it to work?

2009\06\13@023701 by solarwind

picon face
On Sat, Jun 13, 2009 at 7:35 AM, solarwind<.....x.solarwind.xKILLspamspam.....gmail.com> wrote:
{Quote hidden}

Forgot to add image: img196.imageshack.us/img196/5439/termiteworking.png

2009\06\13@040832 by Marcel Birthelmer

picon face
On Fri, Jun 12, 2009 at 11:36 PM, solarwind <x.solarwind.xspamspam_OUTgmail.com> wrote:

{Quote hidden}

It depends on how printf/puts are implemented on the PIC (or more
specifically, in the standard library implementation of C18). it's possible
that the functions aren't reentrant (meaning that if two separate threads
call the function at the same time, it will corrupt some internal state, for
example). Functions that use static variables can sometimes be
non-reentrant. Also, since the PIC doesn't have a stack, it's possible that
local variables are stored in memory rather than on the stack, and that
could cause this sort of problem also.
First off, check if it says anything about that in the documentation for
your libraries.
Since you probably won't need to print from all threads in your program, you
might just make a single thread that does the printing, and other threads
that pass string pointers to it using a queue or some other synchronization
feature provided by FreeRTOS (i'm not familiar with that specific OS, so I
can't be more specific).

2009\06\13@091824 by olin piclist

face picon face
Marcel Birthelmer wrote:
> Also, since the PIC doesn't have a stack,

It sure does have a stack.  Read the C18 manual again.

********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\13@093854 by Isaac Marino Bavaresco

flavicon
face
Marcel Birthelmer escreveu:
{Quote hidden}

If I remember it right, the MPLAB-C18 *printf functions are reentrant.
The _usart_putc may not be.

> call the function at the same time, it will corrupt some internal state, for
> example). Functions that use static variables can sometimes be
> non-reentrant. Also, since the PIC doesn't have a stack, it's possible that
>  

No, Solarwind is using PIC18, which has a stack.

> local variables are stored in memory rather than on the stack, and that
> could cause this sort of problem also.
> First off, check if it says anything about that in the documentation for
> your libraries.
> Since you probably won't need to print from all threads in your program, you
>  

It is just dumb to print from more than one thread without some sort of
lock mechanism. The messages may appear mixed and unintelligible.

> might just make a single thread that does the printing, and other threads
> that pass string pointers to it using a queue or some other synchronization
> feature provided by FreeRTOS (i'm not familiar with that specific OS, so I
> can't be more specific).
>  

I used this method and it works, but it is simpler and wastes less
memory just to allow each task do its own printing. To do this, you must
use a mutex to control screen/console access.

Before a task may print anything to the screen or read from the
keyboard, it must obtain the mutex. After finishing all its interaction,
it releases the mutex so other tasks may interact also.

If one critical task may need the screen while other is using it, and it
must obtain it immediately, you could create a mechanism where the
critical task sends a signal to the other tasks so they know that the
task holding the mutex must release it immediately.


Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\13@114409 by Marcel Birthelmer

picon face
It doesn't have a proper HW stack, in the sense that other processors do
(then again, MIPS doesn't either, so I suppose the point is moot). I know
they probably use the indirect addressing to simulate one, but it's still
not impossible that for some implementation-specific reason, the functions
would use local memory rather than a stack. That's all that I was saying.
- Marcel

On Sat, Jun 13, 2009 at 6:19 AM, Olin Lathrop <RemoveMEolin_piclistspamTakeThisOuTembedinc.com>wrote:

> Marcel Birthelmer wrote:
> > Also, since the PIC doesn't have a stack,
>
> It sure does have a stack.  Read the C18 manual again.
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
> -

2009\06\13@121702 by Xiaofan Chen

face picon face
On Sat, Jun 13, 2009 at 11:43 PM, Marcel
Birthelmer<marcelb.listsEraseMEspam.....gmail.com> wrote:
> It doesn't have a proper HW stack, in the sense that other processors do
> (then again, MIPS doesn't either, so I suppose the point is moot). I know
> they probably use the indirect addressing to simulate one, but it's still
> not impossible that for some implementation-specific reason, the functions
> would use local memory rather than a stack. That's all that I was saying.


More information from MPLAB C18 user guide:
***************************************
The MPLAB C18 software stack is an upward growing stack data
structure on which the compiler places function arguments and
local variables that have the storage class auto. The software stack
is distinct from the hardware stack upon which the PIC microcontroller
places function call return addresses.

The Stack Pointer (FSR1) always points to the next available stack location.
MPLAB C18 uses FSR2 as the Frame Pointer, providing quick access to
local variables and parameters. When a function is invoked, its stack-based
arguments are pushed onto the stack in right-to-left order and the function is
called. The leftmost function argument is on the top of the software stack
upon entry into the function.

MPLAB C18 supports parameters and local variables allocated either
on the software stack or directly from global memory. The static
keyword places a local variable or a function parameter in global
memory instead of on the software stack.[3] In general, stack-based
local variables and function parameters require more code to access
than static local variables and function parameters (see static Function
Arguments). Functions that use stack-based variables are more
flexible in that they can be reentrant and/or recursive.
***************************************

There are also differences between the Extended Mode
and the  Non-Extended mode.


--
Xiaofan http://mcuee.blogspot.com

2009\06\13@124012 by Tamas Rudnai

face picon face
On Sat, Jun 13, 2009 at 4:43 PM, Marcel Birthelmer
<EraseMEmarcelb.listsspamgmail.com>wrote:

> It doesn't have a proper HW stack, in the sense that other processors do
> (then again, MIPS doesn't either, so I suppose the point is moot). I know
> they probably use the indirect addressing to simulate one, but it's still
> not impossible that for some implementation-specific reason, the functions
> would use local memory rather than a stack. That's all that I was saying.
>

That's true, not just the stack is missing but the frame pointer as there is
no indexed-indirect addressing in PIC16 and PIC18. That's why this indirect
addressing emulation of stack and frame pointer is really slow and is
avoided whenever it can be. The 'local memory' is based on stack usually
using a frame pointer to 'mark' a frame on the stack that the function can
use for storing it's local data.

In PIC, however, a so called pseudo stack is used instead by many compilers
around which it is unfortunately not implemented in C18. There is an overlay
storage class instead which is very close to that. This is when the compiler
pre-calculates which memory adresses are used by what functions and shares
the memory with other functions. The compiler makes sure that a single
memory location is used by as many functions as it can be (saving memory) by
determining the program flow. Also it makes sure there will be no data loss
due to calling a function that would use the very same area. Because of this
technique a function is non reentrant or recursive as the new instance would
overwrite the previous' values (as the function always uses the very same
memory location).

I believe that in C18 printf and many other library functions are using
overlay variables for speed and code size reasons therefore those are
non-reentrant.

Tamas
--
http://www.mcuhobby.com

2009\06\13@142809 by Isaac Marino Bavaresco

flavicon
face
Tamas Rudnai escreveu:
{Quote hidden}

Some PIC18 devices support extended micro-controller mode, which have
true indexed access to the stack frame (using FSR2).
In those micro-controllers, when configured for extended instruction
set, there are no access bank (or a very reduced one). Instead,
instructions accessing up to address 0x5f in access mode will access the
stack-frame using address FSR2+n.

Eg.: movf 0,w,access becomes movf [0],w (something like movf [FSR2+0],w)

There are several new instructions also.

In extended mode those devices are much more efficient in manipulating
automatic variables and parameters. Even more efficient than accessing
banked data across banks, and yield great performance gain in C code.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\13@145724 by solarwind

picon face
On Sat, Jun 13, 2009 at 2:38 PM, Isaac Marino
Bavaresco<RemoveMEisaacbavarescospam_OUTspamKILLspamyahoo.com.br> wrote:
> I used this method and it works, but it is simpler and wastes less
> memory just to allow each task do its own printing. To do this, you must
> use a mutex to control screen/console access.
>
> Before a task may print anything to the screen or read from the
> keyboard, it must obtain the mutex. After finishing all its interaction,
> it releases the mutex so other tasks may interact also.
>
> If one critical task may need the screen while other is using it, and it
> must obtain it immediately, you could create a mechanism where the
> critical task sends a signal to the other tasks so they know that the
> task holding the mutex must release it immediately.

I just found this:
http://www.freertos.org/index.html?http://www.freertos.org/Inter-Task-Communication.html

FreeRTOS is more amazing than I thought!

2009\06\13@150853 by olin piclist

face picon face
Marcel Birthelmer wrote:
> It doesn't have a proper HW stack, in the sense that other processors do

It can do push and pop in single instruction cycles.  I don't see what else
it would have to do to qualify for being a "hardware" stack.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\13@160520 by William \Chops\ Westfield

face picon face

On Jun 12, 2009, at 11:27 PM, solarwind wrote:

> They are the routines provided by the C18 library.

In general, I would not expect ANY functions in a normal PIC C library  
to be reenterant (multi-threading safe) unless explicitly documented  
to be so; multitasking operating systems are so uncommon on PICs that  
it's just not a usual design requirement.  See if there are similar  
functions supplied with freeRTOS, or documentation on which functions  
are usable, or plan on wrapping most of your functions inside some  
primitive that will prevent preemption...

BillW

2009\06\13@165041 by Isaac Marino Bavaresco

flavicon
face
William "Chops" Westfield escreveu:
> On Jun 12, 2009, at 11:27 PM, solarwind wrote:
>
>  
>> They are the routines provided by the C18 library.
>>    
>
> In general, I would not expect ANY functions in a normal PIC C library  
> to be reenterant (multi-threading safe) unless explicitly documented  
> to be so; multitasking operating systems are so uncommon on PICs that  
> it's just not a usual design requirement.  See if there are similar  
> functions supplied with freeRTOS, or documentation on which functions  
> are usable, or plan on wrapping most of your functions inside some  
> primitive that will prevent preemption...
>
> BillW
>  

I rewrote most of MPLAB-C18 library functions, and read the original
source code for reference (extended mode only).
It's some time now, but if I remember it right most (if not all)
functions use stack variables and parameters. They use static data in
the "MATH_DATA" and ".tmpdata" sections, but these sections are
saved/restored by FreeRTOS on context switch (indeed there is a compiler
version related bug that I had to solve).

I remember that the original functions worked OK for me, until I
replaced them by my versions.

The problem may arise for functions that deal with the control
registers, which have fixed addresses and FreeRTOS doesn't save/restore.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\13@223640 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

> Marcel Birthelmer wrote:
>> It doesn't have a proper HW stack, in the sense that other processors
>> do
>
> It can do push and pop in single instruction cycles.  I don't see
> what else it would have to do to qualify for being a "hardware"
> stack.

In this context, size? This is in the context of C compilers and
re-entrant functions, which typically means that all data is on the
stack. This requires that besides the stack being a "hardware" stack, it
also has a stack that can be adapted to the application's memory
requirements. PIC18 hardware stacks typically can't be. That's probably
the "sense" Marcel was talking about -- which someone programming in C
probably would know :)

Gerhard

2009\06\14@005854 by William \Chops\ Westfield

face picon face

On Jun 13, 2009, at 1:50 PM, Isaac Marino Bavaresco wrote:

>> In general, I would not expect ANY functions in a normal PIC C  
>> library
>> to be reenterant (multi-threading safe) unless explicitly documented
>> to be so;

> The problem may arise for functions that deal with the control
> registers, which have fixed addresses and FreeRTOS doesn't save/
> restore.

I'd expect the problems to be most likely to show up when global data  
structures (like buffers for a serial port) are involved.   Typical  
buffer code like:
   txbuffer[outptr++] = char;
wont normally contain primitives to protect them against some other  
process doing the same thing at the same time.  And it must, if the OS  
is really preemptive.

BillW

2009\06\14@012227 by Marcel Birthelmer

picon face
Specifically, I was talking about an area of memory that is made available
also via stack instructions. push/pop is, strictly speaking, a hardware
stack, yes. But in the context of this discussion (C programming, frames
etc.), a stack is an area of memory that can be modified via stack-oriented
instructions (push/pop), directly as memory (lda, sta), and whose address is
stored in a special register to facilitate the latter as part of a standard
ABI. I'm sorry if I was unclear.
- Marcel

On Sat, Jun 13, 2009 at 7:36 PM, Gerhard Fiedler <RemoveMElistsTakeThisOuTspamspamconnectionbrazil.com
{Quote hidden}

> -

2009\06\14@085530 by Bob Ammerman

picon face

> Specifically, I was talking about an area of memory that is made available
> also via stack instructions. push/pop is, strictly speaking, a hardware
> stack, yes. But in the context of this discussion (C programming, frames
> etc.), a stack is an area of memory that can be modified via
> stack-oriented
> instructions (push/pop), directly as memory (lda, sta), and whose address
> is
> stored in a special register to facilitate the latter as part of a
> standard
> ABI. I'm sorry if I was unclear.
> - Marcel

The hardware stack as used by C18 is all of the above (especially using the
extended instruction set). In addition, it can, if needed, span nearly all
of available member.

I think there is a lot of confusion between the return address stack which
is limited and really only used for/useful for return addresses and the
"FSR-based" stack which contains function parameters and automatic local
variables.

-- Bob Ammerman

2009\06\14@090959 by olin piclist

face picon face
Gerhard Fiedler wrote:
>> It can do push and pop in single instruction cycles.  I don't see
>> what else it would have to do to qualify for being a "hardware"
>> stack.
>
> In this context, size?

His assertion was about it being a hardware stack or not.  As for size,
since a data stack on a PIC 18 implemented with a FSR and its auto
increment/decrement registers can address any contiguous chunk of memory
without bank boundary issues, the size limitation is all of user RAM on most
PIC 18.

> This is in the context of C compilers and
> re-entrant functions, which typically means that all data is on the
> stack. This requires that besides the stack being a "hardware" stack,

No it doesn't.  First, C automatic variables need not be implemented on a
data stack, although that is often a convenient method on machines that have
appropriate supporting hardware.  Second, whether using a data stack or not,
this stack need not be implemented in hardware.  Your arguments are
therefore orthagonal to the original point.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\14@091245 by olin piclist

face picon face
Marcel Birthelmer wrote:
> Specifically, I was talking about an area of memory that is made
> available also via stack instructions. push/pop is, strictly
> speaking, a hardware stack, yes. But in the context of this
> discussion (C programming, frames etc.), a stack is an area of memory
> that can be modified via stack-oriented instructions (push/pop),
> directly as memory (lda, sta), and whose address is stored in a
> special register to facilitate the latter as part of a standard ABI.

But that's exactly what a PIC 18 has.  The C18 compiler uses FSR1 as your
special register.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\14@112130 by Isaac Marino Bavaresco

flavicon
face
William "Chops" Westfield escreveu:
{Quote hidden}

This is basic, usually the designer must ensure only one task uses each
resource (serial port, etc.) at any given time (just one task use each
resource ever or using a mutex/open, close, etc.).

Even when just one task uses a resource but for instance the task fills
the buffer and an interrupt empties it, the designer must encapsulate
the accesses inside critical sections.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\14@120653 by Isaac Marino Bavaresco

flavicon
face
The PIC18 push/pop instructions act only in the hardware call stack.

For data stack access PIC18 doesn't have proper push/pop instructions,
but the access through the FSRs PREINC1, POSTINC1, POSTDEC1 and INDF1
may be used to access the stack in the proper way. FSR1 is the register
used by MPLAB-C18 as data stack pointer.

Eg.:

movwf POSTINC1,ACCESS = push WREG
movff Var,POSTINC1,ACCESS = push Var

pop is a little more complicated:

movf POSTDEC1,f,ACCESS + movf INDF1,w,ACCESS = pop WREG

For stack frame access, one must use the FSRs PLUSW2 and INDF2. FSR2 is
used by MPLAB-C18 as frame pointer.

Regards,

Isaac


Marcel Birthelmer escreveu:
{Quote hidden}

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\14@171354 by William \Chops\ Westfield

face picon face

On Jun 13, 2009, at 10:22 PM, Marcel Birthelmer wrote:

> in the context of this discussion (C programming, frames etc.), a  
> stack is an area of memory that can be modified via stack-oriented  
> instructions (push/pop), directly as memory (lda, sta), and whose  
> address is stored in a special register to facilitate the latter as  
> part of a standard ABI.

The PIC has a fine data stack via the INDF registers and auto  
increment/decrement addressing modes, no less real than the stacks on  
a PDP11.

What it lacks is a stack for return addresses of CALL instructions  
that can be easily reset to different memory areas for different  
tasks, generally a basic requirement of multitasking.  (we started out  
talking about operating systems, not compilers, right?)  This is not  
insurmountable; it looks like it would be pretty easy to pop return  
addresses off of the HW return stack and put them on the data stack as  
part of the ABI (do any C compilers DO that?  Sorta wasteful if you  
DON'T need it.)  Essentially, this would reserve the hw return stack  
for exception processing.

BillW

2009\06\14@172415 by William \Chops\ Westfield

face picon face

On Jun 14, 2009, at 8:21 AM, Isaac Marino Bavaresco wrote:

> This is basic, usually the designer must ensure only one task uses  
> each
> resource (serial port, etc.) at any given time (just one task use each
> resource ever or using a mutex/open, close, etc.).

Which designer are YOU talking about?  I'm claiming that the designer  
of the C18 libraries is unlikely to have taken into account all  
possible implementations of the multitasking operating systems that  
might run on the same software, and so the C18 library itself is VERY  
unlikely to be "thread safe" in most of its functions.  This is why  
operating systems tend to implement the critical bits of I/O and etc  
as "system calls" rather than library functions.  If you want serial I/
O from multiple freeRTOS tasks to 'work' (you pick the definition of  
"work", Solarwind said "all of the characters show up, perhaps  
intermixed", which sounds pretty good), then you need serial IO  
functions written specifically to work with FreeRTOS, not the  
functions that came as a convenience feature with some random compiler.

BillW

2009\06\14@175559 by Isaac Marino Bavaresco

flavicon
face
William "Chops" Westfield escreveu:
> On Jun 14, 2009, at 8:21 AM, Isaac Marino Bavaresco wrote:
>
>  
>> This is basic, usually the designer must ensure only one task uses  
>> each
>> resource (serial port, etc.) at any given time (just one task use each
>> resource ever or using a mutex/open, close, etc.).
>>    
>
> Which designer are YOU talking about?  I'm claiming that the designer

The system designer, Solarwind in this case. The RTOS author did a lot
of work in this area already, supplying us with nice mutexes, semaphores
and queues.

>  
> of the C18 libraries is unlikely to have taken into account all  
> possible implementations of the multitasking operating systems that  
> might run on the same software, and so the C18 library itself is VERY  
> unlikely to be "thread safe" in most of its functions.  This is why  
>  

I found that the MPLAB-C18 library programmers did a good job in making
most of the library functions reentrant. Just a little more work and we
have a working system.

> operating systems tend to implement the critical bits of I/O and etc  
> as "system calls" rather than library functions.  If you want serial I/
> O from multiple freeRTOS tasks to 'work' (you pick the definition of  
> "work", Solarwind said "all of the characters show up, perhaps  
> intermixed", which sounds pretty good), then you need serial IO  
> functions written specifically to work with FreeRTOS, not the  
> functions that came as a convenience feature with some random compiler.
>
> BillW

For my systems, I wrote myself a complete framework to access hardware
under FreeRTOS. I created open/close, read/write, etc. functions that
deal with multiple tasks trying to use serial ports, etc.


Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\15@111738 by Michael Rigby-Jones

flavicon
face


{Quote hidden}

It's not very amazing that an RTOS provides mechanisms for inter-thread
communications and locking of shared resources; it wouldn't be much of
an RTOS without these features!

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2009\06\16@094402 by Gerhard Fiedler

picon face
William "Chops" Westfield wrote:

> On Jun 14, 2009, at 8:21 AM, Isaac Marino Bavaresco wrote:
>
>> This is basic, usually the designer must ensure only one task uses
>> each resource (serial port, etc.) at any given time (just one task
>> use each resource ever or using a mutex/open, close, etc.).
>
> Which designer are YOU talking about?  I'm claiming that the designer
> of the C18 libraries is unlikely to have taken into account all
> possible implementations of the multitasking operating systems that
> might run on the same software, and so the C18 library itself is VERY
> unlikely to be "thread safe" in most of its functions.  

AFAIK, thread safety is not part of the C standard, so whether or not a
specific compiler or library is or is not thread-safe needs to be
deduced from the guarantees the compiler or library gives. If they don't
give any, this is probably not a good sign. Even if a given version is,
this could be by accident and could be broken by any future update if
it's not guaranteed by the designers.

Gerhard

2009\06\16@130438 by Isaac Marino Bavaresco

flavicon
face
Gerhard Fiedler escreveu:
{Quote hidden}

I use MPLAB-C18 with FreeRTOS in a daily basis, and most of the
MPLAB-C18 library is thread safe and re-entrant.

Several of the assembly files are explicitly documented as being re-entrant.

The only clearly non-reentrant functions are strtok (strtok.c),
strtokrampgm (stokrp.c), strtokpgmram (stokpr.c), strtokpgm (stokpgm.c)
and the busy-wait functions (Delay1KTCYx, Delay10KTCYx, Delay10TCYx,
Delay100TCYx), because they use static variables.

The math functions and built-in operations use static variables in the
section MATH_DATA, but FreeRTOS saves and restores this section in the
context switch.

The peripheral library functions must be considered non-reentrant and
the programmer must provide sinchronization using mutexes or critical
sections.

Best regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...