On another thread (http://www.raspberrypi.org/forums/viewt ... 31&t=99710
) rhapsody asked a question that set me thinking.
I'm not well up on such things, so I didn't want to interrupt that thread with off-topic trivia, so I thought I'd ask on a new thread.
One of the draw-backs of most none-real-time OS's such as Linux or RISC OS is that they take time out to do housekeeping, so we don't know when things are going to happen.
My preferred OS is RISC OS, which isn't (as yet, to my knowledge) multi-core aware.
On the Pi B+, I've had "problems" driving a couple of 32x16 LED panels, because as soon as the Pi wanders off to do other stuff, one line is left lit for too long, causing flickering.
I did look into a hardware buffer to flatten out the timing, but it gets expensive and clutzy.
But we now have four cores, so would it be possible to reserve one of them to do the real-time stuff, and just feed a buffer from the other cores with what we want to output down the GPIOs?
Core 0 running RISC OS, with an area of ram set up as a buffer
Core 1 ... unused
Core 2 ... unused
Core 3 bare-metal program reading that area of ram, and driving GPIOs
My areas of ignorance:
I'm fairly happy about accessing the GPIOs from assembler inside RISC OS (not a problem on B or B+ though there are elephant-traps on 2) but there're probably things I'll need to do to set it up.
I'm not sure how to create an area of ram that other threads can see.
How do we access another core, to bring it awake, point it at its program (that will be probably small enough to fit into the L1 cache, if that makes much difference), and enable it to see the buffer?