Nintendo GC controller to PIC

Discussion in 'Embedded Systems and Microcontrollers' started by takao21203, Aug 12, 2012.

  1. takao21203

    Thread Starter AAC Fanatic!

    Apr 28, 2012
    A while ago I have considered infrared remote control to use it as input device.
    I made progress with some protocols, including a rather slow one, but having fixed command length, and only full command words repeating.

    It is far too slow for game play actually.

    And IR RC devices don't really give the "look and feel" of a TV game console controller.

    As a result, a Nintendo Game Cube controller was ordered.
    It is using 1-wire bi-directional serial protocol, each bit = 4uS.

    24 bits are sent, and the control pad should reply with 64 data bits!

    Today I wrote code to send out 24 data bits. I have tested it inside the simulator, and it looks promizing. Even if the timing still can not be controlled exactly.

    Do you know anything about this serial protocol? Or have you actually used it yourself? What about bit-cell tolerance? Could I stretch it a bit? Or leave a pause between individual bits (when I send to the controller pad)?

    Is it possible to change the transmission speed in any kind?

    How can I store the bitstream fast enough? My clocking speed is 12.28 MHz, so this leaves only 12 instructions for 1uS detection.

    I have used a trick where I only reload more data in the 3uS phase!

    However when I want to store the incoming bitstream, I can not shift bits, and test, and switch the data pointer. It takes too many cycles! Since a C compiler is used. I don't want to use assembler!!!

    Do you have any good ideas for the receive routine?

    What I need to do is to "sample" the timing on the data line,
    and then later convert it to binary.

    Here the code to send out 24 bits:

    Code ( (Unknown Language)):
    1. void gcpad_request()
    3. {unsigned char cmd_d,i;
    5. unsigned const char cmd_seq1[]=
    6. {0x00,0xff,0x00,0x00,0x00,0x00,0x00,0x00,\
    7.  0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xff,\
    8.  0x00,0xff,0x00,0x00,0x00,0x00,0xff,0x00,\
    9.  0xff};
    11. i=0;
    12. cmd_d=cmd_seq1[i++];
    14. while(1)
    15. {
    16.     if(cmd_d==0xff){
    17.      TRISAbits.TRISA0=0;TMR0L=0;
    18.      while(TMR0L<gcpad_1us);
    19.      TRISAbits.TRISA0=1;TMR0L=0;
    20.      cmd_d=cmd_seq1[i++];
    21.      while(TMR0L<gcpad_3us);
    22.     }else
    23.     {
    24.      TRISAbits.TRISA0=0;TMR0L=0;
    25.      cmd_d=cmd_seq1[i++];
    26.      while(TMR0L<gcpad_3us);
    27.      TRISAbits.TRISA0=1;TMR0L=0;
    28.      while(TMR0L<gcpad_1us);
    29.     }
    30.     if(i==24)break;
    31. }
    33. }
    Here the protocol (however, incomplete, and unofficial, I am thankful for additional links).

    And I saw this already:

    Another solution I consider is to use a small secondary PIC chip, and actually code it in assembler. Then the data is transfered between the PICs using the hardware SPI. But why do it when it can be done in C language on the main controller?

    By the way it is a 18F24j10, 12.28 MHz, 3v.
    If I have to use a hardware buffer, the 16f1503 is considered.
  2. Eric007

    Senior Member

    Aug 5, 2011
    Looks like an interresting project in progress!:)

    ...but not my level yet...BUT I'll get there soon! I'm hungry!!