I have a question about adjusting a design for a PS/2 Keyboard/Mouse Interface that previously used 2 pins for clock and data (seperate In and Out) for the clock and data lines:
The signals were combined external to the PSoC:
The code I have written bit-bangs the PS/2 interface with the falling edge of the clock being the trigger to read data bits.
What I'd like to do is possibly change these to single Clock and Data lines to simplify the design.
I have a couple concerns:
1) If I merge ClkIn and ClkOut into a single pin (set for Input/Output - Open-drain drive low) will my Clock interrupt fire when I toggle the pin as an output? If so I will probably need to ignore the interrupt for when the PSoC has control of the clock? I'm already doing this for the existing design so it's not an issue if this is the case.
2) Both the mouse and Keyboard clock signals are on one port. Since (if I recall correctly) there's only one dedicated interrupt signal per-port, will I need to make special considerations to separate the two interrupts? Or would this all be taken care of by having two separate ISR components (one for keyboard clock, one for mouse clock)?
Thanks in advance for any tips. I want to make sure I have an understanding of the inner workings of how this will behave before I go ahead writing too much code.
Solved! Go to Solution.
Relating to question 2:
Looking into this further, It seems I can't have both the mouse and keyboard clock signals on the same port with their own interrupts, because only one interrupt can be assigned to that port. I'm guessing there's no real way around this other than redesigning to place them on separate ports?
Maybe I could have a single interrupt for both clock signals and determine the source when the interrupt fires? PS/2 is not a particularly fast protocol (relatively speaking to the speed the PSoC is running), so determining the source of the interrupt after it has fired, and executing the code for the corresponding device accordingly may be an option? I'd have to use a status register like so:
I could then use CLK_ISR to detect a falling edge on either clock, read the status register in the ISR, then process the next bit in the sequence it for mouse or keyboard accordingly.
2. You can attach individual external interrupts to each pin (PSoC5 has plenty of interrupts). You have to add a logical NOT element in-between, as external interrupt can fire on rising edge only.
Both interesting ideas!
I will mess around with these, thanks for the input!
I ended up going with a similar solution for the Input/Output of the data signals.
This combined with what moto suggested (which also implemented what odissey1 suggested with using an external interrupt rather than the port interrupt) for the clock should actually make porting the firmware from 4 lines to lines much easier than initially anticipated:
For the data line I decided to have the OE be the register I write to with an inverter so I can write MSE_DTA_OUT =0 to drive the data line low and =1 to release the line and have the pull up bring it high.
Although if my pin is configured as Open-Drain Drive Low, it should basically be the same thing as using the generated pin API correct?
> Although if my pin is configured as Open-Drain Drive Low,
> it should basically be the same thing as using the generated pin API correct?
I think so.
Except that you need to have an external pull-up, otherwise writing 1 will not make the signal high.
But I hope that this information is not necessary since you know what you are doing, right?
Indeed, we will have 2k pull-ups on the clock/data lines in the design.
Just a quick update, I implemented this today and it works great, although I did adjust the Data pins to a more plain configuration: