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] [December 2008 Threads] passing strings between tasksPosted by Dave S on December 10, 2008 What's the best way to pass strings between tasks? 1. xQueueCreate( maxstringlength, sizeof( char ) ); 2. xQueueCreate( 1, maxstringlength ); //inefficient because it copies MAX string length instead of actual string length 3. xQueueCreate( 1, sizeof( char* ) ); //also requires semaphores 4. semaphores around a global string?
Thx, Dave
RE: passing strings between tasksPosted by dave m on December 10, 2008 Depends whether the receiving task needs to modify the string, and whether the sending task needs its own copy, or needs to release the memory or whatever. For strings that are const after sending (no task needs to modify or delete them), I'd go with 3. If you're really trying to pass a buffer of data from a producer to a consumer (for example), and have the producer generate more data after the consumer is finished, then I'd go with 4: semaphores around a global buffer.
RE: passing strings between tasksPosted by Dave S on December 10, 2008 Thx Dave. 4 it is. The producer is generating variable sized non-const 'debug' strings that are output to a port by the consumer.
RE: passing strings between tasksPosted by dave m on December 10, 2008 Oh yeah, totally. That's a great way to handle debugging output (everything spews into a common circular buffer, and some low-priority task prints it out when it has a chance). It can get pretty complex if you're doing timestamping and making sure messages interleave on a line-by-line basis, plus the buffer has to be pretty big if you have a lot of high-priority output, but a robust debug/error reporting scheme makes development MUCH easier.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|