FreeRTOS | 'Classic' FreeRTOS distribution. Started as Git clone of FreeRTOS SourceForge SVN repo. Submodules | Robotics library

It sounds like you need a mutex. Each task acquires the mutex when they start running, and release it when they are done. When any of the tasks is running, others are blocked on the mutex.

Since strtok is not thread-safe, in multithreaded programs it is better to use strtok_r if it's available (it's not provided by ISO C but it is by POSIX). You stated in comments that this fixed your crash.

If you were truly only ever calling strtok from one thread (and that includes the main thread), then I don't think this should have made a difference. So perhaps you were mistaken about which threads call this function, or maybe there is another call to strtok elsewhere in your program. You may want to investigate further.

Another wild guess might be that something is wrong with the linking or loading of your program, such that strtok's internal static data isn't properly allocated in writable memory. If it ended up in ROM, one could imagine that the internal pointer would be stuck on NULL, and the second call to strtok would dereference it.

Or, perhaps your library's strtok implementation tries to use thread-local storage, to help alleviate this risk, and maybe there is something wrong with how thread-local storage is set up in your program?

In general, I think your design could work. The semaphores are signals for the two tasks to do work. And the mutex protects the shared I2C resource.

However, sharing a resource with a mutex can lead to complications. First, your operations tasks are not responsive to new semaphore signals/events while they are waiting for the I2C resource mutex. Second, if the application gets more complex and you add more blocking calls then the design can get into a vicious cycle of blocking, starvation, race conditions, and deadlocks. Your simple design isn't there yet but you're starting down a path.

As an alternative, consider making a third task responsible for handling all I2C communications. The I2C task will wait for a message (in a queue or mailbox). When a message arrives then the I2C task will perform the associated I2C communication. The operations tasks will wait for the semaphore signal/event like they do now. But rather than waiting for the I2C mutex to become available, now the operations tasks will send/post a message to the I2C task. With this design you don't need a mutex to serialize access to the I2C resource because the I2C task's queue/mailbox does the job of serializing the message communication requests from the other tasks. Also in this new design each task blocks at only one place, which is cleaner and allows the operations tasks to be more responsive to the signals/events.

It is installed directly into the interrupt vector table. If the vector table uses CMSIS names for the handlers then you can map the CMSIS name to the name of the FreeRTOS systick handler in FreeRTOSConfig.h, as per the FAQ - see the red "special note to ARM Cortex-M users" here: https://www.freertos.org/FAQHelp.html

Let's focus on TX only and assume that we don't use interrupts and handle all the transmission with the tools provided by the RTOS.

µC UART hardware generally have a transmit shift register (TSR) and some kind of data register (DR). The software loads the DR, and if the TSR is empty, DR is instantly transferred into TSR and TX begins. The software is free to load another byte into DR, and the hardware loads the new byte from DR to TSR whenever the TX (shift-out) of the previous byte finishes. Hardware provides status bits for querying the status of DR & TSR. This way, the software can using polling method and still achieve continuous transmission with no gaps between the bytes.

I'm not sure if the hardware configuration I described above holds for every µC. I have experience with 8 & 16-bit PICs and STM32 F0, F1, F4 series. They are all similar. UART hardware doesn't provide additional hardware buffers.

Now, back to RTOS... Obviously, your TX task needs to be polling UART status bits. If we assume that UART baud rate is 115200 (which is a common value), you waste ~90 µs of polling for each byte. The general rule of RTOS is that if you are waiting for something to happen, your task needs to be blocked so other tasks can run. But block on what? What will tell you when to unblock? For this you need interrupts. Your task blocks on task notification, (ulTaskNotifyTake()), and the interrupt gives the notification using xTaskNotifyGive().

So, I can't imagine any other way without using interrupts. But, the method mentioned above isn't good either. It makes no sense to block - unblock with each byte.

There are 2 possible solutions:

1. Move TX handling completely to interrupt handler (ISR), and notify the task when TX is completed.
2. Use DMA instead! Almost all modern 32-bit µCs have DMA support. DMA generates a single interrupt when the TX is completed. You can notify the task from the DMA transfer complete interrupt.

On this answer I've focused on TX, but using DMA is the proper way of handling reception (RX) too.

There's no easy way to mix freeRTOS and deep_sleep mode. During deep sleep the CPU is powered down and its context is lost, yet the RTC memory can be retained. As all SRAM's content is lost, there's no easy backup-restore we can do here to safely restore everything after coming out from deep sleep.

But what you can do is to bring everything down to a safe state before entering deep-sleep, you can signal all your tasks to finish what they're doing and exit, and then take some advantage of ESP32's relatively low wake-up latency. It is a very unpleasant inconvenient for a Wi-Fi connected device, but more or less acceptable for BLE devices that will wake up and send a beacon once in a few seconds.

You would also want to fine-tune the second stage bootloader's configuration by enabling the CONFIG_BOOTLOADER_SKIP_VALIDATE_IN_DEEP_SLEEP option so waking-up from deep-sleep would be faster than booting from a cold reset.

Firstly it's not a good idea to create the queue in the global scope like you do. A global queue handle is OK. But run xQueueCreate() in the same function that creates task1 and task2 (queue must be created before the tasks), something like this:

TL;DR: create a Queue of pointers to std::string and handle new/delete on either side. Make sure both producer and consumer are using a shared memory space.

The problem with using std::string in a "raw" memory API like FreeRTOS Queue isn't actually an issue with the size of the object. In fact the std::string object size is fixed, regardless of the size of the character array stored by the object. Don't believe me? Try compiling and running this simple program on your own machine:

You did not specify if you had any requirements in terms of FreeRTOS version, but you can either:

• use the demo provided in file SW-EK-TM4C1294XL-2.1.4.178.exe available on TI WEB site as is - you will find it in directory examples\boards\ek-tm4c1294xl-boostxl-senshub\senshub_iot
• use this example as a basis to use a more recent version of FreeRTOS: you just would have to replace FreeRTOS source code by the most recent one, and maybe to modify some code in the demo: some function names/signatures may have changed across major versions.

The procedure hereafter describes step by step how to create a minimalist FreeRTOS program with Code Composer Studio 10.3.0 and FreeRTOS v202104.00 in a Windows 10 environment using the second approach. You may have to adjust the drive letter to you specific setup, I am using D: for the purpose of this example..

• Download Code Composer Studio 10.3.0, FreeRTOS v202104.00 and SW-EK-TM4C1294XL-2.1.4.178.exe.

• Install Code Composer Studio with support for the Tiva-C MCU familly. When prompted for a workspace name, specify D:\ti\workspace_v10.

• Unzip FreeRTOSv202104.00.zipinto D:\.

• Unzip SW-EK-TM4C1294XL-2.1.4.178.exe into D:\SW-EK-TM4C1294XL-2.1.4.178.

• Launch CCS

• Use the menu item File/New/CCS Project, and create an 'Empty Project (with main.c).

[]

• Click on the Finishbutton.
• Create the following directories:
  D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\driverlib
D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\inc
D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\FreeRTOS-Kernel
D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\FreeRTOS-Kernel\include
D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\FreeRTOS-Kernel\portable\GCC
D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\FreeRTOS-Kernel\portable\GCC\ARM_CM4F
D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\FreeRTOS-Kernel\portable\MemMang
• Copy D:\SW-EK-TM4C1294XL-2.1.4.178\examples\boards\ek-tm4c1294xl-boostxl-senshub\senshub_iot\FreeRTOSConfig.h into D:\ti\workspace_v10\TM4C129EXL-FreeRTOS
• Copy all .h files from D:\SW-EK-TM4C1294XL-2.1.4.178\driverlib into D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\driverlib.
• Copy D:\SW-EK-TM4C1294XL-2.1.4.178\driverlib\gcc\libdriver.a into D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\driverlib.
• Copy all .hfiles from D:\SW-EK-TM4C1294XL-2.1.4.178\inc into D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\inc.
• Copy all files present in D:\FreeRTOSv202104.00\FreeRTOS\Source\include into D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\FreeRTOS-Kernel\include.
• Copy all .cfiles present in D:\FreeRTOSv202104.00\FreeRTOS\Source into D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\FreeRTOS-Kernel.
• Copy all file present in D:\FreeRTOSv202104.00\FreeRTOS\Source\portable\GCC\ARM_CM4F into D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\FreeRTOS-Kernel\portable\GCC\ARM_CM4F
• Copy D:\FreeRTOSv202104.00\FreeRTOS\Source\portable\MemMang\heap_4.c into D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\FreeRTOS-Kernel\portable\MemMang.
• Edit D:\ti\workspace_v10\TM4C129EXL-FreeRTOS\main.c, and replace its content by: