On Friday 12 May 2023 at 20:43:12, o1bigtenor via Dng wrote:

> I am in the beginning throes of an embedded system (SoC, and/or
> microcontroller) design.

I think that has become a vague definition over the years.

Raspberry Pis were (and still are) a brilliant idea, but they got people to
thinking you can run a full O/S on almost anything. Start working with an
ESP32 and you'll notice the difference.

> Have been reading somewhat on the use of RTOS vs and OS (thinking
> perhaps FreeRTOS and Devuan).

My first question in a situation like this would always be "what exactly does
this software need to run on?"

If the hardware is a Linux-supported CPU with a sensible amount of RAM and
access to a reasonable-sized storage device, then it's worth considering a
full-blown O/S (and yes, for me that would always be Linux).

If the hardware is more of a microcontroller (by which I mean a CPU which is
not directly supported by standard Linux kernel builds, surprisingly little
RAM (less than 1Gbyte), limited standard interfaces (SATA, USB, ethernet,
etc.) or similar surprises) then an RTOS is probably the better way to go.

If the hardware supports a "real" operating system, then installing and
managing software is pretty simple.

If the hardware is more basic than that, then you're just wasting limited
resources by trying to run a full O/S on it, and you're better off starting
from an RTOS or even just dedicated compiled code to do the job you need.

Sometimes the choice starts from the hardware side "what can we get to run on
this thing?" and sometimes it starts from the software side "we need to run
this, what do we need to run it on?".

It's not clear to me from your question whether you're being asked to find
hardware which will run the necessary software, or being asked to work out
what software can run on the given hardware.

If neither is pre-determined, and you have a free rein to choose both, just go
with what you know best, and then the project can be the most productive
possible.

In either case, please don't overlook the maintenance aspect - how do you deal
with security patches, bug fixes, future changes in protocols (just look at how
fast HTML changes, for example, and how badly out-of-date browsers deal with
modern websites) in order to keep this thing functional for as long as
possible.

PS: I've always had a hard time working out what is actually OT for this list,
and I like that.


Antony.

--
RTFM may be the appropriate reply, but please specify exactly which FM to R.

                                                   Please reply to the list;
                                                         please *don't* CC me.