WebbotLib for C++

[Webbot]

Am thinking about making a C++ version of WebbotLib. (Note that this means you could still use C for your own code - you wouldn't need to learn C++)

This means that I could replace all the calls to read different sensors such as:
encoderRead, distanceRead, etc etc
with a single .read() method

For those who know both languages - I could provide both C and C++ apis ie.
encoderRead(myEncoder);
or
myEncoder.read();
using a macro def like #define encoderRead(device) device.read()

So you could use the old (ie the current C) way and/or the new C++ way. But, if I do it, then I would phase out the C way of doing things over time. Then it would probably also make the documentation a lot smaller!

Early days and it would take me quite a while to do it - but is anyone interested in theory?

PS Please don't reply with the usual "C++ is slow and needs more memory" false statements.

[madsci1016]

I'm all for it. I'm loving C++ and it's more intuitive to read sometimes. The Arduino (yes, i know it's a competitor) environment is in C++ and a valid example that C++ and newbs get along quite nicely.

If anything, won't C++ free up program space compared to C?

On a side not, I just realized a few weeks ago that C++ got it's name for the fact that in C, the operator ++ means to post increment by one. so C++ sorta means 'one better then C'. I knew about ++ but didn't put two and two together about the name.

Yes, I am thick.

[KurtEck]

Sounds good to me.

Kurt

[Webbot]

If anything, won't C++ free up program space compared to C?

Not necessarily as I do a lot of C++ type stuff in the library by hand. ie things like UARTs can be hardware or software but share a lot of the same code. This is done by simulating the C++ class vtables for virtual functions. So mixing hardware and software UARTs doesn't add much code. Equally adding more instances of either form of UART wont add any more code.

But good to get a 'Yes'

[KurtEck]

It will be interesting to see what you do. 

I have been playing around with some C++ on a different platform (Renesas H8) using GCC to emulate so of the Arduino stuff.  One place I ran into bloat issues was with classes with virtual functions.   In particular with the code necessary for casting between classes. 

That is if you have something like a Serial class that has a bunch of helper methods that all call of through a virtual read1byte or write1byte function, than you develop two classes, that are defined as subclass of this with their own implementation of the low level functions.  Like a hardware serialport and a bit bang port.   By default C++ will generate a lot of stuff, to allow you to cast back and forth...

Kurt

[knossos]

Add another yes for C++.

[Admin]

I'd rather stick with regular C . . .

1) I have a huge investment of C code already written (as most people do)
2) 99% of the AVR code out there is only C
3) WebbotLib would be the only group doing it (making code sharing harder)
4) You may find yourself bending over backwards to get C and C++ compatibility
      - so it'll be an all or nothing kind of thing
5) It's a huge time investment, so its a choice between new features or improved syntax
6) I'd have to learn all the intricacies/syntax of a new language (not everyone is a skilled programmer)
7) Time might be better spent adding ARM compatibility

Although I trust you that there are advantages in terms of simpler libraries, I don't think the move to be worth it.

[madsci1016]

2) 99% of the AVR code out there is only C

Are you not counting the entire Arduino community? It's C++

The jump to C++ for the end user is fairly transparent. Everything you have in C will run fine in C++. C++ just adds functionality that C doesn't have. What webbot is suggesting is to convert the library function to C++. You can already drop C++ code into your program now, GCC handles both, but the library calls would still be C syntax. After webbot converts calls to C++, you can still use defines to maintain the C syntax if you want.

6) I'd have to learn all the intricacies/syntax of a new language (not everyone is a skilled programmer)

I'm learning it now, and I'm less of a programmer then you are. I was able to write my Arduino playstation controller library in C++ before I even picked up the C++ primer plus book I'm reading now. It sounds scary, but really it's not. I don't even really consider C++ a new language, it's the same with a couple new features.

I'm really in support of this. It will simplify library function calls greatly. No more long multiword function names. I really think it will bring Webbotlib a giant step towards the Arduino library in newb friendliness. 

[Webbot]

Just to sum up, and comment on. some of the points so far:

1. C++ is just like an add-on to C. You can actually mix both languages. ie you can write your own code in C if you prefer (even if WebbotLib is in C++).

2. WebbotLib would provide the existing C calls into the library so that your existing C code will still work. Additionally it would provide the simpler C++ calls as well. The only caveat is that some project settings in AVRStudio may need to be changed to invoke the c++ compiler toolchain rather than the c ones.

3. Regarding KurtEcks points on virtual functions and abstract/derived classes then one of the first things I would do would be to evaluate any 'bloat'. From past experience there should be very little. The only difference with virtual functions should be the vtables associated with each class for the virtual methods. These just provide the implementation address of the function for each derived class. Rather than calling a method directly the compiler should just add one or two lines of assembler to access the pointer from the vtable and then call that address. I already do this in WebbotLib ie 'distanceRead' works for any distance sensor because the sensor type has a pointer to its own 'read' function.

4. ARM support is something for the future IMHO. This would require a total rewrite of WebbotLib as they work in a completely different way. The development toolchain is somewhat hellish to find, install and get working (I tried it a few months ago and it meant downloading all sorts of bits'n'pieces from different places). It also depends on what is meant by 'ARM support' ie just Atmel ARM chips or ARM chips from other/all suppliers (eg Renesas etc).

5. Project Designer code generation would need to be changed to generate C++ declaration/constructors for the devices. However: I would delay this until the conversion of the main library was nearing completion.

There seems to be a general thumbs-up and so what I would like to try is to produce a cut down version to start with. So if anyone wants to be a guinea pig and has a given project in mind then we could work together on it. This would mean identifying a small set of motor controllers/sensors etc for a 'very alpha version'. The compiled code could then be compared with the same code using the current C version. Get in touch if you are interested.
 

[KurtEck]

3. Regarding KurtEcks points on virtual functions and abstract/derived classes then one of the first things I would do would be to evaluate any 'bloat'. From past experience there should be very little. The only difference with virtual functions should be the vtables associated with each class for the virtual methods. These just provide the implementation address of the function for each derived class. Rather than calling a method directly the compiler should just add one or two lines of assembler to access the pointer from the vtable and then call that address. I already do this in WebbotLib ie 'distanceRead' works for any distance sensor because the sensor type has a pointer to its own 'read' function.

Sounds great.  VTables work great as long as you keep things simple. That is for example you don't have classes that are derived from multiple base classes and you find some way to turn off dynamic type casting.  My earlier library code the compiler was generating run time type information and all of the support code that went along with this, including I believe Try/Catch. ...

Kurt

[Webbot]

3. Regarding KurtEcks points on virtual functions and abstract/derived classes then one of the first things I would do would be to evaluate any 'bloat'. From past experience there should be very little. The only difference with virtual functions should be the vtables associated with each class for the virtual methods. These just provide the implementation address of the function for each derived class. Rather than calling a method directly the compiler should just add one or two lines of assembler to access the pointer from the vtable and then call that address. I already do this in WebbotLib ie 'distanceRead' works for any distance sensor because the sensor type has a pointer to its own 'read' function.

Sounds great.  VTables work great as long as you keep things simple. That is for example you don't have classes that are derived from multiple base classes and you find some way to turn off dynamic type casting.  My earlier library code the compiler was generating run time type information and all of the support code that went along with this, including I believe Try/Catch. ...
Kurt

Can't think of anything in WebbotLib that requires multiple inheritance - off the top of my head. Multiple inheritance sucks - and thats why Java doesn't support it - although it is abstracted into multiple 'interfaces'.
But we are getting ahead of ourselves!

[Webbot]

This is just an update for those 'techies' interested in my findings with avr C++ and have posted some stuff on AVR Freaks (but had a mixed response).

All instances of a class are created in RAM. Obviously due to the 'new' operator in the language even though its not really relevant for microcontrollers.
So if your class has member variables then these are also stored in RAM.

This is significant when trying to create a generic class such as a 'Timer' as it suggests that there are two possible soultions. (To keep things simple bellow then lets pretend the only method is a 'read' which returns the current value of a timer).

1. Just have the one Timer class and then create each individual timer as an instance of Timer and have a data element that stores the register to be read. ie in pseudo code:-

Code: [Select]

class Timer{
public:
   Timer(tcnt register){
       m_tcnt = tcnt;
   }
   uint16_t read(){
      return read(m_tcnt);
   }
private:
   m_tcnt;
}

Timer timer0(TCNT0);
Timer timer1(TCNT1);

2. Rather than using data you have a base abstract class which just holds the methods (interface) that a given timer must support:-

Code: [Select]

class Timer{
public:
    virtual uint16_t read(void) = 0; // derived classes must implement the read
};
then

Code: [Select]

class Timer0{
public:
    uint16_t read(void){ return TCNT0; };
}
class Timer1{
public:
    uint16_t read(void){ return TCNT1; };
}
Timer0 timer0();
Timer1 timer1();


The pros'n'cons of these 2 approaches are:-
Method 1: Since there are no virtual methods then there are no vtables. However:- since the instances are created in RAM (in BSS) then the compiler adds code to set up the 'm_tcnt' value for each timer (ie to do the 'constructors'). This obviously lives in flash program memory. Obviously when you fully implement the class then you need to know a lot more than just the register/IO used for tcnt for a given timer. This additional code therefore grows quite alarmingly. The same is true if you have a lot of instances ie there may only be 5 timer instances on an ATMega640 but you could have 50 or so IOPin instances.

Method 2: Since there is no data associated with each timer then there is no constructor code to be generated. Instead: the compiler needs to create a 'vtable' to define the destination of the 'read' function for Timer0, Timer1 etc. Strangely the compiler decides that these vtables are best placed in RAM but since they have initialised values then they are also stored in flash program memory. This therefore requires 'flash program memory' AND 'RAM memory'. I am at a loss as to why they (the compiler designers) have decided to do this as the vtables should be read-only and should, IMHO, only be stored in flash program memory.

I have also tried a hybrid approach to method 1 whereby the data is set up in a program flash memory array and then the start of the array is the only parameter to the constructor. This stops the alarming bloat caused by adding additional information about each timer.

Another 'issue' when comparing C and C++ is the linker. WebbotLib at the moment has several things you can do with an IO pin:- read an input, set an output, measure an incoming pulse, send an outgoing pulse, etc. In C the linker will only bring in the code you are actually using. But for C++ it will always bring in all of the code for any class you have used.

This implementation decision is causing me sleepless nights!! I may have to select between Methods 1 and 2 for each class.

But then I got to thinking...

WebbotLib has a lot of really low level functionality - such as manipulating timers and since it doesn't know what devices and resources your program will use then it has to include everything. Great for the hacker or for adding your own devices.

Heck it doesn't even know until runtime what type of cpu or clock speed you are using. So there is a lot of calculation to cope with this in the runtime.

But when 'Project Designer' came along then you are defining everything you are going to use. So 'does the developer still need all the low level functions'?. Probably not. They just need a read() for each sensor, and a setSpeed or setPosition for each motor/servo. IE they are just interacting with the stuff added in Project Designer and are no longer interacting with the low level hardware.

Even better - Project Designer knows the cpu and clock speed for the board. It could do the calculations and then just generate the correct code to set up timer prescalers etc. The end result would be much smaller code.

Summary: to make a C++ version of the existing C version will bloat the library further meaning that processors like the ATMega8 are defintely 'out'.
Forcing people to use Project Designer would mean generating MUCH smaller (and faster) code and so chips like the ATMega8 would change from 'border line' to 'supported' - and could open up in roads to the Tiny range (but no promises). In this scenario the application code would only interact with the code generated by Project Designer (ie talking to devices be they sensors, motors, etc) rather than talking to the hardware (eg Timers, IO pins etc). The C or C++ interface would then be limited to these devices. A benefit is that your code will be isolated from the hardware and therefore much more portable from one chip to another, as well as a manual that is slimmed down as the low level stuff can be thrown away. The downside is lack of control - but I think this is cosmetic - in that if you wanted low level access to a timer then I could add a 'Timer' object to 'Project Designer'.

Does ANYONE use any of the low level stuff in WebbotLib? eg do you manipulate individual timers rather than use the scheduler? Do you use any of the timer compare/channels for timing purposes rather than using the inherent clock?

Speak now or forever hold your peace.

[Admin]

I think this C++ stuff should be in the C++ for WebbotLib thread . . .

That said, my programming skills aren't high enough to comment on the approaches you are considering.

Does ANYONE use any of the low level stuff in WebbotLib? eg do you manipulate individual timers rather than use the scheduler? Do you use any of the timer compare/channels for timing purposes rather than using the inherent clock?

The 'inherent' clock built into WebbotLib has served all of my purposes quite well.

[richiereynolds]

I'd absolutely love a C++ version, I miss OO so much when programming in C!

[tmoney68]

I'm all for it. Being a noobie-type programmer myself, I tend to get lost/confused with the low-level stuff in the manual. Easier is more fun! And more fun means more people getting involved in this hobby!

Just my 2 cents.

[KurtEck]

I am sort of torn here.  

I am also a bit rusty with using webbotlib right now.  I have been busy on other projects using different processors/boards lately.   I should try out a new project again using project designer.  One question I have is I noticed in project designer it supports or at least shows the Arduino Mega board.  I do have 1 of these and a couple of the Seeeduino Mega boards (Wanted to learn more about Arduino...).   Is this supported?  If so is it difficult to setup to download outside of the Arduino environment...   Sorry I know I am a little off topic here, but I will explain more in a minute...

I do like the idea of making things simpler.  The majority of the time you don't need to know the details.  I also like the idea of making it more object orientated

But suppose I can use one of the Arduino Megas to do my next project (like port my Arduino hosted phoenix code) to webbotlib.  My current Arduino version may be easy as all of the servos are still controlled by an SSC-32 servo controller, which I simply need to send serial data to and that would be easy with webbotlib.  But one of the next steps I was thinking about doing is to have the Arduino do the servo processing.  Since the Arduinos don't have servo connectors (why I like axons), I purchased a Rebotics Servoshield, which has 16 connectors (I hacked 2 more on it)... The shield is hard coded to use 2 16 bit timers to control the 18 servos through 2 4017 decade counters... So If I were to port this to the webbotlib I would need to be able to do the interrupt processing for those two interrupts.   I believe that I can currently do that, but may not be able to describe that in project designer.  That probably is true of lots of different Shields.  

As for the two methods:
1) A constructor is created to initialize your timer variable, which I understand.  I guess the question would be if you can minimize the overhead of this and get this to combine with whatever other initialization you may need to do?  
2) No user data to init, but something has to init the table pointer.  If the compiler can do this without an init type thing, I am supprised that it can not init your timer variable to 0 as well in 1).

Also with bloat what is the differences in the code sizes when you use the different methods.  That is when you do something like: timer1.read() ?  In 1) this would be a push of the object pointer and a simple call to the read function.  in 2) this would be a push, plus then code to get the table pointer, and index to the appropriate slot and then call that, which I believe would add so many bytes per call.  So in this case where you have no need for virtual I think in a real program 2) will be larger.  But in other cases virtual does make sense.

I assume there is probably some way to tell the compiler to turn off dynamic casting support.  That is where I ran into issues on a different processor (still GNU).  Note: I was not using multiple inheritance but it still generated all of the junk to allow me to try to cast a pointer... Which we really do not want here!   That is you could do something like:

Code: [Select]

Timer *pt
Timer1 *pt1
pt1 = (Timer1*)pt The run time would verify that the current value in PT was valid to cast to PT1, if not an exception is generated... A lot of code that can quickly kill a small processor.
EDIT: I think I can probably answer my own issue here, by using the -fno-rtti option to the compiler...

But back to 1) versus 2) I think it will be needed to be decided on a per class basis.  As you mention using project designer it can maybe save some code space on some of the init type stuff, like configuring baud rates if you assume that the program will not change, Mine may for example I may assume that an XBEE is still in default configuration (9600 baud), I then output to it to tell it go to some new baud rate like 38400 and then I need to tell the uart to change to the new baud rate.  In this case the code will still need to be in there to change the uart.  In other places in the code like delay loops, we may have code that calculates the delay times using a CPU speed constants.  The majority of this will be handled by the compiler, so not sure how much will be saved by having it done external to the program.

With the linker if there are no virtual methods as part of a class, does it still always bring in all of the code of a class even it is never used?  I know when a class has virtual functions, The vtable will include pointers for all of the virtual functions, so those are inherently referenced and as such will be brought in, but is that also true for all non-virtual functions?  

I know that for most systems I have worked on, we have used some form of hybrid.  That is we had a high level class structure, but lots of the lower stuff were not objects.  Also we had two levels of classes defined.  We had the public class that the user used and under it we had the implementation class that was a subclass of the public one that had off of the details, including all of the private stuff).  But this usually needs some wrapper function to create the object...   That is however probably overkill as you are not worried that from release to release if you change the underlying code that the user will see and maybe misuse some of the underlying stuff, which will break them in the next release...

Sorry for my long winded meandering answer.  
Kurt

[Webbot]

@KurtEck - "Great reply!"

Project Designer currently supports the following 'duinos: Arduino Mega, Roboduino and uBotino. Others could be added quite easily.
The Shields issue is interesting. 'Yes' - you can do it in WebbotLib today. If I remove the low level stuff from the end user library then the way it would work is that each of the 'device' files in Project Designer would contain a code-generation template. This template would then generate the code to set up the timer and provide the ISR handlers. Hence the code templates could do 'anything' - but the end user can do less. So all the 'fiddly' code is in the driver code template, leaving less for the end user to worry about.

As for the two methods - and bloat:
Method 1) The compiler generates code to initialise each (non-zero) member variable of each class instance you have created. This is annoying if all the variables are constant ie in the case of a generic timer class then the variables are all port/IO values and bit mask values. Since they are read-only then the current WebbotLib creates them, and accesses them from PROGMEM only so the bloat is quite small. But the code generated by C++ gets bigger with the more member variables you have - and then doubles if you double the number of instances. In effect it generates code that does:-
timer1.variable1 = foo1;
timer1.variable2 = bar1;
timer2.variable1 = foo2;
timer2.variable2 = bar2;
 The hybrid approach I eluded to is similar to your scenario of a private class and a public class. For my private class I use a struct (ie a class with no methods) which is held in PROGMEM and then the public class just holds the address of that struct. So the only code generated is:
timer1.progmem_data = &timer1_data;
timer2.progmem_data = &timer2_data;
This code therefore never gets any bigger as if you add any new member variables then they just get added into the PROGMEM struct.

Method 2) The bloat in this case is the vtables which occupy both PROGMEM and RAM. Hence the equation is: 2x(Number of virtual methods * Number of derived classes). The '2 x' is because each entry is a 2 byte pointer. But note that the bloat occurs in both PROGMEM and RAM.

what is the differences in the code sizes when you use the different methods.

You are correct for method 1 - its very minor.
But for method 2 - you're not quite correct. The additional code of calling indirect via the vtable is very small as its done by a common routine that looks up the vtable entry and then calls it. So the code bloat is small - and the runtime speed is only fractionally slower. Note also that the compiler can optimise things as well ie if you are calling the 'read' function and the compiler knows its 'Timer2' then it can just call the Timer2.read code directly (as if it wasn't virtual). The indirection via the vtable only happens if the compiler only knows that the instance is a generic Timer.

Dynamic casting - yep you've answered your own question. I can't envisage why a user would need to do it anyway!

As for changing baud rate - then thats fine - the UART class can still provide the method. You then assume that the compiler can do most of the pre-calculation to initialise something. Whereas this is true for simple expressions then I suggest you look at some of the init code for things like servo software PWM. Currently you tell WebbotLib  at runtime what timer to use. But this timer could already be in use by something else. So there is lots of code in WebbotLib that says for example:-

Code: [Select]

if the timer is not already in use then just set it up
else look at the current timer mode (WGM) and pre-scaler etc to see whether it can still be used
else give an error
endifIt has to do this as everything is added at runtime - and the compiler cant help with this. However: Project Designer knows about ALL the devices you are using - so all these checks could be done by it instead and all these checks could be removed from the generated code.
Equally the current WebbotLib has to intercept ALL of the Timer interrupts for EVERY timer: ie overflow, capture, and those for each channel. It has to do this as it doesn't know what features you will be using. This ISR code is quite big (lots of push/pop for each ISR). Again Project Designer knows which timers you are using and so could only generate the ISRs that are actually needed. This would all be done in the Project Designer code template - ie set up the timer registers during init as well as the ISR handlers.

Long reply to long question.

Hope it makes sense.