Are hosted OS drivers on-topic here?

Question

My other meta question seems to have yet again brought to the fore the question of what is and isn't embedded programming. In other words, where the cutoff is for a questions being off-topic here and better moved to SO.

I have reviewed several other discussions and this use case doesn't really come up.

The current help article says that "the writing of firmware for bare-metal or RTOS applications" is on-topic, while "Programming software for a PC" is not. Personally, I understand "Programming software for a PC" to mean userspace.

This leaves the question whether kernel-space programming, and drivers specifically, are on topic on this site. Where exactly is the line?

Answer 1

On my side, I understand "Programming software for a PC" as "Programming software for a PC", and whether it is user space or kernel space is irrelevant. I don't consider device driver development on PC (or similar generic, consumer platforms) to be embedded programming at all. So it should probably be off-topic. These questions, including kernel space development and driver development, are well-accepted on StackOverflow I believe, and there are a lot of knowledgeable persons there. It is a different skillset than programming on an embedded platform.

IMO, the accepted programming topics should comply with both these constraints:

1. the target platform should be an embedded platform. Now, how to define an embedded platform, I'm not really sure, but one thing is granted: regular PC and Mac workstations are not part of this group. Mobile platforms (Android/iOS) certainly aren't either. One good indicator would be: if you don't have the schematics at hand, chances are it's outside of the scope.
2. the topic should relate to programming the lower layers of the platform itself, not the general high-level application layer. For example, if you design a digital watch, the question shouldn't be about the appropriate algorithm to determine leap years. Indicator: if the answer is the same whatever the platform, it's certainly outside of the scope.

Answer 2

I have no firm opinion on appropriateness conceptually.

However, I'd expect it more likely that a better expert base and general range of experience would be found on SO than here.

Answer 3

The term "embedded system" has always proven unhelpful when it comes to putting a label on something.

First of all there's the major difference between driver programming on a hosted system and driver programming on a bare-metal/RTOS system. These are very different tasks and have pretty much nothing in common:

• Coding a driver for a hosted system/OS requires that you follow the rules, APIs and ABIs laid out by the hosted system. There are restrictions of what you may and may not do. Modern mainstream hosted OS (*nix, Windows ect) come with a rule set for this, related to addressing modes and kernel vs user space. Access of physical addresses is restricted by these rules. Then you have the concepts of processes, heap allocation, threads, ASLR and so on, most of which very specific to the OS.

  These questions are perfectly on-topic on Stack Overflow and that's where you'll find the experts who may answer them.

• Coding a driver for an freestanding "bare metal"/RTOS system (very likely a microcontroller) is about as close to the metal as you come, hence the term. The hardware may either be an on-chip hardware peripheral or an external one. You often have no restrictions what-so-ever since your code is executing at the very bottom of all abstraction layers imaginable. Calling conventions and MMU setup where applicable are about the only concerns. You often access physical memory directly.

  Drivers like these are often very tightly coupled to real-time requirements. They also require a pretty solid understanding of electronics, unlike hosted system drivers. Often you may "outsource" part of the solution to a physical electronic circuit: for example filters and boolean logic may be carried out either in software or hardware.

  These questions are on-topic both on Electrical Engineering and Stack Overflow. However, questions in the borderland between firmware and hardware are more suitable for EE, since SO does not allow hardware questions.

---

As for where to draw the line, this is my suggestion (the terms hosted vs freestanding already exist in the C and C++ language specs):

• Programming of hosted systems is off-topic on EE. This includes *nix, Android, Windows, Mac etc - all personal computers and spawn-offs of such ("Embedded Linux", "Windows CE", smart phones, single-board PC). These are characterized by very high amounts of abstraction layers, all hardware interaction mostly hidden away, little to no real-time performance. Programs are pretty much always executed in non-volatile RAM and there is always file systems present.

• Programming of freestanding systems is on-topic on EE. This includes microcontroller/SoC programming with or without a RTOS. These are characterized by a very close connection to the hardware/electronics, little to no abstraction layers at all, often real-time critical. Programs and data are often stored in/executed from non-volatile memory such as flash.

  Freestanding systems also includes the small niche of bootloaders and similar bare metal applications running on a x86 or similar high end CPU.

• Programmable logic in the form of FPGA/ASIC/PLD using hardware description languages is on-topic on EE.

• PLC programming for industrial automation using specific languages for such is on-topic on EE.

Answer 4

My opinion on this, also from questions I have seen answered on the site in the past several years, is that anything interacting (at least somewhat) directly with hardware peripherals is on topic.

on-topic:

• kernel space drivers
• userspace code using facilities like i2cdev to interact with a peripheral

off-topic:

• general kernel hacking
• any other userspace code