Society of Robots - Robot Forum

Software => Software => Topic started by: Webbot on April 28, 2009, 11:35:38 AM

Title: New C library - testers required
Post by: Webbot on April 28, 2009, 11:35:38 AM
I have finally got around to uploading my new software library to SourceForge as a Beta release so I'm looking for 'guinea pigs' to check it out !

There are 2 downloads - a 'zip' file contains the source, header files, and compiled libraries. There is also a PDF file which you should download as it has a getting started section as well as the full API documentation. The source code is really only there for reference purposes if the documentation is unclear. The getting started guide shows how to use the library without copying any files out of the library. If you want to change the source code, or add to it, then I encourage you to sign up as a contributor on the Source Forge website.

The library makes it very simple to use a myriad of 3rd party hardware such as motor controllers, sonars and various sensors. For example: if you've written a program that uses the built in modified servo support and you decide to replace the servos with a SabreTooth DC motor controller then you only need to change about 6 lines of code. The PDF gives an example of doing this with the Photovore program.

Currently the library supports ATMega8, ATMega168, ATMega32 and ATMega640 processors but I can add extra AVRs very easily (no PIC support I'm afraid). Specific support has been added for the Axon, Roboduino, and BabyOrangutan boards.

Note that this is quite a large, and comprehensive, library and, with your assistance, I want it to become the 'defacto' standard for robotics (whereas AVRlib is just a generic library).

My library doesn't require AVRlib - only the WinAVR files that come with AVRStudio.

There is no I2C support (yet) but I'm working on it.

Here's the source forge project page - http://webbotavrclib.sourceforge.net/ (http://webbotavrclib.sourceforge.net/)

I welcome any feedback

Title: Re: New C library - testers required
Post by: hazzer123 on April 28, 2009, 11:48:11 AM
Wow, a quick look at the documentation and im already impressed!

Ill definitely take a look at it in the near future.
Title: Re: New C library - testers required
Post by: Admin on April 28, 2009, 02:37:39 PM
I haven't had time to look through it yet, but this would make a great replacement for AVRlib (which is seriously out of date).

If you have a $50 Robot and want much better features than the default software in my tutorial, this is what you should start using.
Title: Re: New C library - testers required
Post by: dellagd on April 28, 2009, 06:07:12 PM
I would test it but my $50 board will not work for no apparnent reason (soldering is good. voltage from the regulator. just don't know why)
Title: Re: New C library - testers required
Post by: Webbot on April 28, 2009, 06:12:06 PM
Also works with Axon and Roboduino boards - or any other custom made ATMega8/168/32/640 board
Title: Re: New C library - testers required
Post by: Resilient on May 07, 2009, 07:17:55 PM
Looks great so far.

But I am trying to resolve an issue I am having with Roborealm and want to try tweaking the rprintf function (see http://www.societyofrobots.com/robotforum/index.php?topic=7880.0 (http://www.societyofrobots.com/robotforum/index.php?topic=7880.0)) but am a little unclear as to how to do this because of the precompiled libraries.

If I change the rprintfs.c in your library folder nothing changes (because of the precomiled bit), but if I include a modified version of rprintfs.c in my folder and include that in the AVR Studio source files, it complains about the .elf file not being found (This I don't understand).

Thanks
Justin
Title: Re: New C library - testers required
Post by: Webbot on May 08, 2009, 06:45:36 AM
Looks great so far.

But I am trying to resolve an issue I am having with Roborealm and want to try tweaking the rprintf function (see http://www.societyofrobots.com/robotforum/index.php?topic=7880.0 (http://www.societyofrobots.com/robotforum/index.php?topic=7880.0)) but am a little unclear as to how to do this because of the precompiled libraries.

If I change the rprintfs.c in your library folder nothing changes (because of the precomiled bit), but if I include a modified version of rprintfs.c in my folder and include that in the AVR Studio source files, it complains about the .elf file not being found (This I don't understand).

Thanks
Justin

Hi Jason,
I discovered a potential issue in the uart buffer code which would leave interrupts disabled. So I guess that could be your original problem - ie the transmission stops.

I've uploaded a new release 1.1 to sourceforge - (also contains code to create software uarts and to handle GPS message data).

Could you try that release first and let me know - thanks.
Webbot
Title: Re: New C library - testers required
Post by: Resilient on May 08, 2009, 06:08:11 PM
No dice. Still buffers in Roborealm. I think it really must be an issue on their side.
Title: Re: New C library - testers required
Post by: dunk on May 08, 2009, 07:07:59 PM
dude,
good job so far.

dunk.
Title: Re: New C library - testers required
Post by: Webbot on May 11, 2009, 01:58:44 PM
Ok - some folk seem to be giving it a try - thanks.

Here is a list of other stuff I want to add:-
1. I2C (master only, slave only, master + slave) - split into 3 to keep size to a minimum
2. 7 segment LED support - as per Axon II LED
3. Generic 'pulseIn' function (pulled out of the existing sonar libs) for any IOPin
4. Generic 'pulseOut' function to emit a 'one-off' pulse, or a train of pulses (ie frequency/duty cycle generator)
5. Generic 'frequencyIn' function to return the frequency and duty cycle present at an input pin
6. RF transceiver for inter-robot/pc comms.
7. Single wire UART - for some humanoid type servos
8. SPI interface

Add to documentation:
1. Table of 3rd party hardware sensors/controllers - and what functions to use with each of them. If you've discovered any new combos ie 'this software' also works for 'this device' then let me know and I'll add it to the list.
2. More example programs

This is partly 'a note to self' but more importantly - a chance for you guys to say whats missing. So post any 'votes'.
Title: Re: New C library - testers required
Post by: Admin on May 30, 2009, 11:27:53 AM
Just an update . . . I'll try implementing this on the Axon 2 within the next ~3 weeks, right after RoboGames. My crazy schedule chills out on like the 17th of this month.

Bandwidth and server usage is not a prob, I'm currently using like only ~7% of my alloted resources ;D
Title: Re: New C library - testers required
Post by: Resilient on May 30, 2009, 09:36:43 PM
Edit: Solved my own problem, doing basic subtraction correctly is helpful to programming.
Title: Re: New C library - testers required
Post by: Resilient on May 31, 2009, 12:28:16 AM
Ok, now I really am having a problem that cant be solved by simply doing subtraction right

I got the following code:

Code: [Select]
// Place any #define statements here before you include ANY other files
// You must ALWAYS specify the board you are using
// These are all in the 'sys' folder e.g.
#include "sys/axon.h" // I am using an Axon
// Now include any other files that are needed here
#include "uart.h"
#include "rprintf.h"
#include "libdefs.h"
#include <stdarg.h>
#include "Sensors/Encoder/quadrature.h"
#include "Motors/Dimension/Sabertooth.h"
// Now create any global variables such as motors, servos, sensors etc

#define TIME_REDUCTION 250000 //converts us to 1/4 seconds

ENCODER l_encoder = MAKE_ENCODER(K0,E3,FALSE,64);
ENCODER r_encoder = MAKE_ENCODER(J6,C1,TRUE,64);

SABERTOOTH_MOTOR motor1 = MAKE_SABERTOOTH_MOTOR(FALSE, 128,0);
SABERTOOTH_MOTOR motor2 = MAKE_SABERTOOTH_MOTOR(FALSE, 128,1);

SABERTOOTH_MOTOR_LIST motors[] = {&motor1,&motor2};
SABERTOOTH_DRIVER driver = MAKE_SABERTOOTH_DRIVER(motors, UART2, 19200);


//Wheel circrumfurance 229mm
//Add your code here
//Global variabls
int16_t r_clicks = 0; // Total clicks travled
int16_t l_clicks = 0;
int do_once = 1;

//encoder stuff

TICK_COUNT r_prev_time = 0;//Time of the last encoder reading
TICK_COUNT l_prev_time = 0;
TICK_COUNT speed_calc_timer;

//pid stuff

int16_t r_target_speed = 0; // most recent speed in clicks per 1/4 second
int16_t l_target_speed = 0;
int16_t r_speed = 0; // most recent speed in clicks per 1/4 second
int16_t l_speed = 0;
int16_t r_integral = 0; // integrals
int16_t l_integral = 0;
int16_t r_previous_p = 0;
int16_t l_previous_p = 0;
TICK_COUNT r_prev_integral = 0;//Time of the last encoder reading
TICK_COUNT l_prev_integral = 0;



int16_t calculate_speed(char side);
int16_t pid(char side);
void go_speed(int16_t l, int16_t r);



// This routine is called once only and allows you to do any initialisation
// Dont use any 'clock' functions here - use 'delay' functions instead
void appInit(void){
// Set UART1 to 115200 baud
uartSetBaudRate(UART1, 115200);
// Tell rprintf to output to UART0
rprintfInit(&uart1SendByte);
uartSetBaudRate(UART2, 19200);
sabertoothInit(&driver);
}



// This routine is called repeatedly - its your main loop
void appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart){
DRIVE_SPEED speed = 127;
if(do_once == 1)
{
speed_calc_timer = clockGetus();
do_once = 0;
}
if(clockHasElapsed(speed_calc_timer, TIME_REDUCTION) == TRUE)
{
act_setSpeed(&motor1,100);
if(speed > -127)
{
speed = speed-5;
}
}

}

But no motor is turning. I would expect it to start at near full speed then go down and eventually reverse. It is also throwing a warning saying:

../webtst.c:23: warning: initialization from incompatible pointer type

for the SABERTOOTH_DRIVER driver = MAKE_SABERTOOTH_DRIVER(motors, UART2, 19200); line.

Any ideas here?
Title: Re: New C library - testers required
Post by: Webbot on May 31, 2009, 01:56:44 PM
Hi Resilient - am away on business at the moment. So you may have to hangon until Tuesday. But will see if I can get time to have a look between meetings. Sorry..
Title: Re: New C library - testers required
Post by: Resilient on May 31, 2009, 03:51:56 PM
No problem. I wrote my own function to use the simplified mode on the Sabertooth and that works, so getting it fixed is not critical.

I also tried directly copying and pasting your code from Sabertooth.h and tried running that and had the same result. Wheels just sit there.

So something isn't working right with the Sabertooth functions on the Axon. I am using UART2 (which I did remember to change in your test code in Sabertooth.h) :P
Title: Re: New C library - testers required
Post by: Webbot on May 31, 2009, 04:17:33 PM
Ok think I found the problem. It came about when a created a virtual UART - ie all the code that can use a uart can now use either a hardware uart or a software uart. And this is what is causing your compile warning and therefore for the program to not work (I Think!).

I'd be really grateful, if you have time, to ediy 'dev/ATMega640.h' where it says:
#define UART2 &Uarts[2]
to say
#define UART2 &Uarts[2]._uart_

And then try your original code (or mine) again. Assuming that works then you may as well change the other UART defs in dev/ATMega640.h so that they also have the '._uart_' on the end as well.

Let me know if it works, and I'll do another release to fix the issue for others.

Thanks for all your efforts.

Webbot
Title: Re: New C library - testers required
Post by: Webbot on May 31, 2009, 04:43:38 PM
To those that have tried out my library.....

Currently your application file has to have 2 functions 'appInit' and 'appControl'.

appInit lets you set up all the hardware and therefore timers/PWM/InputCapture etc etc.

On return the the library then tries to find a left over timer to use for its system clock. So on the Axon it can use one of the timers that dont have pin headers and its less likely you will have used it. For this reason the call to 'clockGetus' cannot be used as the clock isn't set up until appInit returns.

appControl is then called repeatedly. It has a 'loop counter' but you cannot rely on testing this for '0' as it will eventually wrap around.

So I've noticed some peoples code (and Resilients attachment below is a good example) still use a flag ('do_once') to do any one-off set up.

I'm thinking of changing this to have a 3rd function inbetween the 2 so that there will be:-
appInitHardware - the new name for the old appInit. Set up your motors/drivers here. Still no clock
appInitSoftware - a new function - called only once. At this stage the clock will exist
appControl - same as before and called repeatedly forever.

So this means you can get rid of those 'one-off' variables and initialise your app in once place. I would make the signature of appInitSoftware be the same as appControl - but the 'loop_count' parameter to appInitSoftware would ALWAYS be 0.

I am also thinking of allowing both appInitSoftware and appControl returns a value in ms. So if appInitSoftware returned a value of 20 then there would be a 20ms delay before the first call to appControl to let the hardware settle down. appControl could return a value of 20 so that it was next called in 20ms minus the time taken for the current pass. Admins code often has a similar delay at the end of each loop to 'prevent crazy oscillations'.

Of course returning a value of 0 would mean dont pause at all - go at full speed.

What do you think?




Title: Re: New C library - testers required
Post by: Resilient on May 31, 2009, 06:17:52 PM
I like both of those ideas quite a bit.

I tried your solution to the sabertooth problem. It fixes the compile problem with the sabertooth function, but breaks every other UART related function. :)

It also doesn't make the sabertooth work. :(

The code I used as a temporary solution is the following:

Code: [Select]
//Takes values between 0 and 127 for motor speeds
void sabertooth(uint8_t m2, uint8_t m1)
{
uartSendByte(UART2, m1);//send a command for motor 1
uartSendByte(UART2,m2+128);//send a command for motor 2
}

This works when the dip switches are set to Simplified Serial mode  (rather than packetized like it was set before) . So serial communication works with the sabertooth with no changes needed to anything, so it seems like there must be something else going on here in the sabertooth functions (rather than the UART functions).



Title: Re: New C library - testers required
Post by: Webbot on May 31, 2009, 06:24:37 PM
Ok - tanks for that. Shows the problem of trying to fix code via mobile/cell phone!

Will take a look when I get home.
Title: Re: New C library - testers required
Post by: Resilient on June 01, 2009, 08:45:04 PM
I ran into a new problem.

I am trying to use a sharp GP2D120 sensor.

When I include:

Code: [Select]
#include "Sensors/Distance/SharpIR_GP2D120.h"
#include "sensor.h"

everything compiles fine, but as soon as i add

Code: [Select]
GP2D120 ir_r_f = MAKE_GP2D120(K5);
GP2D120 ir_r_r = MAKE_GP2D120(K6);

I get:

gcc plug-in: Error: Object file not found on expected location C:\Robotics\webtst\default\webtst.elf

and

avr-gcc.exe -I"C:\Robotics\webtst\..\..\WebbotLib"  -mmcu=atmega640 -Wall -gdwarf-2 -std=gnu99         -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT webtst.o -MF dep/webtst.o.d  -c  ../webtst.c
avr-gcc.exe -mmcu=atmega640 -Wl,-Map=webtst.map webtst.o   -L"C:\WebbotLib"  -lm -lWebbot-ATmega640  -o webtst.elf
c:/winavr-20081205/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr5\libc.a(floatsisf.o): In function `__floatunsisf':
(.text.fplib+0x0): multiple definition of `__floatunsisf'
c:/winavr-20081205/bin/../lib/gcc/avr/4.3.2/avr5\libgcc.a(_usi_to_sf.o):(.text+0x0): first defined here
make: *** [webtst.elf] Error 1
Build succeeded with 0 Warnings...

any idea whats going on here?
Title: Re: New C library - testers required
Post by: Webbot on June 01, 2009, 09:17:06 PM
This is what I think is going on....

My libraries were compiled using my version of win-avr - 13 March 2009. The Sharp IR libs use Admins floating point functions to convert the readings to a linear scale.

You seem to be using win-avr 5 December 2008 - ie a different version to my mine.

So I think its a winavr issue which is a bit of a downer. I'd foolishly assumed that their compiler would be backwards compatible ie not sure why 5 * 1.3 (or similar) should be compiler dependent - seems nuts to me

Any chance you can upgrade winavr by downloading from http://sourceforge.net/project/showfiles.php?group_id=68108 (http://sourceforge.net/project/showfiles.php?group_id=68108)

Title: Re: New C library - testers required
Post by: Resilient on June 01, 2009, 09:17:43 PM
This seems to be fixed by including the libc.a library.

Not sure if this should fix it... but if it should be there, some mention should probably be made in the documentation :)

Edit:
I will also update to the newer version of win-avr
Title: Re: New C library - testers required
Post by: Resilient on June 01, 2009, 09:43:28 PM
And one more question regarding pins.

The Axon is labeled oddly. Either F pins go from 0 to 15 or K starts at K8 and goes to K15. Or some combination thereof as seen here (http://www.societyofrobots.com/axon/images/axon_pinout.png) along the top row.

So how do I address these pins? I have assumed it goes F0 to F7 then from K0 on to K7 (the pin labeled F8 = K0 etc.), but I was getting some odd results using the IR sensors on pins K5 and K6. (the value of the sensor in K5 heavily effects the reading from pin K6, which makes me think these are not actually getting read right)

But if I use pins F0 and F1 it works fine.

Edit: err, this might just be something wonky going on with these damned IR sensors. I think I need some bigger capacitors for them.
Title: Re: New C library - testers required
Post by: Webbot on June 01, 2009, 10:14:48 PM
The numbers along the top from 0......15  are the 16 ADC channels on the Axon.

These are also accessible as I/O pins F0-7 and K0-7 respectively. ie ADC0-7 are also F0-7, and ADC8-15 are also K0-7.

I know that ADC8 onwards require special handling, which I have done in the lib, but perhaps need to revisit in case this is your issue. In which case you may currently have the same problem on ADC channels 8-15 (ie K0-7) for ADC input.

Thanks for the heads-up. Hope to spend time this week to fix this and your earlier UART problem but will keep this thread informed.

Am looking into libc.a issue and will update documentation as needed. Thanks for your help
Title: Re: New C library - testers required
Post by: Resilient on June 02, 2009, 01:08:11 AM
I would hold off on the IR stuff. It looks like its more of a hardware issue. It always seems to default to the reading of the highest numbered pin if any earlier pin is reading infinity.

so, if F0 should be reading infinity and F1 is reading 25, F0 will be pulled towards a reading of 25, even though it should be reading infinity.

I posted this problem over in the electronics forum, but just thought I would update you so you didn't try to fix something that may not be broken. :)

EDIT: testing suggests I might have been calling the sensor functions too close together, I added a delay and that seems to have fixed the issue.
Title: Re: New C library - testers required
Post by: Webbot on June 02, 2009, 02:08:40 PM
Have released version 1.2 at http://webbotavrclib.sourceforge.net/ (http://webbotavrclib.sourceforge.net/)

Read Version.h to see whats changed.

NB Previous code will not compile. This is because I have replaced appInit with appInitHardware and appInitSoftware - and appControl can now return a value in microseconds (as discussed in this thread) The new documentation explains it in the intro sections and the example code has been changed to reflect these changes.

@Resilient - this should fix your Sabertooth issue (plz - let me know). But I'm very confused by your Sharp IR problem. Cant see why a delay would help (its just an A2D conversion) - unless the second sensor is detecting remnants of the first sensors light beam ie its a 'real world problem' rather than hardware/software.
Title: Re: New C library - testers required
Post by: Webbot on June 20, 2009, 01:38:40 PM
Have released version 1.3 at http://webbotavrclib.sourceforge.net/ (http://webbotavrclib.sourceforge.net/)

Read Version.h to see whats changed.

The main differences have come about from trying to debug a Sabertooth motor driver in 'Packetized Mode'. Its a real swine. It auto-detects the baud rate from the first, and only the first, character you send it which is meant to be hex AA. Once set you cannot change it. So contact bounce on the Axon power switch, amongst other things, can mean that you accidentley send it a 'glitch byte' - and it then uses this to mis-guess the baud rate. Has taken an age to get right - and one side effect is that UARTs aren't now automatically initialised to a default baud rate. I've also discovered that if you have a level shifter, eg Max232 or others, in place at the same time for debugging via Hyperterminal then this can cause additional issues.

The whole Sabertooth library interface has changed a bit - in that MAKE_SABERTOOTH_DRIVER now has an additional parameter to allow you to select a protocol. This can either be SIMPLE (ie one byte per motor but limited to one card, or two motors, per UART) or PACKETIZED (the original design - ie many cards with one UART and now hopefully does the correct auto baud set up). If you are getting started then I'd suggest the SIMPLE mode to start with as it is not prone to these errors as the baud rate is set on the DIP switches.

Anyways - the docs now show up to date examples for both methods of control

Webbot

Title: Re: New C library - testers required
Post by: Ro-Bot-X on July 01, 2009, 07:08:50 PM
Webbot, how is the I2C slave going? did you have a chance to work on it?

I need to start testing the motor controller and without the library I can't do it. I have tested part of the controller code on Arduino, using their Wire library, but that doesn't fit in the tiny2313. So I have 2 options: use avrlib or bascom. Altho Bascom has a demo version that can program the tiny2313, I don't want to pay $15 for the hardware I2C Slave library. There is a third party hardware library for Bascom in (written in ASM) but it's in german and I can't understand how to use it. I could use the software library, but it takes too much space I can use for control code. I have no experience with avrlib yet so I don't know if I2C takes a lot of space in the flash and how to set it up to work as a slave.

Please let me know of your thoughts on this matter.

Thanks a lot.
Title: Re: New C library - testers required
Post by: Webbot on July 01, 2009, 08:13:11 PM
Webbot, how is the I2C slave going? did you have a chance to work on it?

I need to start testing the motor controller and without the library I can't do it. I have tested part of the controller code on Arduino, using their Wire library, but that doesn't fit in the tiny2313. So I have 2 options: use avrlib or bascom. Altho Bascom has a demo version that can program the tiny2313, I don't want to pay $15 for the hardware I2C Slave library. There is a third party hardware library for Bascom in (written in ASM) but it's in german and I can't understand how to use it. I could use the software library, but it takes too much space I can use for control code. I have no experience with avrlib yet so I don't know if I2C takes a lot of space in the flash and how to set it up to work as a slave.

Please let me know of your thoughts on this matter.

Thanks a lot.

I'm currently working on adding SPI support and, more specifically, MicroSD memory cards that build upon it. Which doesn't help you. My main issue with I2C being that I have no I2C slave hardware to test against. So I2C is still back burner as its hard to write support for something you cant test. I would also suggest that to make your board more commercial then you should look at something like the Sabertooth boards. They are excellent as they can be fed via a UART, a servo pulse, PWM etc etc let alone I2C or SPI or even an analogue signal. But flexibility like this requires a mcu with a lot of capabilities.

My current lib supports ATMega8,168,32,640 but, since it uses files from Atmel to auto-generate the files, then I have just tried it for ATtiny2313 and it works ok (some atmel files are rubbish and contain wrong data which I keep telling them about). ie my lib so far should support tiny2313 but is still missing I2C support. The main difference is my currently supported chips support I2C/TWI, SPI etc whereas ATtiny2313 uses Universal Serial Interface a kind of superset of stuff including I2C so would need some special handling anyway.

Afraid i know zilch about basic. Could you use AVRlib? - well maybe. I say 'maybe' because their code is targeted at a finite set of mcus which may, or may not, include tiny2313. eg some of their examples dont work on the Axon/ATMega640. The Atmel website is a good ref for specific code for specific chips. Whether its I2c/TWI or the tiny2313 Universal Serial Interface is probably important.

Just being a pain but 'why did you settle on the tiny2313, build the board, and then worry how to write the s/w and see if it would fit?'

Seems like SoR may be able to settle on a chip that is 'overpowered' for most modules but then go for bulk purchase to keep the cost down. By settling on a std chip, ATMega168 for example, then you could share libraries. ie portability vs saving a few cents.

So where now - if Bascom and AVRlib are not solutions for you then I could help you to write the software support (either in my lib or as a one off) but would need a sample card to do it and test it.

Hope that helps - but may just make you go 'aaaaaargh'.

Webbot



Title: Re: New C library - testers required
Post by: Ro-Bot-X on July 02, 2009, 05:17:10 AM
The main difference is my currently supported chips support I2C/TWI, SPI etc whereas ATtiny2313 uses Universal Serial Interface a kind of superset of stuff including I2C so would need some special handling anyway.

Actually, tiny2313 has TWI/I2C. Tiny861 that I wanted to use in the first place has USI.

Quote
Just being a pain but 'why did you settle on the tiny2313, build the board, and then worry how to write the s/w and see if it would fit?'

Well, stupid me. I wanted to use tiny861 because it has 8k flash and I could use arduino, but it has only USI and no UART. And I wanted to make the controller like the Sabertooth controllers. But in 2k it's going to be impossible, unless I'll do it in assembly (that I don't know).

Quote
Seems like SoR may be able to settle on a chip that is 'overpowered' for most modules but then go for bulk purchase to keep the cost down. By settling on a std chip, ATMega168 for example, then you could share libraries. ie portability vs saving a few cents.

Yes, I'll never use the tinys anymore, all boards will have a mega168 from now on.

Quote
Hope that helps - but may just make you go 'aaaaaargh'.

It surelly does.

But here is the thing. I got 2 boards. I'll send you one, perhaps you can help out with the code. Sure, I can buy that stupid bascom comercial lib and do it just for myself (can't make it open source...) so I don't throw in the garbage a good enough board. Just send me a PM with your address and I'll send it to you free of charge. All populated with parts.

Thanks for your time.
Title: Re: New C library - testers required
Post by: Admin on August 10, 2009, 07:13:12 AM
First, I'm announcing my official support for Webbots library. Meaning, I'll actively be encouraging people to use it, and I'll be using it for my new [fully open sourced] projects too.

I read through the manual yesterday and I liked what I saw . . . despite the long emails I sent to Webbot that might suggest otherwise :P
(call me a perfectionist! hehe)

Any 'noob-friendly' EEPROM support yet for your library? All Axons purchased since summer of '09 have proper EEPROM fuses enabled.
http://www.societyofrobots.com/member_tutorials/node/309
Title: Re: New C library - testers required
Post by: Admin on August 14, 2009, 11:03:03 AM
I've decided to use your library today to reprogram my robot fish from scratch. It uses a very old Axon version, using the ATmega2560, and the button activation is inverted in hardware.

Since the 640 and 2560 are exactly the same except memory size, anything I need to change in the ATmega640.h file before making it an ATmega2560? (other than the top two lines, of course)

And what are these .a files?

I was about to ask about the button inversion, but then I noticed in axon.h you reused most of my code, including button code that only works on the really old Axon prototype :P
(you should probably leave credit for my code at the top, saying modified by webbot or whatever ;D)



Also, I see this:
Quote
// ADMIN - not sure why, but this interrupt is being called.  I'm not sure what the PD0 pin is hooked up to on the Axon.
// this is basically the cause of the reset.
EMPTY_INTERRUPT(INT0_vect);
Where in my Axon code is that?
Title: Re: New C library - testers required
Post by: Webbot on August 17, 2009, 05:43:26 PM
The .a files are the libraries.
Take all of my code and compile it for the 640. You now have a load of compiled .o files. If I just gave you all of these .o files then you would have to add them to your link process.

So think of the .a library files as being like a zip file that contains all of these .o files. Whats the benefit well it means that my lib comes pre-compiled. So you just compile 'your' code and then combine it with my already compiled code. Of course my libraries (the .a files) contain lots of stuff you may not actually use - well thats fine - the link process will only include my code that you have referred to - other stuff gets left out.

This means that every time you compile your code then it doesn't have to recompile mine (as it
hasn't changed anyway).

My download includes .a files for ATMega8, ATMega168, ATMega32 and ATMega640. For an ATMega2560 version it will take a few minutes but then a while to make an official release - or I'll just email it to you.

The Axon system file: credit where credit is due. Not hiding anything but was trying to put together a version for you yo play with.

The EMPTY_INTERRUPT stuff was DEFINITELY there in early versions of the Axon lib and looked like a 'workaround' to unexpected interrupts that would otherwise reboot the device. It may have been in earlier versions of the TImer code that has since been re-written. I'll remove it from my lib.

Have been away, and am still away for a few days. My internet is down - am using a friends machine. So bear with me!

New version imminent (next week or so) with some doc fixes and more examples and Blackfin, SPI, EEPROM and microSD card support
Title: Re: New C library - testers required
Post by: Admin on August 17, 2009, 07:52:27 PM
Quote
My download includes .a files for ATMega8, ATMega168, ATMega32 and ATMega640. For an ATMega2560 version it will take a few minutes but then a while to make an official release - or I'll just email it to you.
Hmmm I plan to use it tomorrow at work . . . whats the fastest way? Does it actually need to be added, or I can just compile without it and it'll just take a little longer?

Quote
The EMPTY_INTERRUPT stuff was DEFINITELY there in early versions of the Axon lib and looked like a 'workaround' to unexpected interrupts that would otherwise reboot the device. It may have been in earlier versions of the TImer code that has since been re-written. I'll remove it from my lib.
The early Axon code was all a hacked up version of the outdated AVRlib that didn't actually support the ATmega640. And I'm still a weak coder . . . may the old code be used as an example of how not to code :P

Quote
New version imminent (next week or so) with some doc fixes and more examples and Blackfin, SPI, EEPROM and microSD card support
Any plans for I2C? :P

Sorry for sounding demanding, I'm starting to really like your library, and want to push the limits (without my coding skill being the limit) ;D
Title: Re: New C library - testers required
Post by: Webbot on August 18, 2009, 07:02:45 PM
ATMega2560 - I'll be emailing you an unofficial release - backward compatible with the last release of the lib.

I have written a program to auto generate the device files for each new processor based on the XML part files from ATMEL.  So, in theory, its very easy to add any new ATMEL device. The downside is that I keep finding/reporting bugs in ATMELs own XML files - doh! Whilst they are fixable by me then I have to chase them to make sure that future releases don't 'overwrite' my fixes.

I2C - yep its on my list. I definitely need to provide routines for an I2C slave and an I2C master. The OSCAR project implies a device that is both master and slave - but that extra complexity will need to wait for now until the basics are done. Having no I2C devices then I will be flying blind anyway. Guess I need some voting/polling software for future features.

Keep me/us informed on your on-going progress.
Title: Re: New C library - testers required
Post by: Admin on August 19, 2009, 07:02:42 AM
Having no I2C devices then I will be flying blind anyway.
I'll be using it as soon as you release it ;D

Quote
Guess I need some voting/polling software for future features.
I can arrange for that . . . but expect a lot of people requesting really odd things, like 'a library that detects faces for my photovore robot'.

Personally, I think it better for people to submit their own working code, then you add it to the library. At the moment, I think the basics are more important, like SPI and I2C, and bug fixing. Feature creep for later ;D

edit: Now that I think about it, after you get I2C working, can you convert this code over to your library?
http://www.societyofrobots.com/robotforum/index.php?topic=8393.0
It works using AVRlib I2C, so should be easy to port. Or if you're busy, I'll do it using your I2C documentation ;D
(but you'll probably nod your head in disapproval of my hacked up code, hehe)
Title: Re: New C library - testers required
Post by: jaime on August 19, 2009, 11:32:35 AM
Hi.  I'm a robot noob (1st post, yay).  But I'm a pretty good C programmer, so I'm not a complete loss!

Anyway, I can't get the rprintf functions to work.  I'm working with the AXON micro controller.

My code is below.  The program works in its current state.  The status led blinks every second or so.  However, if I uncomment the rprintf line, the AXON "crashes".  There is no blink, there is nothing.  I assume the program has "crashed" but I can't tell :(

Any ideas?  Thanks!


// Specify which board is being used.
#include "sys/axon.h"
#include "uart.h"
#include "rprintf.h"

typedef void (*puart_sbyte)(unsigned char);


/*
 * @brief Called once for hardware initialization.
 *
 * DO NOT USE ANY CLOCK FUNCTIONS HERE.  Use 'delay' functions instead.
 *
 */
void appInitHardware(void)
{
    uartSetBaudRate(UART1, 115200);
    rprintfInit((puart_sbyte)&uart1SendByte);
}


/*
 * @brief Called once to allow variable initialization.
 *
 * Clock can be used here.
 *
 * @param loop_start contains the current clock value in uS.
 * @return pause counter
 */
TICK_COUNT appInitSoftware(TICK_COUNT loop_start)
{
    return 0;
}

/*
 * @brief "main" function called repeatedly; the main loop.
 * @return the time to wait before callign in uS.  1,000,000 uS = 1s.
 */
TICK_COUNT appControl(LOOP_COUNT loop_count, TICK_COUNT loop_start)
{
    statusLED_set(loop_count % 2);
    // rprintf("Hello world...\n");
    return 1000000;
}
Title: Re: New C library - testers required
Post by: Admin on August 19, 2009, 11:45:08 AM
jaime, I got the same error about 10 days ago. This email, from Webbot, describes how to fix it.


Quote
The problem you are seeing is caused by a "funny" I introduced in the last release (its already fixed but I haven't re-released yet). The problem came about when I added different sorts of uarts ie both hardware and software. The docs also need changing as 'uartSetBaudRate' should be replaced by 'uartInit'.

So change your 'uartSetBaudRate' to 'uartInit' - else the program will hang on your first use of rprintf.

You will still get the compiler warning (until I manage to do a new release) but the code should still run ok.

There's also a bug in the documentation on page 57 where the
include "servos"
should obviously be
include "servos.h"
Title: Re: New C library - testers required
Post by: jaime on August 19, 2009, 11:59:29 AM
jaime, I got the same error about 10 days ago. This email, from Webbot, describes how to fix it.


Quote
The problem you are seeing is caused by a "funny" I introduced in the last release (its already fixed but I haven't re-released yet). The problem came about when I added different sorts of uarts ie both hardware and software. The docs also need changing as 'uartSetBaudRate' should be replaced by 'uartInit'.

So change your 'uartSetBaudRate' to 'uartInit' - else the program will hang on your first use of rprintf.

You will still get the compiler warning (until I manage to do a new release) but the code should still run ok.

There's also a bug in the documentation on page 57 where the
include "servos"
should obviously be
include "servos.h"


Perfect, that did the trick!

jaime
Title: Re: New C library - testers required
Post by: Admin on August 20, 2009, 07:20:14 AM
Webbot, I'm fairly sure its your code that has the H6/E6 bug . . .

I'm using this below code. Its a stripped down version of your photovore code in your manual.
Code: [Select]
#include "sys/fish_2560.h"
#include "servoPWM.h"
#include "a2d.h"
// Define two light sensors connected to ADC channels 0 and 1


// Define two servos
SERVO left = MAKE_SERVO(FALSE, E6,1500, 500);
SERVO right = MAKE_SERVO(TRUE , H6,1500, 500);

// Create the list - remember to place an & at the
// start of each servo name
SERVO_LIST servos[] = {&left,&right};
// Create a driver for the list of servos
SERVO_DRIVER bank1 = MAKE_SERVO_DRIVER(servos);


// In my initialising code - pass the list of servos to control
void appInitHardware(void){
// Initialise the servo controller
servoPWMInit(&bank1);
// Give each servo a start value of 'stop'
act_setSpeed(&left, 0);
act_setSpeed(&right,0);
}

TICK_COUNT appInitSoftware(TICK_COUNT loopStart){
return 0;
}

// This is the main loop
TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart)
{
int i;

for(i=0;i<100;i++)
{
act_setSpeed(&left,50);
act_setSpeed(&right,50);
delay_ms(20);
}
for(i=0;i<100;i++)
{
act_setSpeed(&left,-50);
act_setSpeed(&right,-50);
delay_ms(20);
}

return 20000; // wait for 20ms to stop crazy oscillations
}

The sys file fish_2560.h is exactly like the axon sys file, except this:
Code: [Select]
cbi(PORTG, PG5);  // disable pull-up resistor for v1e and earlier
//sbi(PORTG, PG5);  // enable pull-up resistor for v1f and later
And that 640 is swapped for your 2560 files.

The problem is, E6 and H6 don't work. Both pins work fine with my non-webbotlib code. If I change the code to this, using different pins, it works fine:
Code: [Select]
// Define two servos
SERVO left = MAKE_SERVO(FALSE, E5,1500, 500);
SERVO right = MAKE_SERVO(TRUE , H5,1500, 500);

Anyone else having trouble getting H6 or E6 working on their Axon using the WebbotLib?
Title: Re: New C library - testers required
Post by: jaime on August 20, 2009, 11:50:19 AM
This simple program below works for me, using E6.

Code: [Select]
// Specify which board is being used.
#include "sys/axon.h"
#include "uart.h"
#include "rprintf.h"
#include "core.h"
#include "servos.h"

typedef void (*puart_sbyte)(unsigned char);

SERVO servo = MAKE_SERVO(FALSE, E6, 1500, 500);
SERVO_LIST servos[] = {&servo};
SERVO_DRIVER bank1 = MAKE_SERVO_DRIVER(servos);

void appInitHardware(void)
{
    uartInit(UART1, 115200);
    rprintfInit((puart_sbyte)&uart1SendByte);
    servosInit(&bank1, TIMER1_COMPAREA);
}

TICK_COUNT appInitSoftware(TICK_COUNT loop_start)
{
    act_setSpeed(&servo, DRIVE_SPEED_CENTER);
    return 0;
}

TICK_COUNT appControl(LOOP_COUNT loop_count, TICK_COUNT loop_start)
{
    if (loop_count % 2 == 0) {
        act_setSpeed(&servo, DRIVE_SPEED_MAX);
    } else {
        act_setSpeed(&servo, DRIVE_SPEED_MIN);
    }
    statusLED_set(loop_count % 2);
    rprintf("Hello world...\n");
    return 1000000;
}
Title: Re: New C library - testers required
Post by: Webbot on August 20, 2009, 05:18:34 PM
So the differences are that 'jaime' is using software servo control (which works) and 'admin' is using hardware PWM for the servos (doesn't work).

Admin is using H6 which is also OC2B which is Timer2 channel B, and using E6 which is not a PWM output pin !
Also Timer2 is only an 8 bit timer whereas hardware PWM for servos, as per manual, really requires a 16 bit timer.

@Admin - are you seeing an error msg flashing on your status LED as I'm guessing the lib is not doing anything as you've asked it to do PWM for servos on a non 16 bit timer, and to E6 which is not a PWM output. So it ain't ouputting anything - and is flashing an error number on the status led.

--edit--
so you should either get 7 flashes on the LED (timer must be 16 bit) or 12 flashes (the pin, E6, is not a PWM output)

-- edit2 --
@jaime I can tell from your code comments that you are a top notch C programmer. First post - you say.  You're more than welcome
Title: Re: New C library - testers required
Post by: Webbot on August 20, 2009, 05:41:44 PM
Have released version 1.4 on SourceForge.

There is now only one download - which includes all of the libraries as well as the documentation PDF. Since some folk found it hard to locate the PDF docs. So now its just a one click download.
So whats new:-
ATMega2560 support
New SPI interface support using SPI hardware, or in software or via any UARTs that supports SPI mode (ie ATMega168, ATMega640 and ATMega2560)
Added EEPROM support and documentation.
Added new 'CLAMP' function to libdefs.h
Fixed some doc bugs.
Work in progress for next release is Blackfin camera, SSD card, and I2C.

Decision to upgrade is up to you - but bug fixes will only be made to current/future code streams.

Thanks to all who have downloaded and tried and especially to Admin and Surveyor corp for their on-going patience and commitment.

-- edit --
the SourceForge site should now have some area to post messages. Haven't tried it yet so dont know what its like or whether it will send me an email. Give it a go.
Plan is to continue to release versions on sourceforge but to hold a 'last tested by SoR Admin' copy/link on this site.
Title: Re: New C library - testers required
Post by: Admin on August 21, 2009, 07:01:58 AM
Quote
So the differences are that 'jaime' is using software servo control (which works) and 'admin' is using hardware PWM for the servos (doesn't work).

Admin is using H6 which is also OC2B which is Timer2 channel B, and using E6 which is not a PWM output pin !
Also Timer2 is only an 8 bit timer whereas hardware PWM for servos, as per manual, really requires a 16 bit timer.
oops . . . I thought I was using software PWM all this time . . . lol I feel dumb now . . .

Quote
Plan is to continue to release versions on sourceforge but to hold a 'last tested by SoR Admin' copy/link on this site.
I'll probably wait for another version release or two before establishing a permanent link, just to make sure all the major issues are ironed out.

Just so everyone else knows, I'm rewriting my robot fish code from scratch to use the Webbotlib, my biped (and Biped Engine v3) is now using this lib, the Axon II will fully support it, and I *may* rewrite my ERP code to use the lib too.
Title: Re: New C library - testers required
Post by: Admin on August 21, 2009, 01:00:50 PM
I noticed that I can only use one timer thingy per servo bank. For example, these don't work:

Code: [Select]
servosInit(&bank1, TIMER1_COMPAREA);
servosInit(&bank2, TIMER1_COMPAREA);
Code: [Select]
servosInit(&bank1, TIMER2_COMPAREA);
servosInit(&bank2, TIMER2_COMPAREA);

but these work fine:
Code: [Select]
servosInit(&bank1, TIMER1_COMPAREA);
servosInit(&bank2, TIMER2_COMPAREA);
Code: [Select]
servosInit(&bank1, TIMER1_COMPAREA);
servosInit(&bank2, TIMER1_COMPAREB);

Not sure if you are aware of this, or if it's that important to fix . . .
Title: Re: New C library - testers required
Post by: Webbot on August 21, 2009, 01:41:14 PM
Yep - thats the whole point of having a 'bank'. All the servos in a bank are connected to one timer compare channel.

So in your first example:-
Code: [Select]
servosInit(&bank1, TIMER1_COMPAREA);
servosInit(&bank2, TIMER1_COMPAREA);

Then you may as well put all the servos into bank1 and get rid of bank2 altogether. Obviously a given timer compare channel (ie a bank) can only cope with a finite number of servos (as per manual) otherwise the frequency of issuing the pulse to each servo becomes too long.

Have you got a status LED registered (ie are you on the AxonI or AxonII)? If so then it should start flashing an error message (5 flashes, 2s pause, 5 flashes, 2s pause etc) when you connect bank2 since TIMER1_COMPAREA is already in use - which is what the 5 flashes means as listed in errors.h
Title: Re: New C library - testers required
Post by: Admin on August 21, 2009, 02:10:46 PM
oh! I guess that makes sense then.

As for the status LED error, didn't notice it. I have the Axon and the robot fin tester in my giant water tank like 10 feet away from me. I was too lazy to get up and check it out :P
(yeap, it flashes as you said, with a ~1.5s pause :P)

This error detection + flashing LED idea is interesting. For the Axon II, what if it actually displayed an error number on the display while flashing? That'll limit to 10 errors, but you can flash two numbers in succession for many more.
Title: Re: New C library - testers required
Post by: sonictj on August 21, 2009, 03:32:14 PM
Quote
That'll limit to 10 errors, but you can flash two numbers in succession for many more.


10 numbers but you can also make different combination with the leds. 2^7 for 7 segments is 127 different combinations excluding all off.
Title: Re: New C library - testers required
Post by: Webbot on August 22, 2009, 05:11:06 AM
This error detection + flashing LED idea is interesting. For the Axon II, what if it actually displayed an error number on the display while flashing? That'll limit to 10 errors, but you can flash two numbers in succession for many more.

On the Axon I use the on board LED, and the Axon II uses the decimal point of the segment display. Once I get an AxonII then the plan is to also be able to send errors to any output ie via UART, on board LCD display, or the on board single LED segment as a marquee. Flashing LEDs is a good start point but I've now got a lot of error codes so counting the flashes can be difficult for the larger numbers. The only issues with using the whole 7 segment display is it then becomes reserved for the library which is why I've used the decimal point. I guess I could make it so that the user can access the display but once an error is logged then it ignores anything else from the users program.

Note: don't forget that your own code can also use this feature. My error codes are negative numbers which cause the LED to flash rapidly. Your own codes should always be positive numbers which cause it to flash more slowly - so that you can tell the difference between your own errors and those reported by the library. This is useful if there is a point in your code where something unexpected happens - so you could signal the error and 'stop the robot'.
Title: Re: New C library - testers required
Post by: Webbot on September 02, 2009, 12:40:28 AM
Version 1.5 now released - see my signature for website link.

A2D problems fixed, software servo PWM improved when lots of servos,  some new functions added to rprintf.

See version.h for details.

This release also contains an 'alpha' version of Blackfin support - so no docs for now - but anyone that has used Admins library should see that the functions in Cameras/Surveyor/Blackfin.h are familiar. Am adding support for other Blackfin commands before releasing/documenting.

Thanks to Admin for continuing to test this to destruction !!

Webbot
Title: Re: New C library - testers required
Post by: Admin on September 02, 2009, 07:17:09 AM
Quote
Thanks to Admin for continuing to test this to destruction !!
yea quite literally . . . all previous versions will cause your servos to overheat and fry - and I wouldn't have noticed it if it wasn't for all the debugging I went through to figure out the ADC bug. :P

I just installed the latest version, and I'll play around with it all today. You'll hear back if/when I find problems.

Quote
*         Added 'fraction.h' - not documented as you need to understand Fabonacci sequences. Too long to describe !! But is used
 *            by other lib functions to avoid floating point maths library.
Is this a response to me adding the math.h include in my code? :P
Do I still need it?

And I'm sure you have a good reason for rprintfCharN, but I can't figure out how its useful . . .

Also, since you have seen my code . . . Webbot, I think my hardware.h file method should be used in future versions. Its not a big deal for a robot with just a handful of external stuff, but becomes much more useful to declutter/organize code when you have 10+ servos and many sensors.

Oh, and I'm working on a 'getting started with WebbotLib for the Axon' tutorial. It's 90% done. I'll release it when I'm confident all the bugs are thoroughly squished. ;D
Title: Re: New C library - testers required
Post by: Webbot on September 02, 2009, 08:31:58 AM
Is this a response to me adding the math.h include in my code? :P
Do I still need it?
Yep you still need math.h - until such time as I can get around to documenting the fraction stuff. The fraction stuff is also only useful for multiplying by a real number - the result is always an integer. But its good for mapping linear values - as with some sensors, or when mapping between YUV and RGB values from cameras like the Blackfin (ah hah - that's why its been added).

And I'm sure you have a good reason for rprintfCharN, but I can't figure out how its useful . . .
No worries - one day you may find a purpose ;)  I have used it elsewhere in the lib as it reduces the amount of flash taken up by things like: 
Code: [Select]
rprintf("-------------------------\n");
rprintf("|  Menu Options: |\n");
rprintf("-------------------------\n");

Also, since you have seen my code . . . Webbot, I think my hardware.h file method should be used in future versions. Its not a big deal for a robot with just a handful of external stuff, but becomes much more useful to declutter/organize code when you have 10+ servos and many sensors.
The hardware.h file is a way you have used to make your own code look neater. Its isn't part of the library and changes for each project. My 'dev/*.h' files detail ALL of the processor hardware available - and your file maps the connected devices onto the processor hardware for a given project.

So the best place to comment on it is in your 'Getting started with Webbot lib guide' - as your recommendation of one way of working.

I have done a similar thing myself with my example/test code whereby I can recompile the same example for all of the supported boards/processors.
Title: Re: New C library - testers required
Post by: Admin on September 02, 2009, 09:34:15 AM
Just letting everyone know I've verified that the ADC and servo frying bugs have been squished. Still a minor issue with the servo code (minor servo jumping), but me and Webbot are working on it behind the scenes.


Quote
And I'm sure you have a good reason for rprintfCharN, but I can't figure out how its useful . . .
No worries - one day you may find a purpose ;)  I have used it elsewhere in the lib as it reduces the amount of flash taken up by things like: 
Code: [Select]
rprintf("-------------------------\n");
rprintf("|  Menu Options: |\n");
rprintf("-------------------------\n");
Oh! For purposes of satisfying OCD! :P (just poking fun, I understand why now)


Quote
The hardware.h file is a way you have used to make your own code look neater. Its isn't part of the library and changes for each project. My 'dev/*.h' files detail ALL of the processor hardware available - and your file maps the connected devices onto the processor hardware for a given project.

So the best place to comment on it is in your 'Getting started with Webbot lib guide' - as your recommendation of one way of working.
Yea that was the current plan, and how I structured my tutorial. I'll keep the status quo, then.
Title: Re: New C library - testers required
Post by: Webbot on September 16, 2009, 03:23:46 PM
New version 1.6 released (read version.h from the download) but:-

1. fixed delay issues reported by Admin
2. fixed servo twitch issues reported by Admin when controlling servos (like loads of servos!) via software rather than by hardware PWM. ie Axon is also acting as a servo controller board. May be a small twitch still left but then the controller cant run your program, manage 20 servos, do USART comms etc etc. There are only so many microseconds it has in the day. Bit like me?
3. Added I2C master routines. Nice'n'small'n'tight. Your I2C based sensors will be built into the lib in the coming weeks/months - so unless you want to play with I2C then dont worry. It just works. Oh No - its alpha release of I2C so I will be bombarded with comments that it 'just doesn't' !!
4. Alpha version of Blackfin camera support plus documentation. Watch this space for up'n'coming apps to help support the excellent Blackfin from your PC.

Download from  the usual place - see my signature.
Title: Re: New C library - testers required
Post by: Admin on September 21, 2009, 01:05:43 PM
The alpha version for I2C in v1.6 has a bug. This is how to fix it:

First, in appInitHardware(void), add this:
Code: [Select]
i2cSetBitrate(100);You won't need to do this manually in future versions, Webbot will be adding it in.

Second, in the sys file, enable internal pullups. For example, for the Axon, enable the pull-ups BEFORE DDRD:

Code: [Select]
sbi(PORTD, PD0); // SCL pull-up
sbi(PORTD, PD1); // SDA pull-up
DDRD = 0b11110011;  //configure ports for output

*Note that internal pull-ups shouldn't be used if you have external pull-ups already. The Axon doesn't come with external pull-ups.
Title: Re: New C library - testers required
Post by: Webbot on September 21, 2009, 01:41:17 PM
These two mods were just a temporary fix for 1.6 to get things going.
Come 1.7 then you wont need to do either of these.

*Note that internal pull-ups shouldn't be used if you have external pull-ups already. The Axon doesn't come with external pull-ups.
The internal pullups are between 20k and 50k. So if you have external pullups like 4.7k then the effect of the internal pullups will be negligible. ie the the internal pullups can ALWAYS be turned on (which is what the next release will do).
Title: Re: New C library - testers required
Post by: Admin on September 21, 2009, 02:00:44 PM
Quote
The internal pullups are between 20k and 50k. So if you have external pullups like 4.7k then the effect of the internal pullups will be negligible. ie the the internal pullups can ALWAYS be turned on (which is what the next release will do).
Even better . . . less confusion for beginners, too. :D


So uhhhh what happens after v1.9? What version will it be called :P

Anyone else current using WebbotLib for anything interesting?
Title: Re: New C library - testers required
Post by: Webbot on September 21, 2009, 03:07:00 PM
So uhhhh what happens after v1.9? What version will it be called :P
Luckily computers have lots of fingers - so I'm guessing 10,11,12 etc  ;)
But since most things have been getting a good hammering: motors, sensors, servos, timers etc etc then I feel we are close to the first production release - Version 1.0. Yeah I know that conflicts with the past but live with it for this first release.
Subsequent interim releases will then be 1.0.1, 1.0.2, 1.0.3 until a production 1.1 release is made.

Anyone else current using WebbotLib for anything interesting?
C'mon folk - I know from my PMs who some of you are!  Give us the news bad/good/indifferent! Even if you've just been playing.
 
Title: Re: New C library - testers required
Post by: Admin on September 21, 2009, 06:17:10 PM
Quote
so I'm guessing 10,11,12 etc
I'm thinking 1.9, 1.10, 1.11, 1.12, 1.13, etc.

Otherwise people who search for help on the forum might get confused . . .
Title: Re: New C library - testers required
Post by: Webbot on September 22, 2009, 12:21:27 AM
Version 1.7 is now available  (For Admin this is called 1.0.1.7.8.3.2  ;D)

Whats fixed:
The I2C issues discussed in previous threads.

Whats new:
Toshiba TB6612FNG motor driver - cool little motor driver
Dynamic Engineering - ACCM2D2 3 axis accelerometer
Honeywell HMC6343 compass, with roll & pitch
iopin now has a pulseIn and pulseOut feature
Have restructured the way sensors work - see below *

NB Some flles have been deleted or have been moved. So you should delete your previous install directory before loading this version - to make sure that all the 'old' stuff gets removed.

* Sensors are now organised by type/make/model.h
Where:-
type: is stuff like: distance, voltage, compass, current, acceleration etc
make: is the manufacturer: Phidgets, Devantech, Sharp etc
model: is the part number of the device: TB6612FNG

The old sensorRead and sensorReadRaw functions have gone!! They only returned one value, and some sensors, like accelerometers return lots of values. Also, due to C limitations, they always had to return the same data type. And this became a pain.

Instead they can be accessed via <type>Read(sensor) eg distanceRead, compassRead etc.
But note that the read doesn't return a value - it just reads the sensor and stores away the values. These values can then be accessed (without re-reading the device). Each type can now potentially return a different value eg floats vs uint16_t etc - but all of the devices of the same type will return the same value (ie you can still swap one 'compass' for another without changing your code).
The manual explains all !!

The attached example shows how to use all of the sensors. NB This is not meant to be compiled/executed because, with so many sensors, some of the IOPins are re-used for multiple sensors. Its only for reference.
Title: Re: New C library - testers required
Post by: Admin on September 22, 2009, 01:17:03 PM
Just noting there was a bug in the Accelerometer and Compass code, but its been figured out and the next version will have the fix.

Webbot doesn't have many of the sensors, so its hard to verify code.

All the other code seems to be working fine.
Title: Re: New C library - testers required
Post by: Webbot on September 24, 2009, 08:59:23 PM
Version 1.8 available

Whats fixed: ACCM3D2 and HMC6343 - tested by Admin

Whats new: MPX5100a pressure sensor, ADXL335 accelerometer, IDG500 gyro:- all untested (alpha release)

I've also added a dump routine for each sensor type ie accelerometerDump(device) or compassDump(device) etc - this will dump the last read value of the device to the current rprintf destination meaning you dont have to worry whether to use %d, %u, %ld, %lu etc with your rprintf command - it just does it!

Remaining code remains unchanged and stable. Admin has tested the servo code (with like 10? servos), timers, delays, etc and no bugs currently outstanding.

The library is now getting quite 'feature rich':-

Sensors: 2 x accelerometers, 2 x compasses, 4 x current sensors, 3 x  sonars + many Sharp IR, quadrature encoders, 1 x gyro, 1 x humidty sensor, 1 x pressure sensor, 1 x temperature sensor, 1 x voltage sensor, 1 x camera. Just plug them in and go - no sensor coding required - swap one sensor for another with only two code line changes !!!

4 x commercial Motor drivers/controllers boards

Servos via hardware PWM or software PWM.

Bus options: I2C, SPI, UART, software UART, SPI over UART, SPI in software

Support for ATMega8, 168, 32, 640, 2560 and the Axon, Roboduino, and Baby Orangutan boards

And lots more

Plug, plug !!

Enjoy...
Title: Re: New C library - testers required
Post by: Ro-Bot-X on September 24, 2009, 09:18:51 PM
Nice! Thank you for your efforts! This lib has grown a lot! However, I was waiting patiencefully for some other things to be added like:

Can you add the tiny family (2313... and others) to the microcontrolers? I mean set up the USI to work as TWI (I2C), interrupts, UART... ? Also I know you've written code for AVRcam on Axon, can you add that camera to the library?

Thank you.
Title: Re: New C library - testers required
Post by: Webbot on September 24, 2009, 10:18:06 PM
I do have some tiny 2313 chips now but with only 2k of program space then I'm not sure how usable they are gonna be!

The 'plug'n'play' or 'just does it' approach of my lib always comes at a price and makes life easier for a 'master' board - but I'm not convinced its the solution for a slave sensor/controller device which needs to be a lot tighter.

I'll try to remember to send you a version with support so you can at least have a play (PM me with your email addr).

The tiny 2313 as a 20 pin dip package is not much smaller than say a Mega168 which has 8x more program space and isn't much different in price. So its the usual trade off ie 'easy but requires more space' vs 'compact but harder to code'.

I don't have any I2C devices so its always been hard to experiment with I2C master/slave but now Admin has tested that my I2C master code works then I can now play with I2C slave coding knowing that the master is working ok.

But 'Master and Slave' coding, as required by OSCAR on this forum, is even more complex and I'm not convinced that it will work (too much bus contention) and is very low down on my priority list for now.

AVRcam I haven't done - I've done the Blackfin. ALL of the 'devices' in the lib are supported by ALL of the target devices of my lib. However: the code may 'work' for the tiny but it may not 'fit' into the available space !
Title: Re: New C library - testers required
Post by: Ro-Bot-X on September 25, 2009, 05:27:32 AM
Oh well, don't get me wrong, there are 2 separate things, the tiny2313 and AVRcam. They are both slave devices tied to a "mega" master on a serial line (be it UART or I2C). Different projects. The thing that I'm interested for tiny2313 is setting up the USI to work as a regular I2C. The registers are different in contents and number, so I'm really curious if USI can work as a slave device (I know it can be done, they have a commercial lib for BASCOM-AVR).

Sorry, I must have confused you with someone else on this forum (mbateman) for the AVRcam. He has developed code for Axon to work with the AVRcam, see this thread: http://www.societyofrobots.com/robotforum/index.php?topic=6352.0 (http://www.societyofrobots.com/robotforum/index.php?topic=6352.0) Perhaps you can talk with him to integrate it in your lib?

Thanks!
Title: Re: New C library - testers required
Post by: Admin on September 25, 2009, 07:45:19 AM
Ro-Bot-X, i support getting AVRcam added. Do you own one and are willing to debug/test the code? The requirement to getting your sensor added is that you gotta own it and willing to test/debug alpha code. ;D
Or you can buy Webbot/admin one and we'll do it for you :P

As for the tiny2313 or any other memory limited mcu . . .
WebbotLib is designed to be feature-rich, powerful, and easy to use. This is a direct contradiction to what needs to be done to fit a program on a tiny . . . unless you plan to manufacture 20k+ units of something, the cost savings of a dollar or two isn't worth days of effort.
Title: Re: New C library - testers required
Post by: Admin on September 25, 2009, 08:48:19 AM
Oh, Webbot forgot to mention he also added the Toshiba TB6612FNG motor driver (alpha version).

I've been testing out the various sensors, and it turns out many of them don't match their datasheet. They have fairly bad manufacturing tolerances. So if you use a sensor with the library, keep in mind to calibrate your sensors!

I'll be testing some of the alpha versions today, and only report back if a bug has been both found and fixed.

As a side note . . . the manual gets thicker by ~15 pages per version. Mostly just added external hardware support. The manual is an easy read, but the size can still be intimidating to beginners. As such, I'm finishing up a  ~3 page crash course WebbotLib tutorial. It'll be released when we feel the library is 'beginner-proof'.
Title: Re: New C library - testers required
Post by: Ro-Bot-X on September 25, 2009, 09:02:38 PM
Ro-Bot-X, i support getting AVRcam added. Do you own one and are willing to debug/test the code? The requirement to getting your sensor added is that you gotta own it and willing to test/debug alpha code. ;D
Or you can buy Webbot/admin one and we'll do it for you :P

Yes, I have an AVRcam, I can do tests with it.

Quote
As for the tiny2313 or any other memory limited mcu . . .
WebbotLib is designed to be feature-rich, powerful, and easy to use. This is a direct contradiction to what needs to be done to fit a program on a tiny . . . unless you plan to manufacture 20k+ units of something, the cost savings of a dollar or two isn't worth days of effort.

OK, I get it. No problem, I'll survive without it. Webbot sent me something that might do the trick. Thanks!
Title: Re: New C library - testers required
Post by: Webbot on October 01, 2009, 01:49:25 PM
Version 1.9 released -

Added the following sensors:-
InvenSense IDG300
ST LPR530AL  - which measure pitch and roll and is good companion with
ST LY530ALH - which measures yaw
These two gyros have just been released by SparkFun along with an ADXL335 3 axis accelerometer (already supported) to give a '6 degrees of freedom' sensor.

Added support for ATMega328P processor.

Fixed an issue in the 'clock' where the occasional strange result was generated.

Changed GPS code so that baud rate is not 'auto initialised' to 4800baud. It is now up to you to set the required speed that the device communicates at.

servos.h - added 'setServosConnected' and 'servosSetSpeed' to allow you to send the same command to entire bank of servos.

Title: Re: New C library - testers required
Post by: Admin on October 01, 2009, 04:18:51 PM
ST LPR530AL  - which measure pitch and roll and is good companion with
ST LY530ALH - which measures yaw
These two gyros have just been released by SparkFun along with an ADXL335 3 axis accelerometer (already supported) to give a '6 degrees of freedom' sensor.
FYI for those who don't know, WebbotLib now supports the smallest 6 DOF IMU on the market:
http://www.sparkfun.com/commerce/product_info.php?products_id=9431 (http://www.sparkfun.com/commerce/product_info.php?products_id=9431)

Quote
Fixed an issue in the 'clock' where the occasional strange result was generated.
It was an overflow bug I found. Webbot, you mentioned you'd change the manual:
"It will, after every 7 minutes, wrap around to zero . . ."
Is it 7, or 3.5 now? (just checking)

Quote
Changed GPS code so that baud rate is not 'auto initialised' to 4800baud. It is now up to you to set the required speed that the device communicates at.
FYI for everyone, most GPS units are default (NMEA standard) at 4800. The Venus is 9600, and I'm sure others in the future will come even faster.

Quote
servos.h - added 'setServosConnected' and 'servosSetSpeed' to allow you to send the same command to entire bank of servos.
Webbot, in your manual its called ''servosSetConnected" :P

So, I just call this to turn off a bank?
servosConnect(&bank1);
Title: Re: New C library - testers required
Post by: Webbot on October 01, 2009, 06:07:50 PM
Is it 7, or 3.5 now? (just checking)
Have yet to do the exact maths - and it will now depend slightly on the  speed of the processor. - but its now about every 70 minutes


So, I just call this to turn off a bank?
servosConnect(&bank1);
No - that would 're-connect' the servos. Look at servos.h...
To disconnect you can use:

Code: [Select]
servosDisconnect(&bank1)or
Code: [Select]
servosSetConnected(&bank1, FALSE)
Title: Re: New C library - testers required
Post by: Admin on October 02, 2009, 08:15:47 AM
but its now about every 70 minutes
whoa . . .

Quote
So, I just call this to turn off a bank?
servosConnect(&bank1);
No - that would 're-connect' the servos. Look at servos.h...
To disconnect you can use:

Code: [Select]
servosDisconnect(&bank1)or
Code: [Select]
servosSetConnected(&bank1, FALSE)
lol here I am correcting your typos and I make a dumb one myself . . .

Anyway, I was playing around with your code yesterday and haven't found any new problems with it so far. :)

Oh and just an FYI to everyone else, WebbotLib is now as default too big for the ATmega8. You'll have to remove a bunch of libraries/stuff to get it to fit (otherwise you'll get a compiler error). But honestly, Webbot and I both feel its better to just not support the ATmega8 - its obsolete and the ATmega168 is much better.
Title: Re: New C library - testers required
Post by: dellagd on October 12, 2009, 04:39:29 PM
I'm impressed.
too much code.
nice ;D.
Title: Re: New C library - testers required
Post by: Webbot on October 14, 2009, 09:59:24 PM
Version 1.10 released

Accelerometers are so flakey! The existing code will try to return a reasonable value. But the manufacturing tolerances are so varied that these values may be inaccurate for your device. In which case you can calibrate the software to 'fit' your device.

Use the existing code to find min/max values for each axis then to make them more precise try adding
 accelerometerCalibrateX(device,min,max)
 accelerometerCalibrateY(device,min,max)
 accelerometerCalibrateZ(device,min,max)
in your appInitHardware to force the sensor to return sensible values.
 

Tested and fixed all sonars MaxBotix EZ1, Parallax Ping sonar, Devantech SRF-05
Tested and fixed BabyOrangutan B328 board. On board 1 Amp motor driver verified as working.
Sabertooth.h moved from Motors/Dimension to Motors/DimensionEngineering
Added supprt for LB1836M as used by older BabyOrangutan boards
Changed Toshiba TB6612FNG to allow either 3 or 2 pin control - see manual
Fixed conversions for Sharp IR distance sensors
Each sys file now has a sysInitHardware to init any devices built onto the board
All versions of rprintf now allow %u to print unsigned number
Removed 'servoPWM.h' - its only function is now merged into 'servos.h'
timer.h - added 'compareGetOutputMode' function
Title: Re: New C library - testers required
Post by: Webbot on October 27, 2009, 03:58:10 PM
Version 1.11 released (see my signature for URL)

version.h lists the changes but the main change is the ability to set up a custom hardware PWM output. This is useful if your motor driver isn't 'listed' or if you want to use PWM for other stuff - like dimming an LED etc.

No other code signatures have changed - ie your 'old' code from version 1.10 will still compile with this release.

Enjoy.

--- Edit ----

Known documentation issues:
1. The Maxbotix EZ1 sonar example in the manual should say:-
Code: [Select]
Maxbotix_EZ1 sensor = MAKE_Maxbotix_EZ1(F0);
Known library issues to be fixed in the next release:-
A. The ATMega328P has a problem with uarts that causes the machine to reboot

Title: Re: New C library - testers required
Post by: Webbot on November 03, 2009, 04:56:29 PM
Version 1.12 released (see my signature for URL). As most things have now been tested, by me or others, then this is the first general release.

version.h lists the changes - they are as follows:-

NB If you have any WebbotLib questions then please post under a new thread - DO NOT reply to this posting
Title: Re: New C library - testers required
Post by: Webbot on December 28, 2009, 02:57:11 AM
Version 1.13 released

See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page)

This includes the change for http://www.societyofrobots.com/robotforum/index.php?topic=9911.0 (http://www.societyofrobots.com/robotforum/index.php?topic=9911.0) although it should be treated as 'alpha' as I don't yet have my Axon II to test against.
Title: Re: New C library - testers required
Post by: madsci1016 on January 05, 2010, 10:04:24 PM
I'm trying to make sense of how to use the gpsNEMA header and code, i wish i had an example of how to access the data. For example, does gpsNEMA.latitude work?

Also it doesn't look like you parse out the "degrees of track true" from the NMEA messages, is this correct? Would you add that? I have a compass on my SAGAR BOT (http://www.billporter.info/?p=95) but still need to compare it to GPS Track degrees to compute offset of true and actual north.

Thanks, Madsci
Title: Re: New C library - testers required
Post by: Admin on January 05, 2010, 11:18:15 PM
I'm trying to make sense of how to use the gpsNEMA header and code, i wish i had an example of how to access the data. For example, does gpsNEMA.latitude work?
see Axon II GPS example code until Webbot expands the documentation ;D

Quote
Also it doesn't look like you parse out the "degrees of track true" from the NMEA messages, is this correct? Would you add that? I have a compass on my SAGAR BOT (http://www.billporter.info/?p=95) but still need to compare it to GPS Track degrees to compute offset of true and actual north.
Yea, a few other variables aren't being processed either that probably should be.  :P
As for degrees, it won't be very reliable unless your robot is moving at a decent speed - its not a compass, it uses angle between current and previous locations only.
Title: Re: New C library - testers required
Post by: Webbot on January 06, 2010, 07:19:53 AM
Here's an example for the Axon:

Code: [Select]
// Example of how to use an NMEA compatible GPS card
#define RPRINTF_FLOAT

// We will use UART3 to talk to the GPS
#include "gpsNMEA.h"

#include "buffer.h"
#include "sys/Axon.h"
#include "led.h"
#include "gpsNMEA.h"
#include "rprintf.h"

// Create the gps
GPS_NMEA nmea = MAKE_GPS_NMEA(UART3);


// This routine is called once only and allows you to do any initialisation
// Dont use any 'clock' functions here - use 'delay' functions instead
void appInitHardware(void){
// Set up the hardware UART to xmit the results
uartInit(UART1, (BAUD_RATE)9600);

// Set rprintf to go to output
rprintfInit(&uart1SendByte);

// Turn on LED for no signal
statusLED_on();

rprintf("GPS warming up\n");
}

TICK_COUNT appInitSoftware(TICK_COUNT loopStart){
return 0;
}

// This routine is called repeatedly - its your main loop
TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart){
gpsNMEAprocess(&nmea);
if(nmea.info.valid){
statusLED_off();
rprintf("# sat:%d",nmea.info.numSatellites);
rprintf(" long:"); rprintfFloat(10,nmea.info.longitude);
rprintf(" lat:"); rprintfFloat(10,nmea.info.latitude);
rprintf(" alt:"); rprintfFloat(10,nmea.info.altitude);
rprintf("\n");
}
return 0;
}

I have added 'degrees of track true' into the next release

Quote
Yea, a few other variables aren't being processed either that probably should be.
Let me know if you have any specifics.

NB Don't forget that a given GPS device may only supply a subset of the possible GPS messages, and for each message may only supply a subset of the fields. eg not all GPS' provide altitude.

I tried to use the most useful fields to keep the code and data structure sizes as small as possible. Hence things like the details of each visible satellite are not returned as there isn't, as far as I can tell, anything useful that a robot could do with that info.
Title: Re: New C library - testers required
Post by: Admin on January 06, 2010, 08:05:04 AM
Quote
NB Don't forget that a given GPS device may only supply a subset of the possible GPS messages, and for each message may only supply a subset of the fields. eg not all GPS' provide altitude.

I tried to use the most useful fields to keep the code and data structure sizes as small as possible. Hence things like the details of each visible satellite are not returned as there isn't, as far as I can tell, anything useful that a robot could do with that info.
Well, altitude would be important to process for airborne bots . . .

Number of satellites hints at reliability of position data, useful to plug into a Kalman filter.

And angle is useful for faster robots, like car or aircraft types . . .

Now if a particular GPS isn't supplying some of that data, I'd argue it isn't following the full NMEA standard, and hence should probably be considered a special case.
Title: Re: New C library - testers required
Post by: Webbot on January 06, 2010, 09:34:53 AM
Look at gps.h to see what is returned.

amongst other things: it includes number of satellites, altitude and the next release will have track angle.

What I meant about the satellite info is I dont return: the satellite number and location of each individual satellite that is detected. This is only useful for graphic display.
Title: Re: New C library - testers required
Post by: Admin on January 06, 2010, 09:57:02 AM
I haven't used gps.h since we were originally debugging it. So probably was just the original version missing that stuff, then . . .

Quote
What I meant about the satellite info is I dont return: the satellite number and location of each individual satellite that is detected. This is only useful for graphic display.
oh! ok nm then.
Title: Re: New C library - testers required
Post by: madsci1016 on January 06, 2010, 10:07:50 AM
As for degrees, it won't be very reliable unless your robot is moving at a decent speed - its not a compass, it uses angle between current and previous locations only.

I know, but comparing that value to your magnetic compass is the only easy way to correct for the magnetic north and gps north not being the same, as well as any hard iron offsets in your area.

Thanks for the addition and sample code Webbot.
Title: Re: New C library - testers required
Post by: madsci1016 on January 14, 2010, 09:52:17 PM
Can I make a suggestion? In order to define a UART_RX_BUFFER, buffer.c needs to be included.
However this is not documented in the section on initializing uart buffers, and it took me a little while to figure that out.

Webbot, I am going to be using your library extensively on my Autonomous robot. Is there a way I can help you out more directly in perfecting the library, like adding to the documentation?

I also wrote an interface to control an Irobot Create/Roomba a while back that I could adapt (or try to) into a driver for your library. 
Title: Re: New C library - testers required
Post by: Admin on January 14, 2010, 10:31:56 PM
Quote
Is there a way I can help you out more directly in perfecting the library, like adding to the documentation?
He always needs people testing code, and if flaws are found, help in debugging. In the early days of WebbotLib I was definitely pulling out my hair! But I think I caused Webbot to lose some hair too with all my dumb mistakes . . . :-X

Quote
I also wrote an interface to control an Irobot Create/Roomba a while back that I could adapt (or try to) into a driver for your library.
Thats actually a good idea. Since it uses the ATmega168, it shouldn't take much work to add iRobot Create support to WebbotLib.
http://www.societyofrobots.com/robot_iRobot_Create_mod.shtml (http://www.societyofrobots.com/robot_iRobot_Create_mod.shtml)
Title: Re: New C library - testers required
Post by: madsci1016 on January 15, 2010, 09:24:58 PM
When i find my irobot code, i will see if i can adapt it for the Webbot lib driver style.

What about a wiki for the Webbot documentation? That way a few of the trusted regulars around here could help webbot perfect the documentation. and at the very least, a arduino reference ( http://www.arduino.cc/en/Reference/HomePage (http://www.arduino.cc/en/Reference/HomePage) ) style index.

I assume Webbot and Admin would rather keep it 'in the family', but i have server space and a domain i could donate (yeah for unlimited transfer volume) and I have been waiting for an excuse to learn to install / manage a wiki.

Would you mind if i went ahead and started a wiki? and started to transfer what is in the pdf document into it?
Title: Re: New C library - testers required
Post by: Webbot on January 16, 2010, 01:42:11 PM
When i find my irobot code, i will see if i can adapt it for the Webbot lib driver style.
The way to go is to convert your code to use WebbotLib and then try to generalise it - ie configurable IOPin, uarts etc etc. Once done then this could become a candidate for addition. But since I don't own every piece of hardware, and so cannot test, then I would look for a number of 3rd parties to 'approve' its addition. This is fairly simple to do as your iRobot code can be wrapped up in an h file (or even as an additional precompiled library somewhat like the Arduino contributed libraries) and so users can add it on top of WebbotLib. Once stable, and you've got backers, then its just a case of me moving it into WebbotLib. The only reason why I may sound hesitant is that in order to do a new release I have to co-ordinate and re-test the code and verify the docs. Obviously this gets harder with more contributors. So its a trade off, for me, of being nimble vs having 'helpers'. In the meantime: it would then be your responsibility to release versions of your contributor library and to say what versions of WebbotLib it supports.

What about a wiki for the Webbot documentation? That way a few of the trusted regulars around here could help webbot perfect the documentation. and at the very least, a arduino reference ( http://www.arduino.cc/en/Reference/HomePage (http://www.arduino.cc/en/Reference/HomePage) ) style index.
I don't want a Wiki (for now). If there are holes in the docs for my code then I would rather receive edits/additions etc. This way I can make sure that the docs are, at least, correct. Wikis tend to only be good for the latest release. So lets say something new was added to the software, but not released, then you would need a way to manage documentation for the next release which only became public upon release and only applied to that release.

I assume Webbot and Admin would rather keep it 'in the family', but i have server space and a domain i could donate (yeah for unlimited transfer volume) and I have been waiting for an excuse to learn to install / manage a wiki.

Would you mind if i went ahead and started a wiki? and started to transfer what is in the pdf document into it?
Couple of points:
1. WebbotLib is a 100% Webbot product with Admin being my much appreciated power user, tester, and advocate. So there is no 'family'.
2. I already have space at http://webbot.org.uk (http://webbot.org.uk)
3. Of course you could start an un-official Wiki but you will then have to keep it up to date with new versions.
4. In the same way that I can create trusted code contributors in SourceForge then I can also move my documentation system onto webbot.org.uk for trusted contributors.

Title: Re: New C library - testers required
Post by: madsci1016 on January 16, 2010, 02:26:26 PM
The lib is your baby, and if you don't want me to do it, I won't.

But if you don't care either way, then I would like to try to create an unofficial wiki (or some other documentation style) site.

I think your lib has the potential to be a very powerful alternative the the Arduino IDE; however I feel currently it presents too high a learning curve to most people that are new to micro-controllers. If you are still in the process of perfecting the lib, and then you have plans to better document it after you are comfortable with it's stability, then I will leave well enough alone.

I will give you an example of what happened to me:

I was trying to use Uart communications for the first time, so i went to the pdf, found uart.h in the menu on the left, expanded it, and clicked "uartGetByte" since i knew that was the function i wanted. What i didn't realize was that since i navigated directly to the function, i missed the whole section on Uart buffers are disabled by default. So i spent an hour or so trying to figure out why i was getting the same single byte out of "uartGetByte". Then when i defined buffer sizes, i got strange compiling errors, and spent another half an hour before i realized i had to include buffer.h to get it to work.  (thats not in the pdf, at least i have not found it)

So i guess what i have the biggest problem with is the format the documentation is in. I am spoiled by the Arduino style of reference index, and i felt i could contribute to this community by making the Webbot lib documentation more "noob friendly'.

Like i said, it's your baby, so I'm not going to do a thing before i get a "go/no go" from you, or even a "Don't care" 

What if i keep it simply a unofficial (noob friendly) translation of you pdf releases?
Title: Re: New C library - testers required
Post by: Webbot on January 16, 2010, 03:12:59 PM
Can we take this offline - so as not to dilute the original thread about the software?
We will chat, decide, and post any results.
PM/email/etc me - and I'll get back to you over the next few days.

Title: Re: New C library - testers required
Post by: madsci1016 on January 16, 2010, 07:06:51 PM
Taken offline,

Back to the regularly scheduled program:

It seems the gpsNEMA.c is hard coded to stay in DEBUG mode. I noticed when i setup my GPS for the first time, and got the NMEA string dumped onto my printf terminal.

I investigated, found gpsNEMA.c
 defines DEBUG,

then

Code: [Select]
                                        #ifdef DEBUG
// Dump out the message
rprintfStr(msg);
rprintfCRLF();
#endif

Did you mean to hard code DEBUG mode in your lib?
Title: Re: New C library - testers required
Post by: Webbot on January 16, 2010, 07:28:41 PM
But if you look in
Cameras/Surveyor/blackfin.h
you should see that the
#define BLACKIN_DEBUG
is commented out as its only used by me. Hence the code you've found will never be compiled anyway as the '#ifdef' will always fail and skip the code down to the '#endif'. Unless you've changed the h file and compiled your own version of the library.

If you look further into blackfin.h you will also see that MAKE_BLACKFIN_CAMERA has a different number of parameters depening on whether debug mode is enabled or not.
It has one parameter if debug is switched off, or two if it is enabled.

So if you've only got one parameter then DEBUG is definitely off - otherwise you would get compile errors.

Title: Re: New C library - testers required
Post by: madsci1016 on January 16, 2010, 07:38:18 PM
Hmm, I am not 100% on what you are saying.

I know for a fact that i didn't mess with anything but added the following to my main c file

#include "gpsNMEA.h"
GPS_NMEA gps = MAKE_GPS_NMEA(UART2);
gpsNMEAprocess(&gps);

(in different places)

and i am suddenly getting the NMEA strings in my serial terminal that handles my rprintf.

Nevermind, i see what you are saying, because i tried commenting out #define DEBUG in gpsNEMA.c and it did not stop the nmea sentences in my terminal. So i guess what i am saying it the pre-complied gpsNEMA has DEBUG enabled.
Title: Re: New C library - testers required
Post by: Webbot on January 16, 2010, 08:02:19 PM
Nevermind, i see what you are saying, because i tried commenting out #define DEBUG in gpsNEMA.c and it did not stop the nmea sentences in my terminal. So i guess what i am saying it the pre-complied gpsNEMA has DEBUG enabled.
Well changing the gpsNMEA.c file would only take effect if you compiled it and placed your compiled version in the compiled '.a' file

If your 'blackfin.h' has the '#define BLACKFIN_DEBUG' line still commented out then the BLACKFIN_CAMERA doesn't have any variable to store what UART to use to send debug info to.
Heres the extract from blackfin.h
Code: [Select]
typedef struct s_blackfin {
UART* camera; // The UART used to talk to the camera
BLACKFIN_RESOLUTION res; // The current resolution of the camera
BLACKFIN_BLOB* blob; // The default area to read a blob into
COLOR* mean; // The last read mean value of the image
#ifdef BLACKFIN_DEBUG
UART*     debug; // The UART used to send debug output to
#endif
} BLACKFIN_CAMERA;
See that #ifdef  - its used to store the UART to send debug info to. If BLACKFIN_DEBUG isn't defined then the variable isn't there.

Your program just uses, correctly, the single parameter version:
GPS_NMEA gps = MAKE_GPS_NMEA(UART2);
Which, since it compiles, also suggests BLACKFIN_DEBUG isn't defined - otherwise you would need to specify the additional UART to send debug info out to.

So I'm confused

When you say it goes to 'my serial terminal' then what UART is that on?

Can you attach a mini-program that does the same thing as you see.


Since my debug version can dump stuff at runtime to ANY user specified UART then it needs you to specify the UART number at compile time. You aren't specifying a debug UART and so I dont know how its deciding to use a particular UART.
Title: Re: New C library - testers required
Post by: madsci1016 on January 16, 2010, 08:10:35 PM
where is blackfin coming from? I am not using a blackfin at all.

The gpsNEMA.c has this

#define DEBUG
#ifdef DEBUG
#include "rprintf.h"
#endif

and this

#ifdef DEBUG
// Dump out the message
rprintfStr(msg);
rprintfCRLF();
#endif


So it is dumping out the string into the Uart i initialized rprintf to. ( or so i think). Regardless, I am getting NEMA strings in my terminal i have rprintf writing too. Can I stop that?
Title: Re: New C library - testers required
Post by: Webbot on January 16, 2010, 08:55:43 PM
You are, of course, 100% correct and I was talking complete gibberish!! But then it is 2:57am here and brain a bit frazzled.
New interim Axon lib on its way to you with the debug turned off.
Title: Re: New C library - testers required
Post by: madsci1016 on January 16, 2010, 09:03:36 PM
LOl, Thanks. No more NEMA sentences showing up now.

And go get some sleep already, we can't have you programming like this!!!!
Title: Re: New C library - testers required
Post by: madsci1016 on January 16, 2010, 09:09:17 PM
Actually, I think i spoke too soon, it seems the GPS function is completely broken now. The LED is flashing out a Uart RX buffer overflow almost immediately after powering on, (mine set to 80 bytes, i tried up to 200) and the GPS led shows it has a fix, but I'm not getting anything in my terminal, and i have this

if(gps.info.valid){
rprintf("We got signal \n");
}

Title: Re: New C library - testers required
Post by: Webbot on February 04, 2010, 08:10:50 PM
Version 1.14 of WebbotLib released.
See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page) for info
Title: Re: New C library - testers required
Post by: madsci1016 on February 04, 2010, 08:54:53 PM
Should project designer testers switch to the new 1.14?
Title: Re: New C library - testers required
Post by: Admin on February 04, 2010, 09:10:57 PM
The updated Axon II WebbotLib demo program set for v1.14:
http://www.societyofrobots.com/axon2/downloads/Axon_WebbotLib_examples.zip (http://www.societyofrobots.com/axon2/downloads/Axon_WebbotLib_examples.zip) (1.7mb)

Version numbers will always match that of WebbotLib, no matter how many updates I make to it. But I'll still specify the major updates made in the version information file.

I'm also keeping copies of demo programs supported by older WebbotLib versions, so just contact me if you by rare chance need it.
Title: Re: New C library - testers required
Post by: Webbot on February 04, 2010, 09:17:15 PM
Should project designer testers switch to the new 1.14?

A good question and one I didn't make clear.

The release of 1.14  (from SourceForge etc) is the first official release of 1.14. It replaces the alpha, pre release versions, made available to the Project Designer guinea pigs and is compatible with both Project Designer and the traditional WebbotLib API.

You still need to check version.h or the News section of my website - as there have been a few last minute additions. Although these tend to be standalone (like the AVRcam). If it doesn't work then hey ho: it was never there before and doesn't effect anything else. These new additions are aimed solely at users who have the relevant hardware (which I dont!) and they can get back to me with issues/successes.

So the "quick answer" is YES. Any reported bugs will only be fixed in the main codestream.

But note that Project Designer is still un-released. Maybe a day or two away from general release. There are a few minor releases that I will try to make in the net hour or so (before sleep time!) for those already using it. Changes will be installed next time you launch.
Title: Re: New C library - testers required
Post by: madsci1016 on February 07, 2010, 01:40:36 PM
From the 1.14 release info:

"Added HMC6352 compass - but untested as of yet. If you use it then let me know."

Has anyone tested it for you? I have the compass, but replaced it with a HMC6343. If it's still needs testing I can switch it back out, but I'd rather only spend the time testing if it's still needed.

I think Ro-Bot-X also has it.
Title: Re: New C library - testers required
Post by: Webbot on February 07, 2010, 09:57:48 PM
As of yet untested.
So if anyone wants to give it a try and let me know then it would be good to get it out of alpha.
As a Project Designer tester - then it will write the basic code for you. So hopefully not too much of a burden for a standalone test.

Title: Re: New C library - testers required
Post by: madsci1016 on February 07, 2010, 10:25:54 PM
Scheduler question.

I am following the sample code exactly.

void myCallback(int*, TICK_COUNT, TICK_COUNT);

scheduleJob(&myCallback, NULL, clockGetus(), 100000);

void myCallback(int * data, TICK_COUNT lasttime, TICK_COUNT overflow){}

But i get a compiler warning "passing argument 1 of 'scheduleJob' from incompatible pointer type."

What am I doing wrong?

Title: Re: New C library - testers required
Post by: Webbot on February 07, 2010, 11:00:27 PM
The first parameter to 'myCallback' should be a 'void *'
ie
void myCallback(void* data, TICK_COUNT lasttime, TICK_COUNT overflow){}

This is because the scheduler itself does actually give a monkey nadgers as to the actual data type is - its up to you - its just the address of something (or NULL). So it basically means that 'scheduleJob' can pass in a pointer to anything and in 'myCallback' you give an explicit cast to cast it back into what you think it should be.

Title: Re: New C library - testers required
Post by: madsci1016 on February 07, 2010, 11:19:14 PM
Got it, thanks for the correction.
Title: Re: New C library - testers required
Post by: madsci1016 on February 10, 2010, 02:27:01 PM
You have code in place to stop users, and tell them the data they are polling from a given sensor is stale; hasn't updated.

But you don't have a method to tell if a new NMEA string has come in and been processed.

For example, I'd like to run my main loop at full speed, and only compute positional stuff when i know i have gotten an updated position from my gps.

Would it be simple enough to have 'gpsNMEAprocess()' return a TRUE/FALSE to show that updated GPS coordinates are ready?

I could just use a scheduler to loop at the same speed my GPS updates, 1Hz, but i could be just in front of the GPS message comming in and be 1 second off in my localization programming.
Title: Re: New C library - testers required
Post by: Webbot on February 10, 2010, 07:04:06 PM
I need to give that thought - because the GPS can send various different sorts of messages. Each message updates a certain number of fields. But no message updates all of them.
Title: Re: New C library - testers required
Post by: madsci1016 on February 10, 2010, 08:20:12 PM
Looking through NEMA.c, it seems you only process GGA and RMC messages. Both messages give lat/long, but GGA gives 3D positioning. I would have that message set the flag.

Speed and track true from a GPS are somewhat delayed values as it is, it takes a few number crunching cycles for the GPS to update those values anyway. Functionally, anyone dependent on those two values to be temporally accurate are doomed already.

 But knowing if the 3D position has been updated and is not stale is very important for localization algorithms like kalman filters.

Or, you could just pass an extra parameter in the MAKE NEMA GPS that lets the user pick which message sets the 'fresh' flag.
Title: Re: New C library - testers required
Post by: Webbot on February 11, 2010, 12:13:42 PM
Since different GPS devices reutrn different messages, and a given device may only implement a subset of the fields then I am thinking of returning a variable that is made of 'bits' to indicate which fields have been updated (even if the new value is the same as the old value).
You could then mask the fields you are interested in listening to.
This would be a more generic solution.
Title: Re: New C library - testers required
Post by: madsci1016 on February 11, 2010, 05:07:36 PM
Sounds good to me. Need a tester?  ;D
Title: Re: New C library - testers required
Post by: Webbot on February 11, 2010, 06:01:59 PM
Sounds good to me. Need a tester?  ;D


Life is chaotic at the moment!!

Trying to add things to WebbotLib - mainly displays and other stuff to. (And dont want to get into zillions of code branches!)
Some things have made changes to Webbot that have a knock on with Project Designer and vice versa.

Equally dont want to produce new versions of WebbotLib every few hours as folk will get fed up

So may need to wait for stuff to just settle a bit

Alternative is to learn how to build WebbotLib from source code using Ant. Then I could supply you a source file for something simple and you could make your own build!! Several others have done that already.
Next step is to subscribe to the source code at SourceForge. Then you can add it into the source and check in your change. But I still have veto if I don't like what you've done.
Then rather it being just me - it becomes a community. Ahah open source doesn't just mean you get the source - but also that you can change it! Linux wasn't built in a day nor by one person.


Too much stuff - not enough hours!!! Had a pkg of various LED displays thats been sitting next door un-opened.

Title: Re: New C library - testers required
Post by: madsci1016 on February 11, 2010, 06:36:13 PM
I'd be happy to tackle some stuff on my own.

Do you have any quick links to teach myself Ant and how to use it to recompile the lib?
Title: Re: New C library - testers required
Post by: Webbot on February 11, 2010, 08:00:50 PM
If you want to contribute to source code then go through the Sourceforge pages.

Once subscribed you will be able to download, and share with other developers, the current source. As well as build a library. So we can work together.

You will also have access to the 'build.xml' for WebbotLib which has been the subject of posts with others ie my view was 'unless you are changing the library code' then why would you need to build it? But it will be included in future releases.

So once you're Sourceforge application has been agreed then you have access to the full CVS repository.

So how do you build?

You must also have a Java SDK - if not then see  http://java.sun.com/javase/downloads/index.jsp (http://java.sun.com/javase/downloads/index.jsp)
Download Apache Ant http://ant.apache.org/ (http://ant.apache.org/)

Once you've got both then launch a command prompt
Go to the root folder of WebbotLib
Type ant -projecthelp
And you will see a list of options of which the default is just
ant
which will buld everything
or
ant clean
which will delete all binaries. Follow with an
ant
to rebuild given that all intermediate stuff has gone. So rebuild from scratch.

The Ant website gives all sort of html doc help for your own ref. You shouldn't need to change build.xml

Assuming you are now 'sourceforged' so that we can share source code then also note:-
I can veto your changes
Only I can make releases.
But you can make your own internal releases for testing your own changes.

All I would ask is that if you write something then:-
1 - Do not release it any third party manner. WebbotLib belongs to me - and has required a substantial amount of work. You cannot release 'official' versions of the lib and I will come down hard, legally, on anyone who makes their own release via other websites.
2. - By checking code back into WebbotLib then you are agreeing to make it available as a part of WebbotLib and any copyright, if your changes are adopted by a release, belong to WebbotLib. Sounds heavy! Well you are either contributing free stuff (like me) or you ain't. If your code is precious then keep it to yourself, dont publish it, and become an island. Simple.



Ok lets get away from this heavy stuff. WebbotLib is out there for everyone. I just want contributors to have the same mind set.


Title: Re: New C library - testers required
Post by: Webbot on February 17, 2010, 11:17:54 PM
Version 1.15 released http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page)
Title: Re: New C library - testers required
Post by: Webbot on February 21, 2010, 03:20:49 PM
Version 1.15b released.

A few internal speed changes - but nothing that will need a change to your own programs.

New version of Project Designer - see http://webbot.org.uk (http://webbot.org.uk) - but this will now attempt, if you are using windoze, to create an AVRStudio project file if there isn't an existing one in your project folder. It will NOT allow you to over-write an existing AVRStudio file

First use will ask you to identify where your WebbotLib code is installed.

This is kinda 'unsupported' in so far as I'm clobbered by AVRStudio versions and how they change their (unpublished) format. If it gets hairy then I may have to drop it. But works, for me, for now! If you have problems then let me know about your AVRStudio version and WebbotLib version.

Title: Re: New C library - testers required
Post by: Webbot on March 19, 2010, 10:01:16 PM
Version 1.16 released

See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page)
Title: Re: New C library - testers required
Post by: Webbot on April 02, 2010, 11:39:52 AM
Version 1.17 released

See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page) for details.

Main changes are SPI and I2C EEPROM devices (up to 128kb of storage for a few bucks), as well as support for the 'most excellent' Dynamixel AX-12 servos.

The Dynamixel servos are 'excellent' IMHO - but therefore not cheap - http://www.trossenrobotics.com/dynamixel-ax-12-robot-actuator.aspx (http://www.trossenrobotics.com/dynamixel-ax-12-robot-actuator.aspx)

They can act as normal servos, or as modified servos (motors) - no need for drilling/gluing etc - its all done in software - and have excellent torque. The current 'state' of each servo can be retrieved - such as 'load', 'temperature', etc, etc

Drive hundreds (yes - hundreds) of them over a single UART! They have thermal shutdown and are very hard to destroy!! (But I'm still trying  ;D).

The only additional hardware you need is shown in my manual and in their datasheet. It is a very simple ( 2 x chips), and very cheap, circuit allowing communication to happen over a single UART wire to ALL servos!!

NB I am aware of some software implementations which choose to 'simulate' this hardware using software. But I decided not to use those techniques as they involve short circuiting the Tx and Rx pins of the UART and could blow up your processor if you load another program but still have the 'shorting wire' present.

Enjoy!
Title: Re: New C library - testers required
Post by: Webbot on April 04, 2010, 12:59:37 PM
I'd quite like to build a 'gallery' on the WebbotLib web site as its rather 'text only' at the moment. (Too busy writing code to build robots!)

So if you're willing to contribute then PM me with your 'powered by WebbotLib' robots: giving links to videos (YouTube?) or jpeg images - and perhaps a very brief description of what it does.

Even better: if you want to supply a 'quote' then even better.

Showcase your stuff!!

Thnx
Title: Re: New C library - testers required
Post by: madsci1016 on April 05, 2010, 04:46:37 PM
Maybe I'm missing this, so if someone could enlighten me.

For my SAGAR rover, I was planing on having a 'mission file' of GPS waypoints that I externally create and upload into the Axon's EEPROM. Then, as a start-up routine, my Axon code would start parsing the mission file. I would start copying into a string the contents of the EEPROM incrementally until a '\n' was found, token-ize the string and parse the tokens to GPS coordinates. Once SAGAR achieved the waypoint, it would repeat the parsing of the EEPROM mission file to pull out the next waypoint.

There doesn't seem to be a generic function just to read out a byte of EEPROM at a specified address.

For example, a

while (temp_byte = EEPROMReadByte(address++), temp_byte!='\n')
       temp_string[inx++] = temp_byte;

The 'eeprom_read_block ( )' won't work because i'm not treating my eeprom like system memory with compiler created variables, i'm treating it as a storage device with a text file created by another process.

I guess a hack would be to create a dummy 'char EEMEM eepromString[10];' variable and hope webbotlib and the compiler puts it's address at the beginning of my eeprom where i plan on starting my txt 'mission file', but it still seems there should be a generic EEPROMReadByte(address) function in webbotlib.

EDIT:

Nevermind, I'm crazy. I just re-read the Webbotlibc manual, and realized those are not webbotlibc functions, and that eeprom_read_byte() is what i need, i just need to figure out the memory address of the first byte of eeprom memory, or is it just eeprom_read_byte(1)? Hmm, either way, this is a useless post, and can be deleted. Sorry Guys.

Title: Re: New C library - testers required
Post by: Webbot on April 05, 2010, 05:27:22 PM
Good to see you've answered your own question. (eeprom addressing starts at 0 not 1).

Don't know how big your waypoint files are but if they are big then note the SD card + FAT disk support now in WebbotLib.

This lets you open/create/append to a file and use rprintf to write to it and a 'reader' to read from it. I use a 4Gb SD card.

Advantage is that if you spend a couple of bucks on a USB stick that you can slide the SD card into then you can plug whole thing into your PC as if it were a hard drive - and hence read/write the files from both your PC and/or the robot.

Of course if your robot writes the files in the correct format then your PC could also use Google maps to plot your robots course on a satellite terrain map.

Or vice versa.


Title: Re: New C library - testers required
Post by: Ro-Bot-X on April 05, 2010, 09:23:33 PM
Quote
Of course if your robot writes the files in the correct format then your PC could also use Google maps to plot your robots course on a satellite terrain map.

This would make a nice tutorial... Any takers? Webbot is too busy to do it, so... who can?
Title: Re: New C library - testers required
Post by: Admin on April 05, 2010, 09:49:40 PM
Quote
Of course if your robot writes the files in the correct format then your PC could also use Google maps to plot your robots course on a satellite terrain map.

This would make a nice tutorial... Any takers? Webbot is too busy to do it, so... who can?
cough cough . . .

http://www.google.com/search?q=how+to+plot+a+list+of+gps+coordinates+in+google+maps (http://www.google.com/search?q=how+to+plot+a+list+of+gps+coordinates+in+google+maps)
Title: Re: New C library - testers required
Post by: Ro-Bot-X on April 06, 2010, 05:15:01 AM
Looks like research to write the tutorial...
Title: Re: New C library - testers required
Post by: madsci1016 on April 06, 2010, 06:15:08 AM
Alright, alright, I wasn't going to post again, but since i now have accomplices in this thread-jacking,

My mission file is small enough to fit in the 4k of eeprom. I though about SD cards and would eventually like to add one for mission logging, but i'm not that far yet. I'm aware of the ability to plot waypoints in Google earth, and after I get SAGAR running missions properly and logging them, I'm going to work on that. Right now since my operator software is written in Labview, there's a way to plot the robots position and course real-time on google earth.

And maybe when all is said and done, I'll right a few tutorials on GPS and plotting on google earth.

/thread-jacking
Title: Re: New C library - testers required
Post by: madsci1016 on April 12, 2010, 05:28:40 PM
Here's a problem I've been running into but keep forgetting to post about.

The one and only WebbotLib error I have ever gotten, is error 11, but i get it a lot. Even with gigantic Uart buffers (300+ bytes) I will still get the error.

What I think is going on, is my Uart devices are all on the same power rail as the Axon itself.

If the Axon finishes loading before my (let's say for example) my GPS, then it's ready to receive data, but my GPS's controller may not have initialized it's UART pins and there are still in a high impedance state. The resulting floating pins on the Axon think they are getting a bunch of bytes at full speed.

If i reset the Axon without power-cycling my robot, I get no error. It's only when all my devices and Axon come on together do i get the buffer overflow error.

I can fix it completely by putting a delay_ms(1000); before initHardware();. I'm posting all this in case anyone else runs into this problem, or Webbot, in case you want to add a small delay to you lib for the noobs.
Title: Re: New C library - testers required
Post by: waltr on April 12, 2010, 07:19:59 PM
Quote
not have initialized it's UART pins and there are still in a high impedance state

When I design embedded systems I try to anticipate this kind of condition and put weak pull-ups or pull-down (set in inactive state) on those lines that may be un-driven during power-up and initialization.

I did have a case several years ago where a CPLD during initialization had hiZ pins. But some of these pins were active low bus driver enables. So for a short period during power up four different bus driver chips were trying the drive signals onto the same buss. We found this because sometime the power supply would not come on (it really was shutting down ) and by measuring the power supply current on a scope we saw a large current spike while the CPLD was loading code.
Title: Re: New C library - testers required
Post by: Admin on April 12, 2010, 08:35:32 PM
Quote
I can fix it completely by putting a delay_ms(1000); before initHardware();. I'm posting all this in case anyone else runs into this problem, or Webbot, in case you want to add a small delay to you lib for the noobs.
With many of the sensors, WebbotLib adds in a startup delay for reasons such as this. The GPS manual should point out a specific delay period. Just send Webbot the info he needs, its a quick fix in the code.
Title: Re: New C library - testers required
Post by: Webbot on April 13, 2010, 07:48:16 PM
Some of you may have used my Project Designer - see http://webbot.org.uk/iPoint/37.page (http://webbot.org.uk/iPoint/37.page)
Others may not. Some of this may be because your board isn't supported or you have a home made board.

So I can now announce that the Board Designer is available http://webbot.org.uk/iPoint/36.page (http://webbot.org.uk/iPoint/36.page) - allowing you to create board designs for your own board or for currently unsupported commercial boards.

These board designs can then be shared with others, published over the web, and then used within Project Designer.

Title: Re: New C library - testers required
Post by: Webbot on May 12, 2010, 11:36:47 AM
Version 1.18 has been released

See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page)  for details.

Main changes are:

Title: Re: New C library - testers required
Post by: Cristi_Neagu on May 12, 2010, 02:29:25 PM
This library is getting close to being an operating system for AVR chips ;D Great stuff!
Title: Re: New C library - testers required
Post by: madsci1016 on May 12, 2010, 04:53:19 PM
Webbot, What version of the build do you consider stable for mission critical applications? The latest release, or something earlier?

I may be using the lib and an Axon for something at work.
Title: Re: New C library - testers required
Post by: Webbot on May 12, 2010, 07:34:26 PM
Webbot, What version of the build do you consider stable for mission critical applications? The latest release, or something earlier?

I may be using the lib and an Axon for something at work.

What an excellent question! But one without a simple answer as it depends on the sub-systems you are using.

For example: the 'timer' code, and other core code, hasn't changed for a good while, whereas some features like Sony PS2 controllers are only available in the latest release.
The addition of new processors has zero effect on others - as they each have their own library build.

Some releases, like 1.18, have certain 'fixes' that touch the code but only to make it more robust - ie 1.18 behaves better if you try to flush a UART receive buffer when it doesn't actually have one. But these changes just tend to report errors for 'bad code' but have no effect on 'already working' code.

Equally 1.18 has 'improved code' to parse the GPS messages to give less rounding errors - note this is a completely different subject to your own thread regarding rounding errors in your own code! The old code worked fine but is now marginally better.

I will only ever fix issues in the current branch - so I guess the easy answer is therefore 'the current release'. As of 1.18 there are no known issues remaining.

But if you are producing a truly mission critical system then let me know (PM me maybe) what parts of the lib you are using and I can then analyze when they were last changed and why and let you know what version I recommend. This is not an open invite to everyone!!

Title: Re: New C library - testers required
Post by: madsci1016 on May 12, 2010, 10:17:39 PM
But if you are producing a truly mission critical system then let me know (PM me maybe) what parts of the lib you are using and I can then analyze when they were last changed and why and let you know what version I recommend. This is not an open invite to everyone!!

Understood. Sorry if this gets you spammed by a few people. I debated asking you by PM, but figured others might want the insight as well.
Title: Re: New C library - testers required
Post by: Webbot on May 15, 2010, 01:50:29 PM
Anyone out there using the existing Devantech CMPS03 compass code?

I'm wanting to change this so that it uses I2C rather than the current pulse timing code. Should be more accurate but will mean changing your hardware setup.

If anyone feels strongly about retaining the existing code then PM me.

Webbot

PS And 'no worries' - I own one of these so I at least have something to test with!!
Title: Re: New C library - testers required
Post by: Admin on May 17, 2010, 09:14:38 PM
Any reason to not have both?
Title: Re: New C library - testers required
Post by: Webbot on May 18, 2010, 06:42:43 AM
Have actually changed it do both but just thought maybe the I2C option was more elegant - so both it is!
Title: Re: New C library - testers required
Post by: teoxan on May 18, 2010, 07:59:35 AM

I have a CMPS03 somewhere here, but not tested it with AXON. It's on a small robot I used with the Brainstem micro.

Theo
Title: Re: New C library - testers required
Post by: Webbot on May 18, 2010, 08:45:37 PM
WebbotLib Version 1.19 has been released with the following:-

    * Devantech SRF02 and SRF08 sonar
    * Devantech SD21 Servo Controller (up to 21 servos)
    * Devantech CMPS03 now also supports I2C interface
    * Devantech CMPS09 compass with pitch and roll
    * The I2C code now has some more friendly code for reading/writing registers on a slave device
    * All other code remains untouched

Title: Re: New C library - testers required
Post by: teoxan on May 18, 2010, 11:08:24 PM

Great job, Webbot

I can't seem to find the SD21 support.
Can you please let me know about it?

thanks!


Title: Re: New C library - testers required
Post by: Webbot on May 19, 2010, 10:07:59 AM
I can't seem to find the SD21 support.
Can you please let me know about it?

Ooops my bad - thought I'd added it to the docs when I hadn't.

Rather than making a new release I've updated the online docs for now (but it will also be in the PDF for the next release).
You can find it in the online docs here http://webbot.org.uk/WebbotLibDocs/object.jsp?id=39821 (http://webbot.org.uk/WebbotLibDocs/object.jsp?id=39821)
Title: Re: New C library - testers required
Post by: Webbot on May 27, 2010, 05:58:52 PM
A new version of Project Designer has been released (and it will auto-install the next time you run it).

This release has a File | Print option for saved projects which generates a PDF of your project. Note that you will need to have Adobe Reader installed and this is freely available from Adobe. (but you probably already have it so that you can read the PDF manual!).

 
Title: Re: New C library - testers required
Post by: Webbot on June 07, 2010, 06:08:22 PM
Version 1.20 released

See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page)

My robot talks!!!
Title: Re: New C library - testers required
Post by: Ro-Bot-X on June 07, 2010, 07:12:05 PM
Cool!!! Now you need to add support for VRbot (http://www.tigal.com/1770) module! So the robot can listen to your voice commands!!!
Title: Re: New C library - testers required
Post by: Admin on June 07, 2010, 07:16:39 PM
Cool!!! Now you need to add support for VRbot (http://www.tigal.com/1770) module! So the robot can listen to your voice commands!!!
I was looking at that module too, actually. I emailed the maker of it a few days ago, but no reply yet . . .
Title: Re: New C library - testers required
Post by: Ro-Bot-X on June 07, 2010, 08:51:25 PM
You can buy it from several sources (http://www.sparkfun.com/commerce/product_info.php?products_id=9753). My MiniEric robot uses it successfully. The nice part is that you can train it in any language. I wish we could do the same with speech synthesis...
Title: Re: New C library - testers required
Post by: madsci1016 on June 13, 2010, 07:22:30 PM
I have a function suggestion/request.

A function that returns the number of bytes in the uart RX buffer. When defining binary communications, it's useful to know how much data the lib's buffer is holding, to see whether or not there is a full set of data waiting to be dealt with. Right now i have to define my own second buffer, dump whatever data is in the uart buffer every pass, then decide if i got everything or not. Arduino's have one, and i find it very useful, plus it saves memory not having to have two 'buffers'.
Title: Re: New C library - testers required
Post by: Webbot on June 13, 2010, 07:36:59 PM
ok I have added that.

But if your screaming for it now then just use this:-

Code: [Select]
static __linline__ size_t bufferBytesUsed(const cBuffer* buffer){
size_t rtn;
CRITICAL_SECTION_START;
rtn =  buffer->datalength;
CRITICAL_SECTION_END;
return rtn;
}

The number of bytes 'used' in the buffer is already held in the 'datalength' member. The CRITICAL_SECTION commands just wrap it to make sure that interrupts dont cause any side effects when reading the two byte number as it transitions the single byte boundary.
Title: Re: New C library - testers required
Post by: madsci1016 on June 13, 2010, 07:41:58 PM
Sweet, thank you. I knew it would be something simple.

No rush, what i have works now, but next time i over-haul SAGAR's code(next lib release most likely), i'll add it in.
Title: Re: New C library - testers required
Post by: klims on June 17, 2010, 03:04:57 AM
Been reading through the documentation and I have to say WOW! Great job. This looks like an awesome bit of lib. Very feature rich.

I wanted to ask if you would like feedback on the documentation side of things in this thread, as in completeness, spelling mistakes and all of that?

I'm keen to get my biped up and running with your libs (once I work out how to get my bloody rprintf function working???) so I was wondering at the chances of getting some special functions written up? Initially I was thinking some basic stuff like getting a bunch of servos to move to position all finishing at the same time, but eventually I envision something more hardcore, maybe involving some inverse kinematics. Should I maybe start a new thread on it?

I have a question about your software PWM. if I am controlling 18 servos with software, how much CPU time am I using/wasting on this operation? On average how much CPU would you say it takes to software PWM a servo? I'm wondering if I'm better off buying harware to deal with servos.
Title: Re: New C library - testers required
Post by: Webbot on June 17, 2010, 08:28:37 AM
Been reading through the documentation and I have to say WOW! Great job. This looks like an awesome bit of lib. Very feature rich.
Thanks

I wanted to ask if you would like feedback on the documentation side of things in this thread, as in completeness, spelling mistakes and all of that?
Documentation will always be an on-going job. Feel free to PM me about stuff - I thinks its best kept out of the forum as once its fixed/changed/added then the forum posting becomes irrelevant.

I'm keen to get my biped up and running with your libs (once I work out how to get my bloody rprintf function working???)
Start an rprintf with WebbotLib thread if you need help.

so I was wondering at the chances of getting some special functions written up? Initially I was thinking some basic stuff like getting a bunch of servos to move to position all finishing at the same time,
This is easy enough to do. Hint: look at the interpolate function.


but eventually I envision something more hardcore, maybe involving some inverse kinematics. Should I maybe start a new thread on it?
The easiest way to achieve this pure computational stuff is to get it going as a standalone piece of code and once completed, if you want to donate it to the lib, then I can add your code in and give credit. Yep - start a thread if you need to.

I have a question about your software PWM. if I am controlling 18 servos with software, how much CPU time am I using/wasting on this operation? On average how much CPU would you say it takes to software PWM a servo? I'm wondering if I'm better off buying harware to deal with servos.
It would take me a while to work that out and it would depend on your clock speed (16MHz Axon?). Certainly you would need to experiment with splitting the servos into different banks (timers) to get the best result as one bank (timer) would not be able to send pulses to all of the servos every 20ms. It also depends on what other hardware (especially timers) you need for other things.
Title: Re: New C library - testers required
Post by: klims on June 17, 2010, 04:02:21 PM
This is easy enough to do. Hint: look at the interpolate function.
Yep I already have something like this written, I was just wondering at the chances of getting it written properly...

The easiest way to achieve this pure computational stuff is to get it going as a standalone piece of code and once completed, if you want to donate it to the lib, then I can add your code in and give credit. Yep - start a thread if you need to.
Sounds fair. Same story as above though, it will probably need to be re-written properly.

It would take me a while to work that out and it would depend on your clock speed (16MHz Axon?). Certainly you would need to experiment with splitting the servos into different banks (timers) to get the best result as one bank (timer) would not be able to send pulses to all of the servos every 20ms. It also depends on what other hardware (especially timers) you need for other things.
Ok how about a quick guess? Are we talking <10% all up? or are we talking something more significant(>40%)?
I'm guessing I would use 4 timers, one for each limb.


I need some noob help getting the webbotlib to print out the UART. I'm trying the first example from the documentation folder. Can anyone confirm that using an Axon and this exact example they get stuff printing on the UART? I seem to be missing something basic. I don't even get gibberish!
Title: Re: New C library - testers required
Post by: Webbot on June 17, 2010, 05:19:56 PM
Quote
Ok how about a quick guess? Are we talking <10% all up? or are we talking something more significant(>40%)?
I'm guessing I would use 4 timers, one for each limb.
You'd just have to try it.

Quote
I need some noob help getting the webbotlib to print out the UART. I'm trying the first example from the documentation folder. Can anyone confirm that using an Axon and this exact example they get stuff printing on the UART? I seem to be missing something basic. I don't even get gibberish!
The 'documentation folder' - do you mean Admins own examples or something in the WebbotLib manual?
Title: Re: New C library - testers required
Post by: klims on June 18, 2010, 02:25:55 AM
The 'documentation folder' - do you mean Admins own examples or something in the WebbotLib manual?

Ahhhhhh I figured it out!!!!!!!!!!!! The file I was talking about is in the WebbotLib-1.20 manual that came with the library.
The Axon ver.1 is actually connected via usb on UART1. Very noob of me.
Title: Re: New C library - testers required
Post by: klims on June 18, 2010, 08:20:57 PM
Is there a function in the webbotlib that could easily get me reading a signal from something like a TV IR remote? I assume it would need to be interrupt driven to work properly. I have always wanted to control my robot with my tv remote!
Title: Re: New C library - testers required
Post by: Admin on June 18, 2010, 08:24:55 PM
This thread is just to announce new WebbotLib versions . . . just create a new thread to explain your problem/question.
Title: Re: New C library - testers required
Post by: Webbot on June 20, 2010, 02:44:38 PM
WebbotLib Version 1.21 has been released with the following features:-

    * Added Sensors/Encoder/Generic/fastquad.h for high resolution encoders

    * Added ADXL345 accelerometer (i2c)

    * Added HMC5843 compass (i2c)

    * Added Maxbotix MB7077 (works with 7067 as well) distance sonar- can be used under water

    * Fixed ATMega128 UART problem (darn those ATmel naming conventions!)

    * Changed Controller/Sony/ps2.h to have rumble motors, key pressures, and some extra helper routines

    * Changed buffer.h - added function bufferBytesUsed

The Designer applications now support the Sparkfun 9Dof Razor IMU board (http://www.sparkfun.com/commerce/product_info.php?products_id=9623 (http://www.sparkfun.com/commerce/product_info.php?products_id=9623)) - make sure you get the one with the ATMega328P processor - not the old board with the ATMega168

This means that you can now use WebbotLib to author your own firmware to be installed on this board.
 
Title: Re: New C library - testers required
Post by: Invicta on June 24, 2010, 05:08:24 AM
Webbot

Fancy a challenge?

How about including the CH Robotics' CHR-6dm Attitude and Heading Reference System (AHRS) in the next version of Webbotavrclib. It is a fantastic bit of kit and from what I can see is very good value for what it can do. A complete range of sensors for Pitch, Roll and Yaw with Extended Kalman Filter (EKF) for the output - brilliant. I am keen to try it out but I am shy to pay £173.90 + postage unless I know I can interface it to my Axon 2 without issues.

Specifications and datasheet available at:

http://robosavvy.com/store/product_info.php/cPath/27/products_id/628 (http://robosavvy.com/store/product_info.php/cPath/27/products_id/628)

Yours hopefully
Title: Re: New C library - testers required
Post by: Webbot on June 24, 2010, 08:53:06 AM
I have been working with Admin on adding the Sparkfun Razor 9DoF IMU board.

This is available from the same site you mentioned http://robosavvy.com/store/product_info.php/products_id/625 (http://robosavvy.com/store/product_info.php/products_id/625) and its about half the price.

But the best thing is that it uses an ATMega328 processor and so the Razor board itself can be programmed using WebbotLib which supports all the sensors on the board.

Admin has written an example program for loading onto the Razor which I will be including in the next release and he is intending to add a Kalman filter to the code at some point.

The board you mentioned uses an ARM processor that is not supported with WebbotLib. Its also almonst impossible for me to write code for a sensor unless someone actually has one and they are willing to be guinea pigs for my code and they can commit the time and effort into helping. ie for every change I make I have to send you a hex file to test and let me know the result. Obviously I don't want to splash out £173 for a device that I have no use for once its up and running.

Title: Re: New C library - testers required
Post by: Admin on June 24, 2010, 09:34:35 AM
Quote
Its also almonst impossible for me to write code for a sensor unless someone actually has one and they are willing to be guinea pigs for my code and they can commit the time and effort into helping. ie for every change I make I have to send you a hex file to test and let me know the result. Obviously I don't want to splash out £173 for a device that I have no use for once its up and running.
If you live in the EU, and you don't mind paying for shipping twice, just buy the device and mail it to Webbot directly. When he's done he can mail it to you.

A small price for someone writing code for you :P

As for that IMU, its like 1/3rd the size of the Razor, a good thing for a flying robot. It looks a lot like a secret product I was developing but then ditched last year for market reasons . . . mine would have been 120 euros cheaper and WebbotLib compatible =P
Title: Re: New C library - testers required
Post by: Invicta on June 24, 2010, 12:55:42 PM
Hi Admin & Webbot

I only considered the CHR-6dm AHRS because it seemed to be a complete product with 3-axis position output from a EKF.  It also comes with a PC interface to do all the calibration.  Could you adapt the interface (open source) for the SF9DOF?  I assume that you know of the work done at DIYDRONES to make the SF9DOF into a AHRS? Some links below:

   http://code.google.com/p/sf9domahrs/ (http://code.google.com/p/sf9domahrs/)
   http://diydrones.com/profiles/blogs/new-imu-from-sparkfun-soon-to?id=705844%3ABlogPost%3A129107&page=1#comments (http://diydrones.com/profiles/blogs/new-imu-from-sparkfun-soon-to?id=705844%3ABlogPost%3A129107&page=1#comments)
   http://www.mcselec.com/index.php?option=com_content&task=view&id=269 (http://www.mcselec.com/index.php?option=com_content&task=view&id=269)

If you like I would be willing to purchase a SF9DOF and help with testing  :)

Cheers
Title: Re: New C library - testers required
Post by: Admin on June 24, 2010, 01:16:50 PM
Remember that Webbot isn't getting paid to do this . . . so you need to be committed to the sensor/device that you'd want him to add. Any reason the Razor won't work for you? Its already done, and lots of people already use it. This new sensor might never have any users due to its price and obscurity, meaning Webbots time might be better spent working on adding something else . . .

I recommend taking my Razor code, which I can send to you when you're ready, and hacking it for your IMU. It'll work just the same, and only requires a few tweaks I'm sure. Then submit the working final code to Webbot and he'll clean it up and add it to Webbot.
Title: Re: New C library - testers required
Post by: Webbot on June 24, 2010, 01:27:36 PM
Everyone is able to use the DIYDRONEs code - but I cant snaffle it and make it part of WebbotLib as its their property. You also get into versioning issues/updates as their code changes.

So either use Admins code (written using WebbotLib) for the sensor, or use other peoples like DIYDRONEs. As far as your main board is concerned then WebbotLib will support Admins firmware for the device but not necessarily any one elses for now. But since all of the interfaces work using UART then it would be quite easy to write your own sensor reader to match the firmware you have installed on the Razor.

We have already got this going so buying a Razor wont actually help me at all. It comes down to what you think is the best sensor for the job. If its the one you have discovered then 'you and I' will have to work together to make any use of it.

Hope that helps!
Title: Re: New C library - testers required
Post by: Admin on June 24, 2010, 01:30:21 PM
Quote
will support Admins firmware for the device but not necessarily any one elses for now. But since all of the interfaces work using UART then it would be quite easy to write your own sensor reader to match the firmware you have installed on the Razor.
Invicta just wanted interface code, no firmware rewrites needed (I hope!). Invicta, just email when you want my Axon code that interfaces with the Razor. And we'll work from there . . .
Title: Re: New C library - testers required
Post by: Invicta on June 24, 2010, 04:41:58 PM
Right, tomorrow I will buy a Sparkfun 9Dof Razor IMU board;

http://www.active-robots.com/products/sensors/sparkfun/9-degrees-of-freedom-razor-imu.shtml (http://www.active-robots.com/products/sensors/sparkfun/9-degrees-of-freedom-razor-imu.shtml)                       
Note; must check it has the ATmega328.
Admin, please send me your source code for the Razor firmware (is it written in 'C' ???). Plus any notes you may have on how it works and how to upload it; so that I can swat up. You have my email address.

Webbot, when do you hope to have the updated WebbotavrcLib with support for Admin's firmware available?

Thanks guys for all your help. I will save the CHR-6dm AHRS for another pay cheque.
Title: Re: New C library - testers required
Post by: Admin on June 24, 2010, 04:51:27 PM
sent.

If it says AHRS, then it has the ATmega328P in it.
Title: Re: New C library - testers required
Post by: Webbot on June 24, 2010, 06:53:44 PM
Webbot, when do you hope to have the updated WebbotavrcLib with support for Admin's firmware available?

It will be in the next release - so maybe over the next week or two. But Admin can also give you code to work on the master cpu in the meantime anyway. I am just tidying it up and making it WebbotLib compliant, and adding it to Project Designer. So releases of WebbotLib dont need to hold you back.




Title: Re: New C library - testers required
Post by: Webbot on July 03, 2010, 05:25:15 PM
WebbotLib Version 1.22 has been released with the following features:-

    *  iopin.h - pin_make_output now specifies the initial output value, and pin_pulseIn/Out now specifies if the pulse is active high or low
    *  HMC5842 - the compass now also returns the raw magnetometer values in rawX, rawY, and rawZ. It also calculate the roll and pitch angles
    *  Added Sensors/IMU/Sparkfun/razor.h - but needs new firmware from Admin at societyofrobots.com for the Razor
    *  Added the Maths folder for 3D vectors and matrices and 2D vectors
    *  Added GaitRunner so that your robot can use a gait exported from Gait Designer without needing to be connected to the computer.


Title: Re: New C library - testers required
Post by: dellagd on July 03, 2010, 08:41:37 PM
Hello Webbot-

Have you added this yet? I didn't see it... I found it on the forum from Admin and I was hoping you could add it in. I found it useful.

(See attachment)

You use it like this (and I must say, it is extremely simple):
If you want a 1 digits number you would do (At least this is what I saw in the example code)-

Code: [Select]
int whatever_you_want = random_number(1);
or for 2 digit numbers:

Code: [Select]
int whatever_you_want = random_number(2);
so on, I think u get the point.

here is the thread: http://www.societyofrobots.com/robotforum/index.php?topic=10118.0 (http://www.societyofrobots.com/robotforum/index.php?topic=10118.0)

F.Y.I. ALL CREDIT TO ADMIN




Title: Re: New C library - testers required
Post by: madsci1016 on July 03, 2010, 11:06:20 PM
did the function to return the # of bytes in the uart buffer get added in?

I didn't see it in the pdf.
Title: Re: New C library - testers required
Post by: klims on July 04, 2010, 12:45:53 AM
Hey webbot, what are the chances of getting support for Pololu servo controllers added to the webbotlib? Specifically Mini Maestro 24 channel. I'd be more than willing to test the stuff for you.

Maybe even better would be general support for the Compact, Pololu and SSC protocols.
Title: Re: New C library - testers required
Post by: Webbot on July 04, 2010, 08:00:14 AM
did the function to return the # of bytes in the uart buffer get added in?
I didn't see it in the pdf.

It was added in the previous release. But its not in the uart its in buffer.h - see bufferBytesUsed. This means you can also use it on the transmit buffer (which would help in implementing flow control). Buffers may also be used for things other than uarts.

@dellagd - I dont really want to add the random number generator to the library as it will pull in the ADC support to seed the random number generator. Which is quite an overhead if you aren't otherwise using the ADC channels

@klims - I'll take a look at the protocols but no promises at this stage.
Title: Re: New C library - testers required
Post by: Webbot on July 04, 2010, 06:15:13 PM
Hey webbot, what are the chances of getting support for Pololu servo controllers added to the webbotlib? Specifically Mini Maestro 24 channel. I'd be more than willing to test the stuff for you.

Maybe even better would be general support for the Compact, Pololu and SSC protocols.

Having appraised the different protocols then I will be looking to add the Mini SSC protocol into the next version of WebbotLib. I have selected that protocol as it is the most compact (fastest) - but is still missing a trick to save space - if there is anyone here from Pololu then PM me please please please ! The Pololu Mini Maestro supports this protocol with no special settings and so I'll be sending you an interim release soon so you can test it.

Title: Re: New C library - testers required
Post by: klims on July 04, 2010, 11:41:41 PM
The Pololu Mini Maestro supports this protocol with no special settings and so I'll be sending you an interim release soon so you can test it.

Fantastic! Thanks mate. I'll be waiting for you PM

I'm keen to get one of the other protocols working with the webbotlib. They offer more features with the servo controller than the SSC. I understand that you have a ton of things going so if there is any help I can provide to make it happen let me know
Title: Re: New C library - testers required
Post by: Webbot on July 05, 2010, 02:56:26 PM
The Pololu Mini Maestro supports this protocol with no special settings and so I'll be sending you an interim release soon so you can test it.

Fantastic! Thanks mate. I'll be waiting for you PM

I'm keen to get one of the other protocols working with the webbotlib. They offer more features with the servo controller than the SSC. I understand that you have a ton of things going so if there is any help I can provide to make it happen let me know
I've sent you a PM - but if anyone else has a serial servo controller board that supports either the miniSSC or Pololu Compact protocols and you are interested in helping to debug it then PM me
Title: Re: New C library - testers required
Post by: Invicta on July 13, 2010, 03:48:25 PM
Guys, yet more fantastic work, but a little hard to follow. For this white rabbit I recommend a strong pair of binoculars.

Webbot

I have added the Razor 9DoF in my Project Designer and initiated the generate process. This is my understanding of how it should work for the Razor. Please correct me if I am wrong.

The Example.txt file is just that, it is c-code that can be compiled to give good examples of how to access/control the devices selected in Project Designer.

“Example.txt” includes "hardware.h" that includes "xhardware.h" that includes "razor.h" and so on.

I would use code from “Example.txt” if I just wanted to output the Razor values to Hyperterminal en mass.

If I wanted to extract and use the individual Razor values within my own program I would have to use code from “Razor.c” and include “hardware.h”. “Razor.h” etc would be picked up as above through “xhardware.h”

Admin

Your “razor_9dof_board.c” has a include for “hardware.h”. Is this the “hardware.h” generated by Project designer? When complied, the hex file to be uploaded to the Razor using the Arduino bootloader.

I could not find a include for “axon_processing_code.h”.  Has “axon_processing_code.h” and the “c” file that calls it been superseded by Webbot’s “razor.c”?

Thanks for your help
Title: Re: New C library - testers required
Post by: Admin on July 13, 2010, 04:02:16 PM
Quote
Your “razor_9dof_board.c” has a include for “hardware.h”. Is this the “hardware.h” generated by Project designer? When complied, the hex file to be uploaded to the Razor using the Arduino bootloader.

I could not find a include for “axon_processing_code.h”.  Has “axon_processing_code.h” and the “c” file that calls it been superseded by Webbot’s “razor.c”?
yes on all counts
Title: Re: New C library - testers required
Post by: Webbot on July 19, 2010, 02:45:29 PM
WebbotLib Version 1.23 has been released with the following features:-

    * a2d.h - Added a2dReadMv

    * Reworked ALL analogue sensors to work with different ADC reference voltages


    * Added: Audio/SOMO14D audio playback device

    * Added generic support for serial servo controller cards: see servoSerialInit

    * Added support for the ATMega644

Title: Re: New C library - testers required
Post by: tmoney68 on July 19, 2010, 10:57:05 PM
Again Webbot, you never cease to amaze me!  I only wish to grow up to be like you someday!

Really....excellent work!
Title: Re: New C library - testers required
Post by: Webbot on August 11, 2010, 02:07:12 PM
WebbotLib Version 1.24 has been released with the following new features:-

    * core.h - added the 'isqrt' function to calculate the square root of an uint32_t without needing the floating point library

    * The Stepper directory has been added to handle stepper motors. The initial (alpha) version copes with the Pololu A4893 as well as the generic L297 controller

    * GaitRunner.h has been improved via the new gaitRunnerSetDelta and gaitRunnerGetDelta functions which allow you to modify the gait at runtime. For example: change the ankle joints of a biped if it is walking up, or across, a slope so that it doesn't tip over

    * Sensors/Encoder/Generic/fastquad,h now has a MAKE_GENERIC_FAST_QUADRATUREx2 constructor. This requires an INT pin for both channels A and B - but the resolution of the encoder is doubled generating 4 ticks per stripe on the encoder disk.


(EDIT: fixed a typo )
Title: Re: New C library - testers required
Post by: madsci1016 on August 11, 2010, 05:18:04 PM
   * Sensors/Encoder/Generic/fastquad,h now has a MAKE_GENERIC_FAST_QUADRATUREx2 constructor. This requires an INT pin for both channels A and B - but the resolution of the encoder is doubled generating 4 ticks per stripe on the encoder disk.

To clarify, this means you are reading full resolution quadrature counts now? Or something fancier?
Title: Re: New C library - testers required
Post by: Admin on August 11, 2010, 05:29:50 PM
   * Sensors/Encoder/Generic/fastquad,h now has a MAKE_GENERIC_FAST_QUADRATUREx2 constructor. This requires an INT pin for both channels A and B - but the resolution of the encoder is doubled generating 4 ticks per stripe on the encoder disk.

To clarify, this means you are reading full resolution quadrature counts now? Or something fancier?
Full res . . . I gave Webbot a good talkin to :P
(he gave in after I brought up the crying kittens)

Actually, if coded, it can get even fancier but accounting for rotational velocity and guessing the location between clicks.
Title: Re: New C library - testers required
Post by: Webbot on August 11, 2010, 06:07:10 PM
The encoders now work in one of 3 different ways - and this really depends upon how many INT, PCINT, and just normal IOPins you have available. So all of the 'older' code will continue to work.

1. You can use a PCINTxx for Channel A - along with a general IOPin for Channel B. This gives two ticks per 'stripe' ie 2 x resolution. But PCINTs are 'slowish' so not good for a hires encoder

2. You can use an INTxx for Channel A - along with a general IOPin for Channel B. This is the same as option 1 - but the interrupt is processed faster and copes better with more hires encoders

3. The new addition. You can use INTxx for Channel A and INTyy for Channel B. This gives double the resolution compared to the previous methods (ie 4 ticks per 'stripe') and, like option 2, is highly optimised for the speed of hires encoders.

So the choice is up to you depending on what pins are available.

Quote
Full res . . . I gave Webbot a good talkin to
(he gave in after I brought up the crying kittens)
Well my dog weighs about 30kg. He eats kittens in his sleep.  :)
Takes a lot to make him cry (unless he runs short on kittens)

Title: Re: New C library - testers required
Post by: Webbot on August 13, 2010, 07:45:19 PM
WebbotLib Blog Entry

Next release will add a 4th option - using 2xPCINT pins with 4 clicks per revolution.

Am considering an overhaul of the I2C code. At the moment WebbotLib assumes one hardware I2C bus - which is fine for the currently supported processors. But 'other' processors have more than one. Main change is that the slave I2C device address should be unique on the given bus (at the moment each device must be globally unique given one bus).

One reason for thinking about this: if you want say 2 of a particular device but its I2C address cannot be changed then you are stuffed. So if I allow a bit bang sw I2C bus then you can add extra buses and have one device on each. Or if the hardware has 2 x I2C hardware bus' then thats fine too.

I've already done the SPI stuff like this. ie you create a SPI bus (either using hardware  or simulated in software) and then say what devices are on that bus.

Just a heads up - as you may then need to re-create any I2C devices in Project Designer to attach them to an I2C bus.




Title: Re: New C library - testers required
Post by: Webbot on September 03, 2010, 02:08:54 PM
The online documentation at http://webbot.org.uk/WebbotLibDocs (http://webbot.org.uk/WebbotLibDocs) is now searchable via the text input and Find button - I got fed up waiting for Google to index it all !

The pages load a lot fast now too.

 
Title: Re: New C library - testers required
Post by: Webbot on September 20, 2010, 04:17:08 PM
Version 1.25 released:-

* Encoders - The MAKE command now has an extra parameter to say whether or not you want the encoder to interpolate to generate a guesstimate of its current 'part-click'. Most useful for low resolution encoders attached to large wheels. For backwards compatibility you will need to add a FALSE parameter to your encoder MAKE commands or, if using Project Designer, then regenerate the code.

* Stepper Motors - fixed some bugs and also added Stepper/Generic/Bipolar.h for a generic stepper motor controller using h-bridge components such as the L293 series


Title: Re: New C library - testers required
Post by: Webbot on October 01, 2010, 04:14:09 PM
Version 1.26 released. See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page) for details.
Title: Re: New C library - testers required
Post by: Webbot on October 04, 2010, 01:10:39 PM
A few changes/additions/fixes to Board Designer and Project Designer

http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page)
Title: Re: New C library - testers required
Post by: Webbot on October 09, 2010, 01:45:44 PM
Version 1.27 released. See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page) for details.
Title: Re: New C library - testers required
Post by: madsci1016 on January 04, 2011, 03:18:02 PM
No updates in a few months, everything ok?
Title: Re: New C library - testers required
Post by: Webbot on January 04, 2011, 05:19:15 PM
No updates in a few months, everything ok?
Had to go and get one of those ghastly things called a 'job' ! Cramped my time somewhat since October.

But ... new minor 1.28 release coming soon with a couple of minor fixes plus added the ITG3200 3 axis gyro.

Followed closely by... a beta 2.00 - which does some more code generation - mainly to do with initialising things like timers and interrupt handlers. Makes the code smaller and the interrupt handling much more efficient hence leaving more cpu time for your program to run. Also generates 'makefile's for those not using Windows/AVRStudio.
For those who use 'ant' it will also be possible to have an ant task to generate the code from the Project Designer project file without having to launch Project Designer. Useful for doing a batch clean build of all of your projects when a new WebbotLib is downloaded.

Sort of put the C++ port on ice for now. The avr C++ compiler has quite a few bugs/anomalies and trails the C compiler in support.

So yes ... I'm still kicking ... thanks for asking
Title: Re: New C library - testers required
Post by: Admin on January 04, 2011, 05:28:46 PM
As a power user, I'm also a major driver (slave driver that is hehe) for updates in the past. I'm always adding new devices or finding new bugs. But lately I've been too busy to do either . . .
Title: Re: New C library - testers required
Post by: madsci1016 on January 04, 2011, 05:34:53 PM
Good to hear. Aren't those job things pesky!

Quote
Followed closely by... a beta 2.00 - which does some more code generation

In my opinion, I fully support forcing people to use project designer in the next major release if it optimizes code. I know you had mentioned it in the past... What's your stand on it now?
Title: Re: New C library - testers required
Post by: Webbot on January 04, 2011, 05:39:44 PM
In my opinion, I fully support forcing people to use project designer in the next major release if it optimizes code. I know you had mentioned it in the past... What's your stand on it now?

Yep thats my preference too. But folk like KurtEck make a good case for keeping some of the other bits'n'pieces. So my view is that if you use Project Designer then you'll get better/smaller/tighter code; but if you use the 'power features' like setting up your own timers and handlers then it will still be possible to do - but it will then bring in the extra payload. That way the power users are no worse off, but the PD users get a benefit.


Title: Re: New C library - testers required
Post by: Webbot on January 05, 2011, 02:29:33 PM
Version 1.28 now released - see http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page)
Title: Re: New C library - testers required
Post by: Webbot on January 12, 2011, 01:40:47 PM
Forgot to mention that in Version 1.28 there is the extra functionality:
1. The Tools | Generate menu option now laos creates a makefile - great for those non-AVRStudio, Mac, Unix users who have no other way to build their code. Just change to the project folder and run 'make' to create your hex file.
2. Mac and Unix users were reporting that the 'Tools | Generate' command didn't do anything. I think I've fixed this but have no way of testing. So can the first person who finds it works or fails reply to this post to confirm (ie don't say 'It doesnt work on a Mac' if someone has already said that.

EDIT: A Mac user has confirmed that the Project Designer 'Tools | Generate' option now works correctly.
Title: Re: New C library - testers required
Post by: Webbot on January 17, 2011, 05:18:04 PM
I now want to trial a pre-release of WebbotLib Version 2 - PM/email me if you are interested in being a guinea pig having read the following !

What is it?
Well its a new download of WebbotLib (not yet in SourceForge - so if you enroll then I'll send you the link)
Yes - you can install it into another directory. So you can keep the existing WebbotLib version 1 as well as the new Version 2
The edit box in Project Designer (which asks you to locate the WebbotLib directory) decides if its Version 1 or Version 2 and then generates code, AVR Studio file, makefile accordingly. So the same Project Designer can cope with both versions.
Yes its an alpha release so may have some issues - but you can still use your Version 1 download as well.

Why would I want it?
In summary - it produces much smaller code.

Yep - but I have an ATMega mega with mega amounts of mega program space. So why would I care if the code is smaller when I've got lots to spare?
Well small code normally = more efficient code.
And the main point here is in interrupt handling - ie since the interrupt code is more efficient/quicker then it leaves more time for your application to run or more 'things' that the interrupts can do in the same time - like control more servos via software PWM for example.

So what's the catch?
In order to create more efficient code then the library needs to know what devices you've got connected. With Version 1 then it only knew this at runtime and so had to assume that you might do anything. With version 2 then you must use Project Designer (from my site http://webbot.org.uk (http://webbot.org.uk)) so that it knows ahead of time what you actually want to do. This allows WebbotLib to throw away code it knows you will never use - as well as generate some highly optimized code for the devices you ARE using.

Ok - but I'm an advanced geek and want to add my own code to tap into timer overflows, compare match, and capture interrupts to handle devices not supported directly in Project Designer! Can I still do that?
Sure. All the old calls are still there - but using these advanced features will bring in extra code and cut down on the memory savings.

Do you still support AVRStudio ?
The build process for Version 2 is quite complex to try and squeeze out every bit of non-used code to make the executable as small as possible.
This means setting different compile options for different files. Version 2 even creates a library (.a file) for your project.
Some of these things are achievable in AVRStudio - but not everything. In the meantime, until I find a better solution, then I would suggest that before you regenerate the code form within Project Designer that you close the project in AVRStudio and delete the '.aps' and '.apw' files. Failure to do so may mean that AVRStudio doesn't pick up the latest changes since it doesn't scan these files to see if they have been updated by another thread like Project Designer.
The toolchain in AVRStudio is also rather limited. So to squeeze the last bit of memory in your program then I suggest you use the 'makefile' generated by Project Designer. From a command prompt: move to the project directory and just type in 'make' (without the quotes) and press return.
Alternatively: in AVRStudio go into the project settings and tell it to use an external makefile instead.

What boards do you support?
Since the whole 'sys/' folder has disappeared then you can only use Version 2 if there is a board file for Project Designer to work with. If you have a custom, or unlisted, board then I suggest using my Board Designer to create your own board for subsequent use in Project Designer. Since the resultant code is smaller then Project Designer will now support the ATMega8 - and a 'bare bones' project that does almost nothing, but has the whole WebbotLib harness, only needs about 2.5k.


Why keep AVRStudio?
Well this is one for the future really. Project Designer generates all your skeleton code and a 'makefile'. So it could also run the 'makefile' - ie build your code. So all that is left is a 'text editor' and executing something like 'avr-dude' or 'fboot' to upload it to the chip. The only missing piece is the AVRStudio simulator/debugger.

Summary
The main difference is that you must use Project Designer. If you are using the Axon, Axon II, $50 Robot, or any other board currently supported then this is not an issue.
If you have an unlisted board, or a home made board, then you will need to use Board Designer to make it available to Project Designer. Whilst this may be a hassle - it is a one off process. If you are using Board Designer to describe an unlisted commercial board then let me know - I could add the board design to future releases of Project Designer  to allow everyone to benefit.


Title: Re: New C library - testers required
Post by: smashing robots on January 19, 2011, 10:25:21 AM
You make a great work, many thanks for this library
Title: Re: New C library - testers required
Post by: Webbot on January 24, 2011, 03:35:10 PM
For those of you who want to try the alpha version of WebbotLib Version 2.00

Step 1 - download the library. Its not on sourceforge yet so get it here http://webbot.org.uk/webbotlib/webbotavrclib-2.00.zip (http://webbot.org.uk/webbotlib/webbotavrclib-2.00.zip)
Step 2 - unzip the file into a fresh directory so that you keep your Version 1.xx of WebbotLib as its possible to use both versions.
Step 3 (optional) - if you want to try an existing project with Version 2.00 then I would recommend that you copy your current version 1 directory to a new workspace so as not to clobber your version 1 project. But dont copy the *.aps and *.aws AVRStudio files so that these are generated afresh.

Dont forget that Version 2 needs you to use Project Designer - you can't just build it on the fly by adding a sys/*.h file as they no longer exist. (But don't worry - you can use Board Designer to create your own custom board if its unlisted and use that within Project Designer).

The 'decision point' is in Project Designer when you choose the tools + code generation option. In the familiar 'WebbotLib' folder text box you need to select either your Version1, or your new Version2 directory created in step 2 above. Project Designer will then create code that is appropriate to that version of WebbotLib. Dont worry - it can tell by looking at the directory whether its Version 1 or Version 2.

Having generated the code then either use AVRStudio, or BETTER, launch a DOS Command Prompt and change to your project folder and type in 'make' to execute the makefile generated by Project Designer.

Hint: if you aren't using devices built onto your board then disable them in Project Designer by clicking on the tick box to make the finished code smaller. EG if you aren't using the LED segment display on your Axon II then disable it. Its the only 'built in' device which requires the scheduler code. So it could make your code smaller. Or if your finished robot doesn't require a UART for PC comms then disable any on board uarts. You get the picture.


New: there is a new device called 'clock' which is auto-added to your project. In Version 1 the clock, which generates all the internal timings, was set up to use any timer left over after you had initialised all your hardware. The 'clock' device is automatically added to your project but is ignored if you are still generating code for Version 1 - although the error checking makes sure that there will at least be a timer available for it. However: if you are using Version 2 then it sets aside the timer you have indicated for use by the clock and scheduler. The clock device also has a parameter to allow you to set how many concurrent jobs your own code will put into the scheduler. For example: the marquee on the segmented LED of the AxonII is the only device, currently, which requires the scheduler (to scroll the text) - but no need to worry about that as Project Designer knows that that is the case. However: if your own code uses the scheduler (say to update a PID or IMU) then you will need to edit the 'clock' and indicate that you need '1' scheduled job. Of course you can take the 'mad' approach and say you need loads - but that will waste memory unnecessarily.

Version 2 generates all sorts of new files into the auto-created 'lib' sub folder of your project. By all means take a look at them (but don't change them!). Since Project Designer knows about all the timers you are using, and how best to setup prescalers and timer modes, then the code to initialise timers, and the clock, is now very small and exact.

Advanced: look at lib/opt_TimerCompare.c and similar - these sets up the interrupt service routines for each timer and channel. The generated makefile won't bother including these file unless you have used one of the 'attach' functions to add your own call back to a timer overflow, compare match, or input capture. Hence all those ISRs (which are only a handful of C code lines but generate masses of code) are only added to your finished program if you are using those advanced functions.

Anyway - have a play. Enjoy (ie get frustrated, bang head on table/wall, call me every name under the sun). Since its 'alpha' then PM/email me any issues - rather than posting on SoR. Try comparing the finished program size from Version 1 with the new Version 2 for the same project. Stats would be interesting - well to me anyway! The ATMega8 is definitely a 'supported' player again - although its lack of useful timers will still limit what it can be used for!


BUT - don't forget, you can carry on using your Version 1 code simply by changing the WebbotLib directory at code generation time.

Webbot
Title: Re: New C library - testers required
Post by: Webbot on February 06, 2011, 03:14:01 PM
Just released a new application called Webbot Downloader.
This allows you handle all of my apps in one central place, including automatic downloads to your computer when something changes.
Check it out here: http://webbot.org.uk/iPoint/48.page (http://webbot.org.uk/iPoint/48.page)

Edit: 13 Feb 2011 - New version released to fix a new problem caused by SourceForge changing their site.
Edit: 17 Feb 2011 - Fixed another (SourceForge related) issue which stopped it downloading WebbotLib itself
Title: Re: New C library - testers required
Post by: Webbot on February 21, 2011, 04:22:01 PM
Version 1.29 released.
It supports the ATmega1284P (and the Orangutan SVP board).
It also allows you to control up to 8 servos from just one hardware 16 bit PWM channel (by adding a 74HC238 chip).

Hopefully - those of you who are using the Downloader should now pick it all up automatically, whilst retaining the previous version just in case you are in the middle of something critical !
Title: Re: New C library - testers required
Post by: Webbot on February 22, 2011, 02:22:16 PM
Yet another version of the downloader. Check it out here: http://webbot.org.uk/iPoint/48.page (http://webbot.org.uk/iPoint/48.page)

Main changes are to add WebbotLib V2 and also to let you know if there is a new version of the downloader ! I cant get it to auto-overwrite itself whilst it is running.

No docs yet for WebbotLib V2 (am working on it) - but you MUST use Project Designer to create your code - no more sys/*.h files. You can still access all the low-level stuff to add, at runtime, support for any bits'n'pieces not directly supported by Project Designer.

So the original version of WebbotLib (V1) is planned to be phased out in the next month or two - unless anyone can give me a valid reason !
Title: Re: New C library - testers required
Post by: Webbot on March 08, 2011, 09:40:47 PM
Versions 1.30 and 2.02 here http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page)
Title: Re: New C library - testers required
Post by: Webbot on April 13, 2011, 12:28:54 PM
Version 2.03 release.
As well as incorporating the recent fix for GP2 sensors it also contains a first release for the DroneCell for sending, receiving SMS text messages.
Title: Re: New C library - testers required
Post by: Webbot on April 20, 2011, 12:02:14 PM
Version 1.31 and Version 2.04 released

For details see: http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page)
Title: Re: New C library - testers required
Post by: Webbot on July 02, 2011, 10:44:51 AM
The new C++ version is almost ready. Project Designer will be able to generate either C or C++ code for your project.
For a sneak preview of the C++ docs then see http://webbot.org.uk/WebbotLibDocs2/ (http://webbot.org.uk/WebbotLibDocs2/)
Title: Re: New C and C++ library - testers required
Post by: Webbot on July 06, 2011, 06:24:56 AM
Version 2.05 has been released with C++ support, and a Version 1.32 has been released to keep it inline with the new Project Designer output.
See here for details: http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page)
Title: Re: New C library - testers required
Post by: mdp on July 06, 2011, 05:29:23 PM

Hi Webbot, 

Is there a way to set the PWM frequency for the motor driver?
I ask, since I am worried that it is too high for my motor driver.
I'm using the ST L293D, and in the datasheet it says: 

"This device is suitable for use in switching applications at frequencies up to 5 kHz" 
(First page, last paragraph under "Description")

It would be nice to be able to set the frequency for different conditions.
IIRC, I heard that greater efficiency can be achieved at lower
frequencies, with the trade-off being audible hum (for freq.
between 30 Hz and 20k Hz) or vibration (for freq. below 30 Hz).
I think for battery powered motors, efficiency may be more
important in some conditions than sound or vibration.

Thanks for your hard work.
Title: Re: New C library - testers required
Post by: Webbot on July 07, 2011, 12:26:36 PM
I've done a 'memo to self' to remind me to look at it for the next release - as it will need a new Project Designer as well as libraries. As you've probably noticed it currently uses 10kHz. Having said that I have successfully used it with a L293D but not sure if its a ST one or not though (too faded to read!).

Edit - Coding and docs have been completed - so will definitely be in the next release.
Title: Re: New C library - testers required
Post by: Webbot on July 10, 2011, 10:46:20 AM
New release. See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page)

@mdp - This also includes your PWM frequency request.
Title: Re: New C library - testers required
Post by: mdp on July 11, 2011, 08:11:01 PM

@mdp - This also includes your PWM frequency request.

Hi Webbot, 

I'll try out the new code this week.

Thanks again  :)

Title: Re: New C library - testers required
Post by: Webbot on August 13, 2011, 10:42:41 AM
New release of WebbotLib Version 1.34 and 2.07.  See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page).

Note for Razor users - Board Designer now has board designs for the two revisions that came after their initial board (different compass and gyro) - and Board Designer shouws the Sparkfun product code for each.

AFAIK: Admins code (for loading onto the Razor) only supports the initial design and not the two revisions that have replaced it - but would be easy enough to change as the new compass and gyro are already supported.

Anyone fancy me doing an AHRS for the Razor so that it gives you compensated roll, pitch and yaw?


admin edit: I fixed the dead link
Title: Re: New C library - testers required
Post by: Invicta on August 23, 2011, 04:32:24 PM
@Webbot

Re: AHRS for the Razor.

Yes please that would be great. Will it be able to support the initial design and the two new revisions of the Razor?

I could lend you my Razor (initial design I think with ATmega328) if that will help. A contribution to Webbot.org would also be possible.

Is there any word on the new revisions? Are they better? Have they fixed any problems?

p.s. Did Admin get anywhere with adapting his robot fish Kalman filter for the Razor?

Quote
I'll volunteer.

And actually, we have a simulator for our robot fish that can probably do it, if you forward me the relevant code to convert into MatLab code.

Not sure how well a robot fish Kalman filter will translate into a plane or ground based robot, however . . .


Regards

Invicta
Title: Re: New C library - testers required
Post by: Admin on August 23, 2011, 08:37:00 PM
p.s. Did Admin get anywhere with adapting his robot fish Kalman filter for the Razor?
We never ended up designing a Kalman filter, as we managed to avoid the need for now. We still might in the future, but we are focusing on other stuff at the moment . . .
Title: Re: New C library - testers required
Post by: Webbot on August 24, 2011, 10:38:39 AM
@Webbot

Re: AHRS for the Razor.

Yes please that would be great. Will it be able to support the initial design and the two new revisions of the Razor?

I could lend you my Razor (initial design I think with ATmega328) if that will help. A contribution to Webbot.org would also be possible.

Is there any word on the new revisions? Are they better? Have they fixed any problems?

The new hardware revisions by Sparkfun to the Razor aren't drastic - they just replace 'old components' with  their 'new equivalents'.
This reminds me how useful WebbotLib actualy is ... ie some components were analogue but are now via I2C. So just change it in Project Designer and you get back results from the new device in the same units ie degrees per second - no programming changes needed!
So a 'generic' AHRS code base would be feasible where 99% of the code is the same for all 3 hardware boards.
Lending me a Razor would be great (cant afford the price tag since I have no other need for one!) - but I am based in the UK not sure where you are - need to avoid import duties! Main reason for needing one is to see what the x,y,z axes are and +/- rotation directions - guess it could be done via email if all else fails.
PM me if you are interested
Title: Re: New C library - testers required
Post by: Joker94 on August 31, 2011, 01:14:08 AM
A quick clarification on the implementation of Version 2 (that i am sure will be of benifit to others).

It is my understanding that if i was running version 2 of the lib and for one reason or another wanted to change back to version 1. All i would have to do is regenerate the code specifying version 1 and all of the existing files except the .aps and the *.aws files could be reused without any modifications. In this instance i would be able to copy the existing files to combine them with the .aps and *.aws files. Is this correct or on the right track?

Cheers

Joker94
Title: Re: New C library - testers required
Post by: Webbot on August 31, 2011, 10:02:04 AM
A quick clarification on the implementation of Version 2 (that i am sure will be of benifit to others).

It is my understanding that if i was running version 2 of the lib and for one reason or another wanted to change back to version 1. All i would have to do is regenerate the code specifying version 1 and all of the existing files except the .aps and the *.aws files could be reused without any modifications. In this instance i would be able to copy the existing files to combine them with the .aps and *.aws files. Is this correct or on the right track?

Cheers

Joker94

Since you are obviously using Project Designer then the 'quick' answer is 'yes - you are correct'.
The more detailed answer is:
1. If you are using the C++ output option from V2 then your own code will be using some of the C++ syntax. V1 only provides C output and so you would need to change your own C++ code back into the C syntax.
2. V2 allows you to use streams like stdin, stdout, stderr etc along with the calls in <stdio.h>. V1 doesn't support this. If you are sticking with 'rprintf' then you should be ok.
3. Some of the more recent devices are only support in the V2 code stream - the release notes highlight this and Project Designer will complain if you try to generate for V1 and you are using a 'V2 only' device.
4. If you are generating V1 code and V2 code for the same project then you may want to consider generating into different folders. Reason being that V2 generates some C files in the 'lib' subfolder which aren't appropriate to V1. So if you are using one directory then you may want to delete the V2 'lib' folder before generating for V1.

Am curious about the question - are you moving from V1 to V2 for the first time and want to reassure yourself that you can always move back to V1 just in case? If so - then don't worry. V2 allows you to do everything that V1 does.

It is my intention to drop V1 in the near future - as its really slowing me down having to support 'V1 for C', 'V2 for C' and 'V2 for C++'. Longer term I want to drop 'C' altogether and only support 'C++' (so I only have one set of documentation to update) - but don't panic this won't stop you from writing your own code in C. Most libraries such as Pololu, Arduino etc only provide a C++ option.

Title: Re: New C library - testers required
Post by: Joker94 on August 31, 2011, 07:20:16 PM
Quote
Am curious about the question - are you moving from V1 to V2 for the first time and want to reassure yourself that you can always move back to V1 just in case? If so - then don't worry. V2 allows you to do everything that V1 does.

Pretty much. But from what you have been talking about going to v2 sounds like the logical step. Thanks for the clarification Webbot!
Title: Re: New C library - testers required
Post by: Gertlex on September 03, 2011, 10:00:35 PM
I've got a question about upgrading between versions of Webbotlib... e.g. 2.06 and 2.07.

I've got a project I started in 2.06.  Upgraded to 2.07 when that was released, and regenerated with Project designer.  I fixed the vector square bug I just PM'd you about in the 2.07 files.  But the bug was still there when I compiled.   In AVR Studio 4, looking in "Project>Configuration Options>Libraries" or ">Include Directories" the path for 2.06 was still listed.  Oddly (to me), there was no way to change this (unlike pre-2.0), but this makes sense if Project Designer is intended to control this stuff...

I tried regenerating the project in Project Designer again (with AVR Studio closed) but this didn't fix it - still 2.06.  

I tried copying the Project Designer project to another folder and generating there, and this generated a 2.07 file. Ok.  

(Solution) Then I moved my .aps file to another location, and regenerated in the original folder, and this fixes the library being referenced.  However I then have to open files again and whatnot in AVR Studio.

Is the above solution the intended approach? Am I just missing something? Or be there a flaw somewhere?

Thanks

Edit: on a semi-related note, if I modify (fix) a Webbotlib .c file, and recompile, the change only takes effect if I manually include the .c file, too.  Why is this?  Where is it getting the old version of the code from - one of the numerous files that appear in the same directory as the .aps file?
Title: Re: New C library - testers required
Post by: Webbot on September 04, 2011, 10:19:08 AM
Gertlex there are a couple of different questions there and I'll handle them in reverse order:

1. The .C files supplied with WebbotLib are there for reference purposes as well as single stepping in AVRStudio in debug mode. Your own Project links with the compiled library file (say libWebbot-ATMega640.a). This file contains all the compiled code for the various C files that make up WebbotLib. So if you change a C file that is part of WebbotLib then the changes you have made will be totally ignored UNLESS you re-build WebbotLib itself (since your project totally ignores the C files and only uses the pre-compiled .a file). Dunk has previously done a tutorial on how to do this and I may get around to producing a C makefile to make it easier. This was a conscious decision on my part. It makes building a project much easier as all the WebbotLib code is already compiled, and it also makes support a lot easier - ie most folk don't need to change the C files in WebbotLib and so I should see the same results as they get in their own project. It would become a real headache for me to debug issues if someone has changed lots of WebbotLib files but forget to mention it (unlike your good self!). So the answer is: if you change a WebbotLib .c file then you will need to either rebuild the library or ask me for an interim release (which I give to you alone - but the fix is in the next release for everyone).

2. Now to the AVRStudio / file location issue. Version 1 of WebbotLib used to generate the AVRStudio files (.aps) in a manner in which you could modify them manually within AVRStudio at a later date. Since you could modify them: then Project Designer would only give you the option to generate the AVRStudio file if it didn't already exist - otherwise you would potentially loose the changes that you had made within AVRStudio if Project Designer overwrote the file. The next problem (as you have mentioned) is that if AVRStudio has the project open when you gen from Project Designer the aps file may be read only (since its open in AVRStudio) or alternatively AVRStudio may write back out the old file when you quit AVRStudio. So in Version 2 I took the decision to use a C 'makefile' and the AVRStudio (aps) file is created to say 'use the external makefile'. This means Project Designer can regenerate the makefile on every code generation without worrying about AVRStudio overwriting it. If you are using AVRStudio to modify project settings then it may well be that you have told it to stop using the makefile and you are now controlling the setup in AVRStudio. So when you changed to another version of WebbotLib then you had probably downloaded this to a new location. The makefile created by Project Designer probably uses the new folder - but since you are using the AVRStudio aps file (which already existed and hence wasn't regenerated - see above) then the new settings are ignored. I know this sounds complex and is a great reason to come up with a single IDE that can collaborate with Project Designer). In summary: with Version 2 then either let Project Designer manage everything via the makefile, or if you want to control it yourself in AVRStudio then its now up to you to include the correct libraries etc. I go with the first option.

Final thought is that problem 2 is caused by question 1 - ie when you upgrade WebbotLib and regen then the makefile may have the new library included, the AVRStudio file may not (since it hasn't been regenerated), and either way, you see the same result as before because you haven't recompiled WebbotLib to include your change to Vector2D.c. Regenerating to a new folder probably fixed the issue as it caused a new AVRStudio aps file to be created. Alternatively your AVRStudio file may have originally been created in Version 1 - in which case - always delete the .aps file before upgrading a project to V2 so that Project Designer defaults to re-creating it.


Long answer but hopefully makes sense!



Title: Re: New C library - testers required
Post by: Gertlex on September 04, 2011, 05:55:46 PM
Thanks! That was easy enough to follow.  I think the one bit left unanswered is what you currently recommend as the proper process for updating process when Webbotlib versions are updated.  Sounds to me like I'm doing it fine, and can just ignore what AVRStudio says is its library, but can/should check the makefile if I'm concerned.
Title: Re: New C library - testers required
Post by: Joker94 on September 10, 2011, 12:13:14 AM
Another question that might benifit others.

When i compile  my code I am getting numerous errors, but all of these errors are to do with the header files. Could this be due to the fact that i have not yet updated to version 5 yet?

Another possibility is the ways in which i have the library and other files installed? is there a recommended place to instal the library and where to have the other plugin's installed(eg. gait designer, blackfin plugin)

PS. it doesn;t matter what version of the library i use I still get the same warnings.
Title: Re: New C library - testers required
Post by: Webbot on September 10, 2011, 07:12:59 AM
Another question that might benifit others.

When i compile  my code I am getting numerous errors, but all of these errors are to do with the header files. Could this be due to the fact that i have not yet updated to version 5 yet?

Another possibility is the ways in which i have the library and other files installed? is there a recommended place to instal the library and where to have the other plugin's installed(eg. gait designer, blackfin plugin)

PS. it doesn;t matter what version of the library i use I still get the same warnings.
Assume you mean version 5 of AVRStudio - in which case that's not the issue - I don't use AVRStudio version 5 either.
Perhaps you could give more info: ie are you using Project Designer or writing all the code by hand, how are you building your project ie in AVRStudio or using 'make' from the command line, what version of WebbotLib are you using, and most importantly what error messages are you getting?
Title: Re: New C library - testers required
Post by: Joker94 on September 10, 2011, 07:28:47 AM
I am using project designer as i am using version 2 of webbot lib, version 2.07 specifically. I am using AVR studio to compile the code.

The error messages such as the following ones (22 errors and 8 warning)

Quote
Build started 10.9.2011 at 22:50:13
-Os -c -o lib/opt_TimerOverflow.o lib/opt_TimerOverflow.c

In file included from lib/opt_TimerOverflow.c:1:
lib/lib_timerdef.h:7:21: error: libdefs.h: No such file or directory
In file included from lib/opt_TimerOverflow.c:1:
lib/lib_timerdef.h:14: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PROGMEM'
lib/lib_timerdef.h:19: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PROGMEM'
lib/lib_timerdef.h:24: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PROGMEM'
lib/lib_timerdef.h:29: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Timer'
lib/lib_timerdef.h:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'NUMBER_OF_TIMERS'
lib/opt_TimerOverflow.c:2:19: error: timer.h: No such file or directory
lib/opt_TimerOverflow.c:3:20: error: errors.h: No such file or directory
lib/opt_TimerOverflow.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PROGMEM'
lib/opt_TimerOverflow.c:8: warning: type defaults to 'int' in declaration of 'Timer'
lib/opt_TimerOverflow.c:8: error: expected ';', ',' or ')' before '*' token
lib/opt_TimerOverflow.c:10: warning: return type defaults to 'int'
lib/opt_TimerOverflow.c: In function 'ISR':
lib/opt_TimerOverflow.c:10: warning: type of 'TIMER0_OVF_vect' defaults to 'int'
lib/opt_TimerOverflow.c:11: warning: implicit declaration of function '__timer_overflowService'
lib/opt_TimerOverflow.c:11: error: 'pgm_Timers' undeclared (first use in this function)
lib/opt_TimerOverflow.c:11: error: (Each undeclared identifier is reported only once
lib/opt_TimerOverflow.c:11: error: for each function it appears in.)
lib/opt_TimerOverflow.c: At top level:
lib/opt_TimerOverflow.c:13: warning: return type defaults to 'int'
lib/opt_TimerOverflow.c:13: error: redefinition of 'ISR'
lib/opt_TimerOverflow.c:10: error: previous definition of 'ISR' was here
lib/opt_TimerOverflow.c: In function 'ISR':
lib/opt_TimerOverflow.c:13: warning: type of 'TIMER1_OVF_vect' defaults to 'int'
lib/opt_TimerOverflow.c:14: error: 'pgm_Timers' undeclared (first use in this function)
lib/opt_TimerOverflow.c: At top level:
lib/opt_TimerOverflow.c:16: warning: return type defaults to 'int'
lib/opt_TimerOverflow.c:16: error: redefinition of 'ISR'
lib/opt_TimerOverflow.c:10: error: previous definition of 'ISR' was here
lib/opt_TimerOverflow.c: In function 'ISR':
lib/opt_TimerOverflow.c:16: warning: type of 'TIMER2_OVF_vect' defaults to 'int'
lib/opt_TimerOverflow.c:17: error: 'pgm_Timers' undeclared (first use in this function)
avr-gcc: Lib/Webbot: No such file or directory
avr-gcc: Lib_Library/WebbotLib: No such file or directory
avr-gcc: v2/2.07: No such file or directory
make: *** [lib/opt_TimerOverflow.o] Error 1
Build failed with 22 errors and 8 warnings...

If i use the original example C file generated should it compile and work on the robot? eg. run the attached the devices etc.

I have a feeling that the problems I am having are due to the way in which I have the files placed and linked in with project designer. I have a file in 'my documents' with all files related to Webbot lib. Withing this file I have a file containing all of the files using webbot lib down loader. Is there a specific way I should have the files setup as to allow them to link into project designer correctly?

Cheers

Joker94
Title: Re: New C library - testers required
Post by: Webbot on September 10, 2011, 07:41:47 AM
It looks as though its not finding the WebbotLib folder and hence cant find 'libdefs.h' which then gives you all the errors.

In AVRStudio go into Project | Configuration Options and on the 'General' tab make sure there is a tick against the option to use an External Makefile. If its not there then your project file is probably a hang over from Version 1 days. In which case exit AVRStudio and delete the '.aps' and '.apw' files in your project folder.

In Project Designer make sure that the field asking you about where WebbotLib is installed is correct, and if you deleted the AVRStudio files as described above then also make sure you tick the option to generate the AVRStudio file. Regen the code and try again.

-- edited as I hit submit by mistake --


Title: Re: New C library - testers required
Post by: Joker94 on September 10, 2011, 07:59:59 AM
I don't seem to have an .apw file.

the files that have been generated are
     -hardware.h
     -make file
     -Avr studio file (aps)
     -AWS file
     -C file

Before hand it seems as though it was generated using version 2.07, and the 'use external make file' was selected.
Title: Re: New C library - testers required
Post by: Webbot on September 10, 2011, 08:12:25 AM
My bad - I meant aws rather than apw.

I'm wondering if its down to the usual spaces in fonlder names issue. Open the generated makefile and at about line 17 you will see something like:-
Code: [Select]
# The library where WebbotLib is installed
WEBBOT    = ../../..

# The library to link against
WEBBOT_LIB = $(WEBBOT)/libWebbot-ATmega328P.a


Whats the contents of your WEBBOT variable?
Title: Re: New C library - testers required
Post by: Joker94 on September 10, 2011, 07:00:33 PM
@Webbot, you got it, it was a space in a folder name. For some reason there was a score between the under score and lib
('Webbot_ Lib'). once this was fixed it all compiled as it should.

Thanks very much for your help Webbot, now can get on and use your library in all of my projects!!
Title: Re: New C library - testers required
Post by: Webbot on October 14, 2011, 08:10:05 AM
New release of WebbotLib Version 1.35 and 2.08.  See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page).

Mainly bug fixes- but also includes a DCM class for use by AHRS systems. There are 3 example projects for the different SparkFun Razor boards available for download at: http://webbot.org.uk/iPoint/49.page (http://webbot.org.uk/iPoint/49.page)
Title: Re: New C library - testers required
Post by: Gertlex on October 14, 2011, 06:13:18 PM
Thanks for fixing project designer's motor driver 5V supply problem, too :)
Title: Re: New C library - testers required
Post by: Crunchy Theory on November 06, 2011, 06:04:35 PM
I'm getting the following error when I try to run the ProjectDesigner-generated makefile using both webbotlib 1.35 and 2.08:

    make: *** No rule to make target `../webbotlibV1/1.35/libWebbot-ATmega328P.a', needed by `CR2.elf'.  Stop.

I used WebbotDownloader to install ProjectDesigner and both webbotlibs, and touched none of the files after they were generated, so I'm not sure what I'm doing wrong. Here's what I think is the relevant part of the makefile (let me know if it's insufficient):

# The library where WebbotLib is installed
WEBBOT         = ../webbotlibV1/1.35

# The library to link against
WEBBOT_LIB = $(WEBBOT)/libWebbot-ATmega328P.a
Title: Re: New C library - testers required
Post by: Webbot on November 07, 2011, 08:27:45 AM
The error is because the makefile cannot find the libWebbot-ATMega328P.a file at that location. I trust you are running the makefile from a command window and you have changed into the folder where your project is located (rather than running it from, say, Windows Explorer - whereby your current directory may be somewhat unknown).

Title: Re: New C library - testers required
Post by: Gertlex on December 03, 2011, 10:50:07 AM
Hey Webbot,
You have at least two of the Sharp IR range finder libraries mixed up.  http://webbot.org.uk/WebbotLibDocs/34542.html (http://webbot.org.uk/WebbotLibDocs/34542.html)

The GPD12 is a 4-30cm range sensor, and the GPY0A21YK is a 10-80 cm sensor.  I bought the later, and the former's value is given by Pololu. http://www.pololu.com/search/compare/79 (http://www.pololu.com/search/compare/79)

You even have a comment in the A21YK's code: // The following data looks wrong

Thanks!
Title: Re: New C library - testers required
Post by: Webbot on December 04, 2011, 01:59:46 PM
Not quite sure what you mean. Do you mean that the WebbotLib documentation is wrong or that the code doesn't work?
Title: Re: New C library - testers required
Post by: Gertlex on December 04, 2011, 02:18:17 PM
Ahh sorry, definitely wasn't my clearest post, there.

 The documentation definitely disagrees with Pololu and my own experience.  The code values defining the voltage/distance curves are also mixed up between wrong, I believe (e.g. in GPD12.c and GPY0A21YK.c).  The values in the code are swapped for those two sensors, I think.  My work around was to tell Project Designer that I was using the GPD12, rather than the GPY0A21YK.
Title: Re: New C library - testers required
Post by: Gertlex on December 08, 2011, 06:10:15 PM
In the core.h docs, you have a small pair of typos.  For the interpolateU function, the examples use interpolate() instead of interpolateU()
http://webbot.org.uk/WebbotLibDocs2/47113.html (http://webbot.org.uk/WebbotLibDocs2/47113.html)
Title: Re: New C library - testers required
Post by: Cristi_Neagu on December 15, 2011, 02:00:11 PM
It's really impressive what this library is capable of, let alone what you can do with the project designer and, eventually, the IDE for it. It has effectively turned programming MCUs into a plug and play process (almost). So, I really got to ask Webbot this: Is there an icecube's chance in hell that you'll ever extend beyond ATmegas to something more powerful, like ARM Cortex? And I don't mean right now, but, you know, eventually...

From what I can tell, the main framework of the library should remain the same, only some low level stuff should be changed (like port addressing and stuff). You know this stuff better than I do.

Also, I know this has probably been asked before, but, I dunno... things change (I hope).

Thanks.
Title: Re: New C library - testers required
Post by: Admin on December 15, 2011, 09:01:26 PM
Cristi_Neagu,
Webbot and I have talked about it several times. We agree that at some point the AVRs will become obsolete and we'll have to move on. But that's likely several more years in the future and there is no pressing demand for other chips at the moment.

Many of the ARMs and such are made to be fast with lots of memory and 'low' power usage, but they lack the I/O that us robotics people need. So at the moment it's more of a wait and see.
Title: Re: New C library - testers required
Post by: Cristi_Neagu on December 16, 2011, 06:24:42 AM
Well... I wouldn't say they have limited IO... It's really easy to find ARM boards with 40+ IO pins, and at a quick glance at STM's site, you could have a 72MHz MCU, with 1Mb of flash, 14 16bit timers (which translates to 35 PWM channels), 21 12bit ADC, 2 12bit DAC, with a grand total of 112 IO ports (this is the STM32103ZG). Of course, that's the top of the line, but the others aren't far behind.

Either way, this is beside the point. You guys make the products, so you decide when the time comes. Until then, keep up the great work :)

Thanks.
Title: Re: New C library - testers required
Post by: Webbot on December 16, 2011, 01:28:36 PM
Cristi - thanx for the feedback and kind words.....

The main issue is getting my head around the architecture of different chips. Its not just changing the port handling as you have noted but also: how to configure timers (for the clock, PWM, software UARTs, software servos etc etc), as well as other hardware related things like hardware uarts, I2C, SPI, ADC. The list is quite big. On top of all that I don't have any of the boards (yes - I started with the $50 robot tutorial myself a few years ago). So the code library will be hit quite hard. Project Designer - less so - other than the code generation part of it.

I don't have any of the boards so, at a minimum, I need an existing IDE that allows me to debug/simulate my code so that I can check things where precise timings is important. I say simulate coz I cant afford to buy JTAG on-chip debugging stuff for all of the combinations.

Add to that the 'Webbot Studio' IDE I am creating. This means sourcing compilers and hardware/software programmer code - both of which need to be 'free' for me to bundle them into a single download. Then multiply that by different host operating systems: Windoze, Unix, 32 bit vs 64 bit, Mac(?) etc etc. The new Studio version will, at least, allow people to submit their boards as well as sensors to a download site so that others can have access - I've almost designed this - but it will mean that these are treated like plug-ins and will work with Project Designer etc. The caveat being that the author will need to know something about stuff like XML and/or XSLT. But the aim is to allow the community to expand the existing AVR version.

There just ain't enough hours to spare - especially since I started a job 3 weeks ago and the weekends just seem to evaporate. Hence being slower to reply to forum posts!

If someone is willing to pay me to work on this full time, so I can give up the day job, then I'm up for it !


Title: Re: New C library - testers required
Post by: Cristi_Neagu on December 16, 2011, 03:51:01 PM
Cristi - thanx for the feedback and kind words.....

No worries. You do good work.

Quote
The main issue is getting my head around the architecture of different chips. Its not just changing the port handling as you have noted but also: how to configure timers (for the clock, PWM, software UARTs, software servos etc etc), as well as other hardware related things like hardware uarts, I2C, SPI, ADC. The list is quite big. On top of all that I don't have any of the boards (yes - I started with the $50 robot tutorial myself a few years ago). So the code library will be hit quite hard. Project Designer - less so - other than the code generation part of it.

I figured as much. I do have to admit that things seem pretty different when you cross over to the ARM side. It's not impossible, but it does take time, especially if you're designing a library of functions while learning how to program the thing.

Quote
I don't have any of the boards so, at a minimum, I need an existing IDE that allows me to debug/simulate my code so that I can check things where precise timings is important. I say simulate coz I cant afford to buy JTAG on-chip debugging stuff for all of the combinations.

Then you might want to check out Keil's IDE for ARM: http://www.keil.com/arm/mdk.asp (http://www.keil.com/arm/mdk.asp). It has a pretty capable simulator, complete with serial windows, disassembly and, more importantly, logic analyzer. There is a free version available, limited to maximum 32kB of code, but that should be enough for some basic stuff, I guess. I also understand that ARM code is supposed to be more compact than comparable 16bit code.

Also, if you're ever looking for a board to start from, Futurlec has some interesting choices, right down in the $20-$30 area, comparable to the Axon (albeit with 5 times as much processing power, but lacking the great library and community support). And, yes, I know you western people have an aversion for Futurlec, but they worked out OK for me in the past.

Quote
Add to that the 'Webbot Studio' IDE I am creating. This means sourcing compilers and hardware/software programmer code - both of which need to be 'free' for me to bundle them into a single download. Then multiply that by different host operating systems: Windoze, Unix, 32 bit vs 64 bit, Mac(?) etc etc. The new Studio version will, at least, allow people to submit their boards as well as sensors to a download site so that others can have access - I've almost designed this - but it will mean that these are treated like plug-ins and will work with Project Designer etc. The caveat being that the author will need to know something about stuff like XML and/or XSLT. But the aim is to allow the community to expand the existing AVR version.

There just ain't enough hours to spare - especially since I started a job 3 weeks ago and the weekends just seem to evaporate. Hence being slower to reply to forum posts!

If someone is willing to pay me to work on this full time, so I can give up the day job, then I'm up for it !

What can I say... the whole community is waiting to see what you come up with, and it sounds great :D

I admit that I'd really want to see an ARM version of WebbotLib, and I don't think I'm the only one. But I do know that once you start something, you got to finish it. So we guys can wait.

Anyways, I'm looking forward to the IDE, and, after that, who knows, you might want to check out some ARM MCUs :P Till then, keep up the great work :D

Thanks.
Title: Re: New C library - testers required
Post by: Webbot on April 21, 2012, 11:49:04 AM
New release of WebbotLib Version 2.09.  See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page).

Fixed bug in HD44780 display when using 8 bit data bus

The library now compiles in GCC 4.7.0 although the supplied libraries are still compiled via GCC 4.3.3 (WinAVR-20100110). This is largely due to some errors in GCC 4.7.0 that I have reported to gnu. However: those of you who have reported compile errors in version > 4.3.3 should now be able to compile - but don't moan to me about any issues if you do so! To find which version of the compiler you are using then at a command prompt type in:

Code: [Select]
avr-gcc --version
You will need to make sure that you have downloaded the latest Project Designer and re-generate your projects (standard practice).

NB If you download the latest Project Designer then you will also need to use this version of the library.
Title: Re: New C library - testers required
Post by: Webbot on September 21, 2013, 02:06:45 PM
New release of WebbotLib Version 2.10.  See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page) for changes/enhancements.

This requires a new download of Project Designer (and vice versa).

For backward compatibility there is also a new WebbotLib Version 1.36 for those (few) folk still using WebbotLib Version 1.

Note that any projects should be re-generated in Project Designer after the update otherwise you will get compile errors.
Title: Re: New C library - testers required
Post by: Webbot on October 06, 2013, 08:28:33 AM
New release of WebbotLib Version 2.11.  See http://webbot.org.uk/iPoint/35.page (http://webbot.org.uk/iPoint/35.page) for changes/enhancements.

This requires a new download of Project Designer (and vice versa).

Note that any projects should be re-generated in Project Designer after the update otherwise you will get compile errors.
Title: Re: New C library - testers required
Post by: Invicta on October 21, 2013, 06:51:55 AM
Must be getting slow in my old age:

I have downloaded all available zip files from SourceForge for webbotlib 2.11 and 2.10, but have been unable to find the PDFs for the WebbotLib Manuals. I need the manual to Calibrate the accelerometers, as suggested in the source code from Webbot for the Sparkfun Razor (SEN-09623). I would be most grateful if someone could point me to a good link for the latest webbotlib manual.

Thanks
Title: Re: New C library - testers required
Post by: Gertlex on October 21, 2013, 06:39:57 PM
Must be getting slow in my old age:

I have downloaded all available zip files from SourceForge for webbotlib 2.11 and 2.10, but have been unable to find the PDFs for the WebbotLib Manuals. I need the manual to Calibrate the accelerometers, as suggested in the source code from Webbot for the Sparkfun Razor (SEN-09623). I would be most grateful if someone could point me to a good link for the latest webbotlib manual.

Thanks

I've noticed this missing as well in the latest downloads.
Title: Re: New C library - testers required
Post by: Webbot on October 25, 2013, 05:38:41 PM
ok - my bad. But in the meantime do the html docs help...http://webbot.org.uk/WebbotLibDocs/ (http://webbot.org.uk/WebbotLibDocs/)
Top area lets you swap between C and C++ docs.

For example in C++ http://webbot.org.uk/WebbotLibDocs2/44500.html (http://webbot.org.uk/WebbotLibDocs2/44500.html)
or in C: http://webbot.org.uk/WebbotLibDocs/34511.html (http://webbot.org.uk/WebbotLibDocs/34511.html)