New project advice

[geneM]

I’m about to start a new embedded project that is probably outside my skill set (as usual) and I’m hoping to get some recommendations on what STM MCU might have a reasonable learning curve to build up the MCU part of this system. It’s another autonomous oceanographic observing platform like I’ve built in the past with a lot of help from people on this forum. That system used a STM32H7 MCU. For this case, I need a few more serial ports and an ethernet connection to a new sensor. And I’ll need a file system and lots of Flash and SRAM. Low power matters, but the MCU is pretty low on the power consumption histogram.

The STM32H5 looks like a good choice since it has lots of serial ports and the Nucleo STM32H563 has an Ethernet phy and a USB-C connector that theoretically could support a USB Flash driver.. Here are a few specific questions

Q0 Is there a better MCU choice with an easier learning curve that might meet my requirements?

Q1. It looks like the H5 and STMCubeMX/IDE now use FileX which seems to require ThreadX to deal with a USB Flash drive. I’m not enthusiastic about have to use ThreadX but I did build a simple CubeMX project with that functionality enabled. It looks like it takes 68K just to handle the Flash drive. Does that seem right? Should I just drop the Flash Drive and fall back to the uSD card I’ve used in the past?

Q2. Per some posts on this forum, it seems like I could fall back to FatFS which I’m more used to. I’ve been trying to get a CubeIDE project running using the STM Classic middleware but it’s a heavy lift for me. Is this approach as complicated as it seems to be?

Q3 I’ve never had to deal with Ethernet in an embedded system. Are there enough examples around that I might be able to get this running without going insane?

Thanks - Gene

 

 

[Ozone]

>  It’s another autonomous oceanographic observing platform like I’ve built in the past …

I suppose a more detailed description of your requirements (IO channels for sensors and communication, power supply, storage) would help to narrow recommendations down.

Without knowing those details, I personally would consider a Linux SBC with MCU-based sensor boards.
With the Linux system being either a STM32MPxxx or a commercial one like a Raspberry Pi.

[Saket_Om]

Hello ​@geneM 

For your situation, the easiest learning curve is often “use what is closest to what already worked”, so another H7 variant is probably the safest recommendation unless H5 gives you a very specific advantage you need.

[Andrew Neil]

STM32 MCU product selector

 

Distributors often have good parametric search engines.

 

Have you tried asking Sidekick?

 

[Andrew Neil]

Q0 Is there a better MCU

As ​@Ozone said, I think you first need to think about whether an MCU is the best approach at all…

 

You need to give more details of the application.

 

FileX which seems to require ThreadX

See:

 

 I’m not enthusiastic about have to use ThreadX

Why not?

What’s the blocker here?

It certainly sounds like you’re going to need some sort of OS/RTOS ...

[LCE]

“reuse of components”

is a good way to get things working.

So if you already used an H7 with SD card, why not keep that?

I think most (if not all?) H7s have ethernet.

I recommend the H723 .. H735 types, these have working OCTOSPI interfaces for external flash and RAM (both on H735-DK).

 

Ethernet: when I started using STM32 with ethernet (in 2021 or so) the HAL drivers were terrible (still are, IMHO), but CubeMx and the ST examples gave me something that basically worked with a few tweaks.
Because I needed some 100% reliable TCP streaming with a few special features, I re-wrote the driver completely. With the added benefit that I understand it completely. :D

[Andrew Neil]

So if you already used an H7 with SD card, why not keep that?

Indeed!

 

I think most (if not all?) H7s have ethernet.

The Product Selector says there’s 31 without, out of 133 total:

https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series/products.html

 

[geneM]

The H5F5 has 2X the Flash, a little more SRAM, 2 more UARTs. I’m working on the assumption that almost all of my H7 code will port over pretty easily except the FatFS stuff. I’m going to have to learn how to use Ethernet in both cases. If I can get a file system up and running without pulling too much hair out, the advantages listed above might be worth it.

If I’m being too optimistic about how easy it might be to jump from the H7 to the H5, please let me know.

Thanks