CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Timing issue with EXT INT ISR

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Mounty



Joined: 12 Jul 2013
Posts: 12

View user's profile Send private message

Timing issue with EXT INT ISR
PostPosted: Sat Aug 03, 2013 11:42 am     Reply with quote

Not sure I'm on the right forum for this, but I'm using CCS C so here goes.

I'm designing an adapter which will control an 80's computer, the Commodore CD32, with a Playstation gamepad.

No problems interfacing with the Playstation gamepad, and I can control normal Amiga games with it.

The problem comes when I try to control a CD32 game. The CD32 when in Gamepad mode sends the keypresses through an 8-bit PISO convertor. I have simulated this using an external interrupt to detect the L2H clock from the CD32. My ISR looks like this:


Code:
#int_ext       //Set external interrupt on pin RB0
void isr()

{
delay_us(10);
   if(input(PIN_A7)) {bitcount=0;};

   if (cd32_byte[bitcount] == 0) {output_low(PIN_B5);} else {output_high(PIN_B5);}
   bitcount++;
   
   if (bitcount==9) {bitcount=0;}

}


What happens is the game behaves as though the fire button is constantly pressed. it makes no difference if there's all zeros or all 1's on the bitstream. Pulling the joystick plug stops the behavour.

I hit a brick wall with this three or four days ago and I thought one of you guys might be able to help.
dyeatman



Joined: 06 Sep 2003
Posts: 1933
Location: Norman, OK

View user's profile Send private message

PostPosted: Sat Aug 03, 2013 1:22 pm     Reply with quote

We need more information:
1. What's on PIN-A7? I assume the data line since the clock is on Ext?
2. What PIC are you using?
3. What speed is the PIC running?
4. Are you sure the PIC speed is right?
5. Why is there a 10us delay going into the ISR?
6. Where is the routine cd32_byte[bitcount]? What does it do?
7. What PISO are you using? A chip or a full blown interface?
8. I gather the clock is low to high?
9. Is data line active a 1 or zero? (is it inverted)?

A wiring diagram would be nice...
_________________
Google and Forum Search are some of your best tools!!!!
Mounty



Joined: 12 Jul 2013
Posts: 12

View user's profile Send private message

PostPosted: Sat Aug 03, 2013 3:43 pm     Reply with quote

dyeatman wrote:
We need more information:
1. What's on PIN-A7? I assume the data line since the clock is on Ext?
2. What PIC are you using?
3. What speed is the PIC running?
4. Are you sure the PIC speed is right?
5. Why is there a 10us delay going into the ISR?
6. Where is the routine cd32_byte[bitcount]? What does it do?
7. What PISO are you using? A chip or a full blown interface?
8. I gather the clock is low to high?
9. Is data line active a 1 or zero? (is it inverted)?

A wiring diagram would be nice...


1. On pin A7 is the signal that puts the CD32 controller into gamepad mode by toggling the onboard PISO's (SN74165A) shift/load pin. In my case the CD32 controller has been replaced by a PSX controller and the PIC.
2. PIC16F628A running at 4MHz.
3. I am pretty sure that the PIC speed is more than adequate for the purpose yes.
4. The 10uS delay is just experimentation.
5. The routine cd32_byte[bitcount] is an 8 bit integer array to replace the PISO registers.
6. I'm not using a PISO at all, I'm attempting to simulate the CD32 controller onboard PISO using the PIC.
7. Yes that's right I'm triggering the interrupt using the L2H edge of the incoming clock from the CD32 unit.
8. No it's not inverted although I have experimented both ways.

Thanks for your help. Hope this info gives you a few clues.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sat Aug 03, 2013 3:59 pm     Reply with quote

Quote:
game behaves as though the fire button is constantly pressed

What does this mean ? Does it mean you're getting constant interrupts
on the External interrupt pin ?

If so, what the signal look like on that pin ? Have you looked at it with
an oscilloscope ? Is it constantly pulsing ? Or is it a steady logic level ?
If so, what is the voltage ? What are the high and low voltages of the
signal when pulses are present ?
Mounty



Joined: 12 Jul 2013
Posts: 12

View user's profile Send private message

PostPosted: Sat Aug 03, 2013 4:17 pm     Reply with quote

PCM programmer wrote:
Quote:
game behaves as though the fire button is constantly pressed

What does this mean ? Does it mean you're getting constant interrupts
on the External interrupt pin ?

If so, what the signal look like on that pin ? Have you looked at it with
an oscilloscope ? Is it constantly pulsing ? Or is it a steady logic level ?
If so, what is the voltage ? What are the high and low voltages of the
signal when pulses are present ?


Yes I have a scope and the interrupts are working fine, triggered by a 250Hz clock on RB0. The high voltage is about 4.8V and the low about 0V.

This is sending an 8-bit bitstream out of RB5, to the CD32, which looks like it is formatted correctly and should be accepted by the CD32, but whatever buttons are pressed, even no buttons, the result is the same i.e the game reacts as though a fire button is being held down.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sat Aug 03, 2013 4:20 pm     Reply with quote

Connect the game the way it's normally supposed to be connected, and
study the waveforms and the idle state. Then make sure you copy it
exactly with your PIC.
Mounty



Joined: 12 Jul 2013
Posts: 12

View user's profile Send private message

PostPosted: Sat Aug 03, 2013 11:29 pm     Reply with quote

PCM programmer wrote:
Connect the game the way it's normally supposed to be connected, and
study the waveforms and the idle state. Then make sure you copy it
exactly with your PIC.


Yes that's one logical approach. Unfortunately I don't have an original CD32 gamepad so I'll have to either buy one or build one.
Ttelmah



Joined: 11 Mar 2010
Posts: 19506

View user's profile Send private message

PostPosted: Sun Aug 04, 2013 4:47 am     Reply with quote

The interface to the gamepad, is SPI. As such, the place to start is the SPI peripheral... However the gamepad uses 3.3v logic, while your PIC uses 5v logic. You really need to possibly think about a level translator chip, if your want to keep using this PIC.
Then the clock rate is 250KHz, not 250Hz. No hope at all to interface with a software routine. Your PIC will execute just four instructions in the entire clock cycle. Even using the SPI hardware, 4MHz is 'pushing it' to be able to handle the bytes quickly enough.....
Data is read on the rising clock edge, with the clock idling high. This is SPI mode 3.

Best Wishes
Mounty



Joined: 12 Jul 2013
Posts: 12

View user's profile Send private message

PostPosted: Sun Aug 04, 2013 5:00 am     Reply with quote

Ttelmah wrote:
The interface to the gamepad, is SPI. As such, the place to start is the SPI peripheral... However the gamepad uses 3.3v logic, while your PIC uses 5v logic. You really need to possibly think about a level translator chip, if your want to keep using this PIC.
Then the clock rate is 250KHz, not 250Hz. No hope at all to interface with a software routine. Your PIC will execute just four instructions in the entire clock cycle. Even using the SPI hardware, 4MHz is 'pushing it' to be able to handle the bytes quickly enough.....
Data is read on the rising clock edge, with the clock idling high. This is SPI mode 3.

Best Wishes


Thanks for the info. I'm a bit confused about your statement that the gamepad uses 3.3V logic. The gamepad only has two chips, the SN74165A and the SN74125A, and according to the datasheets they are both 5v compatible. Also, I measured the clock pulse width as 4ms, which gives a frequency of 250Hz, not 250kHz.

Thanks again.
Ttelmah



Joined: 11 Mar 2010
Posts: 19506

View user's profile Send private message

PostPosted: Sun Aug 04, 2013 7:31 am     Reply with quote

You talk about trying to control a CD32. This is a 3.3v device. The CD32 interfaces to it's peripherals using SPI at 250KHz, which it sends out when it talks to a device. Think about it you are not going to get very far using a controller that only updates 31* per second (250Hz).
I'd guess the 250Hz, is something like a 'Are you there' stream, which stops when it gets a reply. It sends a command byte at the same time as clocking in the data.
Pull the CD32 interface specifications. There are plenty of 'hacked' descriptions of how to drive this on-line.

Best Wishes
Mounty



Joined: 12 Jul 2013
Posts: 12

View user's profile Send private message

PostPosted: Sun Aug 04, 2013 7:59 am     Reply with quote

Sorry to disagree with you but the CD32 gamepad is a 5V device. It is powered from the CD32 joystick port which is only capable of supplying 5V.

Also, I think I can tell 250Hz from 250kHz. My scope might not be the most accurate in the world but I don't think it's that far out!
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group