Microcontroller requirements to implement an embedded web server using WebSocket, JS, and HTML5

[Ehab]

Hi,

I'm developing a new product, and one of the design requirements is to implement an embedded web server on the microcontroller. The web pages should be responsive and dynamic like single page application (SPA) web pages and there are 3 pages to be implemented with light images and graphics.

I plan to pick out a microcontroller from the STM32 range, and my questions are related to the hardware design part :

1. what are the minimum Microcontroller requirements to implement an embedded web server in terms of performance and memory?
2. what is the approximate size of the used memory for the lwIP stack, web server, and client-side code?
3. where to store the webpages? internal Flash, ROM, External Flash?
4. And finally, what is the complexity level of the implementation in comparison to the traditional HTTP request?

Thanks,

[TDK]

That sounds significantly above the capabilities of any STM32 MCU. I'm sure one of the STM32MP chips could do it, or a RPi.

[Tesla DeLorean]

Doing simple page serving is one thing, expecting all kinds of other packages to be available and readily integrated is another. Data and graphics provided it is not too large can fit in internal memory, ST has parts with 1MB and 2MB of FLASH readily available. External QSPI memories can easily add up to 256 MB, although the sweet spot for parts is probably 16 or 32 MB.

Look at what commercial stack vendors offer on MCU's and if that meets your time/budget requirements. Otherwise build a model in Embedded Linux and see just how involved that gets.

[Piranha]

I have a project, where I'm doing almost exactly the same thing - dynamically (with snprintf() style function) building HTML, serving static CSS and JS files (directly linked in with linker script), and using AJAX for bidirectional data exchange. The project currently takes 80 KB of ROM, about the same size of RAM and it's already pretty packed with features and besides network related parts has a few other non-trivial software modules.

The lwIP stack itself will take 40-60 KB ROM and similar but even wider range of RAM sizes, depending on configuration. Therefore the approximate minimum requirement for a MCU is 128 KB of ROM and 64 KB of RAM, which means that any STM32 with Ethernet can do it (even STM32F107RB). If up to 2 MB of ROM is enough for everything, go for internal FLASH, if not, add some external QSPI memory. For a basic network servicing the CPU speed doesn't matter much - it mostly depends on what processing and data traffic amounts the application requires.

Of course, for all that to be possible, the software has to be sanely designed. The lwIP stack itself is pretty robust. It's HTTPd web server is of average quality. Nonetheless I managed to get even POST requests for AJAX working with it. It's not trivial, but it's not an impossible magic either. But one thing is for sure - it's not possible to do this by clicking CubeMX.

P.S. Take a look on my demonstration firmware for the network part:

https://community.st.com/s/question/0D50X0000AhNBoWSQW/actually-working-stm32-ethernet-and-lwip-demonstration-firmware

[Piranha]

The reality is almost the exact opposite. 😉 Any STM32 with Ethernet can do at least the minimum of those requirements. Read more information in my other comment.

[waclawek.jan]

> responsive and dynamic

What's that?

> And finally, what is the complexity level of the implementation in comparison to the traditional HTTP request?

Imagine a PC without AMP or similar stack. All you have is TCP/IP stack, and you have to write the rest.

As Piranha said, there's a HTTP server in lwip, but it's quite rudimentary (if you compare it to Apache and kin), and to expand on it - or even use it as it is now - means to dig relatively deep into it. At the end of the day you'll feel like rewriting it from scratch.

But why don't you try? The basic LWIP demo will probably run on any Nucleo144 board which has Ethernet (never tried myself, but started with a 'F4 EVAL back then).

JW

[Jack Peacock_2]

Your requirements point towards using one of the )too numerous to count) Cortex A series application processors. These are built specifically to handle the kinds of tasks you describe, plus about 90% of the software (i.e. Linux) is already done and well tested. One big advantage to going with an A series is that if a single core proves too slow you can drop in a two or four core replacement without a PCB redesign.

Worst case you might look at the dual core A7/M4 variants in the STM32 line. There are other vendors who specialize in A series with much broader lines than ST. If your technical resources are limited to M series controllers, and you don't want to buy (very cheap) A series boards this is likely the best place to start.

Think of it this way: theoretically you can cross the ocean in a rowboat, but it's a lot faster, cheaper and less complicated in a plane. Part of the design process is selecting the right tool for the job.

Jack Peacock

[clock.1166]

Hi Ehab,

I'm going up the learning curve for a very similar project.

I've chosen STM32H743ZI2 and LWIP/RTOS.

I'm wondering whether this is the right solution?

Could you tell me what hardware you finally decided upon?

Thanks,

Chris

[clock.1166]

Or could anyone else give an opinion?

Thanks,

Chris

[waclawek.jan]

As I've said, get the Ethernet enabled Nucleo144 and try yourself.

JW