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 

[Andrew Neil]

I don’t see why porting FatFS should be particularly hard?

It’s a very widely-used independent 3rd-party library - its hardware dependencies are confined to just one file

[Pavel A.]

​@geneM Long time no see!

As always, understanding requirements is the key. For the RTOS choice: The staple today is Zephyr. It has a learning ramp, but very popular and resources are available.

If you need more UARTs and not limited by power: consider external multi-port chips. (we’ve used MAX14830 4-port chip, not sure why the customer chose it).

 

[pavich]

Re Q1: 68K is plausible — most of that is the USBX host/MSC stack, not ThreadX itself (which is small). For a deployed instrument, I'd drop USB MSC and stick with the uSD card: SDMMC+FatFS has no RTOS dependency, you already know it, and it avoids USB host complexity (enumeration, drive-removal handling) that adds risk for unattended field use. Worth it mainly if you specifically need a tech to swap a USB drive on-site.

[geneM]

I’m glad I asked. All your responses are making me reconsider my approach. @Pavel had the most disruptive suggestion: use Zephyr. I’ve never used an OS for the few embedded systems I’ve developed but maybe now is the time. I’m going to take a look at it with the goal of answering few upfront questions like this.

Q1. Is the pain of learning Zephyr less than that of me trying to implement my own bare-metal Ethernet TCP/IP functionality?

Q2. Does Zephyr get in the way of my preferred single threaded, non-blocking state machine architecture?

Thanks for all the help

[Andrew Neil]

​@geneM - best to start a new thread with your new Zephyr questions …

 

(you can always link back to this thread for reference)

[magene]

I’m probably dragging this conversation out longer than necessary but ​@Pavel A. comments about requirements is important. I learned a long time ago to start by defining project requirements. Here are a few for this project.

Req1. Minimize the time and risk associated with learning new technologies

Req2. At least 11 UARTs including 1 LPUART. A few more would be good to support future expansion

Req3. Need to add Ethernet to support a new high bandwidth instruments

Req4. Performance similar to our current STM32H7A3

Req5. Learn from other peoples mistakes and successes

This whole thread has brought me to the conclusion that the only new technology I should really be investing in is Ethernet. And I may be able to side step a tonne of stress by buying a fully packaged Ethernet module with a SPI interface like one of the Wiznet modules.

[Andrew Neil]

Yes, good, clear, well-defined requirements are key.

These ones a still a bit woolly:

Req3. Need to add Ethernet to support a new high bandwidth instruments

What is “high” - 10Mbit/s ? 1 Gbit/s ?

 

Req4. Performance similar to our current STM32H7A3

Define “performance” ?

What is “similar” ?

 

PS:

and from the OP:

a few more serial ports

How many ?

 

lots of Flash and SRAM

How much is “lots” ?

 

Low power matters

What does that actually mean - how low is “low” ?