logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

ESP-32 Dual Core Variable Sharing: Ensuring Safe Read/Write Access

michalek002a 1521 13
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
Reply | New topic
  • #1 19782223
    michalek002a
    Level 6  
    Hi. I want to use two cores in ESP-32 and have the two cores use the same variables. I'm just wondering how to make it so that when one core writes data to a variable, the other core doesn't start reading it, because some strange things might come out. Shouldn't there be a problem with this though?
    Rust on Embedded Online Conference on 16 July with 33 per cent discount for elektroda users
  • ADVERTISEMENT
  • Helpful post
    #2 19782267
    freebsd
    Level 42  
    michalek002a wrote:
    However, shouldn't there be a problem with that?
    Very good intuition. In C you can use "volatile", but in general you should look up "atomic operations", "semaphores" for the language you are programming in.
    Ps.: It is worth, but definitely worth, taking an interest in the Rust language for concurrent programming. I don't know what its status is for the ESP32, and I would add that it is not a straightforward language, but having dealt with large HPC systems I didn't know there was so much I could still learn :-) .
  • #3 19782858
    PrawieElektronik
    Level 10  
    The commonly mentioned "volatile" is not a cure for the aforementioned issues. It is merely a wish not to cache a variable in the CPU registers, but to force it to be deposited into RAM.

    It is indeed appropriate to talk about synchronisation.

    ALE. .
    Depending on the class of the issue, you can get synchronised to death, steam will go to the whistle even 50% of one CPU.
    There should be as little of this as possible, which should be achieved by a good algorithm preparation strategy.
    In different domains, computer science has different proposals for the use of cores, so that as little as possible cores "walk on each other's toes"

    What are you preparing, what issue?
  • ADVERTISEMENT
  • Helpful post
    #4 19784946
    khoam
    Level 42  
    michalek002a wrote:
    I want to use two cores on the ESP-32 and have the two cores use the same variables. I'm just wondering how to make it so that when one core writes data to a variable, the other core doesn't start reading it, because some strange things might come out. Shouldn't there be a problem with this though?
    .
    Mutexes are used for this purpose, i.e. to synchronise the writing/reading of the same data by different threads of a program.
    Example: Link .
  • ADVERTISEMENT
  • #7 19785222
    freebsd
    Level 42  
    khoam wrote:
    What is this quote from wikipedia supposed to serve? I remind you that the topic of the thread is ESP32, and therefore FreeRTOS.
    To expand on the concept of "mutexes".
  • #8 19785234
    khoam
    Level 42  
    :) So I suggest (to start with) reading the detailed description of semaphores and mutexes contained in the book "Mastering the FreeRTOS™ Real Time Kernel". - page 233 The book is available free of charge on the web at: Link . No need to use wikipedia :) .
    FreeRTOS is an integral part of ESP-IDF, so regardless of the programming language used for ESP32, you should know the basics of FreeRTOS.
  • #9 19785243
    freebsd
    Level 42  
    khoam wrote:
    Mutexes are used for this purpose, i.e. to synchronise the writing/reading of the same data by different threads of a program.
    Mutex is a broader concept and does not just refer to "writing/reading the same data".
  • #10 19785250
    khoam
    Level 42  
    freebsd wrote:
    Mutex is a broader concept and does not just apply to "writing/reading the same data".
    .
    I wasn't implying anything of the sort, i.e. that mutex is only used to synchronise writing/reading of shared data. Please refer to the documentation link I provided in the previous post for a colleague to expand on this.
  • #11 19785259
    freebsd
    Level 42  
    khoam wrote:
    In the link to the documentation I provided in the previous post, a colleague can expand his knowledge on the subject.
    Kindly thank you for your concern :-) , but professionally I have not been involved in such small systems for a long time - now it's just a hobby, time permitting, especially as ESP32 does not thrill me.
  • #12 19800187
    michalek002a
    Level 6  
    PrawieElektronik wrote:
    The commonly mentioned "volatile" is not a cure for the aforementioned issues. It is merely a wish to not cache a variable in the CPU registers, but to force it to be deferred to RAM.

    It is indeed appropriate to talk about synchronisation.

    ALE. .
    Depending on the class of the issue, you can get synchronised to death, steam will go to the whistle even 50% of one CPU .
    There should be as little of this as possible, which should be achieved by a good algorithm preparation strategy.
    In different domains, computer science has different proposals for the use of cores, so that as little as possible cores "walk on each other's toes"

    What are you preparing, what issue?
    .
    I need to read and write data to the SD card on the fly, while executing the program uninterrupted. I haven't actually checked what read/write speed I'll have yet, but wanted to be safe.
  • ADVERTISEMENT
  • #13 19800415
    khoam
    Level 42  
    michalek002a wrote:
    I need to continuously read and write data to the SD card, while executing the program uninterruptedly.
    .
    The SD card read/write thread should have a higher priority than the other threads in the program. In a single thread pass, the card read/write should take as short a time as possible, i.e. single bytes rather than blocks of data. This is how I see it ;) .
  • #14 19801147
    JacekCz
    Level 42  
    michalek002a wrote:
    I need to read and write data to the SD card in real time, while executing the program uninterrupted. In fact, I haven't yet checked what read/write speed I'll have, but I wanted to take precautions.
    .

    Programs run in blocks of algorithm, blocks/groups of data .... so in some sense they are "intermittent".
    With good planning this can be done nicely, e.g. by portioning the data from block to block, and then treating it as immutable. Then the synchronised elements are reduced to a minimum.

    Good structuring of data and code is more important than coder tricks with unstructured data.
    There are already more resources available on the ESP, it can be programmed in a decent way, in layers/blocks/objects (since the Atmega 8 has an event queue, simple as it is, but it was there).
Reply | New topic
Report a violation of the law

Topic summary

The discussion centers on the challenges of using dual cores in the ESP-32 for shared variable access, emphasizing the need for synchronization to prevent data corruption during concurrent read/write operations. Key solutions include the use of "volatile" for variable declaration, mutexes, and semaphores to manage access to shared data. Participants highlight the importance of efficient algorithm design to minimize synchronization overhead and suggest prioritizing threads for tasks like SD card read/write operations. The conversation also references FreeRTOS as a critical component for managing tasks on the ESP-32.
Summary generated by the language model.
Popular Topics
ADVERTISEMENT