On 01/13/2017 08:06 AM, james wrote: > 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 > Whoa, quite a post there! It was a good read. Is this coworker looking for any volunteer distro work by any chance? *wink wink* :P
-- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
