It includes anything from thinks like (home) routers and TV set-top boxes to <8MHz 8bit processors.
Embedded devices which have a UI which is not just some simple segment display (e.g. touch screen) are today not seldomly comparable with low end smartphones and tend to
not be battery based.
I mean think about how cheap a 1+GHz ARM chip has become today.
I program complex color displays, wifi on devices with 1GHz clock. Still on batteries; still slow and speed/latency matter. A lot. Embedded is always the smallest device possible for the application. Else the designer made a mistake. So its always critical speed/space.
> And embedded is usually dog slow processor running at minimum clock, to save power.
It used to be like this for a long time, but nowadays the market is moving towards stronger embedded CPUs, either just because they are affordable (raspberry pi), or the power is actually wanted for something (e.g. nvidia jetson for video processing and AI)
Yes I mean I just did some quick price research and I (as a private person) can buy a Quad core Cortex-A53 for just 5.20$... And a Raspbery PI Zero (no WLAN) for 12€.
"Embedded" means different things to different people.
Back when I was a game developer at EA, Madden and many other sports console games all shipped using Flash (!) interpreters with full GC. These were games running on PS2, NGC, XBox, etc.
Sure it does. But if its possible to choose a cheaper hardware chipset and not do GC then that's likely the correct choice. Or the designer has made a mistake (BOM cost higher than it needs to be).
Is it always a mistake for the BOM cost to be higher than it hypothetically could be? Can't a designer reasonably trade off some BOM cost for other things such as development cost?
Lua is not uncommon on embedded devices, even the slow industrial kind, as opposed to "embedded" devices with desktop- and server-class processors.
Independent of fancy algorithms, GC complexity, cost, and latency are straight-forward functions of the number of managed objects. It's not uncommon to use a "glue" language like Lua in a manner where the runtime only juggles a small number of objects, which in turn encapsulate and manage most of the application data independent of the garbage collector. Even in applications with complex, cyclic object graphs (i.e. the ones were GC makes sense), you can usually push the problematic edges into a small number of GC'd objects. Language GC (mark & sweep, reference counting, etc) can at least in principal provide a zero marginal cost benefit.
Java, JavaScript, and Python reflect poorly on the usability of GC because they're extremely object heavy and weren't designed with embedding in mind. Scalars and aggregates didn't figure prominently into their design, including C FFI (to the extent C FFI was even a consideration of their original language semantics). And they're too liberal with heap allocation in both their semantics and implementation, inducing unnecessary object churn.
I've never seen an embedded app with GC.
And embedded is usually dog slow processor running at minimum clock, to save power. So pauses are 10X or more the issue re: desktop.