1
\$\begingroup\$

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?

\$\endgroup\$

4 Answers 4

7
\$\begingroup\$

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.
\$\endgroup\$
2
  • \$\begingroup\$ I certainly concur with your second point. As for the first one, it seems once again that my question about drivers for an NXP SoC fall right in the middle of the divide, as does Linux. But you do rise a valid point that "embedded" is itself a nebulous concept. Is my small ARM Linux computer which will be a part of a bigger solution embedded? What if I replaced it with x86? Does it matter if it was made by our company or bought from elsewhere? What about buying a SoM and designing the baseboard? \$\endgroup\$
    – jaskij
    Commented Apr 7, 2023 at 13:50
  • \$\begingroup\$ @jaskij Developing a driver on your small ARM Linux computer may or may not be in the scope depending on the details: e.g. developing a driver for some USB ethernet adapter is excluded, IMO, because developing a USB driver would be similar on a PC running linux. However, developing a driver for a builtin ethernet adapter on your ARM board, for which you have the schematics and all required datasheets, could be in scope, but only for questions like "how do I initialize my ethernet MAC chip", not for "how do I register my network driver in the kernel". But x86/ARM or bought/made isn't relevant. \$\endgroup\$
    – dim
    Commented Apr 12, 2023 at 14:21
3
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
-2
\$\begingroup\$

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
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .