theoldwizard1 wrote: ↑
Thu Nov 22, 2018 7:41 am
DavidS wrote: ↑
Thu Nov 22, 2018 5:14 am
Obviously you already got to the point of successful boot, successful enabling of the CPU Caches, and successfully turned on the MMU with a valid page table. As such you need little else, as long as your code and data is small enough it will stay in the caches, nothing more to it, so long as that really is all your system does.
Of course that is not the ONLY thing it is doing ! I am concerned about other processes "flushing" the L2 cache (which is shared amongst all of the cores, correct ?)
and/or what ever the "write back" strategy is that would stall the dedicated processor.
LdB wrote: ↑
Thu Nov 22, 2018 6:16 am
I still don't believe it will change the fact the GPIO bus is slow and you still are limited. The max gpio speed is 71Mhz the core is doing 1400Mhz that is a 20 to 1 ratio and you can loop it on 3 cycle loop. If it was capable of going faster it already would.
I am an old
"hard real time" guy. Never really dealt with caches and how they change the determinism of a process or a GPIO pin could not be read within 1 or 2 cycles. These are "new concept" to me ! We did not clock very fast, but these issues just did not exist !
As GPIO is your bottle neck not sure that it matters, though how much code do you have running? Is there anythign that needs to explicitly flush the cache in your system? And do you allign your code to 16 word blocks?
These are all things that will effect how well your code stays in cache. There is rarely a need to manually flush the cache, most things can be done by allocating pages that corrispond with hardware registers, framebuffer, mailboxes, or other things that may require not remaining in cache as write through.