It isn't a matter of how many instructions, you need to call the instruction that constitutes a memory barrier to ensure memory consistency across the whole SoC, not just the one core. And you need to ensure the compiler doesn't mess with access ordering either. The kernel documentation on memory barriers might be worth a read (btw, each core behaves as a separate CPU in that doc).Yes, the datasheet says you only need barriers between reads and writes to different peripherals. In my case I am accessing GPIO, CLK, SMI and DMA registers. Some of these accesses do follow each other pretty closely in my C code, but I haven't looked at the assembly listing to see how many instructions are actually being executed between these accesses. I guess the safest thing would be to use barriers but maybe that would be overkill. Does anyone know what would be a safe number of instructions between accesses to avoid the problem?
And on a multi-core CPU you also need to serialize access to the shared peripheral registers to ensure one core doesn't mess with the peripheral at the same time and break the memory barrier/access ordering requirement. Now you are getting into what the OS does for you. If you try messing with that from userspace you will be contending with the OS itself. Essentially, any userspace solution under Linux that directly messes with peripheral registers is fundamentally and dangerously flawed and should be avoided - unless you can somehow guarantee that your app is the only thing in the system that will be accessing those peripherals. pigpio seems content to assume the latter.
Statistics: Posted by warthog618 — Mon Jan 22, 2024 12:35 am