Searching \ for '(2 micros comm)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=micros+comm
Search entire site for: '(2 micros comm)'.

Truncated match.
PICList Thread
'(2 micros comm)'
1999\02\19@114956 by Marc

flavicon
face
> I want to have a central micro running as a "supervisor" and a second micro
> implementing a remote keypad and LCD display.  I was looking towards I2C,
> but because of the remote micro's limited use, the low-end PICs do not
> implement I2C in hardware (so a software solution would be necessary).
> Does anyone have experience with this type of application?  Could you give
> me some advice/battle scars?  What is the "best" way to interface the two?

I2C is very time consuming for the slave (unless it supports it in hardware).

The probably easiest solution to your problem is a small self-made comm:

Create a CLOCK, and a DATA line. The CLOCK can be push-pull and is controlled
by the master (central micro). The DATA line is opencollector with pullup
and 5V on idle.

When the master wants to transfer data, it can pull DATA low for some time,
ie 20us. Choose a value that is long enough to notice in the slave even with
worst case interrupts.

Then a command byte could be clocked on CLOCK/DATA like with other serial
protocols. The command byte contains information on what type of data
is transferred now, and in what direction.

When the slave has new data and wants to notify the master of that (ie
the user pushed a button, and the master is in powersave mode), it can
do that by pulling DATA low itself. The master has then unlimited time to
notice that and initiate a transfer to find out what new information
is available. (no collision will arise because of the OC wire, and
transfer indication with CLOCKs generated by the master)

That's most easy and CPU/power saving for your purpose I think.

1999\02\19@132605 by Vincent Deno

flavicon
face
On Fri, 19 Feb 1999, Marc wrote:

{Quote hidden}

I have never used, but do believe that the 16C74 has special hardware for
doing exactly what you are talking about (Parallel slave port).

-Vincent Deno

1999\02\19@134235 by Gerhard Fiedler

picon face
At 15:29 02/19/99 +0100, Marc wrote:
>> I want to have a central micro running as a "supervisor" and a second micro
>> implementing a remote keypad and LCD display.  I was looking towards I2C,
>> but because of the remote micro's limited use, the low-end PICs do not
>> implement I2C in hardware (so a software solution would be necessary).
>> Does anyone have experience with this type of application?  Could you give
>> me some advice/battle scars?  What is the "best" way to interface the two?
>
>I2C is very time consuming for the slave (unless it supports it in hardware).

not necessarily -- depends a lot on the traffic on the bus for other
slaves. you don't necessarily have to react to every request immediately;
if you don't, the master knows that because you didn't send the ack and can
repeat it. you can put an interrupt on the low state or high-to-low
transition of SDA in the slave, so you only go there to check when actually
something's happening. and if your interrupt latency is too big, your
master can send out a start byte first, which gives you usually enough time
to be ready (or extends the time between checks of the SDA line to 5 bit
times if you don't have an interrupt to spare).

so the only real time consuming action on a slave is decoding addresses of
messages for other slaves, which is not an i2c-related problem, since you
have it on every serial bus with multiple slaves. or do i miss something here?

ge

1999\02\20@092711 by Adriano De Minicis

flavicon
face
Marc wrote:

> The probably easiest solution to your problem is a small self-made comm:
>
> Create a CLOCK, and a DATA line. The CLOCK can be push-pull and is controlled
> by the master (central micro). The DATA line is opencollector with pullup
> and 5V on idle.
>
> When the master wants to transfer data, it can pull DATA low for some time,
> ie 20us. Choose a value that is long enough to notice in the slave even with
> worst case interrupts.

To avoid this fixed delay, and allow the slave to respond when it
is ready, I suggest a slightly different approach:

CLOCK and DATA are both open collector, with a pullup resistor.
The default (idle) state is CLOCK low (forced low by the master)
and DATA high. CLOCK pulses are generated by the master and can
be stopped by the slave forcing the CLOCK line low (to signal that
the slave is busy). The DATA line is latched by the reading end
during the falling edge of the CLOCK line.

When the master wants to transfer data, it pulls up (tristates) the
CLOCK line, and waits for the CLOCK line to be high before proceeding
with the transfer. This allows for two things: the slow rising edge
of the CLOCK line (due to R/C effects), and the slave busy-signal.
The slave knows that the master wants to talk when it sees the CLOCK
line high (it could trigger an IRQ). When the slave is busy it simply
forces low the CLOCK line low.

When the slave wants to transfer data, it forces low the DATA line.
When the master notices this, it begins clocking by pulling up the
CLOCK line. When the slave sees the CLOCK high, it releases the
DATA low, and the transfer begins.

Adriano

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...