A C++ wrapper for MPS430?

[abc 5]

I may be trying to bring a foreign way of thinking into an area where perhaps there is no need for it, instead of rewiring my brain to adapt to the new field. Having said that, I can't be alone.. there have to be other Java transplants and such, trying to shorten their learning curve in the microcontroller world, even at a little run-time overhead, which some applications (like mine) should be able to afford.

 

It would help me enormously if there was a high-level, OO library that would abstract away much of the complexities of MSP430, "making simple things easy and complex things possible". I would love to see a Timer class, a LowPowerMode class, a Port class, a Pin class, an Interrupt class, etc.

 

How expensive would that be? My guess is, perhaps not very expensive, with methods inlined and then optimized away by a compiler.  

 

Is it doable? Has it been done? Is there a need for it?

 

Energia seems to be one such library, and I love it. Though Energia appears to be 1) more than a run-time library, 2)  so portable it does not seem to provide integrated fine-grained control over MSP430-specific features (which does not appear to be a big problem due to its ease of integration with custom C/asm code).

[wasson65 16]

Here is something that might be more up your alley - Python for Microcontrollers, not sure how much pythonic OO it actually does:

 

http://www.mpyprojects.com/software/mpy-language/

 

Frankly, I rather enjoy the extreme simplicity of fiddling with bits.  I do all my 430 programming in assembly.  It's comforting in a way....

 

Welcome aboard!

[Fred 453]

I do all my 430 programming in assembly.

If I did all my programming in assembly, I'd soon end up looking like your avatar!

[pabigot 355]

@@Rickta59 has a C++ wrapper that's discussed here.

 

Cortex-M is a much more orthogonal architecture, even across vendors, so if I were to do a C++ peripheral abstraction approach I'd target it. My in-development Cortex-M work will support C++ but my initial attempts at abstraction suggest the language is not quite ready for how I want to use it (at a minimum C++14's extensions to constexpr will be necessary for high performance).