2024-05-31 12:30 PM
Hello everyone,
I have a question about the STM32H5 modules. I can't find the integrated FATFS in the list of middleware provided by ST. Is it complicated to integrate FATFS by myself, or should I use the middleware provided by ST?
I am using STM32CubeMX for my project, and I've noticed that the FATFS middleware option is available for other STM32 families but not for the STM32H5. If I need to integrate FATFS manually, what steps should I follow? Are there any specific configurations or additional libraries required to ensure compatibility with the STM32H5?
Additionally, any advice on best practices for setting up the file system, optimizing performance, or troubleshooting common issues would be greatly appreciated.
Solved! Go to Solution.
2024-05-31 12:51 PM - edited 2024-05-31 01:00 PM
Well ST's been shipping the 2017 broken version of FATFS for literally years
The integration is done at the DISKIO.C / SDMMC level, it surely has to be materially similar to the historic versions of SDMMC from F7 and H7. The FILE-X version presumably got to interface at the BLOCK level quite similarly.
Yes, it's probably not going to form at the press of a button, but the port shouldn't be overwhelming.
Debugging, instrument DISKIO so you can see usage and failure, add tables and checksumming for validation.
Speed/Performance, do data work at sector or cluster boundaries, do multi-sector transfers, single-up has huge inefficiencies. Try do deal with the f_read/f_write at these sector sized, sector aligned boundaries. There's no caching, and the deblocking is quite expensive. Avoid lots of small f_writes, buffer at the application level. The erase block size on the media is of the order of 128KB, the card hides the details. Format based on the erase block size expectations, the SD Industry Formatter does this, gets the FAT and Clusters falling on these boundaries, not crossing/spanning them. Avoid f_mkfs() unless you absolutely have to, cards come preformatted, properly.
2024-05-31 12:49 PM
Take a look at:
https://community.st.com/t5/stm32-mcus-embedded-software/roadmap-for-h5-usb-and-rtoss/td-p/625374
This may give you the info that you need.
2024-05-31 12:51 PM - edited 2024-05-31 01:00 PM
Well ST's been shipping the 2017 broken version of FATFS for literally years
The integration is done at the DISKIO.C / SDMMC level, it surely has to be materially similar to the historic versions of SDMMC from F7 and H7. The FILE-X version presumably got to interface at the BLOCK level quite similarly.
Yes, it's probably not going to form at the press of a button, but the port shouldn't be overwhelming.
Debugging, instrument DISKIO so you can see usage and failure, add tables and checksumming for validation.
Speed/Performance, do data work at sector or cluster boundaries, do multi-sector transfers, single-up has huge inefficiencies. Try do deal with the f_read/f_write at these sector sized, sector aligned boundaries. There's no caching, and the deblocking is quite expensive. Avoid lots of small f_writes, buffer at the application level. The erase block size on the media is of the order of 128KB, the card hides the details. Format based on the erase block size expectations, the SD Industry Formatter does this, gets the FAT and Clusters falling on these boundaries, not crossing/spanning them. Avoid f_mkfs() unless you absolutely have to, cards come preformatted, properly.