Re: Announcement of new C++11 library to handle measures
Richard Damon schreef op 12-Oct-14 2:40 PM:
On 10/12/14, 3:42 AM, Wouter van Ooijen wrote:
Richard Damon schreef op 11-Oct-14 11:40 PM:
On 10/11/14, 2:14 PM, Wouter van Ooijen wrote:
Richard Damon schreef op 11-Oct-14 6:44 PM:
On 10/8/14, 1:37 AM, Wouter van Ooijen wrote:
OK. But a pity you did not have something else in mind - I was hoping
for yet another type of solution.
BTW are you aware of any existing library for small chips that takes
this approach?
Wouter
One comment, in one sense the 1st example tries to stack the deck
against C++ by making the program be "more capable" than the C
program,
in that the C program knows exactly what type of pin it is toggling,
while the C++ program can toggle ANY sort of I/O bit with a suitable
class defined.
IF the example had been closer:
int main(){
lpc1114_gpio pin( 1, 0 );
for(;;){
pin.set( 1 );
delay();
pin.set( 0 );
delay();
}
}
I.E., directly using the pin object in the code, and not through a
pointer to a generic base class, the code generated by the compiler
can
much closer to the original since the compiler can bypass the virtual
call mechanism as it knows the real type of the object.
Of course, but IMO that approach has little or no advantage over C in
abstraction power.
I find, at least in my own code, that by far most of the actual
references to I/O devices are done with known type objects or in
non-virtual functions that are part of the device definition, and thus
are no less efficient than the equivalent C code.
That is not my experience: a GPIO point can be pin of the
microcontroller, but it can also be a pin of an I/O extender chip, or
either of such pins, but inverted, etc.
What I wanted to prove in the article is that using C++ templates you
can have your cake and eat it: compile-time polymorphism, without the
run-time costs.
Wouter
Where the advantage comes is now move the declaration of the pin to a
header file that defines your system hardware configuration (or even to
be a member of a class defining a higher level device). By using
preprocessor "magic" or just editing the file, you can define the pins
operation. When accessing the pin, the programmer there doesn't need to
know the type of I/O pin being used, he can just use the generic
interface and operate on it. (The key here is that the compiler DOES
know based on the declaration what type of port it is, so can generate
the efficient code).
I suppose the difference may be that I tend to write things that do
specific things to specific signals under specific signals, and don't
have many cases of writing a program to toggle an arbitrary signal under
some condition.
Indeed. If you never need to do something with 'abstract' pins the C
approach is sufficient.
I want for instance be able to write a bit-banged I2C master, that uses
an abstract pin. In actual use that pin can be a regular input-output
pin, or an open-collector pin. The regular input-output pin needs to be
handled a bit different (low => output and low, high => input). The I2C
code does not concern itself with such details, but the resulting
machine code is as efficient as if it fully knew.
Or maybe I was in a funny mood, and the I2C pins were pins on an
MCP23017 I/0 extender chip.
But I do agree, if you can write your code directly for the I/O pins
that you use there is no advantage in the abstraction I describe.
Wouter
Actually, I find the insufficient as the piece of code to manipulate the
pin then needs to change based on the pin type.
Yes and no: The i2c lib must of course state that it wants an
open-collector pin. But the actual 'conversions' of input-output and
open-collector to open-collector are written once, and are also used by
other protocols that need an open-collector pin, for instance the dallas
1-wire interface. All in the name of 'write it once' or 'don't repeat
yourself.
The relevant part of the i2c interface:
template<
class arg_scl,
class arg_sda
>
class i2c_bus_master_bb_scl_sda {
// use the pins in an appropriate way
// (and assert that they can be used as such)
typedef pin_oc_from< arg_scl > scl;
typedef pin_oc_from< arg_sda > sda;
...
};
All code in the class template uses the scl and sda, not the arg_scl and
arg_sda.
The pin_oc_from class template is specialized for the 3 cases:
input-output pin, open-collector pin, and the default that generates an
appropriate compiler error message. The actual code:
// fallback: compile-time error
template<
class unsupported,
class dummy = void
> struct pin_oc_from {
static_assert(
sizeof( unsupported ) == 0,
"pin_oc_from<> requires "
"a pin_oc, or pin_in_out"
);
};
// from itself: delegate
template< class pin >
struct pin_oc_from <
pin,
typename pin::has_pin_oc
> :
public pin_oc_archetype
{
static void init(){ pin::init(); }
static bool get(){ return pin::get(); }
static void set( bool x ){ pin::set( x ); }
};
// from a pin_in_out
template< class pin >
struct pin_oc_from <
pin,
typename pin::has_pin_in_out
> :
public pin_oc_archetype
{
static void init(){
pin::init();
}
static void set( bool x ){
// to make a pin_in_out behave like a pin_oc
if( x ){
// make it float when it is set high
pin::direction_set_input();
} else {
// make it output and low when it is set low
pin::direction_set_output();
pin::set( 0 );
}
}
static bool get(){
return pin::get();
}
};
With my method, there is
a single line of code, in a header that is visible to the code that
automatically reconfigures the code that is providing the "higher level"
driver.
>
In my method, the I2C Master interface that you describe would get its
pin definitions from an configuration include file, as opposed to having
some setup call build a pointer for them. This does say I need to
duplicate the code if I want to build two bit banged I2C ports in a
given application, or accept the added inefficiency of the virtual calls
(but for bit banged I2C, is it really significant?)
Maybe not for I2C, but you give up that possibility for IMO no gain. And
for (for instance) dallas 1-wire or SPI I can very well imagine more
than one bus of a certain type per system.
What you essentially do is compile-time polymorphism by modifying the
source file to include the right 'input' source file. One thing that I
certainly don't like about that is that it requires you to copy the
library file (bb i2c interface) to your project and modify it. (Or some
other scheme, where #include something that is essentially a source
file, not a header). There are other points, for instance that the
interface between the points and the i2c part is essentially by global
functions.
Note that my scheme is not limited to GPIO's. There are many other
abstractions that can be encapsulated similarly in static class templates.
Wouter