High Level code on micro-controllers

[Crazy_Engineer]

I learned to code in assembly and eventually moved up to C.  In the last couple of years I have noticed that most IDEs support C++, and RTOS integration.  With ram and flash being rather cheap now days, the overhead from the abstraction is less of a concern and I have been wondering if it is time move up.  What are your thoughts on using "higher level" object oriented code and possibly a real time operating system vs plain old C?   

[nctnico]

Getting Lua going on a microcontroller is high on my wish list.

[C]

Not all higher level abstraction costs in code space.
Often the higher level is just better source checking or a different way to do same thing.

If every thing is an integer then you lose the option of compiler throwing an error when you try to combine a temperature integer & something else. Checks like these costs Source space but not code space.

Often a different way to do same thing can let the compiler do a better job.
When you read a "C" program you see "DEFINE" used all over the place.
Think of foundation of "DEFINE". Read source text and replace matching text with new text. Compiler can not check "DEFINE" only the replaced text for proper syntax.
Remember that the compiler writer has to allow for all possible valid uses of "DEFINE".
For example if you use "DEFINE" to work around CPU differences you have a problem. To verify your code you need to recompile for each CPU possible in the "DEFINE" to check for errors.
If the higher level language allows, you could just have a list of CPU's and the compiler check all for errors.

You do not need a higher level of abstraction if the language allows same result with out abstraction.

Think back when each printer needed a different driver due to code sequence to do BOLD for example.
You just need to swap functions based on what printer.

Back in the 70's, I worked with what you would call and embedded system. Code changes happened often and happened while the program was running. Proper language can make this very easy.

Think about "C", will you get an error if you do a dumb think and connect two RTOS things?
Not hard to have error checking for code separation if the language defines such a thing.
"C" gives you great power, but makes you check for errors that are simple with proper language.

Today a language should know what an event is and help with program checks.

So lots of things can become something the compiler can check if the compiler knows what it is and their for what rules to use in checking.
In the process you have to type/input more text but gain in better compiler checking which saves debug time and finds errors better.

Think of what an abstraction is. A way of hiding needed facts from something.

No need to hide something if you can state the facts.

[free_electron]

Getting Lua going on a microcontroller is high on my wish list.

has been done. stm32 can do it. so can esp8266 ....

for many processor cores :
http://www.eluaproject.net/overview/status

for ESP8266:
https://nodemcu-build.com/

ive been running ESP8266 without problems

[Crazy_Engineer]

Abstracting through macros is something I do often.  Indeed many of my projects start off with a long list of macros that relieve me from having to know what pin an input or output is assigned to.  Unfortunately  the C pre-processor has its limits which I have run into when trying to make driver libraries that function across a family of chips.  The driver library in question was for an LCD screen for msp430 series processors.   When writing it there were several times that I thought "A class would probably be helpful here."; but I was dissuaded by the resource inefficiency horror stories that came from my peers. 

[technix]

AFAIK most RTOS is written in C. As of object oriented programming you can do it in plain C too. (If you really think about it the stdio.h filesystem access API is really a FILE class and its methods.)

Personally I don't use a lot of C++ on microcontrollers. AFAIK smaller chips like 8051, STM8 as well as 8-bit and 16-bit PIC don't even support C++ (there was a patchset for xc16 that adds C++ support, but that was flaky AF and abandoned.) OTOH that object-oriented C is very widely used across my own code.

When writing it there were several times that I thought "A class would probably be helpful here."; but I was dissuaded by the resource inefficiency horror stories that came from my peers. 

You can do classes and OOP in C. Ever heard of the concept "callback function pointers?"

[Crazy_Engineer]

You can do classes and OOP in C. Ever heard of the concept "callback function pointers?"

Looks like I have some reading to do.  Thanks.

[technix]

You can do classes and OOP in C. Ever heard of the concept "callback function pointers?"

Looks like I have some reading to do.  Thanks.

From what I see in that book, that fellow took an approach fairly similar to the Objective-C runtime though.

[nctnico]

Getting Lua going on a microcontroller is high on my wish list.

has been done. stm32 can do it. so can esp8266 ....

for many processor cores :
http://www.eluaproject.net/overview/status

Unfortunately the Eluaproject needs a lot of work to get some decent platform support for  NXP's LPC devices.

[abraxa]

Don't forget https://github.com/micropython/micropython/wiki

[legacy]

@C
100++/100 agree with you

[legacy]

#define pin instead of typedef enum?

[andyturk]

Personally I don't use a lot of C++ on microcontrollers. AFAIK smaller chips like 8051, STM8 as well as 8-bit and 16-bit PIC don't even support C++ (there was a patchset for xc16 that adds C++ support, but that was flaky AF and abandoned.)

IMO, the lack of a quality C++ compiler is a good reason to avoid a particular architecture. (if you have the choice, of course).

OTOH that object-oriented C is very widely used across my own code.

Uh huh. 

[legacy]

Unfortunately the Eluaproject needs a lot of work to get some decent platform support for  NXP's LPC devices.

yup, and a bootstrapper 

[obiwanjacobi]

I think there are certain types of MCU devices that can be considered suitable for moving the level op abstraction up a bit. But it all starts with a good compiler. I would not go with interpreted languages such a Lua (which sucks imo). Dicking around with C can do OO too is all very well when you're on a 8051 (or a small AVR) and you have no other choice, but not for larger teams with mixed skill sets.

Ask yourself what parts of the code need to be close to the metal because of performance or efficiency of interfacing. The process flow, driving UI and higher order logic should be readable (and maintainable) code foremost.

Personally I think (C++ 20) meta programming is a very interesting topic for the embedded domain, but here again it's about the compiler. Also a higher level of abstraction may not need a new language but merely a different mindset and design. I (usually) cringe when I see most C library API designs where to my mind all the wrong choices of separation of concerns and single responsibilities have been made. Designing good library APIs is hard.

So yes, it is definitely time to move to a higher level, but not necessary time for a new language and certainly not an interpreted language (unless you aim to run user/custom scripts on the device itself).

[technix]

(unless you aim to run user/custom scripts on the device itself).

Even if I plan to run user scripts, those are always native code loaded into the RAM. Whatever language you are using, compile it down to native code and link against the symbol list of the main application please.

[ajb]

Unfortunately  the C pre-processor has its limits which I have run into when trying to make driver libraries that function across a family of chips.  The driver library in question was for an LCD screen for msp430 series processors.   When writing it there were several times that I thought "A class would probably be helpful here."; but I was dissuaded by the resource inefficiency horror stories that came from my peers.

For cross-platform mid- or high-level libraries, using layers of functions is a better approach than macros.  You write a layer of short, simple low-level functions that interface with hardware (setting modes, starting hardware transfers, handling events, etc), then a layer of functions that sit above that to handle protocol level stuff (sending/receiving via buffers, etc).  Depending on the application, where you delineate the two layers may shift, but when moving to a new platform you only need to rewrite the low level functions.  For simple things like basic UARTs you COULD do the lower level with macros, but functions are more versatile, and all things being equal an inlined function won't produce any extra overhead.

If you wanted to be more objecty about it, you could also wrap up a whole interface as a struct containing a reference to the hardware instance and function pointers to your low-level code.  Your higher-level functions would take such a struct as an argument, and then as needed extract the hardware instance and pointer to the appropriate function and pass the former to the latter (along with whatever other parameters are needed).

[Yansi]

Don't you rather need a quad core ARM written in Java to blink the LED? 

I do not have nothing against high level code, any kind of a complex application will certainly need one. However LUA, Java, Python, etc is not a high level code, that is highly resource hungry garbage, that should be kept out of them, even out of any PC, especially Java. I hate that junk!

[SiliconWizard]

Don't you rather need a quad core ARM written in Java to blink the LED? 

 

I do not have nothing against high level code, any kind of a complex application will certainly need one. However LUA, Java, Python, etc is not a high level code, that is highly resource hungry garbage, that should be kept out of them, even out of any PC, especially Java. I hate that junk!

Ditto.

A lot of people, especially in the purely software world, confuse high-level languages with the existence of a monster (and unavoidable) runtime accompanied with a lazy memory model.
And if you look closely, what a lot of those people are after are actually those gigantic runtimes and libraries, not necessarily the language constructs themselves.

[obiwanjacobi]

Don't you rather need a quad core ARM written in Java to blink the LED? 

Yes! Because the Quad ARM costs less than the other less capable parts you might consider and I am done in 5 seconds because of the higher abstraction level. My solution will costs a tenth of your custom optimized one.

I am exaggerating to make a point here, but the question is: does it matter it is not super lean when the price is significantly lower. Software development hours are not cheap. You could buy a lot of hardware for that. Of course there are specs that may make you to choose otherwise (power, performance etc) but still, the hardware is capable.

[tggzzz]

A lot of people, especially in the purely software world, confuse high-level languages with the existence of a monster (and unavoidable) runtime accompanied with a lazy memory model.
And if you look closely, what a lot of those people are after are actually those gigantic runtimes and libraries, not necessarily the language constructs themselves.

Yes indeed; just so.

[technix]

Just an information drop: there is this thing called gnustep-libobjc2-baremetal. Yes this is about that odd language Objective-C,

Objective-C (yes the old Apple language before Swift,) especially the more modern Swift-compatible-Objective-C, has every feature Java has, but it does not rely on a huge runtime library for everything since it got rid of that virtual machine (uses native code instead) and the garbage collector (uses reference counting instead, with static code analysis used to insert 99.9% of the actual reference counting code at compile time through ARC.) The compiler also enforces a fairly rigid naming convention and class contract, throw tantrums if you deviate even a little from it. The mandatory runtime library itself, libobjc2, is no larger than libstdc++, and for the much larger but non mandatory "class library" Foundation.framework you can cherry pick classes and algorithms you actually need (or allow the linker to throw away unused classes and methods) to reduce code size significantly.

On a language feature level Swift is equivalent to Objective-C but with a more streamlined and concise syntax (since Objective-C have to maintain compatibility to C, being a strict superset of it.) However there is no ready to use libswift mandatory runtime library (Swift's version of libobjc2) that suits embedded development.

[technix]

Don't you rather need a quad core ARM written in Java to blink the LED? 

Yes! Because the Quad ARM costs less than the other less capable parts you might consider and I am done in 5 seconds because of the higher abstraction level. My solution will costs a tenth of your custom optimized one.

I am exaggerating to make a point here, but the question is: does it matter it is not super lean when the price is significantly lower. Software development hours are not cheap. You could buy a lot of hardware for that. Of course there are specs that may make you to choose otherwise (power, performance etc) but still, the hardware is capable.

Now your final product costs 40x more than your competitor's to make. Maybe they have to code on a lower level of abstraction for a week, but due to the vastly simpler hardware and the sheer volume they can churn out so much more products per unit cost the R&D cost per product is next to nothing. This, and overworkng the engineers to death with their creativity suppressed and punished, is how Chinese manufacturers can pump out so many cheap items.

[Crazy_Engineer]

Ask yourself what parts of the code need to be close to the metal because of performance or efficiency of interfacing. The process flow, driving UI and higher order logic should be readable (and maintainable) code foremost.
.....
Personally I think (C++ 20) meta programming is a very interesting topic for the embedded domain, but here again it's about the compiler. Also a higher level of abstraction may not need a new language but merely a different mindset and design.

Interesting points.  For me, I notice that my code becomes difficult to maintain once the program gets beyond a certain length; one of the main reasons I was inquiring about other languages.   It may be I need to more carefully plan, compartmentalize, and document my longer projects.   Speaking of which, does anyone know of any good resources on planning out embedded coding projects?

[tggzzz]

Ask yourself what parts of the code need to be close to the metal because of performance or efficiency of interfacing. The process flow, driving UI and higher order logic should be readable (and maintainable) code foremost.
.....
Personally I think (C++ 20) meta programming is a very interesting topic for the embedded domain, but here again it's about the compiler. Also a higher level of abstraction may not need a new language but merely a different mindset and design.

Interesting points.  For me, I notice that my code becomes difficult to maintain once the program gets beyond a certain length; one of the main reasons I was inquiring about other languages.   It may be I need to more carefully plan, compartmentalize, and document my longer projects.   Speaking of which, does anyone know of any good resources on planning out embedded coding projects?

The best resources and tools are brainpower, good taste, appropriate design patterns, time, and refactoring. Purchased tools can only support those, they can't ensure success.

If you don't already know about it, strongly consider event-driven programming in conjunction with explicit FSM design patterns (i.e. not horrific ad-hoc deeply nested case statements!). Then you can cleanly separate generation of events from what reaction occurs as a result of an event. Test each event generation and reaction in isolation, then when working combine them. Keep a log of events and states, so that when (not if) things don't work as you expected, you can figure out how you got to that point!

Harel statecharts are a good starting point, a.k.a. UML state diagrams.