Hi guys, I just finished the program, Electronics Engineering Technology from a college recently. Now, I am thinking to take a course, c or c++ programming for my electronics field. As I know, in computer field, most programmers are using c++ to make software. But I am not sure that in Electronics field, we are using c programming more often than c++ programming, right?! Will c++ replace c programming in electronics field very shortly? Which programming language should I take for my ELECTRONICS field? Please advise, thank you.

 

C++ is actually not a different programming language. It is an extension of C. If you learn C first, it will be a good beginning for learning C++.

That said, most small microcontrollers have C compilers. Only the larger ones have C++ compilers.

That said, C++ does not have to be only a big-system language. If you are careful about which features you use, it is possible to make a C++ compiler that produces code that is no bigger than the code produced from a C compiler. When I use a C++ compiler, I often use very few of the C++ extension features. I use it as a "better C" compiler.

Robert Scott
Real-Time Specialties
Embedded Systems Consulting

 

c++ is an extension to C.

I don't know how it is these days, but it used to be that a C class was often a prerequisite to c++.

 

Hi,

It may be worth you while to look into C before C++. C will give you background on all of the essential syntax & concepts used by languages like C++ & C# but was designed to be (in its ANSI form) independant of operating system. DSP, microcontroller, and real-time control systems necessitate knowledge of C programming (and some assembly as well). It can be a difficult language to learn but really does lend itself to being used across a wide array of platforms.

C++ is very useful, although predominately for Windows application programming. C++ is an object oriented language (like C#, VB, Java, etc.) and object oriented programming is the current paradigm (or so one of my college profs said).

Unless you see yourself programming applications, definitely consider C. The authors of the C language have a very thorough book on the language (aptly) named "The C Programming Language" that details the ASNI specification, provides a ton of exercises, and gives a reference for the ANSI standard library.

Hope this info helps!

 

If you know neither C nor C++, then I would suggest that you learn C first. If you are interested in programming small microcontrollers (e.g. PIC, etc.), you will want to know C (as well as assembly language). C tends to be used for small programs that operate close to the hardware (which I assume that someone working in Electronics would do). C++ tends to be used for large programs where the object oriented features can be used to advantage.

There are two sorts of C++ courses that I have seen. One type assumes that you already know C, and then builds on that. If you don't know C already, you will have a hard time keeping up. The other type of C++ course is really just a C course with a few C++ concepts added in. In this case, you don't really learn C++ (that happens in the "advanced" C++ course), and the time you do spend on C++ takes away from the time that could have been spent on learning C better.

I don't forsee C++ simply replacing C any time soon. If anything, I would expect C to outlast C++ in mainstream use. There really isn't anything (other than assembly language) in widespread use that is intended to replace C in what it is best at, while languages such as Java (etc.) are however intended to replace C++.

 

C and C++ are more similar than you're giving credit, especially if you've never used either. The notable differences are that C++ has additional libraries that support object oriented programming - something that I would encourage you to eventually learn, but after you write a few C programs and learn how it works. Begin with a class or basic textbook. I think C is a better place for you to start, especially given your interest in electronics versus software development. Focus on learning about functions, memory allocation, data types, variables, constants, operators, etc. You'll be on your way to becomming fluent in the approach, so the language choice will feel more secondary.

-----
Nathan Boeger
Inductive Automation
"Design Simplicity Cures Engineered Complexity"

 

If you are leaning towards embedded programming, C is a good choice. And a good knowledge of C certainly helps in understanding C++. In fact, I think you would have to cover much common material
as C++ is not that distinct from C. But, as you say, if you are leaning towards applications programming in the windows world, C++ is almost ubiquitous, usually for all the wrong reasons.

Regards

cww

 

If you don't know programming, I would suggest you learn that first. The language is secondary. Something like Python will make learning easier; learning programming is difficult enough without the added difficulty of a language like C or C++ (or Java). Better learn programming first and C later.

If you do know programming, I expect that C is and will continue to be the standard in the electronics field (and anywhere memory is tight).

As for most programmers using C++, that would seem to be simply untrue; Java and C are usually listed ahead of C++ in the popularity charts.

Jiri
--
Jiri Baum <[email protected]> http://www.baum.com.au/~jiri

 

To add a bit more detail to how frequently various programming languages are used, there is a web site which publishes a monthly index on the "popularity" of programming languages. This is the "TIOBE Programming Community Index"
(http://www.tiobe.com/tiobe_index/index.htm). I have referenced this site a number of times before on related questions.

The top ten languages for November 2006 in their index (together with rating) are:

1 - Java 20.4%; 2 - C 17.2%; 3 - C++ 11.1%; 4 - (Visual) Basic 9.5%;
5 - PHP 9.2%; 6 - Perl 6.2%; 7 - Python 3.6%; 8 - C# 3.0%;
9 - JavaScript 2.3%; 10 - Delphi 2.3%

The long term trend on their chart shows that C++ appears to be declining in popularity, while C is remaining more or less stable.

 

Why do u learn c++ for Control? PLCs Use ladder logic. If your going cheap with SBC trust me you'll pay in the end in some way.

Tell me the breakdown between your SBC and a PLC. ohh let's go Allen bradley, I can't image anyone writing a PID loop in C++ "dear god". Yes i'm a C++ programmer and others so go ahead, explain please. So you're throwing your Customers into the lion's den?

 

RLL is really just a graphical way of describing boolean logic. any low level programming skills are useful in understanding RLL, and c tends to
make you think pretty low level.

 

Well, there's control and then there's control. I can't imagine writing a FFT vibration analysis and mitigation loop in relays. Ladder logic is good for quite a few tasks, but in certain areas like analog at anything but glacial speeds or where your control variable
is a complex quantity, you have to have a bit more power than the scheme provides. More and more "ladder logic" actually makes use of fairly complex function boxes that don't really fit the
relay model. Indeed, the relay representation is simply a facade and the underlying computer _is_ a SBC in many cases.

Obviously, if correctly programmed, a SBC running a compiled language should certainly be able to do what a SBC with a ladder interpreter can do. As far as the customer is concerned, in my experience with machines, they typically don't get anything more useful with RLL than with a custom program as neither is very fixable or customizable without source code.

Regards
cww

 

In reply to Brian E Boothe - Not every square peg can be pounded into a round hole. There are applications for C, C++, PHP, AWK, Python, Java, LabView, and even (God forbid), Basic.

The original poster was writing as someone who was looking at the problem from an electronics designer viewpoint. Where do you think all this nice hardware that you program in ladder logic comes from? You'll also find that believe it or not, PLCs can't do absolutely everything that needs to be done.

 

I realize that my last Post might have been a little Hasty, I seemingly dwell into embedded system programming a lot myself on my free time, but I work as a developer for A industrial automation firm, were I do alot of development in C++ , VB , ASP , PHP , XML , etc as well as ladder logic But my forethought to his question, he was wanting to Use C++ Maybe to
Control A Industrial Wastewater plant, not to Develop the RTOS or a subset in the PLC that runs ladder for the wastewater plant

 

Well in my mind your right, BUT, go take an electrician "total electrical relay" minded owner of an industrial control company, only thing they know is RLL absolutely nothing else and start talking Low level Code to him, he
will look at you like your crazy, or even analyzing the RLL as C++ or Any other Code, he going to say "why do it like that??, it's already done for u here in RLL, they only Understand TOP level Application software not an
Embedded hardware layer , or the real-time O/S , he doesn’t care Doesn't want to care, that’s my experience anyway, oh and Just a note Allen
Bradley Does Vibration analysis in ladder,, Logix5000, they have instructions just for that,

Peace

 

I personally love the IEC 61131-3 model for programmable controllers. It has multiple programming language types. Formerly most PLC programming in the US was accomplished by RLL only and this was quite a limitation. With the multiple language styles, problems can be solved ad hoc with a more suitable language. My dream is that some smart PLC manufacturer would incorporate the power of C++ into it's 1131-3 format. It would, in my humble opinion, be great to use objects, memory pointers, linked-lists etc. at the plc level in the syntactic code style.

C, and even more so, C++ is an extremely powerful programming environment, primarily (again,in my opinion) because of the direct access that you have with actual computer memory. Some programmers call this a drawback due to security concerns. However, for shear esoteric programming, you can't beat that pointer. In choosing C++ for your education, you will learn the precepts of C and the benefits of the object-oriented C++.

 

That doesn't surprise me, in fact, that emphasizes my point. To control the more complex things that want control, they have resorted to routines in a procedural language with program control flow in relays. Suppose I cracked open a brick PLC, replaced the ROM and made it run a different executive that handled compiled C for example. or say I read the ROM and ran that executive on another board with the same processor. Other than looks they would do the same thing. And there would be little difference in the results. Both could be reliable to the limits of the cheap hardware, which is to say, any hardware these days, as it's all pretty good. There is simply nothing special about PLC hardware anymore except at the perimeter, interfacing with the real world. And that's not magic, it could be applied to any computer IO. But my real point is that it's ignorant to belittle SBCs in a world that's filled with them, especially when they operate so reliably that we forget how almost everything we own works. And that it usually continues to work for the life of the equipment. PLCs are just a tiny, tiny sliver of the embedded computing world and a great many _are_ SBCs. The argument then is about which programming methods are more productive and reliable. PLCs do this by using an extremely limited set of operations that are tested and immutable. There is no reason that you can't do the same thing for a larger set of operations or a different programming paradigm. People seem to judge all programming by what they have on their PC.

Regards
cww

 

If you have a small programmed device with a limited and well defined function, then electricians have no more trouble dealing with it than they do dealing with a big wire-wrap board full of NAND gates. In fact they have less problem because there are fewer things to go wrong. If its broken, throw it away and put in a new one (while with the wire-wrap board, they're expected to actually FIX it).

The important thing is to make sure the device is well designed and has thorough and useful documentation. If you have a board with a PIC and a dozen I/O, you should be able to document exactly what it will do. If input 'a' goes on, then LED 'm' flashes, and output 'x' modulates at 'y' hertz. Draw state diagrams and timing charts and have explanations and then people can work with it. If you throw a pile of assembler or C listing at someone and tell them to "figure it out for themselves", it's no wonder that they don't want to waste their time on it.

It's nice that some AB models has some sort of vibration analysis function built in. However, knowing a bit about vibration analysis I can say that there are many different algorithms for different applications, and if the one they implemented (without even addressing hardware issues) isn't the one you need, and you can't buy what you need anywhere else, then you may just have to buy or build an SBC and program in what what you need in C.

It's not something you do every day because it's time consuming and expensive for one off jobs. Sometimes however, it's the difference between getting the job done or not. If it's not something you can do yourself, then you can always hire someone to do it for you. There are lots of people (like the original student hopes to be) who do this for a living.