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...


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.......


Reply via email to