There are general purpose computers which currently run Debian and could run Emdebian but there are common features amongst general purpose computers:
Lots of different tasks must be supported - lots of different packages installed, each user could quite easily use a distinct set of packages from another user. A single user may need different packages at different times - some for work, some for home.
Multi-user support - even if any one machine is only used by one person, a general purpose computer must have support for adding another user - not just a system user, a real user with a login, shell, possibly bookmarks and browser history etc.
Connectivity - general purpose computers (and that includes mobile phones) must connect to a variety of other computers to be at all useful.
Multi-modal data input - there needs to be support for a mouse and a keyboard or touchscreen and just as likely, software support for accessibility interfaces like an on screen keyboard and switch inputs.
Storage for user data - the system admin can't know how much data users are going to add and if it is general purpose, it's probably going to support media players, image viewers, even office software. The data files managed and written by such software tend to be large and tend to accumulate into large collections. This means that a general purpose machine cannot anticipate the full storage requirements, so has to allow plenty of room for user data storage. If there's so much storage space available, why use an OS which is primarily designed to take up less space? Just use the full version, Debian.
Now compare with the common features of special purpose or single-purpose computers:
Single task only - a splash screen (without support for removal) covers all the boot information, the single task starts as a daemon and if the user quits the task, the task initiates a shutdown, not quit. Every effort is made to prevent the task from exposing the underlying OS, including auto-restarts if it does crash.
Single-user support - indeed, such a user is not the typical Debian user. The user in this case is a non-login user without a shell, created by the postinst of the task package purely to support running the task without root privileges (because if the task doesn't need privileges, it shouldn't retain privileges).
Single mode input - don't expect these machines to support 105 key keyboards. You'll be lucky to have 5 keys which are really just multi-function buttons. The button won't just enter 'J' into the machine, it will fire off a command to charge your bank or start a drill or shutdown a malfunctioning service.
Some devices will replace the mouse with a touchscreen but many are fitted in places where touchscreens simply won't survive, where keys have to be able to withstand being submerged in water (or oil) for hours. Many machines simply won't have mouse support at all. Many will not have any typical external connectors. Indeed, units which go into dirty or wet environments certainly won't have standard external connectors of any kind. Think boats and factories. Internal battery packs with custom hot-fit replacements, buttons encased in 4mm of clear plastic, screens viewable only through protective mesh and or filters.
Restricted connectivity - if the task doesn't need networking, no networking hardware is fitted. If the task doesn't need USB, no USB hardware is fitted. If the task doesn't need serial connections, there will probably be an internal serial connector but also a Warranty void if removed sticker. Don't expect an RS232 inside the case either, this will be a flat cable connector which you'll need to attach to a breakout board which correctly connects the cable wires to the RS232 port pins. That mapping is not standardised (why would it? only service engineers are approved to use it.)
Restricted lifespan - the special purpose device is constrained to a specific task and if that task changes substanitally, the entire device gets replaced, not updated. This also reflects the lack of connectivity as it may not be possible to connect to the device in such a way as to upgrade it and removing the device to open the case and connect to it is awkward or undesirable.
Constrained user data - the task is in complete control and determines what the user can view, store and access. Storage can be expensive and a power drain, so if the task doesn't need Gb of storage, don't fit the machine with Gb of storage. This saves money on the build costs, potentially reduces power consumption (which can be of overriding importance for battery powered devices) and reduces overall complexity.
So what are these mysterious single-use computers running Emdebian? It's hard to tell because the task has no particular reason to tell the user anything about the OS. Perhaps a different way to phrase the same question would be:
Why use a general purpose OS for a special purpose computer?.
Single task does not mean single process - doing one thing can involve doing a couple of different things behind the scenes, so a multi-tasking kernel and userspace is extremely useful in providing a responsive machine without wasting money on unnecessarily powerful hardware. Multithreading support is also valuable.
Software reuse makes good business sense - why write a single-usage operating system when the device needs a multi-tasking OS anyway and suitable ones already exist?
Minimal software - no point packaging Xorg or GNOME when the user interface is a tiny QVGA framebuffer and the device only has 128Mb of RAM. By all means get the core system (cairo, pango, Qt, gettext, dpkg) from Emdebian but the actual code which performs the task of the device will generally be bespoke and, yes, that generally means proprietary, closed source, utterly non-free. This is where GNU/Linux wins over iOS and Windows - the graphical software is trivially separated from the core software and tested as such. If your device has only monochrome text output (and plenty of those still exist), what possible reason is there to use a graphical toolkit? Use the multi-tasking support of the OS to handle inter-process communication and understand the licensing - job done. Again, these devices have deliberately limited storage capacity, the smaller the OS, the lower the cost of the device, within certain constraints.
Debugging compatibility - this is the big one. It's hard debugging the task software on device with the differences in architecture and connectivity. Why not use the same packages on the same OS on the development machines as on the devices? All the power and all the screen resources to properly investigate bugs, simple way to provide an emulator for translation support and other activities (like user interface training). There will always be bugs which have to be debugged on device - timing issues, hardware issues - but why not make at least a proportion of the likely bugs easier to fix by using binary compatible libraries on both the big desktop machines and the small devices?
This is why Emdebian Grip is popular for these machines - because Emdebian Grip is binary compatible with the equivalent Debian suite and when a bug appears in the high level user interface, it is much easier to debug that on the desktop than on device. Debian stable is a fantastic OS for commercial development - the stability of the OS makes detection of interface bugs much easier. It is rare that developers have to investigate whether bugs in their UI come down to a bug in the underlying OS. That saves time and development time is expensive.
The machines themselves? I'm sure others can come up with other examples but these are some which come to my mind (no particular order):
Control interfaces - solar power controllers, robot controllers - anywhere that a low power board can monitor responses from other machines and do something intelligent about reported errors. Temperature limit responses, pressure limit responses, encoding all of those in assembly or VHDL is hard, so use a system which provides for more creative result handling.
Electric car charging points - very simple user interface, single task which doesn't complicate things by expecting the user to tap on something to start the main application - just process the card details, charge the customer and provide power.
Similarly electronic point of sale devices - EPOS. The staff on the shop floor don't want to be waiting for an X server to start up and then using a menu. The device starts up and runs one task (checking barcodes, printing labels, counting stock), if the task is shutdown, the machine shuts down to save battery power.
Communication aids - a machine which presents a simple UI on non-standard framebuffer hardware, lots of audio output but little other connectivity. Resilience is very important, so solid state is vital but why provide more solid state storage than the device can actually use?
Anywhere where the device simply needs to DoTheRightThing in a variety of unpredictable circumstances, you are going to need a general purpose OS to gather the data and produce the right result. Anywhere where the device has only a single task, you're going to want to not provide access to the rest of the system. There's no point providing "general purpose access" when the device doesn't have "general purpose hardware". There's no point fitting general purpose hardware if the device does not use it. That is a waste of money, a waste of resources and causes unnecessary delays if one component or other becomes unobtainable or changes behaviour. Limit your exposure to hardware bugs and get the product out to the user more quickly and more reliably, everyone is happy. Fit non-standard hardware and you can fit custom hardware which better matches the profile of the device usage - why use standard speakers capable of CD quality across a vast frequency range when the device only makes very very loud alert noises which can be done at lower sample rates and with narrow range, high amplitude, speakers.
There are all sorts of estimates for the number of computers now in the average Western home. It's worth noting that the vast majority of those computers are not PCs or laptops or even game consoles and routers - all instances of general purpose machines with general purpose access or connectivity. A lot of the computers in your home are embedded in machines like white goods, media controllers (set top boxes and the like). Some of these will still use low level firmware written entirely in assembly or COBOL. More complex ones already have a general purpose OS inside yet constrain that OS with a simple, user-friendly interface which is tailored to the hardware actually fitted. It might be cool to connect to your set top box over Bluetooth but really, is that actually going to sell more units? Only if there are other high-end services written for the device which the average customer won't want to see pushing up the price of the base unit. Some machines (particularly in automotive uses) will need to be using Real Time operating systems and Safety Critical operating systems but even some of those are based on general purpose systems - just old versions which have been thoroughly tested.
Finally, consider that for a lot of these devices, the customer is not you. The customer is another business who then put the device into something else which is installed into a factory production line which produces something which goes into creating a consumer product you find in Tesco or on Amazon or bundled in with another service like your TV/broadband contract. There is absolutely no reason for these devices to provide general purpose computing to you, even if the device itself is part of something else which can provide such services.
There is no reason why such single-purpose computers should not run a general purpose operating system and there are good reasons for deploying a flavour of a free GNU/Linux operating system which can fill the gap between your custom hardware and your custom user interface.
The Emdebian Grip Guide contains a short review of how these factors affect the use and design of Emdebian Grip and it's deployment on single-purpose embedded devices.
Back to the Emdebian Project homepage.