To set the scene, I’m pretty new to all things BLDC, not to mention all thing microprocessor and embedded engineering related, so I hope my encyclopaedic ignorance is not too frustrating for you.
I’m working on setting up my first BLDC based on the very useful resources of the Simple FOC project. My initial set-up was as follows:
- motor: 22 pole brushless gimbal motor (Quanum)
- sensor: AS5147P, communicating on SPI
- driver board: SimpleFOCShield V2.0.3
- processor: Arduino Uno
So far things went pretty well - closed loop control in each of torque, position and velocity modes all operate as expected. I also added an ADXL345 accelerometer (communicating on I2C), and set that up as a “proportional switch” to set the target torque of the motor. This works great too.
At this point, I was using 90% of the Uno memory, and since I intend to add at least 1 more motor to get my project working, I decided it was time to switch up to a more capable board. Knowing very little about these things, I decided the STM32 nucleo64 boards looked like a popular and capable choice, so I ended up with a nucleo-f446RE. At this point, based on various things I’ve read across this forum, I also decided to switch from the Arduion IDE to PlatformIO.
Whilst a bit of a step up, some serendipitous keyboard mashing was enough for me to get my program recompiled and downloaded (maybe not the right technical terms) onto the Uno from within PlatformIO, and it seems to work just as well as it did when built in the Arduino IDE.
In my naivety I hoped I could then just make a version of the project where I set the board to the F446RE in the .ini file, and press GO. Oh dear. This was about two weeks ago, and since then I’ve spent about six years (it’s non-linear) pressing buttons, reading forums, downloading softwares and engaging in heated, one-sided debates with everything from “the internet” to my coffee mug, and all to little avail.
In more detail: the first thing which I know is not working correctly with the Nucleo board is the SPI signal (that is to read the AS5147). I am attempting to use the same pins I use on the Uno (digital 10-13), which I think it the primary “SPI1” on the Nucleo. While I do get some sort of signal when I run my code, which has some vague correlation to the motor (the signal changes when I spin the motor by hand), the signal is extremely “noisy” and nothing like I was reading through the Uno.
I have come to understand that the F446RE, while it has physically a duplication of the Uno pin-out pattern on the board, does not necessarily constrain itself to using these pins in the same way the Uno does. I believe the processor and/or board and/or software (delete as appropriate) needs to be configured, so as to tell it what to use the pins for.
I downloaded the STM32CubeMX software and, after it had finished downloading a couple of GB worth of files (?!), I was able to see that in the default config for the F446RE, SPI1 is not actually available, since PA5 (i.e. old D13) is mapped as a GPIO Output, not SPI1_SCK, and also that you had to actively choose to “enable” SPI1 for the other required pins to be mapped as anything other than blank.
So the crux of my trouble is that I know some form of configuration has to be done to explain to the board what I want it to do, but for the life of me I can’t find any moron-friendly instructions which explain how this might be achieved.
My possible ideas are as follows:
Use STM32CubeMX to generate a range of C files which capture the settings I might select within the STM32CubeMX graphical interface. The key sticking point here is, once generated, how do I introduce these files (all/some/just one?) to my platformIO project such that when it does its compilation wizardry, it correctly includes these configuration notes? I did find a thing on github called stm32pio, which seemed to be roughly a solution to this conundrum, but when I tried to use that I couldn’t figure out how to make it happy with all its “dependencies”, and the whole thing started to feel quite Alice-In-Wonderland.
Through trawling of these forums, I’m tenuously sensing that there may be another way to explain to the Nucleo what I want it to do through some files already within the scope of PlatformIO. These may (or may not) include:
i) “build flags” in the .ini file
ii) something called the “variant file”
iii) the PeripheralPins.c file
Beyond their names, I’m not really sure what each of these is about, or how to engage with it in a useful way.
Declare war on a small neutral country
As far as I can tell, each of these options has about as much chance of getting this board working as any of the others, so if anyone can guide me, you will have my eternal gratitude. I guess really what I’m looking for is a “basics-for-beginners” type introduction in how to get off the ground with the combination of PlatformIO and the Nucleo board. It’s difficult for me to stress sufficiently how little I know about what I’m actually trying to achieve here, so a really key criteria is an explanation that doesn’t assume I already know what’s going on. I’ve a horrible suspicion I will just need a couple of lines of simple code somewhere I need to say “Dear Nucleo board, please enable the SPI1 on pins XYZ, thanks a lot”, but so far two weeks of searching has failed to uncover the stone under which the necessary lines are hiding.
If anyone can point me towards any resources of this kind, or even put together a basic explanation, it would save a huge amount of (additional) stress and outrageous language, and be received with great gratitude. I’m hopeful that once I get a grasp on this configuration business, I’ll at least have a chance of being able to work my way through any subsequent problems that arise with any of the other signals (I2C, the PWMs etc.) and ultimately get back to where I was with the Uno (i.e. fully working FOC) on the Nucleo.