Problems connecting PS2 controller to Axon

[JadeKnight]

I followed the tutorial on this site exactly (cut and paste the code), however I can't seem to get it to work. It basically loops forever trying to confirm the controller is in analog mode. The PS2 controller (genuine sony brand) does get put into analog mode (red led turns on), however the data received from the controller is always 0 causing the init loop to go on forever.

Here's the real kicker, if I turn off the Axon, I correctly get the 0x73 confirmation byte EVERY TIME, along with a few frames of valid controller data before the telnet connection, and the Axon, die out...

Something about turning off the Axon causes the code to work, in it's last dying breaths...

Any help would be appreciated.

[Admin]

dunk, the guy who wrote the PS2-Axon code, went crazy, colored his hair blue, quit his job, and decided to travel the world with his girl for a year. In other words, send him an email and cross you fingers for help.

dunk didn't use a genuine Sony brand PS2 controller, he used one of the fakes. He mentioned that there is a good chance that they aren't fully compatible. I recommend reading through the PS2 communication protocol and comparing it to the code, to see how things are different.

You might also be able to get some help from:
http://forums.trossenrobotics.com/showthread.php?t=3365&highlight=axon+ps2&page=4
http://forums.trossenrobotics.com/showthread.php?t=3394&highlight=axon+ps2&page=2

I call this multi-forum double posting
http://forums.trossenrobotics.com/showthread.php?t=3579
(linked for reference)

[JadeKnight]

No, he was using a genuine Sony brand controller in the tutorial (as I am). He said the fake ones might have different timing...

I've worked on this for several hours before posting, and I've read many sites and other forum posts on how the PS2 controller communicates. As far as I can see, my pin setup and dunk's code is correct. And as I said the TX seems to works, it's just the RX from the controller that seems to be failing. This appears to be the case anyways. If I move the code around too much, the controller doesn't even go into analog mode.

My main concern is why would the controller RX suddenly WORK when I kill the power, but not normally? What is special about the state of the Axon powering down that makes the code work? I figure if I had the hardware pins wrong or something, it would NEVER work.

(And as far as the 'double-forum' thing goes, I figured different people visit different forums. Get better coverage, and a possible answer. If that was taboo, then I apologize)

[Admin]

Hmmm I'm not really sure, mostly guessing . . .

Does it give you a baud rate option? If so, drop it to be slower. What baud is it at?

And as I said the TX seems to works, it's just the RX from the controller that seems to be failing.

Short the Tx and Rx of your Axon on the UART you are using, then using hyperterminal see if what you type is what gets echoed back to you using USB. You'll have to write a few lines of code to do this (loop back test).

(And as far as the 'double-forum' thing goes, I figured different people visit different forums. Get better coverage, and a possible answer. If that was taboo, then I apologize)

nah thats ok. Just add a cross link in case its solved in one forum but not the other. It basically encourages cross-forum collaboration.

[JadeKnight]

There is no baud rate, as I am not using a UART.  It is a 'bit-banging' approach using 5 digital I/O pins A3-A7 (and drawing 5v power from ADC-15).

I say the 'TX' works, because it appears that the axon is successfully telling the PS2 controller data (it correctly goes into analog mode).

The 'RX' is the data line bits I'm trying to receive from the PS2 controller. It always stays '0' (until I power down).

[JadeKnight]

Something just occurred to me. All the digital I/O pins are set to output by default.

Is this the correct way to set up the data and acknowledge pins as input?

Code:

#define PSclock               3               // PA3    blue wire
#define PSdata                4               // PA4    brown
#define PSacknowledge         5               // PA5    green
#define PScommand           6               // PA6    orange
#define PSattention         7               // PA7    yellow

...

    // PSx controller I/O pin setup:
    sbi(DDRA, PSclock);                // clock. output. (blue)

    cbi(DDRA, PSdata);                 // data. input. (brown)
    sbi(PORTA, PSdata);                //    enable pullup resistor

    cbi(DDRA, PSacknowledge);            // acknowledge. input. (green)
    sbi(PORTA, PSacknowledge);           //    enable pullup resistor

    sbi(DDRA, PScommand);              // command. output. (orange)

    sbi(DDRA, PSattention);            // attention. output. (yellow)

If this is incorrect, could turning off the axon be changing the data/acknowledge pins to input pins somehow?

Do the defines need to be in the form of 'PA#' instead of just '#' (is the 'PA' prefix required for setting I/O direction)?

[JadeKnight]

Problem solved!
I swapped the 'CLOCK HIGH' and the 'read PSdata pin and store' lines in the gameByte function, and now it works!
Still not sure why turning the Axon off made it work though...

This is the fixed gameByte function (from the tutorial) that works for me, in case anyone else has troubles:

Code:

int gameByte(short int command)
{
    short int i ;
    delay_us(1);
    short int data = 0x00;                                   // clear data variable to save setting low bits later.
    for(i=0;i<8;i++)
    {
    if(command & _BV(i)) sbi(PORTA, PScommand);      // bit bang "command" out on PScommand wire.
            else cbi(PORTA, PScommand);
            cbi(PORTA, PSclock);                             // CLOCK LOW
            delay_us(1);                                     // wait for output to stabilise
            sbi(PORTA, PSclock);                             // CLOCK HIGH
            if((PINA & _BV(PSdata))) {sbi(data, i);}         // read PSdata pin and store
            //else {cbi(data, i);}
    }
    sbi(PORTA, PScommand);

    delay_us(20);                                            // wait for ACK to pass.

    return(data);
}