2021-09-29 07:21 AM
Reducing the number of sensors enabled in the configuration file helps, as does slowing down the SD clock (i.e. increasing hsd1.Init.ClockDiv = n in STWIN_sd.c). We've also noted that the code in sd_diskio.c has the compile time build define "ENABLE_SCRATCH_BUFFER". Please can you say if this should or should not be switched on for the StWin1b hs data logger ?
2021-09-29 08:46 AM
Sorry, not familiar with this project.
The scratch buffer method I originally developed for the F4 SPL addressed the unaligned memory issue when using DMA, which needs 32-bit alignment.
It would decompose read/writes into single sector accesses via an aligned buffer, either on the stack or statically allocated.
If you do f_read/f_write with large requests that are sector multiples, sector aligned, and with 32-bit aligned source/dest memory the scratch buffer won't be needed.
Where things get ugly is if you do a lot of small or spanning writes which require FatFs to shuffle and deblock, using portions of your original buffer at a byte level.
SDIO is going to be woefully inefficient with non-sector aligned file IO, you should buffer 8KB or up to 32KB and manage/wrap your output functionality to optimize writing in multiple sectors, on sector or cluster boundaries within the file.
If you're using DMA, and randomly sized f_read/f_write, you're going to want to "double buffer" rather than "transfer in place"
You could add an assert() to the routines in DISKIO layer to confirm this as a potential failure mechanism.
ST's implementation for POLLED transfers is also VERY WEAK, rather than optimize the normative case, it cripples all transfers to handle the potentially unaligned ones.