22

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.

Siraj Muhammad
  • 572
  • 2
  • 6
  • 22

10 Answers10

29

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.

Oli Glaser
  • 54,990
  • 3
  • 76
  • 147
  • 9
    PICs may be cheap, but at the risk of starting a flame war, I would contend that using a PIC as a learning tool teaches you to program PICs rather than teaching you to program a general purpose microcontroller. For this the MSP, AVR (Arduino), Low end ARM Cortex or even the venerable 8051 processors would provide more easily transferable skills. – uɐɪ Sep 06 '12 at 09:12
  • Thank you very much... this was greatly useful. But to summarize your answer: What I need right now is keep working on C++ and mastering C, learning Verilog or VHDL or both, and grabbing a few dev boards for practising or just using those simulators as a beginning. – Siraj Muhammad Sep 06 '12 at 10:55
  • 1
    @SirajMuhammad - Yes, that's about it, apart from learning both Verilog and VHDL is probably not necessary, since they can usually be used together in a design (so for instance you can use a soft core processor designed by someone else in VHDL, in your Verilog design, and it will function fine) so just pick one. – Oli Glaser Sep 06 '12 at 11:53
  • 4
    @Ian - I'm not suggesting it *has* to be a PIC, that's just an example (hence the "like a PIC") In any case, if you are programming in C, I don't think there is much of an overall difference between any of the small micros out there. Of course to get to really know one micro inside out (assembly and all) is useful, but for starting off at a higher level things should look much the same, just the tools being different. I think it's worth trying a few before committing to anything. – Oli Glaser Sep 06 '12 at 12:00
  • A Cortex M3 or M4 is a great start. There are cheap boards, TI just released a $4.99 M4 Launchpad board, STMicro has a $15 Discovery board. They have a great array of peripherals, a USB interface to connect directly to a host machine for programming and debugging, and lots of CPU (relatively speaking, of course). And if you end up with a crazy project idea, there are driver libraries for PWM LED controllers, LCD displays, touch screens, etc. They also have IDEs bundled so you can get started quickly if you want to go that route, and there is arm-eabi-gcc if you like to go the Unix route. – Suboptimus Sep 06 '12 at 19:56
  • 2
    "shouldn't be too hard if you already know C++"? I wouldn't agree on that, somebody who knows "VB .Net, C♯ and C++" probably uses the latter in a rather high-level, object-oriented RAII style and might well need some time to properly get the grasp on manual memory management. – leftaroundabout Sep 06 '12 at 20:55
  • @leftaroundabout - fair point, maybe I put it too briefly - I just meant it will give the OP a good starting point with structure, syntax and a familiar feel, as opposed to starting "from scratch". I agree there will still be plenty to learn, especially regarding actual use on memory limited embedded systems. – Oli Glaser Sep 06 '12 at 22:42
  • @leftaroundabout There is nothing wrong with writing object-oriented programs, and RAII is (when properly used) zero-cost and helps avoiding many silly mistakes (which are inevitable during learning). – Alice Jul 26 '18 at 12:05
  • @Alice exactly my point. Just because somebody can write C++ well, using RAII and all, doesn't mean they'll also be able to program in C. – leftaroundabout Jul 26 '18 at 12:10
23

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.

Suboptimus
  • 871
  • 4
  • 6
  • 1
    It's worth saying that your few lines of assembly will likely be in inline assembly statements (`asm()`), nicely embedded in your C code. This is a winning combination in every way. High level but compact with occasional dips into assembly when, for instance, the timing needs to be just right. The `avr-gcc` toolchain already does this a lot with C macros, so you never notice. – Alexios Sep 06 '12 at 07:12
  • 9
    It is probably more important to be able to READ assembly rather than having to write it. This allows you to understand what the compiler is telling the micro to do, and in very rare cases be able to spot when the compiler gets it wrong. You also need to have some assembly understanding to get the most out of your debug tools and using the single step functionality that they provide. – uɐɪ Sep 06 '12 at 09:07
  • 1
    Definitely agree with that. I think one of the best exercises for an aspiring programmer is writing a toy language compiler and code generator that at least handles functions, arrays and structs to learn what a stack frame looks like and what the basic elements of a programming language look like in assembly. – Suboptimus Sep 06 '12 at 19:55
  • 3
    @Ian - Being able to read assembler is useless if you don't know how to write it. You need to read it and compare it to what you would have done if you'd written it. – Rocketmagnet Sep 07 '12 at 20:07
  • 2
    @Rocketmagnet - You are not out to check that the compiler has generated the most efficient assembly implementation. The requirement is that you have the ability to read the generated assembler and check that the logic of the implemented code matches your intention. This is the same as using other human languages. I can read and understand far more French, German and Latin than I can speak or write. – uɐɪ Sep 10 '12 at 08:10
  • @Ian - Yes I am. Checking for correctness and optimality are both important, as I explained in my post. If your C compiler is generating sub optimal code, then you just won't know it, and you will be buying a more expensive MCU than you need to. I have seen it several times before. Even very skilled C and C++ coders, who have no embedded experience, can write *terribly* wasteful code because they have no idea how to examine it. This has e.g. caused problems with real-time control loops in robots which have had to wait ages for data to come back from poorly coded MCUs. – Rocketmagnet Sep 10 '12 at 09:06
10

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.

Rocketmagnet
  • 26,933
  • 17
  • 92
  • 177
  • What do you mean by "one assembly language"? I know that there is a language called Assembly, does it have branches or something like that? Can you name some please? And Thanks a lot for your answer. – Siraj Muhammad Sep 06 '12 at 10:49
  • 4
    Each type of CPU or MCU has its own assembly language with different instructions. They're all fairly similar, but with important differences. Learn the assembly language for whatever MCU you're using. – Rocketmagnet Sep 06 '12 at 11:14
  • 1
    Was going to say exactly this. C and Assembly are the most used in Electronics Engineering, because you're usually dealing with low level things. Object Oriented isn't really that well-utilized, the kind of low level thinking that comes from C/Assembly will also apply to whatever else you work with. – Muz Sep 07 '12 at 17:34
9

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.

enter image description here

SiegeX
  • 526
  • 2
  • 6
  • 21
  • 5
    All the production LabVIEW I've seen looks more like this: http://thedailywtf.com/Articles/Labview-Spaghetti.aspx I don't doubt there is a strong job market for those willing to maintain such code. – markrages Sep 11 '12 at 21:04
  • @markrages I've been asked to maintain and/or expand on code that was nearly as bad maybe worse as there were dynamic VI calls and globals too. This problem is the double-edged sword that is LabVIEW. On one hand they market it as a language any engineer can program in, however without any solid foundation in software architecture, you end up getting code just like this. Thankfully, NI has sufficiently addressed this issue with LabVIEW 2012 by providing well written & commented templates for architectures starting with the simple state machine to the complex OOP-based actor framework. – SiegeX Sep 19 '12 at 04:55
  • @markrages The problem is twofold. One, management gives engineers just enough training to be dangerous. I'd say 9/10 LabVIEW programmers I've met at my company who have had training only took the first two basic courses which essentially teach you just the syntax. Secondly, LabVIEW has become a feature-rich language that rivals any modern language today yet because it's graphical management thinks it must be easy. Managemnt would never task a software engineer to design a medium to complex circuit yet they have no problem throwing a EE at a complex software problem if they "know LabVIEW" – SiegeX Sep 19 '12 at 05:05
  • @markrages: Right when I was reminded of why I liked LabVIEW, I saw your comment and remembered why I hated it. Oh, the hours of frustration all came back at once. – Christoph B Feb 05 '13 at 12:30
6

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.

Dave Tweed
  • 168,369
  • 17
  • 228
  • 393
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.

Johan
  • 2,385
  • 2
  • 25
  • 27
3

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.

Scott Seidman
  • 29,274
  • 4
  • 44
  • 109
2

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

Paddy3118
  • 229
  • 2
  • 5
2

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.

mjh2007
  • 3,899
  • 24
  • 49
0

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.

placeholder
  • 29,982
  • 10
  • 63
  • 110