Exposed AVR pins not directly used by Bioloid itself

[Miamicanes]

Are any of the Mega128's pins in the CM-5 not directly used by the default software itself accessible via solder pads or testpoints and available for other purposes? Maybe a few pins on at least one fo the ports? God forbid, I2C's DO & DI, or ISP's MISO/MOSI/SCK? JTAG/Debugwire? At the very least, the Rxd pin of one of the Mega128's USARTs?

I looked through the manual (I ordered my kit today), but didn't see anything resembling a schematic or illustrated header map for the CM-5's circuit board. I'm kind of getting the impression that Robotis isn't really trying to be secretive or proprietary... but they don't particularly want to encourage owners to run out, buy female headers from DigiKey, and whip out the soldering iron like they would for a brand new Dragon, Butterfly, or AT90USB, either. I know I could probably try to implement the same RS-485 interface used by the servos and wedge myself into it, but I'd prefer to keep "my" stuff separate, if only to avoid causing weird, impossible-to-debug side effects with the rest of the firmware.

I did see an image of the board in the Bluetooth hack, but the only thing I saw resembling a potentially-available header was "J5". I'm only about 40% sure, but from the one trace I could follow, it looks like it *might* expose the two I2C pins (DO & DI), or possibly be for a "real" ISP header (though 5 pins would be kind of weird, since ISP needs 6 (4, if power is handled separately... RST, MISO, MOSI, and SCK).

(by the way... a pair of hi-res pics of the CM-5's PC board would be a great item to put on the wiki... preferably, with a schematic of the CM-5 to accompany them...)

[pepperm]

Miamicanes

There are a few pins unused on the CM-5s Mega128 but few of them are brought out on a connector I am afraid. There are some ports presented on J5 and the Zigbee connector but all the others unused pins would require connections to the processor pins. Note that PD1(SDA) is exposed on the Zigbee connector but PD0(SCL) is used for the Start button on the CM-5.

I did publish a functional circuit diagram that can be got at from here http://robosavvy.com/Builders/pepperm/CM-5%20Schematic%20V1.JPG

Limor and I are working (somewhat slowly) on a Bioloid I/O module that connects to the CM-5 serial bus and would then allow the connection of all manor of devices through it. I2C would be good I would suggest. The test hardware is designed and published here: http://robosavvy.com/Builders/pepperm/BioloidIOV1.png and I am waiting for Limor (or any one else) to come up with some code to interface with the serial bus.

Is this any use for you?

Mark

[Miamicanes]

Yep, it's exactly what I was looking for

Bummer about SCL. I can think of a few possible ways to hijack the pin for 2-wire use anyway, but I think it would only be viable if the firmware were open-source and I could hack it to let me turn the pin into an output and mask the pin's interrupt so it wouldn't fire every time SCL pulsed.

How sure are you that MISO & MOSI aren't exposed anywhere on the board? Say, as unmarked plated-through holes/vias somewhere else on the board, or even as tiny testpoints designed for pogo-pin contact? After all, Robotis ultimately has to do ISP programming at *some* point during the manufacturing process. I know it's technically possible to flash the chips in clamshell-type sockets before soldering, but I've *never* heard of that technique being used in a production design (if they flash before soldering, they'll spend time/money flashing chips for boards that ultimately will be rejected due to bad solder connections or other parts. By deferring the flash until the board is soldered, they can kill two birds with one stone and flash as part of the testing process). If MISO & MOSI are accessible, that would at least make SPI a viable option.

Also... is the firmware in the Mega128 protected via fusebits, or can it be ripped via ISP (assuming the ISP lines can actually be connected somewhere)? If your schematic is complete and the firmware can be ripped, it might be easier to just make a new board that's basically the same as the one in the CM-5, but with the additional pins brought out to headers. SMD is actually pretty easy to work with, as long as you have a hot air rework tool (I bought one a few weeks ago), use solder paste, and have the boards professionally-made by someone like Olimex or Sparkfun with proper solder masks so surface tension and the flux do all the hard work of aligning the pins with the pads (if you're interested, you can read all about my adventures at avrfreaks.net... the lights pretty much dominated my life from ~October until last week, when they went up on the tree).

[pepperm]

Hi

I'm not sure if the pins you require are exposed through Via's anywhere but am pretty sure they don't come out as pins.

Regarding the firmware, it is supplied on the CD. The Mega128 has a serial boot loader installed and the firmware is uploadable, so you have the hex supplied as a file.

Mark

[djmartins]

Regarding the firmware, it is supplied on the CD. The Mega128 has a serial boot loader installed and the firmware is uploadable, so you have the hex supplied as a file.

Which makes me wonder why no one is working on a Mega128 replacement board that uses essentially the same pinout as the CM5, but brings out more of the IO pins for other uses.
Couldn't one then use it exactly like a CM5 if one wanted to with all the Robotis supplied software?

regards,
DJ

[Miamicanes]

I suspect the fact that the Mega128 is SMD-only has a bit to do with it. The pins on the "big" one are .8mm apart. The pins on the "small" one are .5mm apart. That's pretty dense. Even with a little experience and the right tools, those are hard chips to solder with hot air, and just about impossible to solder with a "normal" iron. Now... removing bridges isn't as hard as it sounds (with a solder wick, it's actually pretty easy to do), but finding them in the first place can be a major pain (problem #1 -- the probes on most multimeters are too big and bulky to easily test adjacent pins for shorts).

Getting the bootloader firmware off the original chip and onto the new one could be a problem, too, if Robotis set the protection fuse when they burned them (AVRs have a fusebit that enables you to protect them from casual ripping). It would be pretty stupid if they did, since their firmware would be almost completely useless without Robotis's own servos anyway, but never underestimate the grief and mischief paranoid lawyers can cause when they start influencing otherwise-sane members of upper management...)

In any case, my own will hopefully be here in less than 9 hours, so I can take a peek myself

[pepperm]

Maybe the Bootloaded is pretty standard and could be replaced by something in the public domain. Bootloaders are pretty simple, they have to be because they only have a small amount of space to live in so a public domain one could be modified if meeds be.

Mark

[limor]

Regarding the firmware, it is supplied on the CD. The Mega128 has a serial boot loader installed and the firmware is uploadable, so you have the hex supplied as a file.

Which makes me wonder why no one is working on a Mega128 replacement board that uses essentially the same pinout as the CM5, but brings out more of the IO pins for other uses.
Couldn't one then use it exactly like a CM5 if one wanted to with all the Robotis supplied software?

regards,
DJ

Actually check out previous posts on this forum for the very affordable Robostix board which has been linked to the Bioloid bus. This board exposes most of the Atmega128 pins.

[dhylands]

How sure are you that MISO & MOSI aren't exposed anywhere on the board? Say, as unmarked plated-through holes/vias somewhere else on the board, or even as tiny testpoints designed for pogo-pin contact? After all, Robotis ultimately has to do ISP programming at *some* point during the manufacturing process.

MOSI and MISO aren't used for ISP programming on the ATMega128. PDI and PDO are used instead.

[pepperm]

Interesting, the Mega128 manual (2467N-AVR-03/06) seems to have lots of errors on page 304. It suggests in table 127 that PE0, PE1 and PB1 are used for the SPI programming interface and these pins are brought out on the J5 connector on the CM-5 PCB. Which is great. However, the text suggests PD0 and PD1 are used. The chip's pin out diagram suggests the SPI interface is present on PB1, PB2 and PB3 though!

So there is some inconsistency.

I would suggest that the PE0, PE1 and PB1 combination is correct because this would make some sense of the J5 connector. MOSI, MISO and SCK are used for ISP programming.

So I take back what I said. I now think that J5 is for programming the Mega128. Thanks for the heads up.

So, we can install our own boot loader is needed. Maybe we could read out the Robotis one?

I'll check the ATMEL site for spec sheet updates.

Mark

[Zoid]

Interesting, the Mega128 manual (2467N-AVR-03/06) seems to have lots of errors on page 304. It suggests in table 127 that PE0, PE1 and PB1 are used for the SPI programming interface and these pins are brought out on the J5 connector on the CM-5 PCB. Which is great. However, the text suggests PD0 and PD1 are used. The chip's pin out diagram suggests the SPI interface is present on PB1, PB2 and PB3 though!

So there is some inconsistency.

I would suggest that the PE0, PE1 and PB1 combination is correct because this would make some sense of the J5 connector. MOSI, MISO and SCK are used for ISP programming.

So I take back what I said. I now think that J5 is for programming the Mega128. Thanks for the heads up.

So, we can install our own boot loader is needed. Maybe we could read out the Robotis one?

I'll check the ATMEL site for spec sheet updates.

Mark

Mark (or others), has this ISP pinout been confirmed yet?

[StuartL]

Mark (or others), has this ISP pinout been confirmed yet?

Yes. We definitely use the SPI interface + reset to program and hack our CM5, and incidentally the AX-12 board too. Just use a multimeter to buzz the J5 connector back to the MCU if you want to double-check the pinout.

Maybe the Bootloaded is pretty standard and could be replaced by something in the public domain. Bootloaders are pretty simple, they have to be because they only have a small amount of space to live in so a public domain one could be modified if meeds be.

Matt wrote a Bioloid-bus-compatible bootloader in a few days. We're probably going to release this as binary-only but to install it you'd need to chip-erase the CM5. This isn't hard and can be done with a parallel port and some soldering.

Alternatively just leave the Robotis bootloader alone. It's not THAT broken...

I suspect the fact that the Mega128 is SMD-only has a bit to do with it. The pins on the "big" one are .8mm apart. The pins on the "small" one are .5mm apart. That's pretty dense. Even with a little experience and the right tools, those are hard chips to solder with hot air, and just about impossible to solder with a "normal" iron. Now... removing bridges isn't as hard as it sounds (with a solder wick, it's actually pretty easy to do), but finding them in the first place can be a major pain (problem #1 -- the probes on most multimeters are too big and bulky to easily test adjacent pins for shorts).

I hand soldered the Mega 164 SMD (0.8mm pitch) and the line driver (0.5mm pitch) we're using on the PSX board. With a steady hand, a good light and a decent wick it's actually quite easy. A magnifying glass is also helpful but not actually necessary.

Getting the bootloader firmware off the original chip and onto the new one could be a problem, too, if Robotis set the protection fuse when they burned them (AVRs have a fusebit that enables you to protect them from casual ripping). It would be pretty stupid if they did, since their firmware would be almost completely useless without Robotis's own servos anyway, but never underestimate the grief and mischief paranoid lawyers can cause when they start influencing otherwise-sane members of upper management...)

We managed to get the Robotis bootloader image off the CM5 and servos in about 5 minutes. They HAVE set the lock bits to prevent reading of the image but they didn't put any sane protection in their own bootloader. You can ask the bootloader to read the flash and then dump it to disk. We've got backups of all the firmwares and bootloaders now, just in case something goes horribly wrong. As I put in another thread I'm NOT prepared to distribute these. I'm happy to help with how it's done but I'm not distributing someone elses intellectual property.

Which makes me wonder why no one is working on a Mega128 replacement board that uses essentially the same pinout as the CM5, but brings out more of the IO pins for other uses.
Couldn't one then use it exactly like a CM5 if one wanted to with all the Robotis supplied software?

We're working on a drop-in replacement for the CM5. Details are still sketchy (still on the drawing board) but it likely to be a 32-bit system capable of running Linux, we're targeting 150MHz and pin-for-pin/screw-for-screw compatibility with the CM5 so that it can go into the same chest cavity.

For our uses we're not planning to run Linux at all (too much overhead for too little gain) but for those wishing to have more intuitive scripting languages (e.g. python) and aren't concerned about 100Hz sampling rates it's likely to be a good solution. More info may be coming, ETA is probably about a year.

[limor]

We're working on a drop-in replacement for the CM5. Details are still sketchy (still on the drawing board) but it likely to be a 32-bit system capable of running Linux, we're targeting 150MHz and pin-for-pin/screw-for-screw compatibility with the CM5 so that it can go into the same chest cavity.

I came across a new open l inux platform based on Xscale PXA270 that was originally invented to offload firewall/antivirus/antispam/etc. off the crippled Vista and onto a separate independent small module running linux. They are called yoggie.com After a few emails it turns out that their "soho" version of the platform exposes the USB and serial pins of the PXA which is what is needed to interface with the Bioloid using a mediator such as a USB2Dynamixel.