I'd say most embedded systems are written in straight C not C++. That's what things like cable boxes and ATM machines are typically written in. A gaming machine could be a lot of things. Python, Java, PHP, Android and iOS type jobs tend to NOT be embedded systems but more human interfaced devices like phones and graphical applications, things not typically lumped into "embedded systems". Often the things that I've seen written in "Python, Java, PHP, Android and iOS" that are truly embedded systems suck performance and memory-wise when written in these languages. This is not to say you can't use them effectively for embedded systems just that unless you have a background or mind-set about 'industrial' engineered embedded systems the results will likely be less than... great probably even less than good.

There is more existing base of C than all the rest combined, in the embedded realm so often you could've used supplied code with many peripherals that you will have to scratch write using any of the latter languages you've mentioned. This means your products/work may have a few extra bugs that were worked out in the C user world already.

Another thing that screws up embedded systems BADLY are programmers who don't consider the boundary layers. Programmers who've written PC, gamer, and 'app' type code frequently fail bitterly in the embedded world. Those type jobs don't often deal with what embedded systems must cope with, that is; slow supply voltage excursions, mechanical shocks, bad data coming in, back-to-back power failures, etc. Industrial embedded programming requires a considerable amount of effort in trying to handle lots of incorrect inputs, failures and comm failures in a robust and recoverable manner, things often ignored by non-embedded programmers.

What I'm saying is if you want to stay in those languages I'd suggest you don't go into embedded controllers as it will likely frustrate you and your customers. Better would be to focus on the more graphical and text handling user interface areas.

Keith Cress
kcress - http://www.flaminsystems.com

I got a TI programmable calculator, and used it to do some engineering, and then to learn about software discipline, by chasing a bug where I was using a register that a canned program was also using.

Then I got access to a TEK-31 calculator, which had something like 2k memory locations and a precursor to the GPIB; my company used them as instrument controllers way back when. I wrote a program to plot a company slogan in a circle, didn't like the jaggies from 3 decimal digit resolution, and hacked a fourth digit using LM339 quad comparators as DACs, and some extra opamps to add the fourth digit's contribution to
the output from the primary DACs.

Much later I used an 8080 SBC to drive that interface (for an analog plotter) and accept digital plotter commands on serial or parallel interfaces, sort of just for fun, and also because they wouldn't buy me a digital plotter.

Before messing with SBCs, I used the TEK-31 to write a math model of a Coulter Counter(r), including fluid dynamics, wide range preamps,
and classifying electronics, and used the model to better understand our company's products.

Then I started doing stepper motor controls, first with an 8080 SBC in FORTH and assembler, later with an 8741, completely in assembler.

I had a lot of fun with the 8741 (we had a few dozen on hand because of an aborted project), and managed to squeeze up to five programs into one. That doesn't sound like a big deal until you read the specs; 8741 has 32 bytes of RAM and 1 kilobyte of EPROM. High level languages and macro assemblers don't help in an environment that constrained.

My umpteenth boss was a big fan of BASIC, because he thought he could understand it. We did some motor controllers using programmable counters and 8052-BASIC chips, some of which found their way into our test equipment. I wasn't real fond of doing things that indirectly; I'd rather just bitbang four wires to run a stepper directly.

I tried C as the company switched over to it from PL/M and assembler, and ran afoul of the preprocessor so many times in so many ways that I basically gave up on it and went back to mechanical engineering.
... except for an interlude at yet another job where I tried to develop a precision controller in C, because that's what they had and what my predecessor had started with. I ran into yet more C bugs that I hadn't seen before, and was asked to leave after burning up their entire supply of OTP eproms with nothing to show for it but some chips that successfully ran HC11-FORTH. ... which the Big Boss, a former Russian Army colonel, described as a 'toy language' in what turned out to be my exit interview.

Mike Halloran
Pembroke Pines, FL, USA

I have been looking at single board PC and came accriss a video that showed the comparison in performance between Raspberry Pi3, Tinker Board, and Odroid-XU4

If I remember correctly, there was a time I found the screen of an ATM machine displaying the task bar that showed the program running and it had a Java icon probably because the programmers failed to replace it in code and someone failed to put the task bar in auto hide mode.

If I wanted to build a slot machine, do I need to learn c++ or can I use a single board computer and program it in languages like Java or C# and just make sure it is the only program that automatically starts once the PC boots up?

You can probably make a decent slot machine with a microcontroller that costs less than a dollar.
... with a mechanical or mostly mechanical display, and lots of flashing lights.

If you want animated hi-res graphics, you will need something a little more expensive and quite a bit more complicated to program.

A very long time ago, Motorola introduced a one bit microcontroller. I think it had a part number like 14xxx.
I doubt you can get the chip anymore, but the app notes could be interesting, particularly the one about making a traffic light controller, which demonstrates how to produce complex behaviors with simple hardware.

I'd suggest starting with some sort of primitive home automation to keep your learning costs down.

Mike Halloran
Pembroke Pines, FL, USA

You can build a slot machine with C - C++/Java/C# are just C with more features: more than most people can fit in their brains, and most programmers don't use 75% of the features. For embedded code, I'd stick to C: not fuss, no mess, simple and no weirdness (like mutually recursive templates or explicit conversions on default parameters). The weirdness will take an age to debug, especially on an embedded system.

Some people use C++ so that they can put declarations all over the place, but really, they are just coding in C with a C++ compiler. Some people like Java and C# because they don't have to worry about garbage collection - just lazy programming: create objects all over the place and don't bother tidying up: just like a messy cook.

You can write semi-OO code with C: after all, the early versions of C++ (CFront) were two stage compilers: first stage was C++ to C, then compile the C code. Systems like X-Windows were written semi-OO but in C.

Raspberry Pi is just a very small Linux computer. Not really an embedded system.

The alternative is python - there are some embedded python systems. It is interpreted so no need to compile.

Mike:

I see you used to work at Coulter. Where I currently work I assist in the manufacture and perform metrology on the base material used in current generation of the flow cell.
Met with Don and Gerry Graham on several occasions, and have heard Don's 'war' stories and adventures several times.

-AK2DM

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"It's the questions that drive us"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Using the slot machine as an example...

These days, "slot machines" are embedded Windows or Linux on microprocessors that are programmed practically the same as any other desktop PC. That's the "new" definition of "embedded programming", but not mine. For me "embedded programming" is bare-metal and/or C coding on microcontrollers. If the slot machine has physical rotating drums, there's a good chance it's using a microcontrollers (and associated firmware) to control the motors, relays, etc. The microprocessor runs an OS which controls a GUI and an LCD, with limited comms between the two processors.

Programming of the two processors is vastly different as one is highly abstracted from the hardware, and the other is very intimate with it. I would recommend looking at a LOT of examples on how hardware is controlled via C to get a feel for how the language is adjusted/used in such scenarios.

Dan - Owner
http://www.Hi-TecDesigns.com

It seems like learning C/C++ is the way to go. Having complete control of the hardware is also desirable but the learning curve is what I’m worried about.

I’ll will look at microprocessors more and see what kind of applications I can build.

The Tinker Board seems to be a the best to start with & then I just need to connect peripheral via USB and a touch screen for input.

I just need to decide if I should invest in learning Windows IoT or just go with Python/Java

Most of the war stories you hear about Coulter are basically true.

I am proud to have known Wallace well enough to insult him with impunity, as you might any friend.

Mike Halloran
Pembroke Pines, FL, USA

Picked up a new term bare metal programming. It looks like I will have a start learning C++

C.. not C++

Keith Cress
kcress - http://www.flaminsystems.com

Is C++ not supposed to be better than C?

It may be but as I mentioned 99% of all the drivers and 95% of all the examples and 98% of all the provided-by-IC makers code is C not C++. Embedded systems generally are very tight on memory and C, I believe, uses it more efficiently than C++ and typically with better visibility and adjust-ability to the person who understands it and writes in it.

Keith Cress
kcress - http://www.flaminsystems.com

Every level of abstraction incurs some cost for the abstracting process, so machine language is more efficient than C which is more efficient than C++, etc. As compilers have improved, the incremental cost is less than it might have been at the nascence of each abstracting language. The latest claim is that C++ can actually be more efficient in programming effort as well execution times, when using template libraries.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! https://www.youtube.com/watch?v=BKorP55Aqvg
FAQ731-376: Eng-Tips.com Forum Policies forum1529: Translation Assistance for Engineers Entire Forum list http://www.eng-tips.com/forumlist.cfm

"Better" is a personal thing: it means different things to different people. If you are just experimenting with stuff, especially talking to hardware, it is simpler to do it in C. If it is just a computer simulation of a slot machine then C++ is fine.

If you are just learning and playing with hardware at the same time, you don't want to be plagued with linking problems, missing libraries, templates, namespaces etc which you sometimes get with C++. Get your hardware interfaces working in C. You can always call C functions from a C++ program but you can't call C++ from a C program. If, at a later date, you wish to change to C#, Java, Python, Fortran or Ada, you can still call the C functions. It is the favoured interface language: almost every language can call C functions.

That does make sense.

Basically I just need to lesrn c and I can design the gui in any of the languages I’m familiar with thay has capability to call c functions.

I guess I have to get the Arduino boards to start learning.

If it's big enough to have a GUI, it's big enough to run C++ without noticeable difference. Again, it's a computer/microprocessor. If it was a microcontroller, I'd say assembly/C all day...

Dan - Owner
http://www.Hi-TecDesigns.com