Are there any standard Peripheral drivers for STM32H7 MCUs?

[MColl.3]

Is there a library of peripheral drivers for "standard" ports such as Serial, USB, Ethernet, SD card, etc.?

For example, I am designing a board with STM32H743 and using a LAN8742A Ethernet Transceiver (RMII interface). Is there firmware code I can download and run the transciever?

Thanks.

[waclawek.jan]

CubeH7

You can get it together with CubeIDE, if you intend to use CubeIDE.

It contains example code for boards like Nucleo, Disco or Eval (thus code supporting chips on those boards). There's no guarantee you'll find your particular PHY supported out of the box, although ETH PHYs tend to conform to a minimal common denominator.

I personally don't really recommend using Cube. Maybe as an inspiration. But then your other option is sweat, tears and toil.

JW

[Nikita91]

Ethernet on H7 has a long history, which is probably coming to an end, look at:

https://community.st.com/s/question/0D53W00001Gi9BoSAJ/ethernet-hal-driver-reworked-by-st-and-available-in-22q1-preview-now-available-on-github

For these standard but complex peripherals (USB, Ethernet, SD), there is hardly any other possibility than to use the HAL provided by ST.

[waclawek.jan]

> For these standard but complex peripherals (USB, Ethernet, SD),

> there is hardly any other possibility than to use the HAL provided by ST.

That's not true.

There are preexisting non-Cube examples even from ST, and then there are various solutions out there avoiding Cube, too. And it's not impossible to roll out your own.

As I've said, much of the complexity of handling these interfaces is independent from STM32 itself.

I personally am more afraid to handle the beast 'H7 is, than dealing with ETH or USB.

JW

[Pavel A. · Accepted solution]

The LAN8742A by itself is installed on many STM32 evaluation boards, and these come with example projects (part of the ST "HAL" library).

ARM also provides drivers for LAN8742 and much more in their CMSIS repository.

But as others wrote, your bigger problem will be dealing with STM32H7's ethernet controller and STM32H7 itself. Start from example projects in the current [or the future draft] ST 'H7 library.

[Piranha]

The reality is almost the exact opposite. Especially for those relatively complex peripherals, using HAL/Cube broken bloatware comes with a 99% guarantee that your system will never be reliable and an 80% guarantee that it will never work at all.

By the way on F1, F2, F4 and F7 the ETH peripheral is not that complex. It's harder to get it working properly than USART, but easier than I2C. The reason for that is the I2C peripheral has to be reconfigured on the fly during every transaction while the ETH peripheral does everything on it's own automatically. Just queue the descriptors+buffers and forget about it... until the interrupt signals the completion, of course! The H7 and ETH in it is more complex, bet almost all of the additional features are optional and base functionality is not much more complex.

[Nikita91]

Of course, we can consider that any average developer may have to redo everything from scratch.

But for that it is necessary to carefully study all the manuals (stuffed with errors and approximations), to have skills in the low level of the protocols involved. In addition to common knowledge such as MPU, linker scrips, DMA, the peculiarities of each memory region of the STM32, where to put the compiler barriers ...

The developer must have time, and he will discover and will have to correct all the pitfalls encountered by ST and all those involved on this site.

There are people who have done this, there are some on this forum. But these are not average developers, and they have many years of practice. For those (including me) who are subject to a project manager, there is little other way than to use what is available.

Unfortunately that doesn't mean it's easy and it works the first time.

And there I regret that the code generated by MX requires so many manual adjustments to be used.