Hello, My team and I are currently completely redesigning our serially executed system in order to use FreeRTOS, which introduced a lot of concurrency and successivly unforseen related problems. To give one (the biggest problem) example: We plan to use a Cache-Manager-Task, which manages all concurrent accesses to flash memory. Writing to Cache is no problem, since we send message containg a pointer to dynamic memory. Ownership to this memory will be granted to the Cache, which will free the dynamic memory once it is copied to flash. Thus, any task writing to cache (by sending a message to the Chache’s queue, can continue to execute it’s code. Reading from cache is a BIG problem, though: The task wishing to read sends an appropriate message to the task, together with a pointer into which the Cashe should read the flash into. Unfortunately, the task must now wait, until the Cache sends a message, that the read as been performed. This introduces a lot of problems: 1. Our code becomes fragmented, if several reads must be performed, mostly because, Reads are limited to flash pages (256 byte). We can no longer loop over the flash. 2. Since we must wait for the cache, other events (messages) may have been put into our task’s queue, before the result message from the cache arrives, introducing very nasty concurrency. I have no idea about what to do aside from writing very complex code, which frustrates me and my team a lot. Is there any possibility to halt my task and somehow continue at the exact place from where the read request was sended, thus bypassing the message queue? best regards, Christian     

How did your old system do this?  Did it just wait for all flash access to complete? I would guess that you write to flash much less frequently than you read from it.  Is it possible for two tasks to read the flash at the same time, with just writing to it the part that must be guarded.  Maybe you could change your cache task to only handle writes and set a lock bit when the flash is currently being written.  The tasks that read need then only get the lock and read directly. Maybe this is too simplistic.  Where is the flash?  Built into the chip or on a bus?  Serial bus or parallel bus if relevant.

I suggest you use a second queue for only the returns of a read action from the flash manager.  Then block on this queue after a read request.  The return could also give you information like read success or fail.