STM32H7 Missing SPI Driver

[thestumbler]

That's a disappointment, I just realized there is no SPI driver for H7 chips.
I should have seen that in the table on page 1, but I realized it after LBUILD kept failing on me.

How big a deal is it to make one?

[salkinium]

cc @chris-durand I believe you may already have a H7 SPI driver?

[chris-durand]

There is an SPI driver, but it's not merged yet (#1052). I'll try to bring the PR to a mergeable state during the next two days.

[salkinium]

The best way forward is to cherry-pick the commits from the PR to your fork, then you're independent of our timings.

[thestumbler]

With my still incomplete knowledge of the framework and modern C++, that's too much of a risk for me (schedule wise). I will proceed by just porting my existing C code, and try to do that in a way that I can easily swap it out in the future when H7 SPI becomes available down the road, or I come back to it later and try to do it myself.

[chris-durand]

I have updated the PR now. Sorry, there was other urgent stuff at work.

[thestumbler]

@chris-durand Thanks for this. I just updated my local fork, and wow was that difficult! In fact, I think I lost the forkedness of my local repo when the dust settled. I'll lay the blame at my feet, because I'm a bit shaky when it comes to recursive submodules.

Ultimately the only changes that I had made, besides new board definition directories, were ones I think are suitable for a pull request:
(1) Extended flash.cpp for minimal H7 support.
(2) added explicit reset pulse definitions to the OPENOCD initialization script.

I'll attempt that process this week.

[thestumbler]

Ironically, I have quite a few SMD 0.050 inch pitch to 0.1 adaptors just for this reason, to be able to plug ICs into a breadboard. But no thru-hole 50 to 100 adaptors. I have some pre-crimped wires that are part of a Molex Picoblade connector kit, which has the same pitch, and those wire ends fit well over the pins on the shuttle. I guess it will be flying wires for me. I did find a shuttle base board that Bosch sells, but it is a full-blown MCU, not just a breakout. Edit: OOPS, wrong sub-thread.

[thestumbler]

What's the test hardware you used, if it is something readily available, that is, for the BMI088 example? I see a tiny evaluation module on Digikey which looks suitable.

I also was excited to discover my client's target board uses this same IMU -- not that I need an IMU for a boot loader, but because it would let me run the example almost unchanged to get me started. That plan was (temporarily) nixed when I realized all the boards I have don't have the IMU populated. I'll be plunging ahead trying to talk to my own SPI device (Wiznet W5100S), but I'm going to get ahold of a BMI088 somehow just as a backup way to check SPI when things go wrong.

[chris-durand]

I've tested the driver with the BMI088 evaluation module ("Shuttle Board 3.0") and a H723 Nucleo during development. In my current project I'm working with a custom STM32H723ZG board with that IMU and a few SPI interfaces connected to other MCUs.

Any SPI device modm supports should work with the driver. If you have anything lying around we already have a driver for you can give it a try with the Nucleo board. It shouldn't be too hard to adapt the example for the H7.

[thestumbler]

Thanks. Good point and I'll check what I have. Alas I followed up with my client and the BMI088 on the schematics is for a future option which explains why none of my boards have it installed!

I did notice one thing, I have a design where two devices share the same SPI2 bus with independent selects. In the future, if I wanted to try MODM in that application, does the framework support multiple drivers sharing the same SPI interface? of course with their own NSS controls, and also understanding the application itself has to ensure they don't interfere with each other.

[rleh]

does the framework support multiple drivers sharing the same SPI interface?

Yes.

of course with their own NSS controls,

Of course.

and also understanding the application itself has to ensure they don't interfere with each other.

The application doesn't have to care about that, the drivers in modm (should) do that with the help of modm::SpiDevice::acquireMaster().
Using modm::SpiDevice::attachConfigurationHandler() even devices with different SPI settings can be used on the same bus.

[thestumbler]

I've tested the driver with the BMI088 evaluation module ("Shuttle Board 3.0") and a H723 Nucleo during development.

@chris-durand I ordered one of those shuttle boards last week, not because I need an IMU but to have a known good SPI module on-hand. I didn't check closely, however, and was surprised when it arrived this morning to see the pin headers had 50 mil pitch 1.27 mm. I'm not familiar with the Shuttle form-factor, is there some accessory adaptor I should have ordered in order to make it useful for breadboarding? Sure, I can put something together from parts in my lab, but I'm curious how people use these boards if not on a breadboard for development.

[thestumbler]

Problem solved. Should arrive by Monday.