Success!

[StuartL]

The power is mine! Mwuhahaha!

Well, 16MHz of mostly single cycle instructions anyway.

I've just successfully compiled my first "Hello world" program for the ATmega128 in the CM-5. Using lots of cut and paste from the example C file with lots of bits I didn't like changed (like typecasting, the interrupt handling etc) I've got a very basic C binary running. It's a whole 223 bytes before I've optimised anything, which should give you an idea of the extreme complexity

Next is my own dynamixel library, after which world domination will be easy.

[roycepipkins]

Congrats!

My bots are sitting on a shelf for the moment. This weekend, however, I hope to make the switch to C. After hello world I want to try to make a single servo inverse pendulum by creating a feedback loop between torque and position.

From there making a robot to oppose your evil robot's quest for world domination should be easy!

[StuartL]

Finally new ground has been broken.

I now have a basic Dynamixel library. It's an entirely interrupt driven 1MBps C library which can do Pings, LEDs and data writes. While it doesn't actually do anything with the return packets it does receive and checksum them correctly awaiting implementation in the real app code.

I've just set my first servo position in C using this library.

Data reads have yet to be implemented (in the sense of scheduling a read and asynchronously waiting for a response) and I intend to write wrapper functions for all Dynamixel instructions including synchronised reads and writes. Return packets will work with something along the lines of a callback to allow continued processing while you're waiting the few milliseconds for the Dynamixel to respond.

This may sound like overkill but if the dynamixel takes 1 millisecond to respond that's up to sixteen thousand instructions which can be executed while the Dynamixel is replying, and that's not counting the time it takes to actually physically execute the move instructions. That's a LOT of processing power you can't use in BCPs.

Once that's all done I'll investigate packaging it properly into a library for you lot to use and it's onto the app code itself.

W00t!

[billyzelsnack]

Have you messed with the return delay? You should be able to do better than 1 millisecond.

[limor]

please share your code here.
You can also put it into the robosavvy project on sourceforge.
(a bit empty at the moment but i plan to upload more bioloid code there soon)

http://robosavvy.svn.sourceforge.net/vi ... vvy/trunk/

to join the sourceforge project, just create your user name there and let me know what it is and i'll add you to the project and you can upload your code and have the benefits of SVN source control.

[StuartL]

I've no problem sharing the library once it's in a release state. I've no problem in using SVN and/or sourceforge for it too.

I've seen comments about the return delay too. I presume it's as high as it is to ensure that the 1-wire pin has time to flip back to receive after the transmit when you've used high level languages. Obviously I won't have this problem in C so I can set this exceedingly low without concern.

I shall post here any more updates. I'm hopeful to have it walking by the end of the week. Optimism? Here? Of course

[limor]

I've seen comments about the return delay too. I presume it's as high as it is to ensure that the 1-wire pin has time to flip back to receive after the transmit when you've used high level languages. Obviously I won't have this problem in C so I can set this exceedingly low without concern.

If you are talking about the time it takes for a servo to respond, that has been previously discussed on this forum. There is no inherent reason for this delay (dont remember how much but it was not negligeable). After the CM5 master sends a message on the bus, it immediately (ie: 1-2 cycles) switches to read-mode and waits till something shows up on the USART. so a safe delay for the servo would be in the order of one microsecond..