How much embedded programming in control/signal processing?

[walk_w/o_aim]

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!

 

[Floid]

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.

 

[walk_w/o_aim]

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!

 

[Floid]

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 definitely 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).

 

[walk_w/o_aim]

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! :)