24

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?

9
  • 2
    Why don't you number those items, so we can talk about item 3, 5, etc.
    – BenjiWiebe
    Jan 30, 2013 at 13:05
  • @BenjiWiebe: Good idea; done.
    – SF.
    Jan 30, 2013 at 13:37
  • Do we answer as in "post an answer", or do we comment here ? I have a suggestion and want to properly add it to the discussion.
    – User.1
    Mar 10, 2013 at 2:42
  • Bluetooth. Big stuff in embedded systems
    – User.1
    Mar 10, 2013 at 2:51
  • 2
    What about Arduino questions? Going this route we'll probably absorb the Raspberry Pi folks.
    – MDMoore313
    May 1, 2013 at 18:09
  • @MDMoore313: I agree both Raspberry Pi and Arduino should have been covered by one "embedded" site from day one, and I find it unfortunate they got separate narrow sites. Still, this one has to take off first...
    – SF.
    May 2, 2013 at 18:48
  • @SF. absolutely, however as their in beta, I see no reason why they can't be absorbed still. Arduino was closed after 16 days in beta, and raspberry pi is still going strong, however it lacks in questions per day: It has plenty of visits per day, so there is potential for epad/epd to absorb RPi and do even better. Like you said though, this one has to take off, I've been promoting it on Google+ in the Embedded hangouts, I'll do what I can but I'm only one person.
    – MDMoore313
    May 2, 2013 at 21:16
  • When it comes to Aurdino and derivatives, I'm not sure this is the level we want (or I want). Aurdino as language is a very high level and it may be a risk that we get a lot of questions about bugs related to lack of fundamental programming skills. I'm not saying everyone using Aurdion don't have the skills, but I have come a cross a lot of Aurdino folks that do lack the skills. Aurdino already have a lot of sites and documentation. I'm looking forward to more in depth questions of how to utilize the hardware to its maximum and embedded microsystem designs.
    – Max Kielland
    Feb 12, 2014 at 3:44
  • I believe, currently, if Arduino site starts, we should redirect most of Arduino questions there. If it's a part of a bigger embedded project we can allow it here - as a component, not as the core.
    – SF.
    Feb 12, 2014 at 10:30

10 Answers 10

Reset to default
9

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"?

5
  • 3
    I tried to be as -inclusive- with the list as possible - "If in doubt, include it". Better to have it voted out than not to have it mentioned and thus not voted in.
    – SF.
    Jan 30, 2013 at 13:40
  • 2
    Your first example - "Please suggest a ***" is generally a poor question in any SE site. They would probably be closed as "Not a real question".
    – W5VO
    Jan 30, 2013 at 17:09
  • 1
    @SF. Yeah that's fine, I think you covered the bases pretty well.
    – Joe Baker
    Jan 30, 2013 at 20:44
  • 1
    Total agreement about the smartphones thing. Let them have their own place or else this will never have a true embedded systems focus. Android group is not bad idea on its own merit at all. Great idea, in fact. Let's support that. If phone questions are proposed as a part of this group, there will be no room for the real embedded systems stuff.
    – User.1
    Mar 10, 2013 at 2:50
  • 2
    I'd like to ask not to ban "userspace for smartphones" with one blanket "off-topic". Tetris or Spreadsheet for Android should be definitely off-topic. Using an Android phone as the control device of a quadcopter (with a userspace app doing the actual task) should be welcome (the "tearing through abstraction layers to raw iron" allowing smartphone OS-es).
    – SF.
    Aug 28, 2013 at 14:11
7

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.

3
  • 1
    It seems to me that did the Rasberry Pi site not exist, many of the questions regarding RPi would fit under this site. The RPi community is large enough that having their own site makes sense, yet I see many questions which could fit under either RPi or this site.
    – ChuckCottrill
    Jan 17, 2014 at 16:28
  • RPi allow to use the same power of a PC of 10 years ago. That's very far from the constraints of system with 8-bit Soc and >64 byte of memory (typically found in remotes controls). Thus you don't have to do things like don't using parameters (using global variable instead).
    – user2284570
    Apr 11, 2014 at 6:27
  • @user2284570: Definition of "Embedded" is not in computational power, but in ease of access to "raw iron", use of the device. Many industrial controllers are just PCs with custom motherboards and modules for controlling machinery, running some RTOS. RPi can be used both as Embedded and as General Purpose PC, and it's only up to the user how they make it, and so some of the questions do belong here, while others do not.
    – SF.
    Apr 11, 2014 at 7:47
7

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.

6

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".

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.
1
  • 1
    I don't see why not. I just hope we get some experts to answer these. If anything, I'm beginning to fear the site will be so broad we'll have a hard time answering anything but bikeshed questions.
    – SF.
    Feb 19, 2014 at 8:01
4

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.

1
  • 2
    Don't forget to ask and vote example questions!
    – MDMoore313
    May 10, 2013 at 14:39
3

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.

3
  • 1
    I doubt these would get much of response here, being a world unto their own, but I wouldn't say these are off-topic at least until some mobile.SE site comes to life. Porting an OS should be very much on-topic but I'm afraid questions like "how to decode LTE signal from [GSM radio] into TCP/IP accessible to Android" may earn the asker a Tumbleweed badge.
    – SF.
    May 3, 2013 at 4:22
  • 1
    @SF. Tumbleweed likely, but we never know. If they have their own GSM radio on a custom board, there should be some documentation on it, and that's a start. All he would need is a kernel module so that the OS sees it as another eth0.
    – MDMoore313
    May 3, 2013 at 14:29
  • @SF. I've added to my answer also.
    – MDMoore313
    May 3, 2013 at 15:46
2

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.

1
  • +1, although to clarify the RTOS comment the OP made was just an example question that may popup on the site.
    – MDMoore313
    Dec 19, 2013 at 16:21
2

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.

2
  • Nice, I think we should only have a single interrupt tag though, as it really is a single thing.
    – MDMoore313
    Feb 7, 2014 at 12:38
  • 1
    Done. Irony. As I was writing this, the word semaphore came to mind. :-D
    – Billy McCloskey
    Feb 7, 2014 at 12:50
0
  • 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.

4
  • 15: I have very bad experience with unix.se regarding these. 27: SO has no clue what deserves moving to hardware.
    – SF.
    Apr 13, 2014 at 22:07
  • No clue? Where do you think the people who would answer questions here are now? They're on electronics.se and SO.
    – Isvara
    Apr 14, 2014 at 1:34
  • on 8051.com and the likes. Seriously, SO is not a good place to get embedded engineering question. Seriously, ask for the absolutely fastest method of reversing order of bits for '51 programmed in C. You're likely to get bit-shaking with ((x&aa)>1)|((x&55)<1) or a lookup-table. I'm fairly sure nobody will suggest wiring P1.0 - P2.7, P1.1 - P2.6, P1.3 - P2.5...
    – SF.
    Apr 14, 2014 at 7:16
  • 6 and 18 are on-topic on Unix & Linux but don't have a lot of experts (most questions on U&L are about desktop or server systems, so most of the audience are people who work with such systems). They're part of the natural overlap between U&L and EP. 15 is off-topic on U&L, it's too programmy; it's on-topic on SO but often too specialized to find the right audience.
    – Gilles 'SO- stop being evil'
    Apr 15, 2014 at 12:10

You must log in to answer this question.

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