Programming languages for electronics engineers

Question

I am an Electronics and Communications Engineering student, before I got to college, I have been interested in programming and computer applications. I had focused on designing Windows applications and learning its techniques, but now, I feel that this is useless in my field... I don't have to learn everything about computer science and developing software! (Am I right about this?)

I know VB .Net, C# and C++. I have plenty of time in my holiday so I want to delve deeper programmatically in "electronics field". So what would you recommend to learn or to focus on?

I want those languages used in programming Microcontrollers and other integrated circuits. Is C++ enough or I should master C as well? Tell me your thoughts please.

Answer 1

Yes, it's almost certainly a good move to learn to use C as well as possible (C++ will give you a helpful starting point, although as leftaroundabout notes, there will still be plenty to pick up, especially the differences between coding for small embedded systems compared to writing for something like Windows) given it's ubiquity.

Most microcontrollers below a certain size (e.g. PIC, AVR, MSP430, etc) use C (or assembler) as there are many high quality (free and $$ versions - e.g. many commercial compilers are based upon the free GCC compiler) C compilers available.
You do get other languages like the excellent JAL for PIC (original author Wouter Van Ooijen who is a member here), PICBASIC, Ada variants, but due to it's popularity and number of compilers available, I'd say C is the language of choice for most. While this certainly doesn't mean it's the best language, using the most popular language comes with obvious advantages (documentation, support, portability, collaboration, etc)
For the more complex and larger 32-bit micros like many ARM variants, there are also C++ and other compilers available.

I would jump right in and grab a few development boards and get coding. You could pick a low end 8-bit micro like the PIC16F (many starter kits on Microchip Direct)
A middle of the range 16-bit micro like the PIC24, and also a C/C++/embedded linux ARM of some sort - the STM32F4 ARM Cortex M4 Discovery is an very cheap dev board that might be worth grabbing.
On the programmable logic and hardware description language (HDL - the big two are Verilog and VHDL) side, it may be also worth getting hold of an FPGA or CPLD dev board from Diglent or similar.

If you don't want to wait for a dev board, you could download MPLAB or MPLABX and use the excellent simulator to try your hand at PIC development. Same goes for other tools too, for instance you can download Xilinx ISE Webpack for free and try out HDLs and programmable logic design.

Answer 2

Learn C, and get a cheap microcontroller development board, like an MSP430 or ARM Cortex, and at least write and load a few C programs.

I have a computer science degree and a software development background, mostly C++ programming for games and now iOS games and apps, but my last job was a semi-pro EE gig that started with doing a bunch of firmware programming for an ARM Cortex M3 system, and then ended up with me learning how to do some basic circuit design and board layout and designing a couple of simple boards. So I basically had to confront the problem of using the best programming language for bridging the hardware/software design as someone who was responsible for both ends of it.

C is absolutely the language you need to know. It's easy for people who program in C++ and never actually have to restrict themselves to C's feature set to say "it's the same thing" but it's not. Especially the way C++ has evolved and gathered features, and the way mainstream C++ programmers use those features, it is really a much different thing to work on a reasonably large C application as opposed to a C++ application. Your firmware SDK will be a bunch of C libraries, anything else that will fit on an MCU will be a C library, any OS that makes sense on an MCU will be written in C, etc. etc.

That said, since many of the MCU toolchains out there end up using GCC as their compiler, you will almost certainly have a C++ compiler available if you're using a decent MCU family. But you have to be very careful about the features you use, especially things from the standard library, as it is very easy to end up with a binary that is way too big to fit on your device. I think there is a good case to be made for using C++ on embedded devices, C++ has quite a few nice features that have litter or no size or speed penalty, you just have to know what you're doing and write code that is way further on the C-style end of the spectrum than the STL end of the spectrum in terms of clever feature use.

Don't pay too much attention to people who say you can use Lua or Python on an MCU with the right embedded interpreter blah, blah. That is true, I've done it and it's fun, but at the moment it's more for toy projects and stuff that shows up on Hack a Day. I think we'll see more of that sort of thing as Moore's Law is relentlessly applied to even the smallest processors, this is something that happened with games where there used to be a lot of assembly, then they held out with C and C++ longer than everyone else, and now everything is so fast, and developer productivity is so important that a lot of development is done with embedded higher-level languages or in a high level language outright. Even so, it'll be a few years before you see companies hiring firmware programmers with Python and Lua backgrounds.

Don't spend too much time on assembly either. It's not bad to be familiar with the concepts, but it is unlikely you'll find yourself doing much, if any assembly programming. There's like this conventional wisdom with games and embedded that it's "good to know" assembly, often repeated by people who don't actually work in those fields. But in reality it is very unlikely you will write any assembly at all, ever, and if you do it'll probably just be a few lines for optimization or something with the hardware you just don't have an API for (but you will after you write one that wraps a few lines of assembly). I've worked on several games and that board/firmware design project and the total number of lines of assembly I've written for commercial projects is probably in the low teens. It's not productive, it's not portable and it's not readable so it's only ever used as the last possible option.

Answer 3

I agree with everyone else that you need to be very competent in C.

I'd also recommend learning at least one assembly language too. Doing this will make you a much better C programmer. You need to know what's going on under the hood, and this is much more true in the embedded world than it is in the PC world.

Understanding the assembler that your C is generating will let you write more optimal C in terms of speed and compactness. Faster code means:

• you can use a slower cheaper MCU and undercut a competitor.
• you can turn down the clock rate for improved EMC compliance.
• in a low power application the MCU can spend more time in sleep, directly leading to increased battery life.

More compact code means you can use a cheaper MCU with less memory. Or have room for more features.

---

The other language you might consider learning is Verilog. This is a hardware description language, and it really quite different to C, not just in the way it looks, but also in its functionality. Verilog will open the way to taking advantage of very powerful chips like the Cypress PSoC3 and 5. It's a microcontroller with analog and digital reprogrammable hardware, which allows you to do some amazing things which are very difficult to do with any other MCU. You'll also be able to do FPGA design.

Answer 4

As an MSEE who has been working in the Defense industry for 8 years, I can tell you that understanding how to program well in LabVIEW (a graphical, strictly typed, dataflow language) means that you'll never be short of work.

LabVIEW started as a programming language for hardware engineers, you can see this in the fact that the code looks very much like a circuit diagram. However, over the past 25 years LabVIEW has developed into a full-fledged, feature rich language with support for Object Orientation and multi-threading. In fact, I would argue there is no other programming language, text based or otherwise, that is easier to program a multi-threaded application in than LabVIEW; this is in large part due to it's data-flow paradigm. As the number of CPU cores continue to increase, LabVIEW will become more and more relevant as a general purpose language.

Another benefit of knowing LabVIEW is that you are only a stone's throw away of programming FPGAs using the LabVIEW FPGA module which takes your LabVIEW code and converts it to VHDL behind the scenes before it passes it to the Xilinx compiler. You also can use your LabVIEW skills to transition over to programming Real-Time code via the LabVIEW Real-Time Module which uses either VxWorks or Phar Lap.

Note: I am a Certified LabVIEW Developer.

Answer 5

If you want to do low-level programming of microcontrollers, then you should be comfortable with assembly-langauge programming (the more different architectures the better), and yes, you will use C a lot more than you use C++.

For general engineering work, math-oriented languages such as Matlab (also Scilab and GNU Octave) will be commonly used for modeling and prototyping.

Also, many IDEs for software and hardware are scriptable, typically using TCL or LUA, so some familiarity with scripting languages in general (also Perl, Python, PHP, Javascript, etc.) would be useful.

For hardware design, you're going to need Verilog and/or VHDL skills.

Answer 6

Is C++ enough? Maybe.

Please remember that C is used in something like 90-99% of all the mcu:s out there, so C is a must on your resume.

But since you are a high level guy you could start to play with the Arduino:s since they are programmed with a scaled down C++, and that would give a rough idea what C++ can do in the mcu world right now.

Answer 7

For microcontrollers (and I'll only address microcontrollers), I think C is a much better entry language than C++. Assembly would be the next step, fantastic for helping you understand how your C compiler is screwing you up, creating bugs, stealing clock ticks, etc., and squeezing the most performance out of your platform. This is all assuming you're talking about a microcontroller -- not an arduino, BASIC Stamp, or any other platform involving a wrapped-up microcontroller.

Hard to say what's useful for "your field" -- and suggest that as a student you might not really know what your field is yet!! -- but I think that your language set seems pretty reasonable and you'll find yourself using it over and over again. At the very least, having a good grip on one structured language makes the next one that much easier, but I think you'll always find your windows programming skills nice to have in your pocket.

Answer 8

You could learn C and the type of assembler code that is generated by C statements if you work with processors, but you should also teach yourself how to use a Unix command line shell such as bash and the tools that go with it such as sed, ed, awk, vim/vi, find, tar, gzip, ... as well as Python which you can use on many platforms and is a good way to "get things done".

Answer 9

You must learn C if you want to be a serious embedded developer. You should also know assembler even though you will probably very rarely use it.

Answer 10

I'll first define electronics engineer to mean someone involved in hardware design from firmware through to board design and onto chip design. In some cases you will be doing firmware, as stated above you'll need "C". Deeper down software becomes simply a tool, understanding some comp sci concepts in complementary languages from C/C++ to Lisp like languages will be more important than specifics. You will need software to support your design efforts but that doesn't take precedence to understanding the fundamental limits of what can be done in a physical implementation. Digital design is NOT Verilog/VHDL even if the design is expressed in those languages. Into full custom and in-silico design you'll see Lisp like languages and C - functional languages. Things are trending more towards Python for scripting but there is a lot of Perl/Skill/C/System C/ Verilog-A/VHDL test benches and checking software/scripts.