dead programming languages

That's the way some chips come. I'd expect that some code changes will be necessary when a new ADC or DAC is installed.

One ADC that we use has a bit in a register that sets whether the SPI interface clocks on the rising or falling edge.

These kind of abstractions rarely have any runtime costs associated with them, modern compilers are very intelligent. If all that's really happening is you're doing elementary operations with the literal types then that's what it'll compile to, even on the lowest optimization settings.

Indeed, that's how most I have seen come, too. But he is right of course, put the ADC left most and you just use as an integer of that size without even knowing the number of real bits.

C++11 and later include an optional type in <cstdint> called "uintptr_t" which can hold a data pointer, and is what you'd reinterpret_cast a data pointer to if you needed to do something unusual with it

It's not super-uncommon for games that are otherwise decent to get released to Steam pretty poorly-optimized.

Then some professional gamer with absolute top-of-the-line hardware with a thousand people watching is laughing at your game stutter and jerk. It's not good advertising..

On a Raspberry Pi Pico? I think not.

In a hard embedded product, what do you do when a range check fails?

Programmers typically can't estimate run times for chunks of their code. They typically guess pessimistically, by roughly 10:1.

There's nothing unreasonable about an IRQ doing a decent amount of i/o and signal processing on a small ARM at 100 KHz, if programmed in bare c.

Lots of CPUs help.

We don't need no stinkin' OS!

I feel like once a "hard embedded" product has enough degrees of freedom in its inputs to make range check failures a likely occurrence, one isn't really designing a "hard embedded" thing anymore.

I'm curious what kind of designs these are where people have to do so many range checks, like I've rarely been concerned a 10 bit i2c ADC is ever going to accidentally return a value of 1024 or something and then need to accommodate that possibility in my code.

He certainly did. He was a huge proponent. He used to post here occasionally, as I am sure you recall.

I use Tim Edward's XCircuit to do drawings for documents, including schematics. It is 100% postscript; I never use the spice aspect of it. Once the documents are finally outputted to pdf, text search works on the drawings too, not just the body text. I mean, I can search for "C66" and it will find it in the body *and* in the schematic drawing. Plus, the drawings are all vector graphics, where zooming never causes pixelation.

ok. Enough of my OT words.

Using modern C++ sure helps a lot with crap like fence post errors. Direct access to raw arrays is a super-privileged operation! Need-to-know basis. Read-only consumers get iterators they don't get to muck with actual data. And iterators are easy to do loops, etc. over they know their own size.

Let's keep dark-ages stuff like using raw pointers to structures as function arguments to a minimum, please. Not entirely unavoidable in bare-metal programming but can at least largely be delegated to the internal logic of containers and allocators.

Relevant Dr. McCoy quote:

As I say, a requirement for more complex IO (especially where there could be some kind of malevolent actor) tends to be the point where I figure some kind of OS or thread-manager is required, even a lightweight one, so there's someplace to fail to.

Like if I wanted to build a device that had some hard realtime requirement but was also supposed to take user input over HTTP I wouldn't try to write my own secure API/input sanitizer, you know? Run embedded Linux and leave that stuff to the professionals who write libraries for it.

Static assertions are great, I don't find much use for runtime checks in e.g. single-threaded 8 bit applications, so I don't tend to miss that they're not available in the first place much.

Guess I'm fortunate that I haven't had to design anything mission-critical enough that it has to compensate for flaws in the compiler, or bugs/damage to the hardware itself.

I'm sure there's software that does checksums and comparisons of the stack and every other bit of data it seems productive to monitor, on every main loop iteration, just to be on the safe side.

What to do when a sensor is broken and is returning unexpected values seems like a design problem, but the context of "range checking" in the original post was about array access.

I think a program that behaved _incorrectly_ when an e.g. accelerator was broken might be a common bug, but who writes code such that a faulty accelerometer can smash the stack?!

Using raw pointers to arrays, rather

New programming languages are invented every day, claiming to solve the many problems of all prior languages. The vast majority of these languages vanish without a trace within a few years, and some hang on for years in academia, as they are really vehicles for trying out various theories then under consideration. (Likewise, operating systems.)

There are about 9,000 programming languages in existence.

.

Mostly forgotten:

.

Filtering the TIOBE list to remove languages unsuited to embedded hardware uses, we end up with C and C++, and assembler.

Notable that C and C++ have been around, and have gone through many revisions and updates, yielding mature standards with large ecosystems.

Turned around, any language that is not decades old and now in wide use is unlikely to endure. The first C version was released in 1972, and the first C++ in 1983.

More generally, if your intent is to develop a product, and maintain it through its product lifecycle, the issues are more practical than theoretical.

The most important issue for development is the general availability of the entire needed ecosystem, including toolchain (compilers, debuggers, et al), operating-system interfaces, tracers, kernel debuggers, et al, a community of interest, and customer support.

The next issue is availability of programmers for the chosen language and ecosystem, covering not just the initial team but also to cover the usual rates of employee turnover to maintain full staffing over time. Which brings us to the next issue:

How widely is this toolchain supported? Is it just one company, so there will be a forced redesign, recode in a different language, and reimplementation of hardware when that company triples their prices and ultimately fails, or decides to leave this business for greener pastures, or whatever. Which happens all the time.

So, there must be multiple entities supporting the chosen ecosystem. Historically, open-source ecosystems have fared better here.

If one does need to change ecosystems, how hard will it be? If the programming language is widely supported, then while a lot of work, adapting existing code to the new toolchain is practical, while rewriting an entire codebase in a different language is usually totally impractical - so that existing code is a dead loss.

For embedded realtime uses, the list of suitable languages and ecosystems is relatively short. Assembly code is excluded, because going from one processor type to another to another is basically a full rewrite.

So we are basically left with C and C++ in their various dialects and forms.

The basic difference is that C is smaller, simpler, and faster than C++, and far more suited to direct control of hardware.

In the large radars of my experience, we use both. Stuff close to hardware is in C (in turn controlling hardware using VHDL of some kind), and the millions of lines of application code are in C++.

So, my vote would be plain ANSI C. Most C++ compilers can handle C as well, and there are also C-specific compilers and toolchains.

Joe Gwinn

In my world (safety critical sw systems, e.g. flight control, medical), Ada is still used - probably on life support tho. More usage in Europe than USA. C is out and out dangerous in this environment even when standards such as MISRA-C are used.

What do you me by 'coding hard embedded products'? you mean 'hard real-time embedded systems' eg. system timing and thread scheduling must be completely deterministic?

My people document FPGA registers in HTML. I think that's weird.

I mean an electronic instrument or controller that has a uP inside. It will typically have an i/o process, hard real-time, and a user interface and communications side that is a lot softer.

Things like this:

A few run Linux, but a typical small box doesn't have an OS or threads as such. The ones we do lately have a dual-core ARM, one for the process i/o and control loops, and one for the softer side, the user interface and communications stuff. Really intense stuff gets done in the FPGA. Usually no OS at all, just some state machines and maybe one periodic IRQ thing.

Ultimately we could have a CPU per process and not task switch or even interrupt.

Why on earth are you answering my statement about *units conversion* with a rant about integer representations and pointer casts.

Don, sometimes you're a master of irrelevance.

CH

If you know COBOL then the US IRS department may have work for you. Apparently that is the language for their tax system...

Is 2036 going to be a problem? They want to phase COBOL out by 2030.

John :-#)#

what is two years between friends...(thanks!)

John :-#)#

Sure, there are all sorts of good reasons to use strong types beyond just enforcing unit conversions, it also makes for self-documenting code. A contrived example is:

class Rectangle { public: Rectangle(float width, float height); .... };

But then at the call site auto r = Rectangle(4, 5);

Someone else looks at that will have to go back to the .h file to see what order the parameters are. You could instead have

class Rectangle { public: Rectangle(Width width, Height height); .... };

and then at the call site is written:

auto rectangle = Rectangle{Width{4}, Height{5}};

So it's more clear what's going on.