1. Limited time only! Sign up for a free 30min personal tutor trial with Chegg Tutors
    Dismiss Notice
Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

How much embedded programming in control/signal processing?

  1. Oct 25, 2011 #1
    Hey there,

    (I apologize if this is in the wrong section - please move it if it is)

    I'm an EE undergrad, and I'm wondering how much embedded software/programming is involved in fields like control and signal processing. To be a bit more specific, by "embedded software," I'm referring to things such as programming microcontrollers/FPGAs, dealing with embedded/real-time OS, and writing device drivers.

    I realize that embedded systems are so prevalent that it may be impossible to go into any area of EE without encountering them in some fashion, but I'd like to avoid dealing with them too frequently if at all possible. I can't really decide which among control, signal processing and analog electronics I find more interesting, while embedded systems has always scared me. Anyway, that's just an aside.

    Thanks!
     
  2. jcsd
  3. Oct 25, 2011 #2
    I do control and signal processing design work (mainly embedded programming!) so here is my experience on the subject:

    I doubt you will find any control projects that don't use embedded programming in some form.

    Signal processing is more hybrid as most designs will have analog and digital portions (with some being strictly analog). There is definatley more room to do analog design work in this field.
     
  4. Oct 27, 2011 #3
    Hey Floid,

    Thanks for replying. If you don't mind me asking a few other questions, what sort of embedded programming do you mostly do in your control projects? For instance, is the work mostly implementing control algorithms, or is it more along the lines of writing device drivers? How important, for example, is a knowledge of (RT)OS concepts and kernels?

    Thanks again!
     
  5. Oct 28, 2011 #4
    Usually I don't have to do the real low level device driver code, but I have had to do that before as well so that isn't a given.

    Generally the controls projects are written in C or C++ and use some type of low level RTOS. The last one I did used Analog Devices DSPs and they have their own RTOS that is free called Visual DSP++ Kernel.

    The code that was involved in that project:

    Digital filters
    A PID controller
    Network interfaces (pretty basic, nothing fancy)
    Self test code
    System test code (monotored system dynamics to make sure there wasn't a problem)


    For the coding: The controller itself is easy to write (as are the digital filters). Tuning those to work together to get the best results is the harder part.

    Don't be scared by RTOSes, threads, etc. For a system like the one above the filters and PID controller need threads of different priorities to make sure everything gets run periodically and at the correct rates. Sometimes that takes some juggling, head scratching, and optimization... but that is part of engineering.


    I have never actually done an entire control design in an FPGA though it is definately possible (especially the ones with embedded processors). Usually my FPGA work has been as part of a CCA design where the FPGA does hardware interface support (like if you were designing a PCI card that had a bunch of A/D converters on it the FPGA would implement the PCI bridge and control all the A/D converters).
     
  6. Oct 30, 2011 #5
    Hey,

    Thanks for the info, Floid. That was very helpful. Embedded stuff still scares me, but at least I'll be able to make an informed decision in picking my concentration. Thanks! :)
     
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook