Why does ARM mbed rely on C++? Is C++ the future?

[rstofer]

One of the problems with trying to sort out languages for 'embedded' work is defining the system.  In my view, embedded implies a fairly small CPU with very limited memory.  Like that LPC1768 with 32k of RAM unless you use the two 16k buffers.  Clearly, the Arduino has limited resources.

OTOH, we could discuss embedded in the context of a Raspberry PI where memory isn't even a consideration.  I haven't seen hardware level projects for the platform (replacing Linux, for example) so I don't know what language would be used but I'll bet it isn't Python!

For the resource limited devices, we need tight code (or a bigger CPU) and I don't see how other languages can compete with C in terms of code size.  The video posted earlier about C++ and embedded just about changes my mind but the problem I have with it is that you need to be a ninja warrior with C++ to get those results.  Of the dozens of ways the problem could be coded, ONE of them results in no overhead.  It remains an exercise to figure out which one.

And, when the code is done, the underlying principles aren't really obvious.  Why was it coded the way it was?  C, OTOH, is pretty obvious when you look at it (mostly).

There's is something to be said for simplicity.  It is a hallmark of C.  A nice simple language.

These language wars go on endlessly.  The thing is, they really serve a purpose.  It's true that I don't know C++ at any significant level and I certainly don't know it at the level of Jason Turner in that video.  None of the books I have on C++ go anywhere near that level of coding.  Maybe I need better books!

Or an application...  I don't learn anything until the day I need it!

[technix]

We know Unix is written in C, Linux is written in C, how about Windows?

AFAIK the Windows kernel is also written in C. OTOH the driver layer of macOS is written in a limited subset of C++ (a good portion of C++ standard library is missing in macOS kernel so only that limited subset is usable) while the kernel proper is C.

[nctnico]

If anyone can mention any language (other than the 3 above) that has a good standard and is adapted for embedded development, please do so!

The problem with this statement is that 'embedded development' is and has been a moving target.

[C]

Easy to put on blinders to make statements.

Yes UCSD compiled to PCODE and itls interpreter was written in assembly.

But as with all narrow statements, facts prove this was not only option.

A CPU existed that ran PCODE directly with out an interpreter.

A lot of Pascals could compile to many different output languages.

An once you have a language running and can compile to assembly language for a CPU it is easy to compile the interpreter from the high level and even improve it in the process.

Back then the common thing for a new CPU was assembly language.
It's a chicken & egg problem. Need to get started on something new and can not use the language until started.
Today a cross compiler is the method after getting past first run problem.

Need to ask why some want more and more standards.
Could the simple answer be that the foundation started full of holes in first place.

Keep seeing complain where and expendable language is bad.
And they are using "C" which is extended by adding functions.

What makes this a good idea and also at same time of not allowing new data type extensions.
It is just defining how things look in source, checking rules and code generation.
Smoke and mirrors hiding what could be easy.

Same can be true for new or expanded commands.
You the programmer just have to have access to underling functions that the language needs.

Think of simple example
You have an integer as a base type. Being able to define a new type and have access to it's memory allocator makes working with many memory areas easy. 

One size does not fit all.
Step one should be defining to language what it has to work with.
How hard is it to have the facts about A CPU & SYSTEM such that the language can check for errors?
The code generator can check for errors?





 

 

[tggzzz]

I would add one point to what we all said.

I personally think that any non-standardized language should not even be considered for professional work.
And whereas C, C++ and ADA all have robust standards that have been evolving on a regular basis for several decades now, this is far from being the case for a lot of other languages that have been mentioned here.

If anyone can mention any language (other than the 3 above) that has a good standard and is adapted for embedded development, please do so!

xC, from XMOS. (Don't bother to say it!).

Effectively the RTOS is cast in hardware in the xCORE processors.

It is essentially Tony Hoare's Communicating Sequential Processes (from the mid 70s) with a C-like syntax. It is designed for parallelism from the ground up, and enables hard realtime guarantees on their 4000MIPS MCUs. The core concepts have been used in processors (e.g. TI DSP processors) and software continually since the mid 80s.

Some features of CSP are re-appearing in modern languages, e.g. Rust and Go. We will see where they go...

[tggzzz]

I suspect that one of your limitations is that you aren't considering RTOSs.

There are many RTOSs but I'll bet the majority are written in C.  I know that FreeRTOS is written in C and it seems to be pretty popular.

C or assembler, with the interesting ones being implemented in hardware.

I'm unconvinced about what will supplant C/C++ in embedded applications, but something will.

Why?  What we have works fine,

But it doesn't work well enough. As Hans Boehm pointed out, you cannot implement threads in C. http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf [1]

there's a ton of code in the wild and there's no motivation to change just for the sake of change.  If anybody cared, there would be a lot more Ada being written.

Never underestimate inertia

The people that care about correctness use ADA. I wonder how the self-driving cars will interact with the law and the insurance industry.

I always remember the concept that, if you don't have to get correct results, you can develop your programs arbitrarily fast and they can execute arbitrarily fast.

As to standards:  What standards?  They keep moving the goalpost, adding features that seem 'gee whiz' but aren't really necessary.  C++98, C++03,C++11,C++14,C++17 and the yet to be released C++20.  C++ is a moving target!  Of course, C is no better.  Once a language has an ISO committee, they have to earn their keep by changing stuff.

You contradict yourself. If "what we have works fine" then there wouldn't need to be so many versions of C/C++ struggling to catch up with problems that were apparent in the 1960s!

[1] That may be becoming less true now, with the latest versions of C/C++

[tggzzz]

There's is something to be said for simplicity.  It is a hallmark of C.  A nice simple language.

There's a lot to be said for simplicity. Simplicity isn't the hallmark of C: count the pages in the standards and then add in the "this is how you ought to use (and not use) it" documents.

[rstofer]

Yes UCSD compiled to PCODE and itls interpreter was written in assembly.

But as with all narrow statements, facts prove this was not only option.

A CPU existed that ran PCODE directly with out an interpreter.

Yes, and I had one: MT Pascal for CP/M.  In fact, the beauty of the Pascal Language is the simplicity of the compiler.  There's something about recursive descent that I find elegant.  Wirth's syntax diagrams made writing the compiler very straightforward.  It's all in the syntax!

Yes, there was an LSI-11 chip repurposed to Pascal.  I didn't have one but I would have liked to.  A bunch of years ago, I decided to do an FPGA project to run P-code directly.  I got the hard parts done but I stumbled when I had to call system routines to do things like floating point arithmetic.  It was going to be a blistering fast Pascal system based entirely on the CDC 6400 version, P4.  I was going to bump the word length from 60 to 64 bits since a 'set' was defined within a single word.

A lot of Pascals could compile to many different output languages.

I haven't run across that but why not?  It's just code generation.  There was also a version of Pascal for parallel computing.  I have the Report on that but I have never given it much thought.

But, without extending the language, there was no concept of registers and interrupts/vectors.

Turbo Pascal is still fun to play with.  I wrote the flood-fill algorithm for MicroMouse in TP and displayed the maze and mouse using Turbo Graphics.  Works well!

Today, FreePascal is readily available and runs under "Bash On Windows" of Win10.  It obviously runs on Linux.  A very nice package!

[technix]

There's is something to be said for simplicity.  It is a hallmark of C.  A nice simple language.

There's a lot to be said for simplicity. Simplicity isn't the hallmark of C: count the pages in the standards and then add in the "this is how you ought to use (and not use) it" documents.

Throw away the pages that is only applicable to hosted environment, which embedded programming rarely is. Now the manual looked a lot thinner isn't it?

On a technical aspect running the freestanding C language code requires only a stack. That is usually set up in a small assembler stub, or even in hardware (for example Cortex-M.) That is where the simplicity comes in to play.

[SiliconWizard]

xC, from XMOS. (Don't bother to say it!).

xC is not bad indeed. But right now it's only targeted at XMOS products AFAIK and has no standard. It may even be seen as a proprietary language I guess, even though there seems to be an open-source initiative (XCore?) That said, the XMOS architecture is pretty interesting.

For the record, C11 introduces thread support. I've read this version of the standard and contrary to what some have said  here, I still find it quite reasonable (which is not the case for the C++ standard). Apart from some nice additions and precisions, there is nothing fundamentally divergent from the C89 version (and even less from the C99 one), so I wouldn't call this a 'moving target' by any means.

[rstofer]

I have a question:  WHERE did the library put my queue elements? On the heap, I imagine.  I want them put in a specific area of memory.
I remain unconvinced!

You need to read more! If you write your own low level allocator you can use any kind of memory you want AND use the library.

So, I went to Dr Dobb's and read an article on allocators written by one of the fellows on the standards board.  It's a great article but, in the end, if I want to put my queue in a specific location, I have to write a ton of C++ and, by the way, it has to comply with the standard if it is to interoperate with the std:: library.

In C it looks like this:

Code: [Select]

[font=courier]#include "mbed.h"
#include "queue.h"

// there is only 16k available in the memory segment
// we use it all

#define QSIZE   (16384)
#define QFULL   (16300)
#define QREFILL (16000)
static char queue[QSIZE] __attribute__((section("AHBSRAM0")));
volatile int qhead, qtail = 0;
volatile int busy_flag = 0;
volatile int qcount = 0;
DigitalOut ioBusy(p15);

void queueInit(void) {
    ioBusy = 1;
}

// this is called from an interrupt routine

void enqueue(unsigned char byte)
{
    int temp;
   
    if ( (temp = ((qtail+1) & (QSIZE-1))) == qhead)
        ;    // we have a problem but don't update qtail
    else {
        qtail = temp;
        queue[qtail] = byte;
        qcount++;
    }
    if (qcount > QFULL) {
        busy_flag = 1;
        ioBusy = 0;
    }
}

unsigned char dequeue(void)
{
    unsigned char temp;
   
    if (qhead == qtail) // empty
        return 0;
    else {
        qhead = (qhead + 1) & (QSIZE - 1);
        temp  = queue[qhead];
        __disable_irq();
        if ((busy_flag == 1) && (qcount < QREFILL)) {
            busy_flag = 0;
            ioBusy = 1;
        }
        qcount--; // protect this code!
        __enable_irq();
        return temp;
    }
}
[/font]

Pretty simple and intuitive.  In std:: all of the queue operations are hidden.  We have to take it on faith that the STL works will all data types although, in this case, the queue has only unsigned char.

[C]

I have seen great pascal source.
A large part that is was great was due to the great compiler,

I do not consider FREEPASCAL great for many reasons.
The source is a mess.
The compiler does not prove the source code is correct,
There are many, many more.

A good foundation keeps paying back the higher or larger you get.
The better a compiler gets, the better the compiler can get.
If you keep fixing the low level problem areas in the compiler, then all programs using that compiler gain.

Embedded and hardware only need a few extensions for pascal to be great.
Same it true for system programming & threads. As a programmer you just need access to some low level details.

Oberon (programming language) actually has fewer syntax rules then Pascal and yet is more powerful.

So the only reason to use P4 is so you have a compiler that can build the better compiler.

The code generator for the pascal I used back then generated very good 68000 code. An assembly language programmer would be hard pressed to do better it was that good.
When HP used it internally and had the source, little reason existed not to make it better.

Think of the foundation. Code generation is just picking the best of many ways the same code could be written.
One place you want speed, another space or something else.

In addition when you just had to have assembly for some reason very little assembly had to be written.

The big problem for higher level languages is the very poor text editor. As a programmer you need to see many areas of code at same time. The compiler knows how to find the areas but the editor is often guessing if doing that much.

Look at some simple facts.
A compiler can create a better compiler.
Source syntax is just one part of language.

Want to get how many DOT Net compilers can have many languages as source? But this also highlights a problem. If the compiler is not written in the same language it might not gain as foundation improves.
Part of the foundation is the base types.
Part of the foundation is the many ways arrays can be created.

Then you have simple concepts that need added syntax.

Interrupt, Event, ERROR, Threads, Programs, Modules, Classes. Operators.
It you think of foundation these are all just versions of a C function call with a more readable name. And due to that name can have additional rules checking the code.

For the record, C11 introduces thread support.

Shows sad state of hacks and patches being done to C.
This existed in the pascal I used in the 1980's.

[nctnico]

IMHO the problem with Pascal is that it has been designed to teach structured programming and not for actual work. I've used Pascal in the past but it just doesn't fit very well with how software is developed. Pascal requires to fix the structure of a program at the beginning and not change it later on. Especially in an agile programming environment (where the structure of a program may change at any time) having a rigid structure just doesn't work.

[C]

rstofer

Might want to think about your code some.
I would say a queue that disables all interrupts is not good code.
But of course I use to work with CPU's that could safely handle an interrupt happing while in an interrupt.

So stating the facts
1. Interrupt in, main code out.
2. main code in, interrupt out.
3. Interrupt#x in, Interrupt#y out.

Most can be fixed by only one side updating a value.
Some can be fixed by knowing that CPU will read x bits as a chunk.
For chunks larger then CPU safe chunk size. A reread the value flag can work wonders.
With less messing with interrupts, you can have less bugs to find.
 

[C]

nctnico

Fixed sizes was true for the educational language compiler.

The compiler I used allowed dynamic creation and deletion.
Little changed in the source code.
From memory two functions
ByteSizeOf(___) and BitSizeOF(___)

With a New that allowed creation size.

Remember that a Pascal that is used to create Systems & Compilers has many needs not in the educational version.
These can be added and still work with Pascal syntax rules.

[rstofer]

In my play with std::queue I came up with a question:  Is it interrupt safe?  There's a bit of a problem messing around with the pointers while interrupts are enabled (assuming push() is coming from the ISR).  Yes, I can write even more code and put a mutex around the pop() operation but it just brings back the same issue that was solved in C.

And, yes, Pascal was originally a teaching language.  The book "Algorithms + Data Structures = Programs" is one of my favorites.  There's a lot of CS education in that little volume.

I didn't realize that Niklaus Wirth ported Oberon to the ARM:
https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon.ARM.Compiler.pdf

A commercial version is here:
http://www.astrobe.com/default.htm

I have been tempted to buy it just to play with the language.

[technix]

rstofer

Might want to think about your code some.
I would say a queue that disables all interrupts is not good code.
But of course I use to work with CPU's that could safely handle an interrupt happing while in an interrupt.

So stating the facts
1. Interrupt in, main code out.
2. main code in, interrupt out.
3. Interrupt#x in, Interrupt#y out.

Most can be fixed by only one side updating a value.
Some can be fixed by knowing that CPU will read x bits as a chunk.
For chunks larger then CPU safe chunk size. A reread the value flag can work wonders.
With less messing with interrupts, you can have less bugs to find.

I do agree that code smells a little. No two interrupt should have access to the same memory, and I doubt there exists a processor architecture that allows an interrupt to interrupt itself. When you split interrupts and overall code into well defined objects, the necessity of disabling IRQ's just goes away, since no two objects share memory anymore.

BTW, when I speak of objects, I am referring to object-oriented programming, not a specific language. You can do OOP in plain C just fine.

As of C, AFAIK most recent additions are hosted environment only or are standard library imports (C11 threads? That minus thread-local storage is really just an import from POSIX threads which is already standardized and very common in hosted environments. Thread-local storage is an import from C++.) The language itself, OTOH, is stable.

[rstofer]

I got the quotes all messed up so I'll just write my stuff:

I'm pretty sure I need a hardware interrupt on an SPI channel running at 11 MHz.  I sure couldn't use polling because the CPU is bogged down doing the real work.

I'm pretty sure there is only 1 interrupt and it is the SPI Slave Receive ISR.  The shared object is the qcount.  I need to guarantee atomic increment/decrement.

There is always a problem with queue code if one end is in an ISR.  You can't compare pointers if one is changing out from under the evaluation.  Yes, multiple evaluations is one way to handle it but not the only way.  If the results disagree, you wind up making the comparison 3 times.  Fine, but you have to get it done pretty quick, those bits are flying down the wire and they aren't going to wait around.  DMA would work well...  In fact, if I ever revisit the project, I might consider that.  As long as I can guarantee there won't be any wrap-around.

It is possible to disable individual interrupts, and it's a good idea, but there is only one interrupt in the entire project, why bother playing with the NVIC?  Set it and forget it!

BTW:  The IBM 1130 had no instructions to enable/disable interrupts.

[andyturk]

In C it looks like this:

Code: [Select]

// a bunch of code

Pretty simple and intuitive.  In std:: all of the queue operations are hidden.  We have to take it on faith that the STL works will all data types although, in this case, the queue has only unsigned char.

It's more likely that the STL implementation is correct than any personal equivalent we might write. I'm not knocking your code specifically, but STL has gotten a great deal of exposure and most of the kinks have (hopefully) been worked out.

Queues and FIFOs are an interesting thing in the embedded world. A friend of mine once observed, "Seems like every firmware engineer has their own FIFO implementation. Why is that?"    You've got one. I've got one in C++ too (and it's not STL). Most large embedded codebases seem to have at least one FIFO implementation buried somewhere.

I think the fact that there are so many different versions of the same idea comes from one of C's deficiencies: it's not easy to reason about a piece of code and know how it will perform generally. You've got to test it in your own environment to be sure that it works for what you need it to do.

The queue implementation you posted has architecture-specific calls that are probably important, but might not be available on my system. There are hard coded sizes, linker directives and various things in there that might break if I try to modify it casually. E.g., what if I want my queue to be only 100 elements deep? What if I want more than one queue?

I don't agree with tggzzz on much (in this thread), but he's very correct in pointing out that straight C code is anything but simple.

[C]

 technix

I doubt there exists a processor architecture that allows an interrupt to interrupt itself.

You can do this easy with most CPU's
The old Z80 makes this easy if it's wanted.
You can have a section of high speed interrupt code and slower hanging off the same interrupt.
For Z80 you just do a Push of slower code start point.
Fast returns to slower which returns to main.

The 68000 allowed interrupts to interrupt interrupt code.
With 68000 you have interrupt levels.

rstofer
The best reference to pascal I have found is
"The Pascal Handbook" by Jacques Tiberghien SYBEX

HP had a special print run that added the "railroad tracks" for HP Pascal.

Very little syntax changed to compile system code.
Most of the time was just a RULE change.
Often the compiler switch that enabled MODCAL (the system compiler flag) allowed access to compiler internal data.

With System compiler flag enabled you had control of everything in a safe way. It really just made possible lower level details that is normally hidden in compiler output.

As for Oberon, to truly make use of it you need compiler source.

For example, In great compiler source, it is quick to change the pointer size to match the system. In fact a compiler that can compile for many processors changes this based on CPU type.

Like all things, if you start out with a great foundation then change is easy. If you start out locked into the idea of "ONE" then change is hard.

You might want to check out
"GitHub - vishaps/voc: vishap oberon compiler"
Oberon source in and C source out.

There are also come compilers that use DOT NET as foundation.

Think about something simple.
PCODE is often seen as bad. A version or minor change is replace the interpreter with calls.

You often hear that "RISC" CPU's are great. This greatness is inside the CPU, Outside the memory bus takes a hit which is already at limits. So you add cache to make the big problem smaller. Your code generation becomes more complicated as you need to stay in cache to gain benefit.

Now think of a Risc CPU running PCODE. Code is already small and a cache miss could be pulling higher level code.
The net result is that it could be faster running PCODE or called code then native machine code.
A CSC CPU could be built with microcode & Risc and lower memory use.

Most only state the best part of idea where total system is what counts.

build your fifo from a circle buffer then you can have side separation if you are careful of when you access values.

Note that C is well known for reordering code which can readily break code that needs a safe order.

[rstofer]

Well, the reason there are so many FIFOs is the need for elasticity.  Particularly on input, it may not be possible for the CPU to use polling.  For output, it is simply more efficient to stuff the data in a queue and let the IO handler deal with it.

The same project uses an array of array of chars to build up TCP packets.  Each array of chars is filled to somewhere around 500 bytes (the actual length depends on the incoming text so there is room for a little extra) and the outer array is treated as a queue.  Once the packet is filled, it is marked as available for the TCP/IP stack.  This structure uses the other 16k buffer.

There's a lot going on in the program:  An 8 bit code comes in and the bit pattern is actually a CalComp 1627 step command.  There is one byte per step, 100 steps per inch.  I accumulate similar steps because I will eventually convert the total number of similar steps to an HPGL sentence that makes the entire vector in one command.  I have to accumulate commands in the pen-up position but I don't have to write them until a pen-down command comes along.  These HPGL sentences are stuffed into the output array and ultimately drive the LaserJet.

It works well!  And, yes, it is non-portable.  Most embedded projects are!  At some point you just have to get down to the hardware level.

Why?  Well, I have an FPGA implementation of the IBM1130 and the real machine had the CalComp plotter.  It was a great tool for a young fellow wandering through EE school while working for a living at a company that allowed me unlimited access.

[rstofer]

It's more likely that the STL implementation is correct than any personal equivalent we might write. I'm not knocking your code specifically, but STL has gotten a great deal of exposure and most of the kinks have (hopefully) been worked out.

Yes, it will be very well developed.  It's the assumptions and side effects I worry about.  Under the conditions for which it is applicable, it will work perfectly.  Under 'my' conditions, well, I wonder.  So, test it!  When I go out on the Interwebs and find out that containers aren't necessarily interrupt safe, I have to wonder how they are applied.  Clearly they must work in that environment, it is just a matter of figuring out how to do it.  Somebody knows how!

[tggzzz]

Queues and FIFOs are an interesting thing in the embedded world. A friend of mine once observed, "Seems like every firmware engineer has their own FIFO implementation. Why is that?"    You've got one. I've got one in C++ too (and it's not STL). Most large embedded codebases seem to have at least one FIFO implementation buried somewhere.

Just so. The number of times that wheel has been (poorly/incorrectly/incompatibly) reimplemented is ridiculous.

C is touted as a language that is good for embedded systems work. Given that, I find it astounding that as late as 2004 (and probably after 2011) it was impossible to write queues for multithreaded environments[1]. Even Java was better than that after a mere couple of years (courtesy of Doug Lea and a sound foundation) rather than C's working lifetime!

But then the poor C/C++ committee was (in the early 90s) tied in knots for years about whether "casting away constness" was mandatory/forbidden (there are good arguments for either!). And there are too many other such examples, e.g. whether the template language is Turing complete (it is, but the committee denied it until someone rubbed their faces in it).

[1] Hans Boehm, and he wasn't the first to point that out http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf

I don't agree with tggzzz on much (in this thread), but he's very correct in pointing out that straight C code is anything but simple.

You're forgiven

[tggzzz]

Under 'my' conditions, well, I wonder.  So, test it!

There are old engineering maxims: "you can't test quality into a product" and "testing can only demnostrate faults, it cannot demonstrate absence of faults".

Why is that so hard for software weenies to comprehend?

[tggzzz]

Well, the reason there are so many FIFOs is the need for elasticity.  Particularly on input, it may not be possible for the CPU to use polling.  For output, it is simply more efficient to stuff the data in a queue and let the IO handler deal with it.

Well, no. That's a valid argument as to why there are so many instances of FIFOs, but not why there are so many implementations of FIFOs.