(First of all, you can check out the sample codes from here)
In my navigation projects, I started to use STM32F4 discovery board as a basic prototyping board. It is STM’s microcontroller evaluation board which costs only 19$. Despite its cheap price, it has everything that immediately makes interfering with the inertial sensors possible. It not only contains pin-outs for the microcontroller, but also has an on board debugger/programmer (stm32 link/v2) so that embedded code can be directly uploaded (and debugged) via the USB port without an additional JTAG module.
If you had any previous interest on hobby electronics, you would have probably heard about Arduino boards. Arduino can also be considered as fast prototyping board. Due to its immense popularity among enthusiasts, there are significant amount of existing code samples on the internet. However, compared with the stm32f4’s capabilities, the Arduino boards are kind of simple toys. Therefore, I strongly suggest you not wasting your time with it.
The biggest problem with the STM32 is that there are not sufficient code examples on the internet. Therefore, it sometimes becomes quite a burden to read pages of reference manual to understand the function of certain registers, or to learn the efficient way of using a peripherals. There are some sample codes for STM32F1, however, these codes cannot be readily used for STM32F4 due to the differences between the F1 and F4 architectures. (By the way, STM32F4 is based on ARM Cortex M4 which is the newest pseudo-DSP family of the ARM microcontrollers.)
Currently, STM is the only manufacturer which produces ARM Cortex M4 based microcontroller. NXP is also going to start selling its own Cortex M4 family very soon. In fact, NXP has bigger user support and sample code base compared to STM. Furthermore, its application notes is more explanatory than the STM. Therefore, I think NXP may be a better choice for the beginners. On the other hand, STM32 has more peripherals than the LCP (NXP) which makes STM32 more favorable at least for me.
I have uploaded two STM32 sample projects for the I2C and SDIO peripherals. These peripherals are essential for the IMU designers as they are required to communicate with the sensors and then to record the sensor data to the SD cards. You can download these sample codes from the github page (here).
STM32’s I2C interface is a little bit problematic. One has to write different functions depending on how many read/write transaction is going to be performed. In order to stretch the clock properly or send NACK/ACK at the correct time, you have the read and learn each function of all registers. There is a considerable difference between reading a single byte and multiple bytes. In the sample codes, I added plenty of comments so that you can see how a proper read/write sequence can be performed with the I2C peripheral without using the DMA for different number of bytes.
STM32 uses 6 wire SDIO interface to communicate with the SD cards. SD cards themselves are also another pain to learn and to use. Because of it is a proprietary technology, there is no sufficient reference on the internet. Therefore, when your embedded code does not function as it is intended, it becomes hard to understand whether it is the code that has bugs or it is you who cannot understand the correct command/response sequence.
Most of the SD cards also support SPI interface. But, the SPI interface uses the same command and response protocol. As SPI uses the same line for data and command transmission, it becomes almost impossible to recover from an error. Therefore, I suggest everyone to use SDIO rather than SPI for the SD cards regardless of the data rate requirements.
The example codes that I uploaded have functions to perform single/multiple block write operations using the DMA. Again, I included plenty of comments to not only describe the codes but also the overall SD communication protocol. Therefore, I believe it will be quite useful for anyone who wants to record inertial sensor data to the SD cards for post processing.
The most problematic point about programming the SD cards is that the SD cards arbitrarily switch themselves into the so-called busy mode from time to time. During these busy modes, SD cards do not respond anything other than certain commands (in SPI mode, as the data line is the same as the command line, it does not respond to anything at all). Therefore, without using a DMA, it is almost impossible to use SD cards for projects which require strict timing specifications (such as periodic IMU sampling). The STM32’s data-path logic of SDIO takes care of these “busy-modes” without the intervention of the microcontroller when the DMA is used. (However, as I indicated in the comments of sample codes, one has to check the busy mode manually for the command-logic). In single block write operations, SD puts itself busy mode after every block. That is why, you should prefer multi-block write with an internal buffer structure if you want to use SD cards as fast as possible.
One problem with the STM32F4 discovery board is that another integrated circuit is connected to the microcontroller pins which are needed for the SDIO. Therefore, before using the SDIO interface you need to remove that component with a hot air gun. Otherwise that component will pull the lines high and block all the communication.