I'm investigating the i.mxrt1170 as an alternative to the STM32 range (faster, more memory, better chip layout, more ports, etc.)
The hardware looks excellent for the purpose I have in mind, but I've spent the last two weeks or so not really getting very far with the IDE.
- The first time, I naively tried to create a project with all the things I wanted enabled. I've done this before with the STM32CubeMX and it (pretty much) worked. I enabled ethernet, USB (both), SD, LCD, a few SPI/I2C etc. It wouldn't compile - ok, maybe I need to ease into it a bit...
- Next I tried a 'C' project just to blink an LED, that worked great.
- Next I tried a 'C' project with FreeRTOS, that didn't work, but there was an example design I could use, so I thought "ok"
- Next I tried adding the example 'C' project that uses an SD card with the FreeRTOS design, and that worked as well. I was feeling confident and on a roll! That was 2 weeks ago.
There was no C++ SD-card/FreeRTOS example, so I tried creating a C++ project that implemented these - this is going to be a larger design, so I want the maintainability and data-isolation of C++. This hasn't worked for me. The config I tried is below (steps 1 and 2) in case there's something glaringly wrong...
When the project has finished being made, it refuses to compile due to a conflict in the 'osa' component. There's a "_bm" (bare metal ?) as well as an "_freertos" instance.
Deleting the "fsl_osa_abstraction_bm.*" files in the osa component seems to let it compile, and indeed this then prints out "Hello World" on the console.
So far so good, maybe, but then I tried using the code from the 'C' example, in this C++ project. After fixing up all the make-a-filesystem variables/definitions and altering a few things:
- Need to get rid of the extra BOARD_SD_Pin_Config() function in board.c
- Need to change the CD detect algorithm to be DATA3 because the GPIO default doesn't work on the board
... it still didn't work. The SD card code is hanging inside some event-based loop that I don't really understand when it tries to initialise the card.
I'm kind of scared that if it's this hard to get something basic like an SD card working, it's going to be very hard to start integrating all the other peripherals, and I don't want to be in the position where I've invested 3 months of work before hitting a brick wall with (say) ethernet...
I also noticed that the file structure was a bit different for the example and the SDK-generated code (the newly-generated code puts sdmmc_config.{c,h} into a 'template' directory (which gets compiled, it's not just a template) whereas the example has it under the 'board' subdirectory.
So, am I barking up the wrong tree ? Is it possible to get C++, FreeRTOS, and peripheral code to work well together ?
As another option, I tried last night to use the Azure SD card example. That just hung after initialising the application - no threads appeared to be running... [sigh]
