I need to create a serial data stream.....

Hello,

I need to create a serial data stream for a work project. This is a single wire serial data stream where the clock and data are combined into a single wire. Clock is extracted from the leading edge of the data pulses and runs between 550 kHz and 150 kHz. Data is the width of the pulse. A pulse width of 250nSec is considered a 0 and a 750nSec is considered a 1.

Data is sent a byte (8 bits) at a time in a continuous stream consisting of a stop byte, start byte, data byte, and another stop byte. Each byte has a 9th bit which is an even parity bit. The data byte has each bit dedicated to a specific on-off function and I need the ability to change them on the fly.

I'm trying to find out if an Arduino is even able to meet these timing and data requirements or if a shield is available that can do this function.

Thanks!

-John C.

Almost certainly no shield.
Timing is not possible, even with interrupts, as a 250 ns pulse is just 4 processor cycles on a 16 MHz processor, and the reaction time on the incoming clock pulse is almost that long. A faster processor such as the ESP8266 (80 MHz clock) would be able to handle this, an even faster one such as the ESP32 or Teensy would easily handle this short pulses and have quite some time left for other things. The 750 ns pulse for a 1 would be possible.

At 550 kHz every bit takes about 1800 ns, no problem there. If you could change the parameters to say 750 ns for a 0 and 1500 ns for a 1, I think it may work. You’re still pushing the limits and the processor can’t do much else, especially if your incoming clock is at 550 kHz.

A piece of code like this I assume is in the form of a library, which takes the data to be sent as input, and puts it on the wire.

So I hope I understand your protocol correctly:

  • you have a clock pulse that is connected to an input, and which gives the start of the pulse.
  • the wire is idle LOW (if idle HIGH that’d be a simple reversal); driven HIGH/LOW (if like I2C it’s to be open collector that again can be done by a simple change in the code).
  • the moment a clock pulse comes in a bit is sent: 250 ns HIGH for a 0, 750 ns HIGH for a 1.
  • 9 bits per byte including parity, no start/stop bits.

What you have to define:

  • what’s the source of the data, and how would this be supplied to this library? As said the device can’t do too much else!
  • how to handle the situation of an incoming clock but no data? Simply not sending out anything? A missing pulse may be useful to synchronise the receiver.

Thanks very much for your insight into this issue, its very helpful!

I actually found a good way to do it: I'm using an arbitrary waveform generator to statically generate different bit patterns. Its more than fast enough and has plenty of memory for the waveform. It also has a PC GUI to design the waveforms and save them to files. Win-Win-Win.

I am confused by your description. How would you tell the difference between THREE zero sent one after the other and a single 1 sent? They are the same time value.

Paul

The bit starts when a clock pulse arrives, the next bit is at the next clock pulse. No problem to distinguish between bits as a 0 is much shorter than a 1: check the line 500 ns after the clock pulse and if it is a 0 the line is low already, if it is a 1 the line is still high.
More efficient though would be to have a 1 to be high for the full clock cycle, a 0 low for the full clock cycle, and have the receiving end check the line halfway the clock.

wvmarle:
The bit starts when a clock pulse arrives, the next bit is at the next clock pulse. No problem to distinguish between bits as a 0 is much shorter than a 1: check the line 500 ns after the clock pulse and if it is a 0 the line is low already, if it is a 1 the line is still high.
More efficient though would be to have a 1 to be high for the full clock cycle, a 0 low for the full clock cycle, and have the receiving end check the line halfway the clock.

Exactly how the OLD USART did it, but synced a PLL clock at the beginning of a transmission.

Paul