interfacing PS/2 voltage levels to CMOS

I would like to interface the inputs of a CMOS microcontroller with a PS/2 signal. What interface circuitry should I put in between the PS/2 signal and the microcontroller inputs? It should be able to accept the standard PS/2 input voltages. Supply Voltage is 5V dc.

Standard PS/2 input voltages:

High-Level Input Voltage: 5.0V - Pullup (minimum) Low-Level Input Voltage: 0.5V (maximum)

DC Characteristics of the CMOS microcontroller:

Input Low voltage: -0.5V...(0.3)*Vcc Input High Voltage: (0.6)*Vcc...Vcc+0.5V

Any suggestions would be greatly appreciated.

Reply to
Laszlo Cser
Loading thread data ...

Not quite sure what you mean by "PS/2 levels" but judging from your incomplete description I would suggest using copper wires as interface hardware.

and

Reply to
Grzegorz Mazur

The logic levels should be fine with each other. You can use bare wire. I would put some small resistor values in-line with each signal and perhaps

120pF capacitors to ground to eliminate some noise susceptibility.

Noel

--
Noel's Lab
www.noels-lab.com
 Click to see the full signature
Reply to
Noel Henson

Thank you for all the replies. Unfortunately I posted the wrong PS/2 levels. Here are the right ones. It seems TTL to me.

High-Level Input Voltage: 2.0V (minimum) Low-Level Input Voltage: 0.5V (maximum)

Could you please suggest some circuitry for this TTL to CMOS problem?

Laszlo

PS/2

Reply to
Laszlo Cser

Could you please tell us what the loading on the PS/2 lines are? And then what the high and low level _output_ voltages for your microcontroller are?

You may very well find your microcontroller can output these voltage levels directly -- many today have I/O pins that can, e.g., drive LEDs directly and have far more than enough 'oomph' (drive) to interface with TTL.

---Joel Kolstad

Reply to
Joel Kolstad

It is unlikley that you will have any problem directly connecting the PS/2 device to your microcontroller.

It is a good idea to add buffers to your signal though, and you could guarntee TTL compatiblity by adding a TTL compatible buffer in front of your CMOS device. I doubt many cheapo mouse and keyboard makers even go through the trouble of complying with TTL signal levels. Most uC's and logic devices are CMOS these days, other than special line drivers and whatnot. Try the 7407 or 74132 (schmitt input) buffers. Good Luck.

-J

Reply to
Mood

The interface is still a wire. The thing you may have to worry about is the current drawn at a low level input.

Please DO NOT toppost. I have fixed this one.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

Laszlo,

Essentially, you don't have to worry about it. Your microcontroller will be using CMOS outputs. These will be able to comfortably meet the PS/2 port specifications. I've done this quite a bit. I've even used 3V micros to drive the PS/2 port.

I hope you aren't getting confused with CMOS input and output levels in trying to drive the TTL inputs. Standard CMOS inputs are 33%VDD and 66%VDD but you won't find this on most micros. You'll usually find input requirements of 0.8V (max low) and 2.0V (min high). The CMOS outputs usually drive a 0.6V (max low) and a VDD-0.7V (min high). Theses definitely exceed the TTL and CMOS input requirements. Relax.

You're only real issues concerning input buffer circuitry will be static protection and noise elimination. Both of these can usually be resolved with a single resistor and capacitor for each signal.

Noel

Laszlo Cser wrote:

--
Noel's Lab
www.noels-lab.com
 Click to see the full signature
Reply to
Noel Henson

...and possibly a network to provide some protection against static discharge.

Reply to
CWatters

Hi,

I have to design the interconnection of an assembly interrupt handler the rest of the C language software. The handler performs some speed sensitive portread+process operations. The results (a few 8-bit variables) should be passed on to the rest of the software. Implementation is done by an Atmel AVR microcontroller and the WinAVR port of the AVRGCC compiler.

What approach should I take?

The interrupt handler could be written either as a separate .s module or in inline assembler. I don't see how the interconnection could be done by the latter one.)

#1 - interrupt handler is implemented in a separate assembly module. Fixed SRAM addresses reserved by the linker command file form an interface towards the rest of the software. (What't the best way to do this?) #3 - assigning a variable to a specific register (I'm not sure of this one. Can it be guaranteed, that the variable is placed into the register. Even if it can, the compiler still may use the register for other purposes?)

Any help would be appreciated.

Laszlo

Reply to
Laszlo Cser

I don't think you can actually do that, unless the AVR is a rather unusual platform (I've never used it myself...). Interrup handlers either have to be written completely in asm, or the C compiler has to give you special support to allow writing them in C, because they almost invariably need a different kind of call convention (RTI instead of RET on return, and similar nitbits).

So yes, it quite probably should be done as a .S module (capital S and you'll have the C preprocessor applied to it, which may come in quite handy...)

The interconnection isn't the problem --- the call frame is.

There shouldn't be any particular reason to have fixed SRAM addresses for that. The linker can resolve those for you, i.e. your assembler code can directly reference variables defined and declared by C. In case of doubt, write a simple prototype interrupt handler routine in C and use 'gcc -S' to see how to access those variables from assembly.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Or write a small assembly routine that saves some registers, then calls a function written in C and when it returns, the assembler routine takes over and restores the registers and perform the actual RTI instruction.

If the interrupt service routine is coded in C, it is extremely important that it does not call any run time library routines explicitly or implicitly (e.g. emulated floating point addition), since the library routines are not set up properly or their activation may cause strange errors, if the libraries are not designed to be called from the ISR.

Many C-compilers add an underscore to the global function and variable names, so if you declare outside of any function

volatile unsigned char Var1 ;

the assembly language should contain a reference similar to

EXTERN _Var1 (or Var1_)

The linker should take care of mapping the C and assembly language references to the same physical address.

It is also very important to use the volatile keyword in non-interrupt C-code, if the interrupt routine updates the Var1 memory location.

Paul

Reply to
Paul Keinanen

I've seen several instances where the RTOS provides a tiny interrupt handler stub that calls the actual programmer supplied handler (via a C function pointer perhaps).

--
Darin Johnson
    Caution! Under no circumstances confuse the mesh with the
 Click to see the full signature
Reply to
Darin Johnson

sensitive

in

the

towards

Don't use fixed addresses. This is destined to lead to errors. Either declare the variables in the C module and use exernals in the assembly module or declare the variables in the assembly module and use externals in the C module (e.g. extern char Value;). I always declare the variable the the module that 'produces' the data.

Meindert

Reply to
Meindert Sprang

Can you no just write the lot in C, using WinAVR extensions?

For example, an ISR for compare match A can be written as:

void SIG_OUTPUT_COMPARE1A( void ) __attribute__ ( ( signal ) ); void SIG_OUTPUT_COMPARE1A( void ) { /*compiler automatically saves used registers here.*/

/* ... Your C code here ... */

/*compiler automatically restores registers and inserts end of interrupt instruction here.*/ }

Richard.

formatting link

Reply to
Richard

I don't have any experience with the AVR port, but the corresponding feature in the H8 port works great:

void myISR(void) __attribute__((interrupt_handler)) { /* gcc saves all used registers */

/* user code here */

/* gcc does return-from-interrupt */ }

--
Grant Edwards                   grante             Yow!  One FISHWICH coming
                                  at               up!!
 Click to see the full signature
Reply to
Grant Edwards

In that case, though, you still write the actual interrupt handler in asm. It's just calling some C function to help with the job.

You're correct debunking my statement that it had to be "completely" in asm, though. An ASM wrapper is sufficient.

"Many" C-compilers are beside the point, though. It's the single compiler actually being used in the particular situation that matters, and that's where the option of having the C compiler generate assembler code for output comes in handy. You don't have to know what convention is used by the compiler, you don't even have to RTFM for it. You just have the compiler tell you all the ugly details --- it must obviously know what the convention is, after all. "gcc -S" (or its equivalent on the compiler in question) is about the best documentation tool for low-level aspect of ABIs ever invented.

Definitely.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.