PS/2 to USART

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys,

We're designing a circuit with an AT90USB1286 as the main MCU and there's a PS/2 peripheral device which needs to send data to the AT90USB1286.

I guess the AT90USB1286 could bit bang PS/2, but that would be pretty resource consuming and it couldn't do much else so I though that using an intermediate IC, PS/2 could be converted to USART which the AT90USB1286 speaks natively, so it could do any other processing.

I think an ATtiny could do the PS/2 to USART conversion with bit banging. Is there any ASIC that is specifically crafted for this job? If there isn't any other options then which is the cheapest ATtiny that could do the job?

Thanks in advance!

Laci

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've done it with a Tiny45. By taking away some features, could probably fit it in a Tiny25.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm pretty sure that the Tiny45 does the job and there are probably some candidates between Tiny25 and Tiny45, but I'm not sure which features should I look for, specifically:

* Universal Serial Interface
* Full Duplex USART

Which one do I have to look for?

And in general, if I want to bit bang between two non-native protocols, is it possible?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PS/2 protocol is very undemanding. And even less so if you hook PS2CLK line to a pin that triggers interrupt on change. Are you sure you don't want to do that with the big micro alone?

The Dark Boxes are coming.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, I'm not sure :)

The question is how much resources does PS/2 consume. I thought that bit banging requires constant, significant processing power but if it can be solved in a interrupt based way then I'll go for it.

What do you think?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only complexity about the PS/2 protocol is that rather than the possibly expected interface where there is a synchronous serial link between the host CPU and the keyboard controller in which the host CPU (AVR) is the clock master in charge of pulsing the CLK line whene IT is ready for a transfer to be made, instead the PS/2 device itself is the clock generator and the host (AVR) must actually be ready to respond to it at a moment's notice as soon as it starts to generate clock pulses and put out corresponding data on the DATA line. The clock runs at something like 50kHz so the AVR does not have that much time to respond to each clock edge. Now it could do this with polling but it would have to be sensing the clock state very regularly (1/50000 s) and there might not be much over-head for doing much else.

However if you use an interrupting IO pin on the host CPU connected to the PS/2's CLK line then each time the interrupt occurs all it has to do is read the state of DATA and shift the bit state into the 8-bit received byte that's being built up. Every 8 clock pulses it has a complete byte that can then be processed as a make or break code. (with some complication because of multi-byte sequences and the need to hold Shift/Ctrl/Alt state)

So if you use an interrupt and the ISR is written efficiently it need not steal more than a few percent of the CPU time.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you very much for your detailed answer, Cliff!

Modifier keys won't play because I want to interface the AVR with a touchpad, but otherwise it's all relevant. I think I'll try without an intermediate adapter first to see whether it works.