Ethernet Protocols

[vbk22398]

Hi everyone,
 My requirement is as follows. I must be able to implement Basic DHCP, HTTP, HTTPS, MQTT, FTP, UDP, TCP etc., So I thought of choosing an MCU which has standard working examples and thereby it'll save more time than to adapt a code to a particular MCU. Please suggest me a good MCU or a MCU series in STM32 for ethernet and certain suggestions related to the same.

Thanking You!

[Ozone]

I would use a Linux SBC for that.
You can get e.g. a Raspberry Pi Zero for a similiar price like a STM32 discovery board.

Cortex M devices quickly run into performance issues with realistic network traffic.

[mbarg.1]

STM32H7 is suitable for what you are looking for - we do use as such with all but MQTT -

BUT 

Memory (RAM and ROM) will limit number of open sessions !!

AZRTOS (aka ThreadX) is stable but NetXDuo not (as it delivered will crash in many test) and there is lack of ongoing develpment on that.

We had to rework several part to correct and complete implementation to a reasonable level.

How much do you want to invest in your project ? Are your requirements more next to IOT or to PC based ?

Obviously, there are no working examples from STM ...

[vbk22398]

@mbarg.1 

We can trade MQTT or any such protocols but I need TCP, UDP, DHCP to work. It is not concerning IoT but it is for a local project where the data transfer is of 30metres to 70metres range. That is the requirement.

[mbarg.1]

STM32H7 is by sure a great choice - just have a look at errata and double check.

Eventually, also H5 can be a solution if 10MB Ethernet is ok, I would not use @100MB full duplex speed due to limited processor speed.

[Andrew Neil]

This is mostly down to the networking stack that you choose - not the MCU itself.

ST has examples for LwIP and NetXDuo:

https://community.st.com/t5/forums/searchpage/tab/message?advanced=false&allow_punctuation=false&filter=includeTkbs&include_tkbs=true&q=ethernet

Other stacks are available.

Why an MCU? As @Ozone said, something like a Raspberry Pi may be better suited ...

[Ozone]

> This is mostly down to the networking stack that you choose - not the MCU itself.

Which is in my experience not entirely correct.

But basically all of the ethernet peripherals of Cortex A and other application processor devices contain internal buffers to keep at least on jumbo frame, usually several once.
Cortex M devices usually not, which often makes them very vulnerable to overrun issues, even under relatively moderate network traffic loads.

Although I must admit, I switched to Linux SBCs for such applications about 3 years ago, and didn't try Cortex M networking since then.