interfacing PS/2 voltage levels to CMOS

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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.



Re: interfacing PS/2 voltage levels to CMOS
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.

Quoted text here. Click to load it
and



Re: interfacing PS/2 voltage levels to CMOS

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: interfacing PS/2 voltage levels to CMOS
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

Quoted text here. Click to load it
PS/2
Quoted text here. Click to load it



Re: interfacing PS/2 voltage levels to CMOS
Quoted text here. Click to load it

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



Re: interfacing PS/2 voltage levels to CMOS
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  


Quoted text here. Click to load it

Re: interfacing PS/2 voltage levels to CMOS
Quoted text here. Click to load it

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 ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: interfacing PS/2 voltage levels to CMOS


Quoted text here. Click to load it

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



Re: interfacing PS/2 voltage levels to CMOS
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:

Quoted text here. Click to load it

--
Noel's Lab
www.noels-lab.com
We've slightly trimmed the long signature. Click to see the full one.
Mixing C and assembly in interrupt handler (AVRGCC)
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



Re: Mixing C and assembly in interrupt handler (AVRGCC)

Quoted text here. Click to load it


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...)

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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 ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Mixing C and assembly in interrupt handler (AVRGCC)
On 22 Feb 2004 19:02:06 GMT, Hans-Bernhard Broeker

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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


Re: Mixing C and assembly in interrupt handler (AVRGCC)
Quoted text here. Click to load it



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.

Quoted text here. Click to load it

"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.

Quoted text here. Click to load it

Definitely.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Mixing C and assembly in interrupt handler (AVRGCC)

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Mixing C and assembly in interrupt handler (AVRGCC)
Quoted text here. Click to load it
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



Re: Mixing C and assembly in interrupt handler (AVRGCC)
Quoted text here. Click to load it

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.

http://www.FreeRTOS.org






Re: Mixing C and assembly in interrupt handler (AVRGCC)
Quoted text here. Click to load it

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!!
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline