Prev: Request for help in neew development with AO, DIO, counters and real time
Next: (AT91SAM9260) Where to buy Schukat parts in Italy?
From: Grant Edwards on 29 Apr 2010 08:57
On 2010-04-29, Leo Havm?ller <rtxleh(a)nospam.nospam> wrote:
>> Errmm... in my opinion, "standard serial" is mostly asynchronous.
> Then im probably using the wrong term.
> A serial port is locked to a baudrate => a fixed clock is needed to derive
> the baudrate.
> E.g. for a 2-wire I2C interface the clock is provided by the master i.e. the
> slave does not need a fixed clock to drive or sample the I/O pin.
>
>>> - The slave has no clock with a fixed frequency that can be used => the
>>> interface must be asyncronous.
>>
>> Does the slave have a clock at all?
> Yes, it even has a crystal ;-)
> Due to power saving the clocks are changed up and down all the time => no
> fixed clock is available.

What you want is usually called "self clocking".

In the world of serial communications, asynchronous means something
else.

--
Grant Edwards grant.b.edwards Yow! ... this must be what
at it's like to be a COLLEGE
gmail.com GRADUATE!!
From: 1 Lucky Texan on 29 Apr 2010 09:01
On Apr 28, 11:48 pm, Leo Havmøller <rtx...(a)nospam.nospam> wrote:
> Hi,
>
> Im looking for a short-range (20 cm) 1-wire I/O interface that is fully
> asyncronous.
> Does such a thing exist?
>
> Leo Havmøller.

OK, I'll ask...why 1 wire?

Could it be optical?
From: D Yuniskis on 29 Apr 2010 11:23
Hi Leo,

Leo Havm�ller wrote:
> Hi,
>
> Im looking for a short-range (20 cm) 1-wire I/O interface that is fully
> asyncronous.
> Does such a thing exist?

How fast does it have to be? Does it have to be a *hardware*
device (i.e., you can do this relatively easily if you bang bits)
From: Rob Gaddi on 29 Apr 2010 11:59
On 4/29/2010 1:39 AM, Leo Havm�ller wrote:
>> Errmm... in my opinion, "standard serial" is mostly asynchronous.
> Then im probably using the wrong term.
> A serial port is locked to a baudrate => a fixed clock is needed to
> derive the baudrate.
> E.g. for a 2-wire I2C interface the clock is provided by the master i.e.
> the slave does not need a fixed clock to drive or sample the I/O pin.
>
>>> - The slave has no clock with a fixed frequency that can be used => the
>>> interface must be asyncronous.
>>
>> Does the slave have a clock at all?
> Yes, it even has a crystal ;-)
> Due to power saving the clocks are changed up and down all the time =>
> no fixed clock is available.
>
> Leo Havm�ller.
>
>
>

Then use standard 1-wire, but in the receive direction implement an
external timer using an HC123 one-shot, with the delay set to split the
difference (harmonic mean) between a '0' and a '1'. Have the rising
edge of the data fire the one-shot.

If you've got edge sensitive interrupts, put a 1G74 tinylogic flip-flop
downstream, and use it to latch the 1-wire data line on the termination
of the one-shot. Also use the termination of the one-shot to fire an
interrupt.

If you've got level sensitive interrupts instead, put an HC74 downstream
of it, clock both flops with the termination of the one-shot. One flop
latches the data, the other latches a constant '1'. Use the constant
'1' to drive an interrupt pin, and have the ISR blip the reset line for
that flop.

That takes care of the receive direction. In the transmit you'll need
both halves of another HC123, with its time constants set to the '0' and
'1' bit periods respectively. Drive each from a dedicated port pin; one
to represent the zero, and one to represent the one. Combine the
outputs with either an OR gate or a diode OR into a tristate buffer,
which you control from yet another port pin.

In other words, how certain are you that you require your requirements
as stated?

--
Rob Gaddi, Highland Technology
Email address is currently out of order
From: robertwessel2 on 29 Apr 2010 19:25
On Apr 29, 3:39 am, Leo Havmøller <rtx...(a)nospam.nospam> wrote:
> > Errmm... in my opinion, "standard serial" is mostly asynchronous.
>
> Then im probably using the wrong term.
> A serial port is locked to a baudrate => a fixed clock is needed to derive
> the baudrate.
> E.g. for a 2-wire I2C interface the clock is provided by the master i.e. the
> slave does not need a fixed clock to drive or sample the I/O pin.
>
> >> - The slave has no clock with a fixed frequency that can be used => the
> >> interface must be asyncronous.
>
> > Does the slave have a clock at all?
>
> Yes, it even has a crystal ;-)
> Due to power saving the clocks are changed up and down all the time => no
> fixed clock is available.


How much do they vary? So long as the clocks are stable enough to
keep the actual baud rate within 2% of the nominal baud rate (assuming
a typical async serial port), you're OK. Something like Manchester
encoding lets you have something like 20% slop. If your clocks are
worse than that, you'll need a more complex modulation scheme. For
example, a three level transmission scheme where the extra level is
used to represent the "clock" between any pair of bits (which use the
other two states).

Another possibility is that if the *rate* of change in the clock rates
is gentle enough, you could probably have one side adapt to the drift
be ensuring that enough clock data is transmitted. Or if the drift
within a message can be limited, having the receiver adapt to a clock
sync signal transmitted at the beginning of each message would do the
trick.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Request for help in neew development with AO, DIO, counters and real time
Next: (AT91SAM9260) Where to buy Schukat parts in Italy?