those that worked with saturn controllers

[ulao]

Hey, wondering if anyone that is working or has worked with saturn ran in to this?

In working with the digital controller setting the switches and reading data, I found the controller ( knock offs) to start sending bad data. It seems to happen after 20-30 very brief testing uses. All I'm is using an avr running at 12hmz to set the switches and then read the data in one pass. My thought was that I need to set the switch and delay, then read. I was thinking without a delay the saturn chip was getting stressed, seems that may not be the case.. At least with 10 us for each switch.  It could be the knock offs, but I really dont want to put my 3d controller on here to find out the hard way.

Anyone have a though or run in to this before?


UPDATE: I just checked my 10 us test controller again and its working, so the 10 us may have done it, that or the controller has not been completely damaged yet.  

UPDATE: Ok that one is gone.  Another guy mentioned doing a power down after each run. I would be shock if no one here was doing something like this with all the saturn talk. It could just be the knock off controllers.

[l_oliveira]

I don't know how your code works, but can't you make some test (debug) routine in it so it powers an LED while you keep a button pressed down ?
By reading your message, I have the impression that you're dealing with some software bug within your program.

The pads can be read at any frequency you want, but there's no real need/benefit on anything faster than 100hz.
I don't think that even button mashing champion Takahashi Meijin can notice any difference if you poll the controller at 30hz, 100hz or 1khz even.

I built a circuit to "split" the buttons of the Saturn controller so I could connect it to a CPS2 arcade board... No matter what frequency I put on it's refresh
(as long it was faster than 30hz) it ran fine.

The trick is that my circuit "remembers" that the button was pressed until the next read cycle when it checks the controller status for that specific group of buttons again.
Why not try that on your program ?

Hope this post give you some ideas

[ulao]

l_oliveira , I was thinking of a way to limit my passes. like that. but if I use a button release flag, will another button be able to be pressed? In other words, hold down X and then hitting Z will never respond no? Maybe I miss understood you.

I don't know how your code works, but can't you make some test (debug) routine in it so it powers an LED while you keep a button pressed down ?
By reading your message, I have the impression that you're dealing with some software bug within your program.

- Posting the code would just clutter things up here, but I can explain any of it no problem.  Yes I do have access to an LED flasher, but the HID display  shows the output of the button, and basically is the same thing.  What sort of bug would cause a controller to become Tuesdays trash? This being my question here.  I too feel its a bug, but as you said the digital pad is nothing fancy, not time sensitive, nor latch responsive.  Yet I have gone though 3 of them.

This is the guts of it. I added the delays in hopes that would help. They are not there by intended design. PinStatus just return a 1 or 0. The last build stuff is for the HID.

Code Select Expand


if ( pinStatus(1<<2) ) data |= 0x80; // button L

PORTC &= 0x3E;_delay_ms(10);  //swiches set to  on off
if ( pinStatus(1<<5) ) data |= 0x2; // button B
if ( pinStatus(1<<4) ) data |= 0x4; // button C
if ( pinStatus(1<<3) ) data |= 0x1; // button A
if ( pinStatus(1<<2) ) data |= 0x8; // button start

PORTC |= 0x3;//set to both on
PORTC &= 0x3D;_delay_ms(10);  //swiches set to  off on

if ( pinStatus(1<<5) ) y = 0;   //Up
if ( pinStatus(1<<4) ) y = 255; //Down
if ( pinStatus(1<<3) ) x = 0;   //Left
if ( pinStatus(1<<2) ) x = 255; //Right

PORTC &= 0x3C; _delay_ms(10); //swiches set to  both off
if ( pinStatus(1<<5) ) data |= 0x10; // button Z
if ( pinStatus(1<<4) ) data |= 0x20; // button Y
if ( pinStatus(1<<3) ) data |= 0x40; // button X
if ( pinStatus(1<<2) ) data2 |=0x01; // button R at bottom row

PORTC  |= 0x3;_delay_ms(10);// set switch back to both on
}
last_built_report[0]=x;
last_built_report[1]=y;
last_built_report[2]=0x7f;
last_built_report[3]=0x7f;
last_built_report[4]=0x7f;
last_built_report[5]=0x7f;
last_built_report[6]=data;
last_built_report[7]=data2;




[l_oliveira]

Okay bro... I'm not a software guy, but I think I can give you a idea for making this a bit easier...

I know that most microcontrollers have an timer interface with direct connection to an interrupt controller.
This means you can generate timed interruptions for a application such as pooling the input ports (which is what need to be done
on this project, btw...)

So a "good" flow for the program would be:

HID/USB software runs all the time, pooling a 32 bit buffer (4 bytes) containing the cached status for all buttons on two saturn
pads. (since each pad is 4 bits and the microcontroller port is 8 bits why not make it so it supports two controllers at the same time ?)
This cache is feed to the PC as the buttons status. The timer is set so at a set interval (we will call this PAD refresh) the interruption is
called and one group of four buttons is updated for both pads... In fact you just read the input port and copy the value for the matching
byte on your "button cache". The counter for the multiplexer (S0 and S1) is updated so that next interrupt the next group of buttons
is read. And finally you return from interrupt routine so the microcontroller can continue executing the HID/USB code.

If you stop to analyze the schematic posted on this board, you will notice that the 4th set of buttons is aways "001X" where you need to
ignore X when using it to "detect" that the pad is connected. If the user is pressing  the "L" button that button group would read as "0010"
and "0011" with "L" released.

That feature would be useful to detect that the pad is disconnected from the microcontroller or that an incompatible controller was connected.

Another important thing you need to do hardware wise is add "pull-up" to the microcontroller port being used to read the button status.
An group of eight 10k ohm resistors are what the Saturn uses internally to pull up it's controller port. You can use the same value for your circuit.
Also make sure both the PAD and microcontroller run at 5V.

Hope these ideas help you on your project

[ulao]

This chip has internal pull ups, I just didnt show that code. FYI, the code work just kills controllers Also this chip is running on a solid 12mhz and timing is a must for most other projects I use. So if your expressing the need to be very precise thats already done for example, When I read a clock latch data controller like a pc-fx, I need to pulse every 6 us and have a total of 6us*32 ( 6 for each bit ).  My_ delay function you see in the code is exact.   A delay of (2) is exactly 2us. Not sure if that is what you were getting at.


This does give me some great ideas. If the pooling is for another reason, then I mentioned above any links about it let me know, I;d like to read up. Not 100% I follow you, nor why I'd need it. So Any info would be great.  I do check the Hex ID at start up, this is how I know if I have a analog or digital controller.  I could easily check this during operation. Thx for the tips going to look over a few thing  thx.

[l_oliveira]

No, honestly I just meant that precision is not required at all. What matters is the order you do the stuff and doing them all...
The speed you read the pads just would affect the precision, and after a certain speed it can no longer be noticed at all.

Ah the only thing I can imagine that could kill the controllers is if you have the MCU output anything on the same port used to read the buttons.
I'd say use an different port to send the S1 and S2 bits and keep the port connected to the controller pins D0-D4 aways set as input.

[ulao]

True , I know I was setting high on the data lines during testing. Perhaps that killed it. Though now that the testing is done I wont be doing that. Thx for all the help.