FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [June 2006 Threads] memcpy in queue.cPosted by John W. on June 5, 2006 Richard,
I was wondering what the issues can be of using a memcpy from the target's CLIB that may not be reentrant - or other string functions.
queue.c includes both stdlib and string.h files.
Thanks, John W.
RE: memcpy in queue.cPosted by Richard on June 5, 2006 These functions definitely need to be reentrant and although the scheduler code should guard against pseudo simultaneously calls it cannot guard against the application code making similar calls.
I would be amazed if this function was ever not reentrant, although many of the SDCC libraries are not (hence I provide a download of reentrant versions).
The design decision was taken to use the library function as it was considered more likely to be the source of errors if an equivalent function were defined in the portable layer (as different memory alignment requirements could cause problems).
Do you think you may have found an issue?
Regards.
RE: memcpy in queue.cPosted by John W. on June 5, 2006 Richard,
I'm still investigating this. If I have found an issue - it is only in my MSP430 IAR port.
I've discussed this with IAR and they have told me the functions are reentrant - but I need to do further testing to determine if I've hit some kind of corner case.
Thanks, John W.
RE: memcpy in queue.cPosted by Richard on June 5, 2006 I think you will find the memcpy source in: IAR Systems\Embedded Workbench 4.0\430\src\lib\clib
looks reentrant.
Regards.
RE: memcpy in queue.cPosted by John W. on June 5, 2006 Is memcpy the only function to worry about?
Thanks, John
RE: memcpy in queue.cPosted by Richard on June 6, 2006 I think strncpy() is used to copy the task name into the TCB - so only when a task is created. Other than that the library functions are used when configUSE_TRACE_FACILITY is defined and you are creating a table of the task status.
Regards.
RE: memcpy in queue.cPosted by John W. on June 6, 2006 Richard,
I have noticed this - and this is in my app - not the core FreeRTOS code. If I do something like this - back to back:
memset memcpy strtoul
I get results in the debugger that seemingly aren't 'real'. If I run 'realtime' - all seems to be well - but if I set breakpoints and try to examine - I get conflicting results. An example - I initialize a 'packet'. Part of the 'packet' get's memcpy(ied) like above - but when I stop the debugger and look at the packet contents - it shows the initialized values - even though this is impossible. Kindof strange - I noticed it's hard to debug if you have too many back-to-back lib functions stacked up for some reason...
Thanks, John
RE: memcpy in queue.cPosted by Richard on June 6, 2006 I can't see why calling library functions would be any different to calling your own defined functions, but here are some random thoughts:
+ Some library functions can use a lot of stack. memset and memcpy should use hardly any, but strtoul has potential to use a bit.
+strtoul seems to be reentrant having had a quick scan of the code.
+ Some compilers will inline some smaller library functions as a matter of coarse. Could this be messing up your debug attempts?
Regards.
RE: memcpy in queue.cPosted by John W. on June 6, 2006 Richard,
I don't think I'm having a problem with inlining - but I'll check that. I suppose that could explain the issue with trying to debug with back to back lib calls.
Thanks, John W.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|