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:
Here the protocol (however, incomplete, and unofficial, I am thankful for additional links).
http://www.int03.co.uk/crema/hardware/gamecube/gc-control.html
And I saw this already: http://www.raphnet.net/electronique/gc_n64_usb/index_en.php
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.
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:
Rich (BB code):
void gcpad_request()
{unsigned char cmd_d,i;
unsigned const char cmd_seq1[]=
{0x00,0xff,0x00,0x00,0x00,0x00,0x00,0x00,\
0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xff,\
0x00,0xff,0x00,0x00,0x00,0x00,0xff,0x00,\
0xff};
i=0;
cmd_d=cmd_seq1[i++];
while(1)
{
if(cmd_d==0xff){
TRISAbits.TRISA0=0;TMR0L=0;
while(TMR0L<gcpad_1us);
TRISAbits.TRISA0=1;TMR0L=0;
cmd_d=cmd_seq1[i++];
while(TMR0L<gcpad_3us);
}else
{
TRISAbits.TRISA0=0;TMR0L=0;
cmd_d=cmd_seq1[i++];
while(TMR0L<gcpad_3us);
TRISAbits.TRISA0=1;TMR0L=0;
while(TMR0L<gcpad_1us);
}
if(i==24)break;
}
}http://www.int03.co.uk/crema/hardware/gamecube/gc-control.html
And I saw this already: http://www.raphnet.net/electronique/gc_n64_usb/index_en.php
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.
