C++ hardware library for (small) 32-bit micro-controllers

You mean that it is a problem that you can't see which parts use how much ROM?

I don't see why a templatetized implementation could not do that too?

Would it be a problem to re-compile?

I started on such a class/object/vtable approach 2 years ago, but found a number of problems:

- it is slow for very simple operations

- it hinders optimization

- it requires an object, which takes RAM, of which there is preciously little on small micro-controllers

- compilers seem to be bad at eliminating virtual functions that are never used

About optimization and speed: suppose I have a LED on a certain pin:

typedef gpio_1_0 LED; LED::set( 0 ); // LED off

OOPs, the LED is connected to Vcc, not to ground! So I change this to

typedef invert< gpio_1_0 > LED; LED::set( 0 ); // LED off

With the template approach the second version generates exactly the same amount of code, and is exactly as fast, as the first version.


Reply to
Wouter van Ooijen
Loading thread data ...

Hey gasbag Which functions are thread safe? How about interrupt safe?

Reply to
Vladimir Vassilevsky

Aw, c'mon... I just *know* you love those (lethal) 3 ft icicles!

Yup. I miss *good* apples.

I always enjoyed clearing the driveway/sidewalk with the snow blower. Of course, as I work at home, I never had to *go* anywhere *in* the snow -- unless I wanted to do so. That "option" makes the world of difference in how you regard the cold ;-)

Yes, but inertia can be great -- if you are aware of it! It tells you that your thinking "may be in a rut" and, if you're "aware", challenges you to challenge yourself, more.

Some "habits" are good and helpful. Others can be restrictive and crippling.

Reply to
Don Y

Given that the same code-base compiled on more than twenty different vendor's C++ compilers, just one of those being different versions of gcc on a further twenty different platforms (16, 32 and 64 bit) I'd guess it wouldn't be hard at all to get it building again. We had all our own portability infrastructure (for build and runtime) and didn't use any templates nor STL (which were broken or unimplemented on some compilers back then). But I don't have time or inclination to do it.

Of course, the result would only support the GUI widgets that were current at the time - newer ones would require new work. These days, you'd rip out the Java-esque compiler/interpreter and put the V8 Javascript engine in instead, too.

Clifford Heath.

Reply to
Clifford Heath

Who are you adressing? I did not notice anyone with that name in the discussion.


Reply to
Wouter van Ooijen

Pot, kettle?

Please don't snip attributions!

Ian Collins
Reply to
Ian Collins

Don't feed the troll!

Reply to
Tom Gardner

Yep. It probably depends a lot on the toolchain and its configuration, but having two-pass template compilation and linkonce sections doesn't actually make writing linker script files easier unless you can get the compiler to inline everything.

It could do that, but assuming that the RPC operation is more than just dereference-a-pointer-and-set-a-bit, it would risk duplicating more code, see below.

Yes. Our software usually has to run on half a dozen board versions at least.

Now imagine you have a flash driver, and want do drive two flashes.

typedef spi_flash Left_Flash; typedef spi_flash Right_Flash;

This would duplicate the flash driver. Sure, each one would have incredible speed. I decided to rather pay the virtual dispatch than the code space, because speed is good enough for the things I do. Your mileage will probably vary.


Reply to
Stefan Reuther

When the code is small and/or has substantial possibility for optimization due to inlining the template approach wins. When the code is large and needs to be used with two or more sets of pins (or run-time configurable pins or other resources) the OO approach wins.

Inbetween the contest is on. Hence my quest for a good way to make a dual hierarchy.

One approach here is the template-inherits-from-non-template-class approach. Put the bulk in the non-template, and the few fast things in the template.

I think in this case the template should be the SPI part, the flash driver should not be a template. Separating the SPI makes sense anyway, beacuse you want to be able to use the flash driver over a bit-banged SPI, a hardware SPI, and tomorrow over yet something else.


Reply to
Wouter van Ooijen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.