Web UI control -> Embedded systems - How it all comes together

[embeddedguy85]

I'm a beginner to embedded systems and I'm trying to get an overview of how web UIs work to control embedded devices.
I want to use HTML5/JS/Golang for the web part.

In terms of the stack I see:

Web server (lightttpd?)

|

Golang code

|

C code

|

RTOS

|

Hardware


Can anyone give me an overview of how this all comes together? Is the above correct?

Also, what are the hardware requirements for this kind of stack?

[dmills]

That would be a fairly heavyweight system, last one of these I did was HTTP server (Written in C and run as part of the TCP stack) -> rest of the system code -> Hardware, that was a PIC32 doing a lot of other more important things in 512K of flash with 128K of ram.

Often the elephant in the room is that web devs (Unless you hit them repeatedly with sticks) do so love their javascript libraries and seem to think nothing of pulling in 500kB of code to do something fairly trivial but pretty.
Provisioning a honking great off chip flash over SPI or such is helpful when this happens as you can cook up a toy file system and put all the web doings in the off board flash.

I would think you are looking more at the kind of arm with rtos scale system  with a few tens of MB of ram if you want golang hiding in there.

Be careful about memory fragmentation it can be hard to have these larger systems reliably statically allocate everything, and they are often tight enough on ram that it starts to show up after a week or two of runtime.

Regards, Dan.

[nctnico]

IMHO a web framework like JQuery (which IIRC can be compressed) and some additional javascript can do a lot to simplify the interaction with the hardware. The hardware doesn't have to generate webpages like PHP does but the client just requests data which can be pushed out in some kind of text format.

Having written that I'd make a clear distinction between stuff that needs to be accessible by a local network only or from the internet. In the first case an embedded device will do as long as you don't need SSL. Currently microcontrollers are not powerfull enough to run an SSL stack which provides good security.
If you need access from the internet I'd use a server and make the device contact the server through a proprietary encrypted protocol and exchange data with the server. At the other end the client interacts with the server. This keeps it easy to update security towards the client and still keep the hardware side low costs.

[dmills]

Most browsers will take gzipped data if you include the correct headers, but even so you can land up with a lot of bytes, JQuery, Angular, Some sort of 'responsive design' thing (By which they don't mean fast response they mean reorganises itself badly for mobile phone and tablet screens), add some javascript fiddles because the web does not really do standards.... Meh!

I was annoyed to discover that javascript does not have the means to talk UDP let alone multicast traffic, the nearest thing you can get is "web sockets" which is over a TCP link and thus needs state on the server side, very annoying when a bit short on ram. 

AJAX, while inefficient does not need you to keep the socket open so one or two socket buffers can serve more then one or two clients.

Regards, Dan.

[technix]

For me I almost never put Web code onto the small processors. These uses UDP-based binary protocols for the most case. There is always a gateway device, be it my some server, a Raspberry Pi or a custom board that runs Linux. Or I would just build a native app that talks that UDP protocol directly.