On 01/13/2017 02:45 AM, Sven Eden wrote:
Btw.: Even "embedded experts" wholeheartedly agree that they disagree what
"embedded" actually is. But I do think SoCs actually *do* qualify, at least to
some degree...
Huh?
Probably who you deem as an expert; they have not clearly defined
systems types and semantics of an embedded systems. An embedded system
is one that is 'closed' to pedestrian/consumer/user modifications,
excepting rooting and other non-normal bypass mechanisms. A modification
is not the same thing as a configuration. An embedded system is designed
with limited functionality or "canned product functionality" for
consumers of very specific task-sets. Early Micros where often more
accurately referred to as 'microcontrollers' as their function was
simply to replace mechanical control systems that were prone to wear and
failure. When programming occurs (again rooting and hacking do not
count), it is only allowed by the system designer(s). So a Rasp. Pi on
the internet, open to dozens or thousands of coders, is not an embedded
system. At some point it may become an embedded system, but it must be
locked down, limited in functionality and purged of all that software
used for development but not needed to run and function as the
designer(s) intend. Updates are usually in a binary form, again under
the strict control as designed by the product (embedded systems) developer.
Given that, the reason why so many folks are confused as to what an
embedded system actually is, is that there are lots of "open" platforms
where users are encouraged to be the designer, thus having architecture,
coding, and modification access that an ordinary user would not have;
again, security hacks that grant non-normal access
do not count. That is if you 'hack' into the product or the bios of a
computer, you have not converted the device's intended usage into a
embedded system, although you may have low level access to the hardware,
firmware and other subsystems that the designers did not intentionally
make available to you. When a computer is 'locked down and limited' like
a kiosk, it actually is an embedded system.
Traditionally, the easy way to set up product developers was through
vendors (OEM like Freescale, Samsung, Broadcom, etc) via a 'dev board'.
Example codes, minimal stack of an rtos or vendor supplied software
system, along with documentation and details of the in-situ hardware
that comprise the 'dev board'. Small systems did not have (nor do they
now) have an 'OS' instead they were simple state-machines or run a
polling algorithm. Most embedded systems still operate on these sorts of
codes, even today.
Fast forward, Rasp. Pi et. al are dev boards that can be turned into
open, multi user systems, say if you make it a typical minimized linux
system. Some even have inputs for keyboard, mouse and terminal; so that
sort of system, would not be an embedded system. Now take the same
board, lock it down so all it does is control the sprinklers in your
yard, with limited functional interfaces to the 'standard user' and it
is indeed an 'embedded system'. Most products with a small
microprocessor are 'embedded systems'. Most Rasp. Pi boards are user
systems because they are open and unlimited an any given time and are
not 'locked down'.
It takes a designer, or a team of designers to create an 'embedded
system', particularly if the embedded system is to be turned into a
commercial product. The net effect of boards like Rasp. Pi is open up
the opportunity for folks to learn 'product development'. Most have
chosen to create user systems with some functionality not found in
traditional desktop systems. Surely there are edge cases that blur
the lines of distinction; but most are not a finalized product (embedded
system) as they are in a constant state of flux related to the interned
software, thus they are not an 'embedded system'. A properly designed
embedded system can last in its minimized and limited form for decades
or more and operated as intended (think digital alarm clock). Others do
need an update to the firmware (locked down internal software), but that
is only performed by the product owners or vendors, in the normal case
of operation. Indeterminant hardware is just hardware; it has to be
robustly defined, tested and implemented to be a user system, an
embedded system, or whatever the designer has in mind.
So hopefully, I have articulated the fact that an 'embedded system' is
determined by the designer, not the underlying hardware from a vendor.
Robust embedded system design, regardless of VHDL or C or ? codes
are more of an art-form than a technical expose on software development.
I know embedded designers that have created thousands of products some
in a matter of weeks, and other teams that fail to produce a single
robust product, in their entire lifetime. The most prolific designer of
them all, is simple referred to as 'doctor bitch' by her subordinates
and friends. Some, more respectfully refer to her as the queen of
assembler, as she has fixed thousands of compiler bugs from a myriad of
compiler vendors, not for compensation, but because the bugs got in her
way.......
hth,
James
