> Dualpob seems to be a very sophistated extension, but I'm afraid it
> exceeds my programming facilities.
I understand your opinion about the programing part: i give you in this
mail more explications about the dualpob :
* dualpob comes with a default firmware. This firmware answer to command
from various input.
The goal of this default firmware is to link dualpob with others devices
wihtout the need of programming the dualpob:
* The dualpob is see as a big sensor from the external device (for you,
the nxt "see" the dualpob likes a big input/output board connected on i2c).
Some commands are to get or set digital input/output, others for set
servomotors, others to drive pobeye camera etc etc...
* Currently the dual-pob are runing in different prototype project:
some users replace the default firmware and set the dualpob as a
"brain", others users drive the dualpob with the default firmware.
* Today, the dualpob can receive orders from serial or pobeye bus and
i'm working on i2c protocol to set dualpob as a generic i2c slave device
(and interact with the nxt i2c master for example) and build the
protocol documentation and simple example source code for the users.
As you say for the Compass driver, the dualpob driver have to share the
//send a command to dualpob from an i2c master:
i2c_send( dualpob_address );
i2c_send( a_command );
i2c_send( a_parameter );
i2c_send( another_parameter );
//get some status from the dualpob...
status = i2c_receive();
In your RobotC development kit, you only have to write the driver with
the correct command (servo command for example) and parameters (position
x at speed y) and of course i have to provide all docs and source code
example (and finish the code...
I hope that this mail can help you?
(thanks for the robotc forum link!)
Ingénieur système embarqué
4 rue nicéphore niépce
Tel : +33 (0)4 72 43 02 36