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

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

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.

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.

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

Wouter

Pot, kettle?

Please don't snip attributions!

Don't feed the troll!

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.

Stefan

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.

Wouter