Go Down

Topic: Porting Arduino Hexapod (Phoenix) robot code to run on DUE (Read 3078 times) previous topic - next topic


Feb 03, 2013, 07:14 pm Last Edit: Feb 09, 2013, 09:48 pm by KurtE Reason: 1
I am new to using the DUE and SAMS in general so please forgive me if some of these questions have been answered before.  I do have a reasonable amount of experience on several other platforms including Arduinos including Megas and Pic32s (Chipkit Max32/Uno32), Renesas H8, Propeller...

I recently purchased a DUE and modified the design of a shield I did earlier for the Arduino Megas to hopefully properly handle 3.3vs.  Yesterday I finished assembling one of the boards (minus a few parts I was missing).  You can see a picture of the shield in the DUE below.

Now I am in the process of trying to modify my Arduino port of the Phoenix Hexapod code to run on the DUE. So far on the board I have been able to verify that I can get sound from the speaker and my LEDS blink and I have done a little testing that I can output to some of the IO pins and it appears like I can use I2C to talk to the EEPROM on the board...

Some things I have run into so far.  Some I have found solutions to include:

1) Way to conditional compile for DUE.  So far I am using
Code: [Select]
#if defined(__SAM3X8E__)
Code: [Select]
#ifdef __SAM3X8E__

2) Having issues with IO pin usage differences.  On other platforms this works to toggle the LED:
Code: [Select]
digitalWrite(13, !digitalRead(13));
So far it looks like Reading the current state of a IO pin set to output does not work the same.  Suggestions on how to do this?  Obviously I can keep an external variable with the state and toggle it and use it to do the digital write.

3) Currently trying to port the Playstation 2 controller code (http://www.billporter.info/2011/03/27/arduino-playstation-2-controller-library-troubleshooting-guide/) to run on the DUE.  I earlier did the work to make it run on the Pic32 processors.  The code tries to manipulate the IO pins as efficiently as possible, but it must be interrupt safe. On Avr processors for example to set the CLK high it does:
Code: [Select]
inline void  PS2X::CLK_SET(void) {

  register uint8_t old_sreg = SREG;
  *_clk_oreg |= _clk_mask;
  SREG = old_sreg;

On the Pic32's this is much easier and you don't have to disable interrupts as the shadow register operations are atomic
Code: [Select]
inline void  PS2X::CLK_SET(void) {
*_clk_lport_set |= _clk_mask;

So my questions here are:
a) Is there a recommended way to set and clear IO pins faster than digitalWrite?
b) Is it atomic?

4) Having to deal with PROGMEM related issues.  I am currently defining a work around in at least one of my header files that includes stuff like:
Code: [Select]
#if defined(__SAM3X8E__)
   #define PROGMEM
   #define pgm_read_byte(x)        (*((char *)x))
//  #define pgm_read_word(x)        (*((short *)(x & 0xfffffffe)))
   #define pgm_read_word(x)        ( ((*((unsigned char *)x + 1)) << 8) + (*((unsigned char *)x)))
   #define pgm_read_byte_near(x)   (*((char *)x))
   #define pgm_read_byte_far(x)    (*((char *)x))
//  #define pgm_read_word_near(x)   (*((short *)(x & 0xfffffffe))
//  #define pgm_read_word_far(x)    (*((short *)(x & 0xfffffffe)))
   #define pgm_read_word_near(x)   ( ((*((unsigned char *)x + 1)) << 8) + (*((unsigned char *)x)))
   #define pgm_read_word_far(x)    ( ((*((unsigned char *)x + 1)) << 8) + (*((unsigned char *)x))))
   #define PSTR(x)  x

Note: On the Pic32 (mpide), I believe that they defined these in a header file like Arduino.h, such that it became transparent to the users.

That is all for now.


Not sure how many people up here are interested but I know of a few up on my main forums who are interested in using a DUE or the like on their Hexapod robots.  So I thought I would give an update for this.

1) Test program wise, I have verified a few things working up on my Shield.  For awhile I thought there was an issue of not being able to get inputs from the buttons on the shield, but figured out the stackable headers were not making contact on these pins.  Fixed for now with foil...  If I build another shield wondering if there are better stackable headers for making contacts or should I use something else...

2) Playstation 2 controller is working.  This is updates to Bill Porters library.  My version of it is up at:

3) Buttons/Leds/I2C EEPROM working.  Analog input appears to work properly At least I am getting valid inputs for the two battery voltages that are connected through resister divider.

4) Next will use Logic Analyzer to verify all of the output pins are working.

5) Then check XBee connections.

I now also have a version of the Arduino Phoenix (hexapod code) compiling for the DUE.   As I mentioned in the first posting here, I wish the system header files had things in it (like the PIC32 ones do) to make things like PROGMEM be transparent.  Hopefully it is...  Will be testing it soon on real robot.

That is all for now.  Again not sure if anyone here is interested.  If not will mainly continue to post on the Robotics forums.

Go Up