Re: Announcement of new C++11 library to handle measures
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. 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?)