Dual Core access to memory

[goingalong]

I have two tasks running constantly, one in each core. Both tasks access a common byte array.

One task collects data via an SPI daisy chain and writes it into the array. It does this constantly. The other reads the data from the same array. It does not matter if the data is out of sync for a while so I should not need a software handshake mechanism unless there is some form of "electronics" problem here.

Am I correct?

[PeterR]

It does not matter if the data is out of sync for a while

It is not clear what you mean by this.

Am I correct?

It depends but I would say no.

I am sure that you understand the multitasking issues. Its easy to overlook execution order issues however:
https://www.modernescpp.com/index.php/s ... onsistency

In your instance I guess that your writer writes to the array* and then updates the write pointer. The reader would read the write pointer, read from array (if new data exists) and then update a read pointer. The SC issue is that the write pointer might be updated before the value is written, even if your code updates the write pointer first.

* your 'array' would need to be a circular buffer. You can create a circular buffer without locks etc provided you only have one reader and one writer, well at least in the olden days before clever compilers, CPUs, cache etc.

[goingalong]

So to expand. What is happening here is that I am detecting the position of a hand above a sensor array. My collector task (core) is collecting sensor data and writing it into a common array at the maximum rate it can be collected from a 100kHz SPI daisychain. Each position on the array is an analog input from one of the sensors only and always from the same sensor. Sensor sample inputs come in at different times from each other and there is no synchronisation between the sensors. An interpreter task (core) uses the individual contents of the array at different times on the assumption that the content of the entry is the latest reading from that sensor, but it does not matter very much if it isn't because it will correct at the next reading. Hence no need for buffers or interlocks and the code structure is simple.

But it does depend on the memory controller not allowing any one physical memory location being read from and written to at the same time. (It also depends on neither core taking exclusive control of the available memory access time)

[PeterR]

OK. That makes sense.

1) Obviously the ADC would have to be 32 bits or less.
2) As long as you are using DRAM, write/read in an atomic unit then that's fine (e.g. uint32_t results = reading; rather than memcpy)
A 24bit ADC might not work with certain optimisations e.g. if you pack the array.
I would suggest std::atomic though. You won't loose any throughput, its simple and portable.

Are you trying to read multiple sensors at 100KHz each?
I think you will struggle. There is at least 10uS setup on each SPI transaction & then add SPI time etc.

[goingalong]

I appreciate the help with my architecture but what I am trying to understand is really simple. We can ignore arrays and SPI because it's really about memory transactions at the hardware/firmware level and that is the way I should have framed my original question.

In one core I have a task that writes to a memory location (at a non constant rate). In the other core that reads from that same location (at a non constant and different rate). Can the two actions conflict in such a way as to cause corruption to that location.

Many thanks.

[PeterR]

If; (a) ESP32, (b) 32 bit or less read/writes, (c) one task only reads, one task only writes and (d) DRAM memory then you will be ok.

You will understand why you might not be ok if you used PSRAM.

Personally I would use both belt and braces and so std::atomic.