Changing from webbotlib V1 to V2: compatibility/issues

[klims]

This might be a good place for us to note down changes that you may need to make to your code to make it compatible with webbotlib V2.

I'm having some compile issues which I think are related to definitions of uint8_t, uint16_t, DRIVE_SPEED and boolean. Does anyone know if these types have been removed/changed, and if so what they have changed too?

Edit: I can see that webbot is still using the above mentioned types, so does anyone know what might cause a compile error coming from V1 to V2?

[joe61]

This might be a good place for us to note down changes that you may need to make to your code to make it compatible with webbotlib V2.

I'm having some compile issues which I think are related to definitions of uint8_t, uint16_t, DRIVE_SPEED and boolean. Does anyone know if these types have been removed/changed, and if so what they have changed too?

Edit: I can see that webbot is still using the above mentioned types, so does anyone know what might cause a compile error coming from V1 to V2?

I don't use webbot so I can't speak to it directly, however depending on the exact errors you're getting you might just need static_cast<...>() somewhere. You don't say what DRIVE_SPEED is defined as for example. If you don't know you could try grepping the code to find the definition, or compile with -E to see the preprocessed output.

It might be as simple as an incompatibility between signed and unsigned types. Try posting the actual error messages you're getting and maybe someone will see the issue.

Joe

[Webbot]

Some of the inter-dependencies between header (*.h) files has changed.
Since the errors you are getting are for the basic datatypes then you will probably need to include libdefs.h in the offending code.
Without a compiler error report then its hard for me to see the .h file nestings to see exactly whats giving the issue.

Incidentally - using 'make' will produce a smaller hex file than compiling in AVRStudio. But you can tell AVRStudio to use the external makefile to get the same result..

Edit:- have just notice that 'hardware.h' in Version 2 lists the .h files in alphbetical order rather than chronological order. So released a new Project Designer - regenerate your code and you should see 'libdefs.h' as the first include file in 'hardware.h'

[klims]

Damn. Wish I recorded the error. I uncommented the offending code, compiled and everything went smoothly...
The errors went something like 'expected bla before method' when the return type for the method was uint8_t or DRIVE_SPEED which is why I thought the types were not yet defined.

@Webbot: yep can confirm that this is working.

New error: can't get scheduler to compile. At the top of my main file I include scheduler.h, then include the scheduled file (called it uartComms) and I get a compile error at scheduleJob(). Error reads "undefined reference to 'scheduleJob' ". I have tried including scheduler.h in the uartComms file but no luck.

Could this be because there is no scheduler.c in V2? There is one in V1.

[Webbot]

In V2 the scheduler code, and some other bits, has been pulled out into optional files (whereas in V1 they are always included as V1 never knew if you were going to use it or not).

These files are code-gend into the 'lib' subfolder of your project - and start with opt_xxxxx..c
If the scheduler isn''t there: then in Project Designer edit the 'clock' device and enter the number of concurrent scheduled jobs. The default is '0' - meaning you aren't using the scheduler.

[klims]

Right again webbot  

In case anyone wanted to know, having compiled using V2 my code is about 25% smaller than using V1!

I don't know if this is a Project Designer issue or V2, but using a UART buffer screws with things. ANY tx and rx buffer size I use always ends up with a buffer overflow error. I get the feeling that the buffer stuff is working ok but the UART stuff screwy. This is what happens:

With no buffer and using UART1 on my Axon I run the following code

Code: [Select]

void uartComms(SchedulerData data, TICK_COUNT lastTime, TICK_COUNT overflow)
{
//***uart1*****************************************************************
int ch = uartGetByte(UART0);
if(ch != -1)
{
rprintf("\nGrabbed something: %d", ch);
}

scheduleJob(&uartComms, &data, lastTime, 200000);
}
Any byte sent through hyperterminal makes it go crazy. One would think it would get the byte and then stop thinking there were any more bytes. This is what I get in hyperterminal:

Code: [Select]

Grabbed something: -29952
Grabbed something: -29952
Grabbed something: -29952
Grabbed something: -29952
Grabbed something: -29952
If the UART getting clogged it would make sense that the buffer would immediately overflow, but I can't work out what is causing it! Anyone seen this before?

[Admin]

I gave V2 a try last night. I ran into problems as direct access to the buffer was disabled, preventing me from flushing it to work around some not yet explained bugs.

Webbot is aware of this issue, I'm just letting you know as it could be related to your problem.

[Webbot]

I gave V2 a try last night. I ran into problems as direct access to the buffer was disabled, preventing me from flushing it to work around some not yet explained bugs.

Webbot is aware of this issue, I'm just letting you know as it could be related to your problem.

Nope they are different things. A version 2.01 is on the way as klims issue is more fundamental. Amazing the chaos I can cause by omitting a single underscore character in my code !!

[Webbot]

@Admin
Your 'issue' is that I have hidden whether a uart is buffered or not. This is because your code shouldn't rely on it being buffered or not - it should cope with both cases.

So: to flush UART1 for example then:-

Code: [Select]

// Existing routine to flush the receive buffer
uartFlushReceiveBuffer(UART1);

// Until I write a 'uartFlushTransmitBuffer' then use
bufferFlush(uartGetTxBuffer(UART1));


[klims]

Still no luck. When I execute this code and hit something on the keyboard

Code: [Select]

void uartComms(SchedulerData data, TICK_COUNT lastTime, TICK_COUNT overflow)
{
int ch;

//***blueUART****************************************************************
ch = uartGetByte(blueUART);
if(ch != -1)
{
rprintf("\nSomething in blueUART: %d", ch);
//remoteControl(blueUART, &motionsMgr);
}

//***uart1*****************************************************************
ch = uartGetByte(uart1);
if(ch != -1)
{
rprintf("\nSomething in uart1: %d", ch);
//tuneSensor(uart1);
}

scheduleJob(&uartComms, &data, lastTime, 200000);
}
I get this in hyperterminal:

Code: [Select]

Something in blueUART: -29952
Something in blueUART: -29952
Something in blueUART: -29952
Something in blueUART: -29952
Something in blueUART: -29952
Something in blueUART: -29952
What I find interesting is that I never get anything registered in uart1 which is what you would expect having hit something on the keyboard. I have tried commenting out the blueUART section and what happens is that I get "Something in uart1: -29952".

Might also be worth noting that when I add a buffer to uart1 and blueUART, the first time I hit a key I get a buffer overflow error.

[Webbot]

Thats the exact problem I've fixed 2.01
Are you sure you've picked up the 2.01 zip file ?

[klims]

My mistake...  

Just today I thought my program had outgrown my axon. Using webbotlib V1 I was getting jerky looking motions because of all the scheduled routines I am running. I can now happily say that using webbotlib V2 my bot is running like it should and handling all the scheduled routines like a champ!   Thanks webbot!