PIC/AVR serial modes

On Thu, 18 Dec 2008 12:51:13 +0000 (UTC), valwn@silvtrc.org wrote:

>>> That work for open collector or RS485 bus too..?
>
>>Of course. The SPI output is just a serial output, just like the UART TX
>>output. You can add anything to that port, an open collector stage, a
>>MAX485, anything.
>
>SPI has three signal lines. My bus is only 1-bit "wide" (open collector).
>So somehow clock + data must be joined.

If you want to encode clock information in your data stream you have
to do it before writing it to the SPI register. SPI is basically a
parallel in serial out register on the transmit side, and a serial in
parallel out register on the receive side. If you keep loading 0x55
into the SPI DATA register you will get a clock signal of 1/2 the
SPI clock on the MOSI pin. Keep loading 0x0F, and you will get a clock
at 1/8 of the SPI clock on the MOSI pin.

Regards
  Anton Erasmus

<valwn@silvtrc.org> wrote in message news:gidh00$dmb$1@news.ett.com.ua...
> >> That work for open collector or RS485 bus too..?
>
> >Of course. The SPI output is just a serial output, just like the UART TX
> >output. You can add anything to that port, an open collector stage, a
> >MAX485, anything.
>
> SPI has three signal lines. My bus is only 1-bit "wide" (open collector).
> So somehow clock + data must be joined.

IIRC you wanted to create a serial signal without the boundaries of start
and stopbits or a predefined word length. For that, you only need the SPI
output (MOSI). You don't need to join clock and data. Or it must be that you
want to do something more than you asked us...

Meindert

>If you want to encode clock information in your data stream you have
>to do it before writing it to the SPI register. SPI is basically a
>parallel in serial out register on the transmit side, and a serial in
>parallel out register on the receive side. If you keep loading 0x55
>into the SPI DATA register you will get a clock signal of 1/2 the
>SPI clock on the MOSI pin. Keep loading 0x0F, and you will get a clock
>at 1/8 of the SPI clock on the MOSI pin.

Now that's an idea. However there will be a problem to recover the clock
on the receiving side.

On Thu, 18 Dec 2008 13:49:54 +0000 (UTC), valwn@silvtrc.org wrote:

>>If you want to encode clock information in your data stream you have
>>to do it before writing it to the SPI register. SPI is basically a
>>parallel in serial out register on the transmit side, and a serial in
>>parallel out register on the receive side. If you keep loading 0x55
>>into the SPI DATA register you will get a clock signal of 1/2 the
>>SPI clock on the MOSI pin. Keep loading 0x0F, and you will get a clock
>>at 1/8 of the SPI clock on the MOSI pin.
>
>Now that's an idea. However there will be a problem to recover the clock
>on the receiving side.

If you use something like manchester encoding on your trasnmit side,
you are guaranteed an edge at least every second bit. On your Rx side
you can use a Phased Locked Loop to align a local clock with your data
stream clock.

Regards
  Anton Erasmus

>If you use something like manchester encoding on your trasnmit side,
>you are guaranteed an edge at least every second bit. On your Rx side
>you can use a Phased Locked Loop to align a local clock with your data
>stream clock.

Can this PLL be accomplished without external components ..?

On Sat, 20 Dec 2008 18:31:32 +0000 (UTC), valwn@silvtrc.org wrote:

>>If you use something like manchester encoding on your trasnmit side,
>>you are guaranteed an edge at least every second bit. On your Rx side
>>you can use a Phased Locked Loop to align a local clock with your data
>>stream clock.
>
>Can this PLL be accomplished without external components ..?

Depends on your data rate. In principle it is possible. 
You may also be able to decode using an edge triggerred interrupt
on a GPIO pin. A negative edge is a 0 and a positive edge is a 1.


Regards
  Anton Erasmus

On Dec 18, 2:52=A0pm, Anton Erasmus <nob...@spam.prevent.net> wrote:

> If you use something like manchester encoding on your trasnmit side,
> you are guaranteed an edge at least every second bit. On your Rx side

What? By definition, Manchester encoding has an edge *every* bit at
the centerpoint, where the direction of the edge indicates the data
bit being encoded.

On Dec 21, 12:28=A0am, larwe <zwsdot...@gmail.com> wrote:
> On Dec 18, 2:52=A0pm, Anton Erasmus <nob...@spam.prevent.net> wrote:
>
> > If you use something like manchester encoding on your trasnmit side,
> > you are guaranteed an edge at least every second bit. On your Rx side
>
> What? By definition, Manchester encoding has an edge *every* bit at
> the centerpoint, where the direction of the edge indicates the data
> bit being encoded.

I prefer the variant where there is a transition at the start of every
bit and another transition in the center if the bit is a 1. I think it
is called 'Biphase-S' (of FM). It has the benefit that it is
insensitive to the polarity of the signal and very easy to sync to the
start of a bit.

What Anton may have been referring to is MFM as used on disk
controllers.
http://www.storagereview.com/guide2000/ref/hdd/geom/dataMFM.html

On Sat, 20 Dec 2008 14:28:31 -0800 (PST), larwe <zwsdotcom@gmail.com>
wrote:

>On Dec 18, 2:52&#4294967295;pm, Anton Erasmus <nob...@spam.prevent.net> wrote:
>
>> If you use something like manchester encoding on your trasnmit side,
>> you are guaranteed an edge at least every second bit. On your Rx side
>
>What? By definition, Manchester encoding has an edge *every* bit at
>the centerpoint, where the direction of the edge indicates the data
>bit being encoded.

You are correct. I meant compared to the original clock, the
manchester data stream has an positive edge at least every second 
clock period.

Regards
  Anton Erasmus