Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Open-collector interface

Status
Not open for further replies.

o_0

Member level 3
Joined
Sep 30, 2009
Messages
58
Helped
2
Reputation
4
Reaction score
2
Trophy points
1,288
Activity points
1,873
Hi,

The attached code has three 1-axis accelerometers sending data to an Atmega32, which interfaces with the PS/2 port of the computer. I have some questions about this:

(1) At the beginning of the code:
#define CLK_OUT PORTC.1
#define DATA_OUT PORTC.6
#define CLK_IN PINC.3
#define DATA_IN PINC.4

I'd like to know how this relates to the following diagram of an open-collector interface. In the diagram, what do A, B, C, and D mean in terms of CLK_OUT, DATA_OUT, etc? C and D don't connect to the computer at all?

Ps2_circuit.PNG


(2) Also, in the code I'm trying to figure out what pins take the accelerometer inputs. I would much appreciate it if someone could please enlighten me regarding this as well as pointing out the part of the code that says it. Thanks in advance.
 

Attachments

  • ps2.zip
    7.9 KB · Views: 72

Hi,

PS/2 is for Bi-directional communication;
If Data and Clock lines in your diagram go to PS/2 port of PC, then
CLK_OUT PORTC.1 would be "C"
DATA_OUT PORTC.6 would be "D"
CLK_IN PINC.3 would be "B"
DATA_IN PINC.4 would be "A"

C and D connects to PC via those transistors (to send data). A, B are receiving lines.

You must get the hardware-schematic of the circuit and User-manual of accelerometers to correctly figure out connections.

Wish you success !
 

    V

    Points: 2
    Helpful Answer Positive Rating
Thanks for your response.

C and D connects to PC via those transistors (to send data).

On the transistors, the base comes from the microcontroller, the collector goes to +5V and the emitter goes to ground. So where does the PC connection come in?

Another way to phrase this would be, in this PS/2 pinout where would A,B,C,D connect? (Pin 1, 2, etc.)
**broken link removed**

PS/2 connector pinout
Pin Signal In/Out
1 Data Out
2 N/C
3 Ground
4 +5V
5 Clock Out
6 N/C


You must get the hardware-schematic of the circuit

I wish I had the hardware schematic. That's what I'm trying to figure out from the code.

Here's the accelerometer datasheet: **broken link removed**

I guess I should rephrase the second item. When connecting from the accelerometers to the microcontroller, what pins on the microcontroller are involved?

That info should be somewhere in the code, the micro is getting its data from somewhere, I just can't find where.
 
Last edited:

Hi,

You can see collector pins are connected to Clock and Data lines also, not-only to +5V. Consider transistor connected to C of microcontroller; its collector is connected to Clock line; a resistor has connected to that same place also (other end of resister is at +5V)

Your wires are mapped as follows;
uC------PS/2-port in PC
Data -> pin 1 (Data)
Clock -> pin 5 (Clock)

Accelerometer is 3-axis and there are 3 voltage out pins corresponds to X,Y,Z axis. Those 3 line should be connected to 3 analog-inputs of uC. Then those voltages will be converted to digital values (AD convention).

In code; for x-axis ADC0 line of uC is used; and for y-axis ADC1 is used.

Hope this info helps you to dig the code,
 
  • Like
Reactions: o_0

    o_0

    Points: 2
    Helpful Answer Positive Rating
Thanks,

Another thing, the operating frequency is supposed to be 12.5 kHz, how do you think this should be done? By using an external clock? It would be great if you could provide a link to where someone is selling one. I looked online and all I seem to find is clock ICs that are the kind of clock that keep the time of day, not what I'm looking for. I can't seem to find any 12.5kHz crystals. Is there such a thing? I think a crystal would be better because it's more accurate. Thanks again.
P.S. I'm using ATmega32a

Would this one be a good choice?
http://www.atmel.com/dyn/resources/prod_documents/doc4674.pdf
If so, are there any like this one that aren't automotive?
 
Last edited:

Hi,

I think the "operating frequency is supposed to be 12.5 kHz" means system clock(Oscillator) for your ATmega32a.
If so, your proposed IC in link is useless. As it say, it's a long-term timer "Delay Time Range: 3.7s to 20h". It's not for clocking a uC.

---------- Post added at 08:08 ---------- Previous post was at 07:48 ----------



Why you can't operate it with commonly available crystal ?
However you can use available higher value crystal with a Frequency-divider circuit. (eg. 100kHz crystal with Frequency-divider by 8.)
Is this helps you ?
 

Why you can't operate it with commonly available crystal ?
However you can use available higher value crystal with a Frequency-divider circuit. (eg. 100kHz crystal with Frequency-divider by 8.)
Is this helps you ?

Thanks DineshSL. I found that in the code, the ADC divider is 128, so the crystal should actually be 1.6 MHz I think. Is there such a thing as a 1.6 MHz crystal? I've checked google and digikey and can't find one.

I've heard about the 4060 and LTC1799, too bad the LTC1799 is SOT packaging, I'd prefer DIP. The 4060 is DIP, I've found this application circuit
clip_image0026.gif

Would you happen to know the formula for determining the capacitor and resistors on pins 9, 10, and 11 given the desired frequency?

Do you happen to be familiar with the PS/2 protocol and what would be the best way to clock the uC for it? Thanks again
 

Alternatively, I've heard that the microcontroller frequency does not have to be the same as the PS/2 frequency. If so, would it be good enough to just leave the uC on the default setting (internal RC 1 MHz)?
 

Hi,

The PS/2 interface standard requires the device (µC in this case) to always generate the clock signal. A valid clock frequency can range from 10kHz to 16.7kHz. A clock frequency in this range can easily be generated by the use of a timer in your code with almost any system clock, therefore frequency of the µC is largely irrelevant with the proper selection of a timer prescaler value.


Tutorials for applying AVR timers as clock sources:

AVR Timers – An Introduction

Signal Generator with an ATmega8

And for the PIC people out there:

1Hz Clock Generator using PIC12F675

The ISR routine in your PS2 source file,

Code:
// this interrupt should run every 20us or 1/4 period of the clock
interrupt [TIM0_COMP] void timer0_overflow(void)

handles both the data transmission and clock transition.

Initialization of the timer occurs in the following routine:

Code:
void initialize(void)
{        
    Button0pushed = 1050;
    Button1pushed = 1050;
    ADMUX = 0b01000000; //ADLAR is not set
      ADCSRA = 0b11000111; //Enable & Start ADC w/ division factor of 128 
    OCR0=5;                       //20 uSec
    TIMSK=2;                   //turn on timer 0 cmp-match ISR 
    TCCR0=0b00001011;        //prescalar to 64  and Clr-on-match
    .
    .

The open collector diagram you have pictured demonstrated the use of an open collector interface, C and D, used to drive the data or clock PS/2 interface low, near ground levels, when a high or '1' is output at the corresponding pin. This configuration is used for PS/2 signalling protocols.

Rather than take the time to type the protocol out here is a quote for a very nice tutorial page I just found, link follows the quote:

The Data and Clock lines are both open collector. A resistor is connected between each line and +5V, so the idle state of the bus is high. When the keyboard or mouse wants to send information, it first checks the Clock line to make sure it's at a high logic level. If it's not, the host is inhibiting communication and the device must buffer any to-be-sent data until the host releases Clock. The Clock line must be continuously high for at least 50 microseconds before the device can begin to transmit its data.

As I mentioned in the previous section, the keyboard and mouse use a serial protocol with 11-bit frames. These bits are:

1 start bit. This is always 0.
8 data bits, least significant bit first.
1 parity bit (odd parity).
1 stop bit. This is always 1.
The keyboard/mouse writes a bit on the Data line when Clock is high, and it is read by the host when Clock is low.

The PS/2 Mouse/Keyboard Protocol

As far as the accelerometer is concerned, DineshSL is correct, the unit requires the use of A/D inputs along with axis selection lines. Look for three matching RC low pass filters between the accelerometer outputs and µC inputs as Freescale recommends.

Hope the info helps you in your endeavors.
 
  • Like
Reactions: o_0

    o_0

    Points: 2
    Helpful Answer Positive Rating
I tried simulating this in Proteus using the default fuses of the uC. Things are happening, but I'll have no way of knowing if this works until I actually build it and try it. See you later

---------- Post added at 01:58 ---------- Previous post was at 01:48 ----------

A clock frequency in this range can easily be generated by the use of a timer in your code with almost any system clock, therefore frequency of the µC is largely irrelevant with the proper selection of a timer prescaler value.

Thanks bigdogguru for taking the time on a thorough response, the above is what I needed to know. I'll try just leaving the uC in its default setting (internal RC 1 MHz) and see if it works.
 

Out of curiosity, why the use of a PS/2 interface. I noticed the reference to 'mouse' in the code. Seems to be a very round about way of data transmission? Why not implement a serial port? Or is this an HID, Human Interface Device, such as a glove or gaming interface. However, I sure there is a good reason for its use. I have several accelerometer interface examples floating around here somewhere. I 'll post them when I find them.

Thanks
 
Last edited:

Hi,

Yes, Serial communication is the best for you application; lot of samples, discussions can be found, and it's easy (No clock signal !!!)

However if you still proceed with that code; you must need to know Clock-source used for original design; since it was used to calculate PS/2 clock signal. Otherwise dig the code and change calculation.

Wish you success !
 

is this an HID, Human Interface Device

yup

Why not implement a serial port?

So I don't have to write a driver

I have several accelerometer interface examples floating around here somewhere. I 'll post them when I find them.

Thanks but no need. I can just search for them. Besides, if I can get this sample to work I'll be happy. It does exactly what I need, written for the ATmega32, and written in a way that I can follow. Only problem is...no schematics, but you guys have helped a lot.


you must need to know Clock-source used for original design; since it was used to calculate PS/2 clock signal

I just know that the PS/2 frequency is 12.5 kHz, which is a period of 80us, and the interrupt activates every 1/4 period. I think the clock source is Timer0 if that's what you mean. bigdogguru tells me in the above posts that the uC frequency doesn't matter. So I hope I can use the default setting which is internal RC 1 MHz.
Later
 

Ok,
PS/2 frequency 12.5 kHz must be generated by uC. Am i correct ?
That generation depends on uC clock supply.

uC clock can be selected as we like; it will be used for timers, delay-routines. Ultimately affect all uC outputs.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top