PS/2 on I2C?

Duane Degn

I'm running out of IO pins (again) on a recent project.

I'm trying to make room for a PS/2 keyboard.

After looking at the circuit from the Propeller Proto board's pdf, I realized the circuit is very similar to I2C.



What kind of problems might I have if I added a PS/2 connector with the series 100 ohm resistors to P28 and P29? The modified circuit is shown below. I don't think the change with the way the resistors are connect should be a problem.



I am worried about interference between the keyboard and an I2C device (EEPROM). What are the odds keyboard data will match the address of the EEPROM?

Will reading and writing to the EEPROM freak out the keyboard?

I probably have enough pins to get by without doing this on this project but I wondered if anyone else has tried it.

I know Clusso99 has a one-pin keyboard driver but I'd rather stick with the standard driver.

I'd appreciate knowing your thoughts.

Thanks,

Duane

Peter Jakacki

Do not hook-up PS/2 directly to the I2C as it will interfere with boot operations for sure as the PS/2 can pull down the data line low plus it also controls the clock. You are far better off looking at ways of optimizing other I/O rather than cannibalizing existing I/O. Tell us what you have hooked-up now and we may be able to offer you a quick and easy solution.

Duane Degn

Peter,

Thanks for the reply.

Here's of how pins are presently used in my recent project.

' Pin Definitions
  _DebugTxPin = 30
  _DebugRxPin = 31
 
  ' Pins to Hong Kong Nordic nRF24L01+
  _HkSpiIrq = 0
  _HkSpiMiso = 1
  _HkSpiMosi = 2
  _HkSpiSck = 3 
  _HkSpiCsn = 4     
  _HkSpiCe = 5   
 
  _MainButtonPin = 27  ' Panic button, active high
  _MainBuzzerPin = 26  ' To a transistor base to buzz a piezo speaker
  _AdcCsPin = 25 ' ADC to monitor battery voltage and possible a photo resistor to monitor light levels.
  _AdcData = 24 ' ADC has two channels.
  _AdcClock = 23
  _LedBluePin = 20 ' RGB LED common cathode
  _LedRedPin = 19
  _LedGreenPin = 18
 
  ' Phone keypad control.                            
  _SpeakerOutPin = 6
  _SpeakerInPin = _SpeakerOutPin + 1
  _COutPin = _SpeakerOutPin + 2
  _CInPin = _SpeakerOutPin + 3
  _ThreeOutPin = _SpeakerOutPin + 4
  _ThreeInPin = _SpeakerOutPin + 5
  _FiveOutPin = 16 
  _FiveInPin = 17 
  _RedInPin = 22   
  _KeyboardDataPin = 24 ' Share pins with ADC 
  _KeyboardClockPin = 23 ' Share pins with ADC 
  _TvBasePin = 12 ' four pins.  There should be a way of only using three pins.

This is still part of my panic button project. There is no longer an urgent need for these panic buttons so I've been thinking of ways to make them more useful.

I thought the ability of the base station to send a text message would greatly add to the usefulness of these buttons.

As you've seen, I'm trying a round about method to interface with a cell phone. I have not been successful in trying the method you suggest (I've been working on this aspect for a couple of days now). I'm just about ready to go back to the relays.

To control the cell phone requires nine pins. The Nordic nRF24L01+ module uses six pins. Three pins are needed for a RGB LED. Besides communication with the EEPROM, I'm using the I2C line to communicate with a real time clock.

One pin to monitor the panic button. One pin to drive a piezo speaker with a transistor. Three pins are used to communicate with a two channel ADC chip (used to monitor battery voltage and possibly light level with a photo resistor).

I'm using pins 30 and 31 for debugging and entering text messages from a terminal. This pins could be used for something else once I've finished debugging.

I think that's just about it for devices the unit will need to interface with most of the time. So far the count is:
RX/TX, I2C: 4
LED: 3
button, piezo: 2
ADC: 3
Nordic: 6
cell phone: 9

Total (so far): 27

I'd like to be able to use this base station unit to type and send text messages (besides the notification text messages stored in memory). I'd like to be able to attach a TV and keyboard to the unit

The TV adds three pins (if I can figure out how drop the fourth pin for the setup). The keyboard uses two pins.

With these last additions the total is now 32 pins.

I'd like to be able to use some sort of display besides the TV so the unit could be used as a clock. I could probably use pin 30 to transmit data to some sort of serial display (either a LED or LCD display).

So it seems like I might have enough pins after all.

I agree with you that sharing the I2C bus with the keyboard isn't a good idea. I do think the keyboard could share the ADC data and clock pins. If the CS pin is left high the ADC shouldn't care what the data and clock pins are doing.

Another way to free up some pins is to add one more relay to control the power to the other relays. If the nine cell phone relays don't have a 5V power source, it shouldn't matter what the pin state is to the controlling transistors. Right?

I might want to add a microphone and speakers to some of these units. I think before I do that, I'll find a better cell phone solution.

I could get by without using all the devices at once. As I've suggested, the battery voltage wouldn't need to be monitored as a text message is composed. The Nordic module, LED, panic button and piezo buzzer also don't need to be active while composing a text message.

I'm beginning to see there a lots of options to share pins (if I need to). The shared I2C and PS/2 idea is officially dead.

Duane

Peter Jakacki

First thing is to figure out which I/O requires direct connection to the Prop such as the audio functions and PS/2 etc. There are many ways to offload the I/O and straight away you could save 3 I/O just by using an I2C ADC chip. If you were to do that though it would not be any different then if you used a small microcontroller chip to act as an I2C slave and provide A/D functions as well as extra I/O for LEDs etc. If you used a small Silabs C8051 type chip then the Prop can load up it's firmware and I have both 8051 firmware and ICP software that makes that as easy as using any other dumb chip (true).

So you see, even with these solutions you already free up a lot of I/O. But I would get rid of the relays and run the keypad matrix directly or at the very least use opto-mosfets as they are a lot more compact than relays. But the slave micro could handle the keypad interface for you as well and you would only need to talk to it via I2C. I have interfaced to cell phone keypads many years ago with the direct I/O method by sensing active column scans although I actually removed the keypad & display pcb and connected directly to the socket on the main pcb and this may be possible for you too.

Otherwise one of the tricks I use for talking to serial devices is to use the I2C lines as the SCK and MOSI to the SPI style chip and run back the data separately or combined or tristated back onto the SDA. If you have say 3 SPI chips then this saves at least 6 I/O straight away, all you have to do is to preferably tie in I2C and SPI communications into one driver. I have done this with multiple SD cards and other devices too. Even the slave Silabs micros are programmed in-circuit from the I2C lines and all I need is a "chip select" line.

How do you feel about these suggestions then?

Sapieha

Hi Duane.

Why not use I2C expander on same pins as EEProm to drive Led's and free 3 pins of Propeller -- I think that even piezo can be driven by that IC.

Tubular

Duane,

You may have you reasons for wanting to use a full phone, or it may just be convenient for the time being.

If you jump to a GSM/GPRS modem, it will only need 3~4 wires to communicate with it (RX, TX, OnOff and perhaps handshaking), and they have powerful "AT" commands for handling many things including speaker/earphone/mic.

I've got some boards which connect the Telit GE865 to the prop, and there are also solutions from Sparkfun and elsewhere

Clive Wakeham

http://www.gadgetgangster.com/find-a-project/56?projectnum=333

Keyboard and mouse on I2C

Toby Seckshund

As I said before to get around any boot problems I stuck on a 4053 chip to change the pins over from the default IC2 lines to the PS2 lines. Initially I tried to get this switch to throw over at the end of IC2 activity but the FF could see some other switching on the pins before the boot actually started and so disconnecter the EEPROM too early. In the end I just used the start up of the VGA H syncs to do the switch (Dracblade(ish) board).

ADDIT

Did the AVR code for this ever get released or is it commercial?

Peter Jakacki

It's a funny thing I've noticed on this forum that when some start to run out of I/O the first ones that are invariably sacrificed on the altar of didntthinkitthrough is the I2C lines. These lines have got to be the most useful, the most important I/O lines available, they are sacrosanct, don't touch them. It may be my opinion but for one I also use the program EEPROM for backup of variables amongst other things and having I2C means I can add a swag of other I2C chips without any other I/O being touched. I even leave 4-pin headers on pcbs just so I can expand externally if I want to. There are no other lines like it, so why wreck them?

Toby Seckshund

I wanted to get as many I/Os in a row, preferably 0-7 for Data, and then if possible 8-19 for Addresses along with four for the SD card. As the VGA pins have to start at a 0, 8, 16 or 24 boundary I stuck this onto P24 and resticted it to two lots of syncs and just two vid pins for a white on blue screen. This left me with the choise of sacrificing the I2C or the serial pairs so that the KBD could be attatched, as the serial could be useful for debugging etc the I2C got ditched.

I have never done much with I2C until recently, and that is mostly with a TV tuner module (just in time, they started the analog shutdown here yesterday :-))

Duane Degn

Tubular wrote: »

Duane,

You may have you reasons for wanting to use a full phone, or it may just be convenient for the time being.

If you jump to a GSM/GPRS modem, it will only need 3~4 wires to communicate with it (RX, TX, OnOff and perhaps handshaking), and they have powerful "AT" commands for handling many things including speaker/earphone/mic.

I've got some boards which connect the Telit GE865 to the prop, and there are also solutions from Sparkfun and elsewhere

Tubular,

Yes, I've seen your (IMO beautiful) boards with the Telit GE865. I would like to go that route eventually.

I had an extra cell phone and I wanted to see if I could get it to work by simulating key-presses. It did work and it was a lot of fun to hear the relays click away at 10 Hz (the fastest I could get it without garbling the message). I even had enough relays on hand.

@Others, I would like to keep the hardware homogeneous on these devices. I load all of the (up to six) units with the same firmware. Each unit has an ID number in its upper EEPROM so it know its turn to communicate.

There are a couple of units with slightly different hardware (a 12V light to go with the LED). I need to include these exceptions in the program. I'd like to keep the exceptions to a minimum.

I just noticed the similarity between the I2C circuit and the PS/2 circuit. I'd think if the keyboard weren't attached at bootup then there would like be less of a problem in sharing the lines. The keyboard would be an occasional accessory. But as I stated above, I don't plan on sharing the I2C lines. I'll find a different phone solution before adding any other devices that may need IO pins.

Thanks everyone for the ideas.

Duane

Toby Seckshund

I isolated the two sets of devices so the either wouldn't spot, by chance, a valid command or act on some piece of data from the other.

What about one of those wonderful switches, like they had bolted to the wall in all the classic horror/mad professor films ? The 4053 was not far behind them :-)