What is Embedded?
pedward
Posts: 1,642
I was pondering today, what exactly is embedded development today?
When I started really using computers, I had a MAD-1, 80186 6Mhz with 512K of RAM. At the time embedded usually meant 8051 with a few K of RAM.
When I started programming qBASIC, I had a 80386SX 16Mhz with 512K of RAM, an EGA card, and CGA monitor. This was a cobbled together system I built to sell and ended up keeping for myself.
Then I got into Linux, running on a variety of platforms, from a 386-25 on up. By this time I was grokking C and started writing "Unix" software, which was a lot like being thrown back to DOS because there wasn't any graphics, but I was past the trivial graphics toys I wrote in DOS.
Today embedded development is considered writing software on Linux running on an ARM processor that is 500Mhz+ with 32MB+ of RAM.
That ARM processor is more powerful than any computer I had growing up, or for that matter until a dozen years ago.
How far we have come that embedded development has lost it's scope, I (we) were doing embedded development all along!
I learned C on a 486-33 with 8MB of RAM at Borland. My early professional Unix development was on Sparc processors with less than 1GB of RAM. My phone has more ummph than our early servers.
Today I relish doing "embedded" development on a 32 bit microcontroller with 8 cores that run at 80Mhz, with a paltry 32KB of RAM.
My instincts tell me that it's faster than many of the computers I used until my late teens.
This thought was prompted by the "Embedded XXXXX developer wanted" posts I see on Craigslist. I've been an Embedded developer my whole professional life, I just didn't see it as "embedded" then!
It's the limitations I (we) grew up with that make us better programmers today; my distaste for Java is a direct result of it's inefficiency and frequent abuse.
When I started really using computers, I had a MAD-1, 80186 6Mhz with 512K of RAM. At the time embedded usually meant 8051 with a few K of RAM.
When I started programming qBASIC, I had a 80386SX 16Mhz with 512K of RAM, an EGA card, and CGA monitor. This was a cobbled together system I built to sell and ended up keeping for myself.
Then I got into Linux, running on a variety of platforms, from a 386-25 on up. By this time I was grokking C and started writing "Unix" software, which was a lot like being thrown back to DOS because there wasn't any graphics, but I was past the trivial graphics toys I wrote in DOS.
Today embedded development is considered writing software on Linux running on an ARM processor that is 500Mhz+ with 32MB+ of RAM.
That ARM processor is more powerful than any computer I had growing up, or for that matter until a dozen years ago.
How far we have come that embedded development has lost it's scope, I (we) were doing embedded development all along!
I learned C on a 486-33 with 8MB of RAM at Borland. My early professional Unix development was on Sparc processors with less than 1GB of RAM. My phone has more ummph than our early servers.
Today I relish doing "embedded" development on a 32 bit microcontroller with 8 cores that run at 80Mhz, with a paltry 32KB of RAM.
My instincts tell me that it's faster than many of the computers I used until my late teens.
This thought was prompted by the "Embedded XXXXX developer wanted" posts I see on Craigslist. I've been an Embedded developer my whole professional life, I just didn't see it as "embedded" then!
It's the limitations I (we) grew up with that make us better programmers today; my distaste for Java is a direct result of it's inefficiency and frequent abuse.
Comments
It's only the idea that the computer is part of another machine or system, doing it's job without anyone needing to know that it is there.
Of course now a days all but the lowliest computers have a network connection and a web page configuration tool so what is embedded?
Well, consider that processor that is controlling your SD card or USB dongle or the processor in your credit card or a million other tiny things.
In the propeller world we have Spin. All the arguments I have against Java also apply to Spin. Except Spin does provide a solution to the problem of getting the most functionality into the small space of the Props memory.
Usually, a processor on a wrist watch or in toaster can be "embedded", and a processor on a PC is not. But when your cell phone is more powerful than you PC and you can start developing code right on the unit, or you a laptop in your robot as the brain, the distinction gets blurred.
Embedded is about the issues of using the processor out of its bed; ie "Thanks to telecommuting, I am working from bed this morning, I am an embedded programmer".
Embedded machines generally have different characteristics from what we consider "computers" in the standalone sense. They usually have no, limited, or optional user interfaces. Both for reasons of economy and durability they tend to be very limited, often lacking mass storage devices (or using no moving parts ones like SD cards) and not having operating systems, not having software that can be updated without physical access if at all, and emphasizing physical process I/O over HID display and data entry (and especially, once a big deal, batch mode) interfaces.
It seems laughable today but another watchword used to be "real time programming," that is software meant to interact with a physical system in real time instaed of being run in a batch queue from Hollerith cards with your output printed out and slid into your physical mailbox. The earliest embedded computers were minicomputers like the PDP-8 and HP2100A -- the latter boasting 4K of 16-bit magnetic core RAM, running at a smoking 175 KHz, size of a dorm refrigerator and eating 15 amps at 220 VAC, and a relative bargain at only $40,000 in 1974. That $40K did not include the Model 33 teletype you'd need if you wanted to program it natively.
PLC's are a major market in industry and they are all embedded controllers by the strictest definition.
The leakage point nowadays is the appearance of operating systems, including Windows CE but much more often Linux or QNX, on circuit cards deep within the bowels of non-computery machines. These devices present as embedded but harbor complexities and hazards we usually associate more with HID-level systems, and that's a trend that will get more common as those HID-level systems become smaller and more, well, embeddable. Why write a TCP stack if the Linux team has done it for you? But then, especially if you expose your TCP stack to the internet, you're also exposing all those vulnerabilities that lie hidden in the great versatility of the OS to the risks of malicious probing. Most embedded systems don't really need to be running programs from files that can be updated externally. Is that capability a feature or a bug? If your embedded device has an OS the answer doesn't matter; it has the capability whether you want it or not, unless you take pains to lock down all such features you don't want active. In many cases doing that to a Windows or Linux installation can be as daunting a job as writing the application from the ground up on a system with no OS, or a "RTOS" where modules are compiled in to create a single firmware image that can't be changed remotely.
like a computer in something else serving a function enhancing the device but in a way that is going " hey I'm a friendly device not a computer."
When something is 'embedded' it's usually dedicated to a single task, or possibly a small number of related tasks.
(The stereo/nav computer/dash info system in a car is an embedded system. The same with a 'MicroATX PC used as a multimedia system in a custom sound system)
A modern SmartPhone can't really be said to be an embedded system. There's too much 'direct use' of the resources.
But now we have "Smart TV's" all internet connected and ready to be hacked ihttp://www.infoworld.com/d/security/spoiler-alert-your-tv-will-be-hacked-191013
No longer can they be considered "embedded systems".
Now, if I could just get root on my telly and install Debian...
This is a good way of putting it.
This thread is chatter, but I bet a lot of kids will have this question at some point, and the opinions give context to the idea.