Legacy Forum: Preserving Nearly 20 Years of Community History - A Time Capsule of Discussions, Memories, and Shared Experiences.

MR-C3024 and AVR Development Tools

Hitec robotics including ROBONOVA humanoid, HSR-8498HB servos, MR C-3024 Controllers and RoboBasic
29 postsPage 1 of 21, 2
29 postsPage 1 of 21, 2

MR-C3024 and AVR Development Tools

Post by mpthompson » Tue May 30, 2006 5:34 am

Post by mpthompson
Tue May 30, 2006 5:34 am

I'm new to the RoboNova (just built my robot on Thursday), but I have some pretty decent experience with Atmel AVR MCU development with other chips similar to the ATmega128 used in the MR-C3024. I would certainly like to break through the limitations of RoboBasic and do software development using many of the excellent tools for AVR microcontrollers. I have seen other on-line stores selling the MR-C3024 indicates it can be programmed with AVR Studio, but there is no information as to how. Has anyone come across information on alternate development environments for the MR-C3024 controller?

Below are some things I've learned so far.

There are three basic methods of programming the ATmega128 Flash and EEPROM: SPI Serial programming, Parallel programming and JTAG programming. These can be disabled in various ways on the MCU and we'll need to determine how locked up Hi-Tec made the MR-C3024.

SPI Serial programming the ATmega128 would be ideal. It requires only five wires -- four of which are already conveniently exposed on the connectors of the MR-C3024. The fifth wire is the RESET line to which a new single pin is easily added to solder filled in hole just below the MCU. I made the necessary connections, but SPI Serial Programming failed for me. Most likely HiTec disabled serial SPIEN fuse on the MCU. If this were not the case it would have been trivial to back-up the contents of Flash and EEPROM and replace it with new programming. I'll probably check things over once more just to make sure I didn't make a mistake, but I'm fairly certain that using SPI Serial programming is a "no go" until the SPIEN fuse in the MCU can be programmed.

Parallel programming of the ATmega128 is more involved. I'll need examine what pins of the ATmega128 are exposed via pin connectors and how to gain access to those that aren't. I'll also need to determine the risk to the MR-C3024 to damage by the high voltage required to program the MCU with this mode. At this point while I'm still mostly learning about the RoboNova I want to be careful to not fry it's brain.

JTAG programming is another option, but I read somewhere else that it was tried and didn't work. If so, this likely because HiTec disabled the JTAGEN fuse on the MCU just as they probably did the SPIEN fuse. I'm not experienced with JTAG programming so I'll need to explore this in the future.

The fourth option is to reverse engineer the bootloader protocol on the MR-C3024. I haven't see whether other people have done this and if it does indeed open up the entire MCU Flash and EEPROM for programming. Have others looked into this yet?

-Mike
I'm new to the RoboNova (just built my robot on Thursday), but I have some pretty decent experience with Atmel AVR MCU development with other chips similar to the ATmega128 used in the MR-C3024. I would certainly like to break through the limitations of RoboBasic and do software development using many of the excellent tools for AVR microcontrollers. I have seen other on-line stores selling the MR-C3024 indicates it can be programmed with AVR Studio, but there is no information as to how. Has anyone come across information on alternate development environments for the MR-C3024 controller?

Below are some things I've learned so far.

There are three basic methods of programming the ATmega128 Flash and EEPROM: SPI Serial programming, Parallel programming and JTAG programming. These can be disabled in various ways on the MCU and we'll need to determine how locked up Hi-Tec made the MR-C3024.

SPI Serial programming the ATmega128 would be ideal. It requires only five wires -- four of which are already conveniently exposed on the connectors of the MR-C3024. The fifth wire is the RESET line to which a new single pin is easily added to solder filled in hole just below the MCU. I made the necessary connections, but SPI Serial Programming failed for me. Most likely HiTec disabled serial SPIEN fuse on the MCU. If this were not the case it would have been trivial to back-up the contents of Flash and EEPROM and replace it with new programming. I'll probably check things over once more just to make sure I didn't make a mistake, but I'm fairly certain that using SPI Serial programming is a "no go" until the SPIEN fuse in the MCU can be programmed.

Parallel programming of the ATmega128 is more involved. I'll need examine what pins of the ATmega128 are exposed via pin connectors and how to gain access to those that aren't. I'll also need to determine the risk to the MR-C3024 to damage by the high voltage required to program the MCU with this mode. At this point while I'm still mostly learning about the RoboNova I want to be careful to not fry it's brain.

JTAG programming is another option, but I read somewhere else that it was tried and didn't work. If so, this likely because HiTec disabled the JTAGEN fuse on the MCU just as they probably did the SPIEN fuse. I'm not experienced with JTAG programming so I'll need to explore this in the future.

The fourth option is to reverse engineer the bootloader protocol on the MR-C3024. I haven't see whether other people have done this and if it does indeed open up the entire MCU Flash and EEPROM for programming. Have others looked into this yet?

-Mike
mpthompson
Newbie
Newbie
User avatar
Posts: 6
Joined: Mon May 29, 2006 1:00 am
Location: San Carlos, CA

Post by KurtE » Tue May 30, 2006 6:35 am

Post by KurtE
Tue May 30, 2006 6:35 am

I did a little looking earlier and contacted HITEC, here is an excerpt from their response.


As for programming in C, you could but Hitec does not have any libraries to help with this. Also, to program the chip directly, it would have to be removed from the board, something I don’t suggest.



Regards,

Tony Ohm

Service Manager

Hitec RCD USA, Inc.

Ph: 858-748-8440

Fax: 858-859-2618
I did a little looking earlier and contacted HITEC, here is an excerpt from their response.


As for programming in C, you could but Hitec does not have any libraries to help with this. Also, to program the chip directly, it would have to be removed from the board, something I don’t suggest.



Regards,

Tony Ohm

Service Manager

Hitec RCD USA, Inc.

Ph: 858-748-8440

Fax: 858-859-2618
KurtE
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 28
Joined: Thu Apr 13, 2006 1:00 am
Location: Washington State

Post by mpthompson » Tue May 30, 2006 5:48 pm

Post by mpthompson
Tue May 30, 2006 5:48 pm

I received the same response from Tony Ohm this morning. Oh well, I guess we are on our own if we wish to push beyond RoboBasic.

As it seems the SPIEN fuse is unprogrammed, the main trick would be to somehow program this fuse on the MCU -- probably through high voltage parallel programming. This would likely entail removing the chip from the board which is not an easy job and likely requires special desoldering equipment. Unfortunately, I don't believe the fuse can be programmed via software. If the chip can be desoldered it would probably be easiest to simply replace it with fresh ATmega128 which can be ordered from DigiKey for about $15.

At this point the safest course of action would be to understand the bootloader and what's it's capabilities are. Something I haven't looked at yet.

-Mike
I received the same response from Tony Ohm this morning. Oh well, I guess we are on our own if we wish to push beyond RoboBasic.

As it seems the SPIEN fuse is unprogrammed, the main trick would be to somehow program this fuse on the MCU -- probably through high voltage parallel programming. This would likely entail removing the chip from the board which is not an easy job and likely requires special desoldering equipment. Unfortunately, I don't believe the fuse can be programmed via software. If the chip can be desoldered it would probably be easiest to simply replace it with fresh ATmega128 which can be ordered from DigiKey for about $15.

At this point the safest course of action would be to understand the bootloader and what's it's capabilities are. Something I haven't looked at yet.

-Mike
mpthompson
Newbie
Newbie
User avatar
Posts: 6
Joined: Mon May 29, 2006 1:00 am
Location: San Carlos, CA

Post by subpilot » Tue May 30, 2006 7:18 pm

Post by subpilot
Tue May 30, 2006 7:18 pm

An easy way to remove high density surface mount parts is to use a butane powered soldering iron (Digikey sells them). You remove the tip and use the flame to heat evenly around the body of the part. When the solder is melted you rap the board against the table and the part will fall right off. I do it all the time and all though you have to be careful to not overheat the board it's pretty easy. You can also get some Chip Quick http://www.howardelectronics.com/chipqu ... etter1.htm
and make it even easier. I can do it without using Chip Quick with little trouble. After the part's off just solder wick the pads to clean it up.
You can also solder in the parts with the same technique. Just get a syringe of solder paste, put a dab on the pads, place the part and use the butane iron to melt the paste. Get a high quality butane iron with a good heat adjustment control.
It would be great if somebody could come up with the C library functions for the servo I/O.
The lack of C support is why I'm going with a new Rabbit micro based controller (when I get off my rear). I use PICs, MSP430s and Rabbit controllers and don't know much about AVRs so going with the Rabbit makes sense for me. Using the existing controller board would be much easier hardware wise and I'm glad you guys are going down that path.
An easy way to remove high density surface mount parts is to use a butane powered soldering iron (Digikey sells them). You remove the tip and use the flame to heat evenly around the body of the part. When the solder is melted you rap the board against the table and the part will fall right off. I do it all the time and all though you have to be careful to not overheat the board it's pretty easy. You can also get some Chip Quick http://www.howardelectronics.com/chipqu ... etter1.htm
and make it even easier. I can do it without using Chip Quick with little trouble. After the part's off just solder wick the pads to clean it up.
You can also solder in the parts with the same technique. Just get a syringe of solder paste, put a dab on the pads, place the part and use the butane iron to melt the paste. Get a high quality butane iron with a good heat adjustment control.
It would be great if somebody could come up with the C library functions for the servo I/O.
The lack of C support is why I'm going with a new Rabbit micro based controller (when I get off my rear). I use PICs, MSP430s and Rabbit controllers and don't know much about AVRs so going with the Rabbit makes sense for me. Using the existing controller board would be much easier hardware wise and I'm glad you guys are going down that path.
subpilot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 146
Joined: Sat Feb 25, 2006 1:00 am
Location: Lake Arrowhead, Ca,USA

Post by Bullit » Wed May 31, 2006 5:17 pm

Post by Bullit
Wed May 31, 2006 5:17 pm

Bullit
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 291
Joined: Wed May 31, 2006 1:00 am
Location: Near robot

Post by subpilot » Wed May 31, 2006 7:01 pm

Post by subpilot
Wed May 31, 2006 7:01 pm

That is indeed a nice controller. I may opt to go that route. Would need to see how well it would work with the Hitech HMI servo protocol.
Maybe New Micros can give some answers/advice.
That is indeed a nice controller. I may opt to go that route. Would need to see how well it would work with the Hitech HMI servo protocol.
Maybe New Micros can give some answers/advice.
subpilot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 146
Joined: Sat Feb 25, 2006 1:00 am
Location: Lake Arrowhead, Ca,USA

Post by subpilot » Wed May 31, 2006 7:20 pm

Post by subpilot
Wed May 31, 2006 7:20 pm

Looking at the manual for the Isopod I see that it can measure PWM inputs but "only" has 14 timer inputs. Could be dificult to get more input chans unless you could figure out a way to multiplex them. Still looks very interesting and worthy of further investigation.
Looking at the manual for the Isopod I see that it can measure PWM inputs but "only" has 14 timer inputs. Could be dificult to get more input chans unless you could figure out a way to multiplex them. Still looks very interesting and worthy of further investigation.
subpilot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 146
Joined: Sat Feb 25, 2006 1:00 am
Location: Lake Arrowhead, Ca,USA

Post by i-Bot » Fri Jun 02, 2006 2:41 pm

Post by i-Bot
Fri Jun 02, 2006 2:41 pm

The position feedback possible under the PWM mode on the HSR8498 is next to useless. It is easier to have your software remember where you told it to be.

You need to decide if you will do the timed synchronised movements of servo groups in your own software, or expect provided subroutines to do this for you. The quality and efficiency of this routine and the underlying PWM generation is the measure of a good robotics servo controller, especially if you want other software threads to monitor gyros and accelerometers.

At first sight this board does not seem to do this timing and synchronisation for you, so you would have to either do it using their high level coding (very inefficient) or in assembler.

I would be good to get Newmicros feedback to this.

I has got two serial ports, so you will be able later to control the servos via serial to get position.

I would go for a more common processor based solution (ATMega, PIC, ARM7) with a good C development environment and debugger.
The position feedback possible under the PWM mode on the HSR8498 is next to useless. It is easier to have your software remember where you told it to be.

You need to decide if you will do the timed synchronised movements of servo groups in your own software, or expect provided subroutines to do this for you. The quality and efficiency of this routine and the underlying PWM generation is the measure of a good robotics servo controller, especially if you want other software threads to monitor gyros and accelerometers.

At first sight this board does not seem to do this timing and synchronisation for you, so you would have to either do it using their high level coding (very inefficient) or in assembler.

I would be good to get Newmicros feedback to this.

I has got two serial ports, so you will be able later to control the servos via serial to get position.

I would go for a more common processor based solution (ATMega, PIC, ARM7) with a good C development environment and debugger.
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by Bullit » Fri Jun 02, 2006 4:19 pm

Post by Bullit
Fri Jun 02, 2006 4:19 pm

Sure would be nice if Hitec would just give us the source for the ATMega128. Its not a bad choice for platforms. Just rewritting all Hitec has provided with Robobasic in assembly is duanting. I noticed there is a new robot http://www.turbolinux.co.jp/company/pressrooms/image_download/robo2.jpg turborobo that uses turbo linix.
Sure would be nice if Hitec would just give us the source for the ATMega128. Its not a bad choice for platforms. Just rewritting all Hitec has provided with Robobasic in assembly is duanting. I noticed there is a new robot http://www.turbolinux.co.jp/company/pressrooms/image_download/robo2.jpg turborobo that uses turbo linix.
Bullit
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 291
Joined: Wed May 31, 2006 1:00 am
Location: Near robot

Post by i-Bot » Fri Jun 02, 2006 9:06 pm

Post by i-Bot
Fri Jun 02, 2006 9:06 pm

Don't expect too much. I suspect Hitec do not own this option, but are simply licensees of other peoples software.

Continued delays in promised product releases, and their ignorance in support suggest they do not have the basic product knowledge in house.

The RoboNova represents an excellent demonstration of the current state of the art, but may be a dead end for development.

It is good to see more open options for those of us who wish to move forward.

Thanks for the link
Don't expect too much. I suspect Hitec do not own this option, but are simply licensees of other peoples software.

Continued delays in promised product releases, and their ignorance in support suggest they do not have the basic product knowledge in house.

The RoboNova represents an excellent demonstration of the current state of the art, but may be a dead end for development.

It is good to see more open options for those of us who wish to move forward.

Thanks for the link
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by subpilot » Fri Jun 02, 2006 9:43 pm

Post by subpilot
Fri Jun 02, 2006 9:43 pm

Here's a reply from NewMicros

Hello Bob,

I've checked over the protocol sheet mentioned below, looks pretty interesting. I'm not so sure that the Hitec controller actually reads the servos for position feedback though. Reading over the description for the MR-C3024 controller used shows it to be powered by a Atmel Mega128, which only has 4 timers, compared to the 14 available on the ServoPod. Seems there are servo controllers based on similar AVRs chip for up to 32 servos, but only delivering the pulses, not reading them back. And this pulse delivery may be in a "banked" form, where each set of either 4 or even 8 servos is sequentially commanded through some sort of shift register or demultiplexer, or through the processor generating interrupts on various pins to read the pulses.

How servo control has been done with the ServoPod previously was to make use of the 12 PWM pins as well as the 14 Timer pins to deliver pulses. We've discovered that though servos work adequately with a 50 Hz refresh of pulses, they can have a quicker response with more torque at the 76 Hz pulse rate, the lowest the PWM channels can operate at with the CPU at full speed. This allows direct drive of pulses for 26 servos. There is no need for software interrupts, or hardware demultiplexers for this method.

Now if you were wanting to both send drive pulses and receive feedback pulses on a ServoPod for 16 or more servos, it would probably be done with some sort of bi-directional demultiplexer or perhaps through software interrupts on other port pins, though we have not explored that yet. Alternatively the PWM channels could be used to simply drive pulses to the sertvos requiring greater torque, typically the legs, while position info could be monitored with Timer pin driven arms and grippers. Let me know what you think.

David Peterson
www.newmicros.com
Here's a reply from NewMicros

Hello Bob,

I've checked over the protocol sheet mentioned below, looks pretty interesting. I'm not so sure that the Hitec controller actually reads the servos for position feedback though. Reading over the description for the MR-C3024 controller used shows it to be powered by a Atmel Mega128, which only has 4 timers, compared to the 14 available on the ServoPod. Seems there are servo controllers based on similar AVRs chip for up to 32 servos, but only delivering the pulses, not reading them back. And this pulse delivery may be in a "banked" form, where each set of either 4 or even 8 servos is sequentially commanded through some sort of shift register or demultiplexer, or through the processor generating interrupts on various pins to read the pulses.

How servo control has been done with the ServoPod previously was to make use of the 12 PWM pins as well as the 14 Timer pins to deliver pulses. We've discovered that though servos work adequately with a 50 Hz refresh of pulses, they can have a quicker response with more torque at the 76 Hz pulse rate, the lowest the PWM channels can operate at with the CPU at full speed. This allows direct drive of pulses for 26 servos. There is no need for software interrupts, or hardware demultiplexers for this method.

Now if you were wanting to both send drive pulses and receive feedback pulses on a ServoPod for 16 or more servos, it would probably be done with some sort of bi-directional demultiplexer or perhaps through software interrupts on other port pins, though we have not explored that yet. Alternatively the PWM channels could be used to simply drive pulses to the sertvos requiring greater torque, typically the legs, while position info could be monitored with Timer pin driven arms and grippers. Let me know what you think.

David Peterson
www.newmicros.com
subpilot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 146
Joined: Sat Feb 25, 2006 1:00 am
Location: Lake Arrowhead, Ca,USA

Post by i-Bot » Sun Jun 04, 2006 3:24 pm

Post by i-Bot
Sun Jun 04, 2006 3:24 pm

Just a couple of inputs which may make this easier.

The RN updates the servos every 12mS, however this is not actually necessary if all the servos are HSR8498HB which are digital.

I checked the servo alone and one pulse is enough to move the servo to the requested location. Therefore you only need to send a pulse at the stages in the group move where a position change for that servo is required.

The RN does not appear to use the position feedback continually, only when doing a capture.

If Newmicros are able to program an efficient timed group move function based on the assumption all servos are digital. And offer an "occasional" position feedback capability, this may be enough.
Just a couple of inputs which may make this easier.

The RN updates the servos every 12mS, however this is not actually necessary if all the servos are HSR8498HB which are digital.

I checked the servo alone and one pulse is enough to move the servo to the requested location. Therefore you only need to send a pulse at the stages in the group move where a position change for that servo is required.

The RN does not appear to use the position feedback continually, only when doing a capture.

If Newmicros are able to program an efficient timed group move function based on the assumption all servos are digital. And offer an "occasional" position feedback capability, this may be enough.
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by subpilot » Mon Jun 05, 2006 2:18 am

Post by subpilot
Mon Jun 05, 2006 2:18 am

I agree, once set the PWM outputs require next to no CPU overhead. As you say the position feedback is only required for capture and not required in normal operation. The more I look at it the more the NewMicro board makes sense. The multitasking capabilties are very nice.
I agree, once set the PWM outputs require next to no CPU overhead. As you say the position feedback is only required for capture and not required in normal operation. The more I look at it the more the NewMicro board makes sense. The multitasking capabilties are very nice.
subpilot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 146
Joined: Sat Feb 25, 2006 1:00 am
Location: Lake Arrowhead, Ca,USA

Post by mpthompson » Mon Jun 05, 2006 7:26 pm

Post by mpthompson
Mon Jun 05, 2006 7:26 pm

I'm putting aside any efforts right now to replace the ATmega128 on the MR-C3024 and instead looking at the serial protocol. Both to understand the capability of the existing firmware for control of the RoboNova servos and software download protocol.

To help in this process I came across a very useful free serial port monitor that can be obtained from here. HHD Software gives away this tool to promote their professional protocol monitoring software.

Has anyone yet attempted to understand and document the existing serial MR-C3024 protocol?

-Mike
I'm putting aside any efforts right now to replace the ATmega128 on the MR-C3024 and instead looking at the serial protocol. Both to understand the capability of the existing firmware for control of the RoboNova servos and software download protocol.

To help in this process I came across a very useful free serial port monitor that can be obtained from here. HHD Software gives away this tool to promote their professional protocol monitoring software.

Has anyone yet attempted to understand and document the existing serial MR-C3024 protocol?

-Mike
mpthompson
Newbie
Newbie
User avatar
Posts: 6
Joined: Mon May 29, 2006 1:00 am
Location: San Carlos, CA

Post by Bullit » Mon Jun 05, 2006 8:32 pm

Post by Bullit
Mon Jun 05, 2006 8:32 pm

I've started to look at it. It appears that the robobasic interface operates at 9600 and 115k baud. 9600 for basic control functions and reading servo positions. 115k for programming. It appears that allc ommands are packetized (framed STX, ETX) every packet is acknowledged from the MR-C3024. I haven't looked to far yet but my interest is also to make the most out of the MR-C3024. Its too bad that Hitec will not provide us with at least documentation of this serial protocol.
I've started to look at it. It appears that the robobasic interface operates at 9600 and 115k baud. 9600 for basic control functions and reading servo positions. 115k for programming. It appears that allc ommands are packetized (framed STX, ETX) every packet is acknowledged from the MR-C3024. I haven't looked to far yet but my interest is also to make the most out of the MR-C3024. Its too bad that Hitec will not provide us with at least documentation of this serial protocol.
Bullit
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 291
Joined: Wed May 31, 2006 1:00 am
Location: Near robot

Next
29 postsPage 1 of 21, 2
29 postsPage 1 of 21, 2