Scope of Embedded Programming

Question

Proposal: Embedded Programming and Design

Let's discuss how far "up" or "down" this site should go. Which belong here, which are better left to SO, EE or elsewhere.

1. IDE, tools, configuring the "desktop" for programming given platforms
2. building (compiling) the crosscompilers for your platform (that's -mtune=arm920t and not -mtune=armel!)
3. using debug tools with platforms too small to run them (gdb over sockets?)
4. "Please suggest a platform that has" (CAN, Ethernet, >64MB RAM, SPI, RS485, 32 GPIO, runs on 3.3V, MicroSD and is rated for up to -40°C) - these are a "list" questions but the list of answers will more frequently be "none" than "too many".
5. Configuring and use of simulators/emulators.
6. Compiling Linux kernel for given platform (finding the right modules for specific hardware can be a pain in the neck.)
7. Linux questions unlikely to be of "common interest" on Linux sites ("I'm writing a kernel module that requires function called in 0.1ms intervals measured with at least 0.01ms precision. How do I go about that?" or "Can I get the kernel to ignore the Write Protect flag on the SD card?")
8. C for Small Embedded (interrupt functions, bit type variables, lack of "normal" IO)
9. Bypassing hardware bugs - "Errata sheet says feature X of chip Y is bugged. How badly? Can I emulate this somehow?"
10. Interfacing embedded devices and peripherals (Does M-7065D expose inputs on Modbus-RTU by "Read Coils 32-36" or by "Read Inputs 0-4"? How to read USB keyboard under Linux on TS-7200?)
11. Understanding and caveats of protocols common in Embedded (can I listen on 2 different addresses on CAN? How can I identify devices on RS-485?)
12. Ratings, safety and testing (The device will work below -40°C for which it is rated; how can I assure it will work correctly? How can I assure the device fails gracefully on short circuit?)
13. Understanding and using system registers (EP9302 CAN config is spread over 2 or 3 registers, none longer than a byte but each must be written with a 32-bit write command, 8-bit write will be ignored.)
14. Tiny communication protocols (get two ACE microcontrollers, 1K Flash, 64 bytes RAM, 6 pins, to talk over infrared - say, garage gate remote controller.)
15. Tearing through abstraction layers to get from userspace to raw iron. ("I have the locations in /dev/kmem mmap()'ed but readouts are late by a second or two vs reality" or "I want a function (in userspace) executed no longer than 1ms after power zero-crossing")
16. PLC and ladder languages, similar alternatives
17. SCADA, industrial control systems
18. Filesystems for embedded (YAFFS vs JFFS2 vs UBIFS - what are advantages and weaknesses of each? How do I prepare a blank JFFS2 partition? How to get it to SD over /dev/mtdblock?)
19. Writing/editing hardware drivers (edit given kernel module to adapt it to RTOS)
20. Kiosk software ("Embeddifying" normal OSes, making them maintenance-proof and sandboxing the UI, deferring all maintenance notifications from screen to remote)
21. Network infrastructure software (adapting OS for running on a router or such)
22. Redundancy operation (recognize own fault, defer operation to backup)
23. hacking firmware (CHDK, OpenWRT, car computers, programmable calculators)
24. Userspace software for smartphones
25. Hacking/writing/editing OS for smartphones
26. Hacking/writing/editing firmware for dumbphones
27. System architecture design (better to write that calculation/processing in assembly for the microcontroller, or better to have it sent over TCP/IP to the PC?)

28. Programmable Logic

    1. FPGAs (Xilinx Virtex and Spartan, Altera Arria and Cyclone, etc.)
    2. CPLDs (Xilinx Coolrunner, Altera MAX, Lattice MACH and iCE, Atmel ATF, etc.)
    3. PLAs
    4. ASICs
    5. PSoCs (Cypress PSoC, etc)
    6. Discrete Logic Devices (7400 series, 4000 series)

Which are a good fit here, and which would better belong to other sites?

Anything else I forgot?

Answer 1

I don't have any suggestions for additions off the top of my head, but there's a few I have to disagree with:

"Please suggest a platform that has" (CAN, Ethernet, >64MB RAM, SPI, RS485, 32 GPIO, runs on 3.3V, MicroSD and is rated for up to -40°C) - these are a "list" questions but the list of answers will more frequently be "none" than "too many".

This should probably be posted on EE... and then closed either as a shopping question or being too localized. This is more or less a Digikey parametric search, but written as a StackExchange question instead of just searching on Digikey.

Ratings, safety and testing (The device will work below -40°C for which it is rated; how can I assure it will work correctly? How can I assure the device fails gracefully on short circuit?)

There are probably safety/testing questions that would fit, but the examples you've given are better for EE.

Userspace software for smartphones

This sticks out like a sore thumb as belonging on SO. Imagine someone asking about Java/Android basics and how out of place that would be. There would be a few exceptions (for example, I recently got Android to use the audio jack output as a UART transmit with the help of some simple analog processing). How about something like "Userspace software for smartphones to interface with embedded systems"?

Answer 2

Concerning the worries about the Raspberry Pi site and requests for integration, I'm against it - see my analysis of their current profile.

tl;dr: RPi is currently a site primarily focused in using RPi as a general-purpose PC, troubleshooting and programming for its flavors of linux, working out its own quirks (say, the fancy-partitioned SD card), and using it with its dedicated hardware. The questions about embedded programming are few, far inbetween and with poor quality answers. It's a very useful site for RPi users - but not for embedded programmers.

My opinion on the subject is to accept Raspberry embedded programming questions with open arms, while sending all the rest back to the RPi site.

Answer 3

I think that discussion of relevant regulatory bodies and standards as they apply to embedded systems is an important topic as well. For example, writing code for medical devices cannot be done without adherence to FDA standards or some other standard such as IEC 62304.

There is often a lot of confusion on regulation, standards, and risk management in safety-critical systems and how it affects your development process. I think this would be the right forum for these discussions.

Answer 4

Personally, I believe the "upper layers" of SCADA shouldn't be here - writing the control app in InTouch for a factory floor, is not really "Embedded" - but a level quite comparable to "developing userspace apps for smartphones". Still, getting all the wiring, the sensors, the PLCs and so on - "the dirty side" - is very much "embedded design".

Answer 5

Would questions covering the following be considered on topic I wonder?

1. Coding for safety critical systems, (many embedded systems are safety critical and most safety critical are embedded).
2. Testing embedded systems, tools and design for test.
3. Validation tools for things like MISRA compliance.

Answer 6

I would be glad to see point 5. I'm a beginner in embedded environment and most of my experiments and learning based on Qemu. Google research show that there is a lot of interest in this matter. Take a look at Virtual Development Board and number of comments on Balau blog.

Answer 7

What about porting an OS (let's say Android for the sake of easy identification and current popularity) to an embedded device? If it goes that route, then questions about smartphones would come up, but smartphone user space apps would certainly still be off topic, in my opinion that's a pretty clear line. Smartphones are embedded devices afterall. I believed I proposed an example question about porting [embedded OS] to [embedded device], don't think it currently has votes yet though.

---

We also have to be clear where the hardware lines are drawn, and where the software lines are drawn for on-topic questions. For example,

How do I design a PCB so that there is as little crosstalk as possible

Would likely be a better fit on EE. I'm not well-versed in hardware yet so someone else could weigh in or where to draw the line there, but I'll say that software questions should be limited to the kernel/device driver layer, and an answer for this discussion already stated to not allow user space apps, and I suppose that's ultimately what I'm getting at.

Answer 8

Writing/editing hardware drivers (edit given kernel module to adapt it to RTOS) I think this should generally not limited to adapting to an RTOS. Writing device drivers is a big part of embedded programming, regardless if it's an controller without or with RTOS or an embedded linux.

Without proper device drivers no embedded device couldn't work.

Answer 9

Searched this page, & would suggest that some or most of the following keywords be added to the scope of Embedded Programming:

(kernel) exit
Board support package (BSP)
call back
context switch
cycle-wrap
data coherency
debugger
disable (interrupts)
enable (interrupts)
executive
flash file system
interprocess communication
jitter
latency
rate monotonic
rate-group
remote
s-records
safety critical
scheduler
scheduling algorithms
semaphores
target

The scope of Embedded Programming would cover these, IMHO.

Answer 10

• 4 - doesn't belong on SE
• 6 - unix.se
• 12 - electronics.se
• 15 - unix.se (maybe)
• 18 - unix.se
• 20 - somewhere else
• 21 - somewhere else
• 24 - android, iOS etc SEs
• 26 - modifying an existing one? somewhere else. Writing a new one? here.
• 27 - SO
• 28 - here or electronics.se

There others would be a good fit for here.