Asyncronous 1-wire interface?

How fast does it need to be? Does it need to be bidirectional? Have you looked at 1-wire? Even standard serial can be used if the two ends coordinate who's transmitting and who's receiving. A small resistor between them protects against both sides transmitting at the same time.

The master will probably clock it between 1-10MHz.

Yes.

Yes, its syncronous => no good.

Also syncronous.

Yes.

Some further information:

- The master always controls what happens on the "bus".

- The slave has no clock with a fixed frequency that can be used => the interface must be asyncronous.

- An equivalent interface with 2 wires would be e.g. I2C i.e. 1 wire for clock, 1 wire for I/O.

Leo Havmøller.

Two standard async UARTS, all TX and RX signals harwire-orred together with a pull-up.

Errmm... in my opinion, "standard serial" is mostly asynchronous.

Does the slave have a clock at all?

Meindert

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.

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.

A better term would be variable frequency/baudrate I guess. But that is easiest to achieve with synchronous communication. The clock provides a reference of when to sample the data. But that requires at least 2 wires, like I2C. ;-)

So the clock can change even in the middle of a transmission? I'm not sure there is a way to make asynchronous communication work reliably under those conditions. Maybe you can make it work with things like manchester encoding, but certainly not with standard peripherals.

If there is a way to guarantee a fixed frequency during a complete transmission, it might be easier to get it working. But that also requires the receiving side to fix frequency as soon as the first edge of a start bit is detected.

no

Can you assume that the clock will not change during a message? Because if so, the problem is quite easy - it's exactly the same problem as transmitting simple AM radio messages.

asyncronous.

This transfers data from the module to the PC at 1Mbps and is pretty robust.

Nial.

"Nial Stewart" wrote in message news: snipped-for-privacy@mid.individual.net...

Also locked to a specific baudrate, so does not fit the requirements.

Leo Havmøller.

Huh? "Standard serial" (e.g. UART w/ RS-232 driver) is asynchronous,

What you want is usually called "self clocking".

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

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

Could it be optical?

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)

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?

ive

the

the

no

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.

On Apr 29, 8:39=A0pm, Leo Havm=F8ller >

no

We still do not know the baud rate, message sizes and average data rates you are looking for.

If you have just one wire, you have the time-domain, and the voltage domain to chose from.

Most systems use the time-domain, because that is simplest, and many systems are clock tolerant. Some schemes can work with nothing more complex than a monostable - a RC element.

Just how power/energy paranoid is this application, and how much power does that crystal you have consume ?

If you have a crystal, is it running all the time ?

-jg

You could try DQ or HDQ. It still needs a stable clock the data is transmitted in the pulse width.

"Leo Havmøller" skrev i meddelelsen news:hrb32b$tm1$ snipped-for-privacy@speranza.aioe.org...

By pure coincidence, an unrelated event led med to a brand new IEEE standard for the interface needed. It is using 2 wires (1 clock and 1 I/O). The chip vendor has accepted that this is the way to go. Case closed.

Leo Havmøller.

Cost. As a rule of thumb, each pin on a chip is 1 cent.

Leo Havmøller.

Could you write which IEEE standard you'll use? There are many two-wire protocols, a standard would be useful when I need it.

This sounds like you are creating a chip. You wrote that the clock of the chip can change, but I'm sure that the chip has some stable internal clock reference, or at least within the chip you know the current clock frequency, so you can derive a stable clock for a simple UART.