So, if I'm working on some project that involves software that's running close to bare metal, with no UI beyond a button and a blinking light, and either a task loop or an RTOS, I call it "deeply embedded".

My boss calls it "small processor" -- which I cannot, because my first processor was a COSMAC 1802, and anything with a 32-bit core isn't "small".

What do you call it if you've got a processor on a board that's taking the place of some logic or some analog circuitry more than it's running a video game or whatever?

Hi, Tim!

I've not the answer, but I have doubts to contribute :-)
Is your project 'deeply embedded' when ...

... You have to design the PCB?

... There is at most 2 people involved in the project?

... You have to write the low level drivers?

... You have to fully understand the peripherals of the microcontroller?

... Is it intended for a very specific application?

... Its memory footprint has less than 1 MB?

This digikey explanation seems to fit the bill for me.

@rtomkins:

I concur. Basically, stuff you don't think about being embedded. (For relative values of "you" :^)

I tried to give you a beer, but that function seems to gone dry....

Ok, this works well.  Because, first, I agree with it, and second, it's not my work so I can bask in the reflected authority.

I cut my teeth on an 1802 and SC/MP from Nat Semi. The 1802 dev unit had tape to tape assembly. Funny how cassette tapes are making a come back. From there I migrated to the Intersil 6100. Eventually I went the path of analog mixed signal.

Sorry, I cannot answer your question but thank you for the flashback.

My first processor was an 1802, in a COSMAC ELF-II, obtained when I was in eighth grade.  I come from a family that did not promote Christmas requests, and I basically requested that all the parents, aunts, uncles, etc., get together and get me that for Christmas.

There was much doubt about getting such a geeky gift, and stepping so far outside of convention, but it was lovely.

To me a deeply embedded system is a hard real time system, where the processor is directly connected to the hardware and the processor activity is critically involved in the function of the hardware and/or the system.

So an engine management controller would count, although it may use a big processor with an RTOS and communicate with other systems.

At the other extreme a processor in a sensor to implement an interface like CAN would be included.

An RPi controlling a brewing machine is embedded but not deeply embedded, since it isn't hard real time  and a most of the function of the processor is used for GUI etc.

But these definitions are always very fuzzy  - although I don't much like 'small processor'.

MK

For me, deeply embedded would be a small MCU, with firmware, that does a simple task and has no means of being field updatable, and doesn't even have a programming header on the board. It performs one fuction, does it fine and it's firmware will probably never change.

To me, "Deeply Embedded" is where a major part of the final devices operation relies upon programmable logic in a CPLD,FPGA, or other "Hard" device! I cut my teeth on Intel 4004 and 8008, before the 8080 and z80 existed!

This seems more of a marketing than technical distinction, based mainly on complexity. Any attempt to define "deeply" based on clear objective criteria (memory size, UI, power source, etc.) will invite counter-examples and endless discussion.

It's one of those distinctions where we all have a similar idea what it is but none of us will have precisely the same definition, kind of like asking when a value becomes a "core value." (A value stored in core memory isn't the kind of value I'm referring to here!)

"A value stored in core memory isn't the kind of value I'm referring to here!"

Unless maybe you're an AI device built using 1960's technology?

I'm OK with squishy definitions.

Mostly I'm interested in a definition that doesn't take processor capabilities into account, and that to some extent represents an expected skill set.

I don't consider a TRS-80 with 16k of ROM, 16k of RAM and a tape drive to be "deeply embedded", but I could easily consider a Cortex M3 part with 32k of flash and 128k of RAM "deeply embedded" if it's doing something like controlling a motor in response to serial commands.

Yes indeed! I think most would agree that firmware for a fixed-function sensor with some type of serial interface and no human UI qualifies as deeply embedded, while firmware for a device with a fully featured operating system, keyboard and display does not. In between lies a near continuous spectrum of solutions.

Consider a battery powered standalone sensor that captures data based on a simple set of schedule parameters, and runs embedded linux only during data offload to allow the data to be extracted over a high-speed wireless ethernet link. Is this just a glorified sensor, or is it a standalone linux system with network interface? If it is not deeply embedded because of the linux kernel and ethernet link, does that change if embedded linux is replaced with an RTOS + TCP/IP stack? What if the ethernet link is replaced with a hard-wired serial interface and we lose the RTOS? To the outside world the system functionality remains essentially the same.

Definitely a squishy definition, and no great surprise that the question arises from a discussion with management as opposed to with a fellow developer! It's an interesting question that makes for a good discussion.

I'm amazed that you mention a Cortex-M3 motor controller with a serial command interface, I've implemented a couple of these on SoC platforms with on-die FPGA.

Not that it matters here, but I cut my teeth writing assembly language for the Signetics 2650. I was working as an engineer at the time but had no degree of any kind, an issue that I quickly realized had to be fixed when I tried to change jobs. They say that experience is what you get right after you needed it, but in my case it was a diploma.