ChibiOS Free Embedded RTOS

Probably it would be better to add a compile time option for flushing, to be enabled if it is required: device type, default allocation.

Giovanni

steved wrote:Not sure whether there's any advantage to checking whether the buffer is in cached RAM, but it didn't seem to do any harm.
I've also adjusted my malloc() to assign memory starting on 32-byte boundaries (i.e. cache lines)

I took a different tactic, since:
- For third party stuff like this sqlite VFS layer I'm making, it may hand me pointers that it allocated on its own stack, or using newlib's malloc and I cannot guarantee they are 32 byte
- The FIL data structure's internal buffer may not be 32-byte offset from the start of the structure (now or in the future)


I think my 32byte alignment, married with your check to see if it is in a cacheable RAM segment would be optimal (and of course with better #ifdef logic, but I'll leave that to Giovanni).



Dave

Here's a fixed version of my previous patch. I shouldn't do ptr math after two pots of coffee; just one.

we hit something similar in ArduPilot, and ended up solving it using a bouncebuffer API, allowing for an external manager for DMA-capable memory. Patch for SDMMCv1 is here:
https://github.com/ArduPilot/ChibiOS/co ... a984a90803
The bouncebuffer code is here:
https://github.com/ArduPilot/ardupilot/ ... cebuffer.c
https://github.com/ArduPilot/ardupilot/ ... cebuffer.h
We setup the main stack/heap/data in SRAM1/SRAM2, and use DTCM for bouncebuffers and for the heap when the primary heap is full.
We use the same bouncebuffer code for SPI and I2C as well.
Cheers, Tridge

dflogeras wrote:

steved wrote:Not sure whether there's any advantage to checking whether the buffer is in cached RAM, but it didn't seem to do any harm.
I've also adjusted my malloc() to assign memory starting on 32-byte boundaries (i.e. cache lines)

I took a different tactic, since:
- For third party stuff like this sqlite VFS layer I'm making, it may hand me pointers that it allocated on its own stack, or using newlib's malloc and I cannot guarantee they are 32 byte
- The FIL data structure's internal buffer may not be 32-byte offset from the start of the structure (now or in the future)


I think my 32byte alignment, married with your check to see if it is in a cacheable RAM segment would be optimal (and of course with better #ifdef logic, but I'll leave that to Giovanni).

sdc_cache_coherency.patch.zip

Dave

I created my own malloc() (initially for other reasons), so it was easy to make it call Chibi's heap allocator with 32-byte alignment.

This whole business of managing cached RAM could do with some refinement, although I'm not sure how feasible it is to do things in a totally generic way. It would probably be enough to specify non-cacheable areas in one of the configuration files, which auto-generated MMU code to disable caching if necessary. This then needs a way of keeping track of which MMU banks are in use..... Then a call to determine whether caching is enabled on a particular block - isMemoryCached(start, blockSize), which feeds through to the cache flush and invalidate functions.
Would certainly be better than my very processor-specific check.

Using MMU is not that easy because it requires 32 bytes alignment, a general approach is hard.

What could be done is to create a special segment guaranteed to be non-cached (using MMU or other means) but it would still up the application code to put buffers in there, something not easy when using a 3rd part library like FatFS.

Giovanni