innomatic

Build a low level driver for SD card, then the glue logic for FatFs and USB MSD is pretty much the same as Flash memory case posed before. In case of SD card, sector size is 512 in most of the cases. Thus the memory requirement is much relaxed. You can even allocate a file buffer that is bigger than the sector size. FatFs site has a  dedicated page for MMC/SDC, on which you can find fairly detailed explanation about how to interface MMC/SDC via SPI bus. Implementation should be straightforward until you encounter with cheap SD cards that do not behave very well. In such cases, you either have to protect your code with redundancy or just stick with quality devices. If you choose SanDisk or Kingston brand, you will be safe. ADATA on the other hand, frequently generates timeout error at first try. Most of the SD card sockets have a pin to detect the presence of the card. This pin is usually connected to GND pin or some other pin. You can use this to generate interrupt whenever ...

STM32Cube framework provides very similar interface for FatFS as USB MSC we have seen before. Again the same argument applies to this case about the basic unit of read/write operation on a flash memory. In this case, the sector size and the cluster size should be equal to the sector size of flash memory, namely 4KB. This can be set in the file ffconf.h , in which a lot of customization can be done by changing the definitions. In particular, following definitions should be set. In the file user_diskio.c, USER_read and USER_write functions can be implemented as the same way as before. Here we assume that the count is always one for the simplicity. In reality this can be bigger than one if you call f_read() with the buffer size larger than the sector size (4096). However given the limited memory capacity, that is not realistic. By similar token, pdrv variable can be ignored. If ioctl is to be used, then  FatFs allows users to not only read and write files but also to ...

Sometimes implementation of UART communication is asymmetric. In general, Rx tasks are time critical and total size of the data is unknown, thus it is best to handle the task in an interrupt service routine where individual incoming bytes are checked without delay. While Tx tasks can be implemented rather relaxed manner. For example, you can use a blocking call inside the main loop. In this sense, UART HAL functions provided by STM32Cube framework is useful for Tx but not very much so for Rx task. Thus you may have to write your own UART interrupt handler using LL drivers while still using HAL UART Tx functions in Tx task. Use STM32Cube to generate all the chores of setting the UART module except the interrupt part. LL interrupt is activated after the UART port is initialized using LL functions: Source file 414 void SerialComm_Init () 415 { 416 LL_USART_EnableIT_RXNE ( huart1 . Instance ); 417 } Then write the interrupt handler to call Rx routine: ...