40X2 spiout clock speed (for playstation 2 controller emulation)

[Mahhari]

Hi guys!

I'm trying simulate a playstation 2 controller with a picaxe 40x2. The problem i'm running into is the clock speed of the playstation is too fast for the picaxe to see. I'm a little confused why that is. The playstation clocks at 250khz, so that is about 4us for one clock period. I set the frequency of the picaxe to 16Mhz and the fastest it can pulse seems to be 240us. (a simple high-low command). Is this just simply out of the picaxe's performance range or is there something i'm missing?

thanks guys!

for more information on playstation 2 signals go here:

http://www.curiousinventor.com/guides/ps2#mappings

 

[Mahhari]

Here is a logic analyzer picture of the playstation 2 controller protocol (http://www.tinkerjunkies.com/Sample1.html) I need to keep up with the clock sent from the playstation to the controller.

each clock pulse period is 2us and pause between clock cycle is about 8us.

if the picaxe can't do it, do you know what can?

thanks!

 

[MartinM57]

This is probably going to be too fast for the PICAXE depending on exactly what you are trying to do. You are in the rightballpark seeing the speeds that you are - http://www.picaxeforum.co.uk/showthread.php?t=13262 shows a 20X2 toggling at max speed.

Due to the way that the PICAXE executes code, you are looking at 50-100 times slower that what a raw PIC can do. So what can do it - a raw PIC, an AVR etc programmed in assembler, C or maybe even some dialect of BASIC

 

[Mahhari]

haha I somehow new I would end up having to use the "raw" PIC one day. the PICAXE days where too good to last. Is the PICmicro the same as the raw PIC? Or is that a different product?

 

[MartinM57]

Yep, same thing...

 

[benryves]

I wrote a piece of software in C# to receive input from a PlayStation 2 controller connected to a PC's parallel port, and even on a multi-gigahertz machine I was still missing the acknowledgement pulses so ended up having to write the low-level code in straight C.

Personally, I've found AVRs to be much more straightforward than PIC micros. With AVRs you get the free GCC to write programs in C (to my knowledge there is no free 8-bit PIC C compiler, though I may have just missed one) and even if you choose to use assembly the AVR instruction set is a lot more practical than the PIC one. PICAXE still trumps both for ease of use, of course, but if you need to take advantage of every clock cycle then some sacrifices have to be made.

 

[hippy]

A PICAXE with hardware SPI can keep up with the PlayStation data rate but will not likely have the speed required to turn the bus round and respond. A PICAXE-20X2 can handle SPI up to 4MHz, perhaps higher, but it has to handle each byte received before it can handle others.

Connecting a PlayStation controller and the like to a micro should be relatively straight forward as that micro is in charge of bus timing. The other way round, trying to create a controller, and the micro has to keep up with the PlayStation which sets the timing requirements. That's a much tougher challenge, and most console manufacturers are not in the business of making it easy for third-parties to interface to their products.

 

[Mahhari]

I wrote a piece of software in C# to receive input from a PlayStation 2 controller connected to a PC's parallel port, and even on a multi-gigahertz machine I was still missing the acknowledgement pulses so ended up having to write the low-level code in straight C.

Personally, I've found AVRs to be much more straightforward than PIC micros. With AVRs you get the free GCC to write programs in C (to my knowledge there is no free 8-bit PIC C compiler, though I may have just missed one) and even if you choose to use assembly the AVR instruction set is a lot more practical than the PIC one. PICAXE still trumps both for ease of use, of course, but if you need to take advantage of every clock cycle then some sacrifices have to be made.

Yeah i've read that C# has larger overheads that make it slower. So the code you made in C worked well? I could use a parallel port and go straight to the ps2. What program specifically did you use?

Also I'm divided over which path i should go, AVR or PIC. I've read PIC is more powerful with speed and functions but harder to use. But the AVR has very few general chips.

You're right hippy connecting a micro to the ps2 controller is easier, but i have to do it the hard way around

 

[alband]

If your trying to make a "dummy" controller, presumably with your own inputs, it should be fairly simple to find the main micro-controller in the PS2 controller, find it's various input pins, then feed PICAXE outputs into those. Let the PS2 chip do the talking, you just tell it what to say.

 

[benryves]

Yeah i've read that C# has larger overheads that make it slower. So the code you made in C worked well? I could use a parallel port and go straight to the ps2. What program specifically did you use?

The problem with C# is that crossing the managed-unmanaged boundary (as you would when calling a C library to access the parallel port) incurs a performance penalty. I didn't use any specific programs (unless you count Visual C++ and Visual C#), but the program I wrote can be downloaded here.

If you have a PS2 controller you can sacrifice then alband's suggestion sounds like the least amount of work.

 

[Mahhari]

haha I thought about sacrificing a ps2 controller, but if I take the easy way, how is a boy to learn and grow up to be great guru microcontroller users like yourselves! =D

 

[MartinM57]

Depends if you want to enjoy(or battle your way through) the journey or just get to the destination. Simplicity over complexity every time for me - although complexity is needed sometimes unfortunately...

 

[hippy]

Sometimes taking the easy path is evidence of 'guru' status, realising that a battle is sometimes not worth being fought when there are viable easier options

Interfacing to high-speed buses where one has to meet the timing of that bus is often no mean feat and can test even the most skilled of software engineers. It may dictate a particular choice of solution which isn't prefered or easy to use and attempts to use other solutions can be frustrating and a battle against what those solutions are designed for.

That journey can be a long, hard slog, and for the most part you will be on your own, venturing into areas no one else has gone before. Ultimately it may be that the knowldge gained is 'cannot be done', 'does not work', 'will not be reliable', and while that is useful knowledge in itself, other paths can lead to 'this works' knowledge which could be considered more useful for effort and time invested. Only you can decide which path you want to go down.