I waved PICs goodbye a long time ago, and switched mainly to ARM/Cortex and C++ for micro-controller programming. A side-effects of this is that I'll be doing the closing keynote on the Meeting C++ conference in Berlin, november this year, on the subject of (C++ and) embedded. My picture is up on the website, so I can't deny it any more..

Which leads me to my problem: the term "embedded" is often used for the time/space/energy/cost/xxx-sensitive work done on micro-controllers. (Roughly what was thye focus of this group in its big days.) But this "embbeed" term was a problem from the beginning (embedded systems can and do contain large computer systems, with a very different way of programming), and is getting even more so these days (ESP8266 are programmed in Lua and Python, and how long will it be before a single-chip system will run a common Linux distro?).

Hence the term "embedded" is no longer sufficient to describe a programming (and system design) style that is (very) sensitive to (code and data) space and timing. So do you have a better (preferrably one-word) term to describe this domain? The best I have so far is probably "severly resource constrained", but that is not 100% accurate and too long by two words . "small micro-controller" is another candidate, but it is still one word too long, and feels negative.

To me, embedded has always meant a computer system built for a specific
purpose where the user is very unlikely to run software of his own choosing
on it. It doesn't fundamentally have much to do with resource constraints.
Also the user interface of an embedded system is usually specialized for
its purpose - often having only a few buttons or a basic touchscreen with
no facility for a full keyboard.

> Hi everyone
>
> I waved PICs goodbye a long time ago, and switched mainly to ARM/Cortex
> and C++ for micro-controller programming. A side-effects of this is that
> I'll be doing the closing keynote on the Meeting C++ conference in
> Berlin, november this year, on the subject of (C++ and) embedded. My
> picture is up on the website, so I can't deny it any more..
>
> Which leads me to my problem: the term "embedded" is often used for the
> time/space/energy/cost/xxx-sensitive work done on micro-controllers.
> (Roughly what was thye focus of this group in its big days.) But this
> "embbeed" term was a problem from the beginning (embedded systems can
> and do contain large computer systems, with a very different way of
> programming), and is getting even more so these days (ESP8266 are
> programmed in Lua and Python, and how long will it be before a
> single-chip system will run a common Linux distro?).
>
> Hence the term "embedded" is no longer sufficient to describe a
> programming (and system design) style that is (very) sensitive to (code
> and data) space and timing. So do you have a better (preferrably
> one-word) term to describe this domain? The best I have so far is
> probably "severly resource constrained", but that is not 100% accurate
> and too long by two words . "small micro-controller" is another
> candidate, but it is still one word too long, and feels negative.
>
> A better term, anyone?
>
> --
> Wouter "Objects? No Thanks!" van Ooijen
>
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

To me 'embedded' is where the user has access to a system without (necessarily) realising there is a computer of some sort doing the hard graft behind the scenes - they are not programming it directly (by loading applications or programs, or generating programs) or using it to store or compute data (databases, accounting etc), but may be interacting with it through minimised (specialised) keyboard and display, such as coffee maker, microwave, toaster or flight simulator. Into this category could also go PVR, (modern) television sets, and so on where the use of a computer is not obvious to the user.

But to boil that down to a single word, the best I can think of is 'hidden', 'not obvious', 'behind the scenes'.

Interesting topic - I still describe myself my specialism as embedded
systems on my CV (despite having not been paid to do that for a long time!)
though I've largely moved on from PICs and AVRs via more complex embedded
processors running RTOS (when I was still being paid to do it) to Raspberry
Pi and similar. I'd still think of most of my applications for a RPi being
embedded as they're controlling something else and the computing is hidden
from the end user.

I'm tempted to think that the correct term for what you want is
"microcontroller". I'm not sure you even need the "small" caveat - to me a
microcontroller is a good definition of the sort of thing you're thinking
of, when it gets bigger than that and you're running an OS I'd start
describing it as a microprocessor instead. At least that is how I tended to
describe the higher powered processors running RTOS I was developing for -
even though they shared a lot of characteristics with microcontrollers and
were effectively a single chip system on a custom board.

> Interesting topic - I still describe myself my specialism as embedded
> systems on my CV (despite having not been paid to do that for a long time!)
> though I've largely moved on from PICs and AVRs via more complex embedded
> processors running RTOS (when I was still being paid to do it) to Raspberry
> Pi and similar. I'd still think of most of my applications for a RPi being
> embedded as they're controlling something else and the computing is hidden
> from the end user.
>
> I'm tempted to think that the correct term for what you want is
> "microcontroller". I'm not sure you even need the "small" caveat - to me a
> microcontroller is a good definition of the sort of thing you're thinking
> of, when it gets bigger than that and you're running an OS I'd start
> describing it as a microprocessor instead. At least that is how I tended to
> describe the higher powered processors running RTOS I was developing for -
> even though they shared a lot of characteristics with microcontrollers and
> were effectively a single chip system on a custom board.
>
> Chris
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

-- Clint.

*No trees were harmed in the sending of this mail. However, a large number
of electrons were greatly inconvenienced.*
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

My two cents...
"Embedded" is part of something greater. A consumer never goes to the store
and buys an "embedded computer". They buy a *product* that happens to have
an embedded computer in it.
It might be the smallest 10F/ATtiny as an LED flasher in a toothbrush
handle or it might be as complex as a car. Consumers don't go to the car
dealer and ask to see the newest models because they heard the engine
control module is built with an octo-core super processor now with 17 TB of
RAM.

Cell phones are an interesting example here. A decade or so ago (perhaps
two, time flies), people bought devices that could make a phone call. The
internal architecture was largely irrelevant and mostly ignored. Now
they're buying something that is a more general purpose computing platform
with the intent of running far more diverse programs. As such the internal
architecture is more involved in the discussion.

I think the idea of working in a "resource constrained" system is a natural
outgrowth of the business of volume production of products. Unless it's a
high-volume product, saving a penny per unit at the expense of another
month of engineering time is never going to be profitable. "Resource
constrained" is a math problem: [DevCost + (UnitCost * Quantity)] With the
drop in cost of more capable silicon and the improvement in development
tools, that math changes all the time.

So, I think "embedded" is the right term, but the definition may have been
a bit mangled through the years.

> Microcontroller was usually defined as a chip that could have its own RAM
> and ROM and could, given relevant voltages and a clock, operate
> independently of external peripherals wasn't it?
>
> I would consider an embedded system to be any system where an application
> only is exposed to a user, doesn't matter what resources it has but it
> would usually be self contained (usually, not always)
>
>
>
> On 27 September 2017 at 13:48, Chris McSweeny <.....cpmcsweenyKILLspam.....gmail.com>
> wrote:
>
> > Interesting topic - I still describe myself my specialism as embedded
> > systems on my CV (despite having not been paid to do that for a long
> time!)
> > though I've largely moved on from PICs and AVRs via more complex embedded
> > processors running RTOS (when I was still being paid to do it) to
> Raspberry
> > Pi and similar. I'd still think of most of my applications for a RPi
> being
> > embedded as they're controlling something else and the computing is
> hidden
> > from the end user.
> >
> > I'm tempted to think that the correct term for what you want is
> > "microcontroller". I'm not sure you even need the "small" caveat - to me
> a
> > microcontroller is a good definition of the sort of thing you're thinking
> > of, when it gets bigger than that and you're running an OS I'd start
> > describing it as a microprocessor instead. At least that is how I tended
> to
> > describe the higher powered processors running RTOS I was developing for
> -
> > even though they shared a lot of characteristics with microcontrollers
> and
> > were effectively a single chip system on a custom board.
> >
> > Chris
> > --
> > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > View/change your membership options at
> > mailman.mit.edu/mailman/listinfo/piclist
> >
>
>
>
> --
> Clint.
>
> *No trees were harmed in the sending of this mail. However, a large number
> of electrons were greatly inconvenienced.*
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

It's not so much mangled as that computing has got so much cheaper and
smaller and single board computers have become available, so that now it's
perfectly feasible to put a RPi Zero in a lot of things, and it's still
perfectly reasonable to call that an embedded system. The issue being that
an RPi is a proper computer capable of running a desktop OS, so is
completely different to what Wouter wants to refer to.

> â€‹... â€‹
> So do you have a better (preferrably
> one-word) term to describe this domain? The best I have so far is
> probably "severly resource constrained", but that is not 100% accurate
> and too long by two words . "small micro-controller" is another
> candidate, but it is still one word too long, and feels negative.
>
> A better term, anyone?
>
> â€‹Not ideal, but the classic "black-box" (blackbox?, black box?) â€‹concept
overlaps with much of what has been said so far.
Maybe "embedded or blackbox" system :-).
Maybe that the first time then use either term thereafter.

> To me, embedded has always meant a computer system built for a specific
> purpose where the user is very unlikely to run software of his own choosing
> on it. It doesn't fundamentally have much to do with resource constraints..
> Also the user interface of an embedded system is usually specialized for
> its purpose - often having only a few buttons or a basic touchscreen with
> no facility for a full keyboard.

Many years ago I had to write a program for a "till" (point of sale terminal). At its heart was a Z80, a mix of RAM / EPROM (upto 64k), a dot matrix (plasma) display, a keyboard (a large array of mechanical switches) a dot matrix printer (mechanical pin head), a magnetic stripe reader/writer (on cardboard), a current loop serial interface and the draw lock solonoid. Although this hardware was capable of running many different kinds of programs it had one dedicated function. I consider the program I wrote for this system to be truely embedded. There was a great deal of hardware control going on.

Many years later I was part of a team writing code for another point of sale terminal. Our software was highly abstracted and ran on OS/2. I consider this program to be an application running on hardware with a dedicated function.

Although both systems had cores capable of general purpose use the first had a program that was tightly coupled to the hardware. The second had a program sitting on top of an OS that provided services to it.

In my opinion, a product that has a computer inside it can be correctly described as having an embedded computer but programming it should only be described as embedded programming if the code does not rely on an underlying OS. I would view such code as being an application even if it does perform a little bit of hardware manipulation (e.g. flashing a LED, controlling a servo or reading a switch).

So in my view I would consider that programming an embedded computer is moving away from true embedded programming towards application programming. Perhaps the term being sought is "embedded application programming" - I know this isn't one word but these are the lemons I have :-)

>
> On Wed, Sep 27, 2017 at 3:30 AM, Wouter van Ooijen <@spam@wouterKILLspamvoti.nl> wrote:
>
>> Hi everyone
>>
>> I waved PICs goodbye a long time ago, and switched mainly to ARM/Cortex
>> and C++ for micro-controller programming. A side-effects of this is that
>> I'll be doing the closing keynote on the Meeting C++ conference in
>> Berlin, november this year, on the subject of (C++ and) embedded. My
>> picture is up on the website, so I can't deny it any more..
>>
>> Which leads me to my problem: the term "embedded" is often used for the
>> time/space/energy/cost/xxx-sensitive work done on micro-controllers.
>> (Roughly what was thye focus of this group in its big days.) But this
>> "embbeed" term was a problem from the beginning (embedded systems can
>> and do contain large computer systems, with a very different way of
>> programming), and is getting even more so these days (ESP8266 are
>> programmed in Lua and Python, and how long will it be before a
>> single-chip system will run a common Linux distro?).
>>
>> Hence the term "embedded" is no longer sufficient to describe a
>> programming (and system design) style that is (very) sensitive to (code
>> and data) space and timing. So do you have a better (preferrably
>> one-word) term to describe this domain? The best I have so far is
>> probably "severly resource constrained", but that is not 100% accurate
>> and too long by two words . "small micro-controller" is another
>> candidate, but it is still one word too long, and feels negative.
>>
>> A better term, anyone?
>>
>> --
>> Wouter "Objects? No Thanks!" van Ooijen
>>
>> --
>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>> View/change your membership options at
>> mailman.mit.edu/mailman/listinfo/piclist
>>
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

Which is entirely consistent with the fact that embedded systems,
especially in domestic appliances, are becoming less reliable

So in my view I would consider that programming an embedded computer is{Quote hidden}

> moving away from true embedded programming towards application
> programming. Perhaps the term being sought is "embedded application
> programming" - I know this isn't one word but these are the lemons I
> have :-)
>
> Regards
> Sergio Masci
>
> >
> > On Wed, Sep 27, 2017 at 3:30 AM, Wouter van Ooijen <KILLspamwouterKILLspamvoti.nl>
> wrote:
> >
> >> Hi everyone
> >>
> >> I waved PICs goodbye a long time ago, and switched mainly to ARM/Cortex
> >> and C++ for micro-controller programming. A side-effects of this is that
> >> I'll be doing the closing keynote on the Meeting C++ conference in
> >> Berlin, november this year, on the subject of (C++ and) embedded. My
> >> picture is up on the website, so I can't deny it any more..
> >>
> >> Which leads me to my problem: the term "embedded" is often used for the
> >> time/space/energy/cost/xxx-sensitive work done on micro-controllers.
> >> (Roughly what was thye focus of this group in its big days.) But this
> >> "embbeed" term was a problem from the beginning (embedded systems can
> >> and do contain large computer systems, with a very different way of
> >> programming), and is getting even more so these days (ESP8266 are
> >> programmed in Lua and Python, and how long will it be before a
> >> single-chip system will run a common Linux distro?).
> >>
> >> Hence the term "embedded" is no longer sufficient to describe a
> >> programming (and system design) style that is (very) sensitive to (code
> >> and data) space and timing. So do you have a better (preferrably
> >> one-word) term to describe this domain? The best I have so far is
> >> probably "severly resource constrained", but that is not 100% accurate
> >> and too long by two words . "small micro-controller" is another
> >> candidate, but it is still one word too long, and feels negative.
> >>
> >> A better term, anyone?
> >>
> >> --
> >> Wouter "Objects? No Thanks!" van Ooijen
> >>
> >> --
> >> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> >> View/change your membership options at
> >> mailman.mit.edu/mailman/listinfo/piclist
> >>
> > --
> > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > View/change your membership options at
> > mailman.mit.edu/mailman/listinfo/piclist
> >
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>