What protocol is this called?

Log in or register to post comments
Go To Last Post
10 posts / 0 new
Author
Message
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
#1
Posted by abcminiuser: Sun. Dec 12, 2010 - 07:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Freaks,

Working with some code today reminded me of a discussion I had with a fellow student during last semester. My friend, as part of his fourth year electronics project, was trying to create a reliable one-way link between two AVRs. One constraint was that he had only had two GPIOs available (no hardware UART).

My idea was to keep things very simple, to ensure he was able to code it without much difficulty, and to ensure that bytes weren't missed.

Of the two lines, one was data, the other clock. The Data line was controlled by the master, while the clock was controlled by the receiver (slave). When idle, both lines are pulled high.

To signal that the master wishes to send a byte to the slave, it pulls DATA low. The slave, seeing the transition when it is ready, clocks in the byte and the master idles DATA again.

Idle:

[AVR 1 - Master]            [AVR 2 - Slave]
________________            _______________
        (VCC)--|----DATA----|
               |----CLOCK---|--(VCC)

Master waiting for transmission:

[AVR 1 - Master]            [AVR 2 - Slave]
________________            _______________
        (GND)--|----DATA----|
               |----CLOCK---|--(VCC)

Sending Data

[AVR 1 - Master]            [AVR 2 - Slave]
________________            _______________
       (Data)--|----DATA----|
               |----CLOCK---|--(Clock)

This scheme worked great - the system ensures that both AVRs are ready before the data exchange takes place. Discussing things further, I came up with an extension; use the same system as before, but allow for half duplex communications in both directions. The scheme is exactly the same, except one AVR pulls its data line low, and the other AVR clocks in the data on the opposite communication line.

Idle:

     [AVR 1]                    [AVR 2]
________________            _______________
        (VCC)--|----DATA1---|
               |----DATA2---|--(VCC)

AVR 2 waiting for transmission:

     [AVR 1]                    [AVR 2]
________________            _______________
        (VCC)--|----DATA1---|
               |----DATA2---|--(GND)

Sending Data to AVR 1

     [AVR 1]                    [AVR 2]
________________            _______________
      (Clock)--|----DATA1---|
               |----DATA2---|--(Data)

AVR 1 waiting for transmission:

     [AVR 1]                    [AVR 2]
________________            _______________
        (GND)--|----DATA1---|
               |----DATA2---|--(VCC)

Sending Data to AVR 2

     [AVR 1]                    [AVR 2]
________________            _______________
       (Data)--|----DATA1---|
               |----DATA2---|--(Clock)

Now, I'm smart enough to realize that something this basic has already been invented many times before. Can someone point me in the direction of the official name for this protocol?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Tags:

Learning and Information, General Electronics
Top
leon_heller
leon_heller's picture
Level: Raving Lunatic
Joined: Fri. Jul 27, 2001
Posts: 7680 View posts
Location: St. Leonards-on-Sea (UK)
Posted by leon_heller: Sun. Dec 12, 2010 - 07:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Microchip has a synchronous serial mode for the EUSART used in most of their chips, they do that sort of stuff in hardware. Slave and master operation are supported.

Leon Heller G1HSM

Top
Jepael
Jepael's picture
Level: Raving Lunatic
Joined: Mon. May 24, 2004
Posts: 6279 View posts
Location: Tampere, Finland
Posted by Jepael: Sun. Dec 12, 2010 - 08:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds almost what PS/2 keyboards and mice use.

Two open collector lines. Clock and Data idle high. Keyboard is the clock master. PC side can pull clock low to prevent keyboard from transmitting. PC side can also pull data low to request transmission to keyboard.

Or almost what TI85 calculators use. Two open-collector lines. Both wires are bit wires like in Wiegand protocol. Listening device just listens to the wires, transmitting device pulls wire '0' low or wire '1' low to transmit a bit. Now the receiving side must acknowledge it has gotten a bit by pulling the other bit line low. Transmitting side waits for acknowledge from receiver, and lets transmitted bit line float. Receiver sees this and lets acknowledge line float again, so both wires are idle, and transmitter is free to pull a bit wire low again.

Top
jayjay1974
jayjay1974's picture
Level: Raving Lunatic
Joined: Wed. Oct 30, 2002
Posts: 5770 View posts
Location: The Netherlands
Posted by jayjay1974: Sun. Dec 12, 2010 - 09:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks much like I2C that supports clock stretching by a slow slave.

Top
ka7ehk
ka7ehk's picture
Level: 10k+ Postman
Joined: Fri. Nov 22, 2002
Posts: 20616 View posts
Location: Tangent, OR, USA
Posted by ka7ehk: Mon. Dec 13, 2010 - 08:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a 1-wire version of SPI that this sounds a lot like. Not very familiar with it though, and don't know if it still requires the select line (I suspect that it does) or that is uses actions on the data line to alert its companion (bet it does not).

I am familiar with some number of protocols but don't recognize this one. Does mot mean much, though!

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Mon. Dec 13, 2010 - 08:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks everyone for the responses. Seems like no one knows of a direct existing implementation - time to run to the patent office!

Actually, I was just thinking of writing it up as a simple library header/article/etc. for basic chip-chip communications where it is important that the bytes aren't missed (unlike UART) but also when the number of pins is constrained. At the time I thought it was a neat idea, but like all my ideas I always have them after someone else.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
ka7ehk
ka7ehk's picture
Level: 10k+ Postman
Joined: Fri. Nov 22, 2002
Posts: 20616 View posts
Location: Tangent, OR, USA
Posted by ka7ehk: Mon. Dec 13, 2010 - 10:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, I think you have hit on a pretty good idea, here. It MIGHT not be uniquely "yours" but it does solve a challenging problem.

And, would not be hard to implement in a hardware block (that is. like the TWI and SPI and USART). I do wonder if the signaling aspect could be "piggy-backed" with the synchronous function of the USART to provide a less software-intensive version when you have the hardware option to do it. For that matter. maybe it could be "married" to the SPI block without the select line (or, maybe faking select). Could the AVR SPI module "select itself" by manipulating the SS pin?

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Top
kevin_white
kevin_white's picture
Level: Hangaround
Joined: Tue. Oct 5, 2004
Posts: 178 View posts
Posted by kevin_white: Tue. Dec 14, 2010 - 01:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:

Freaks,

Working with some code today reminded me of a discussion I had with a fellow student during last semester. My friend, as part of his fourth year electronics project, was trying to create a reliable one-way link between two AVRs. One constraint was that he had only had two GPIOs available (no hardware UART).

My idea was to keep things very simple, to ensure he was able to code it without much difficulty, and to ensure that bytes weren't missed.

Of the two lines, one was data, the other clock. The Data line was controlled by the master, while the clock was controlled by the receiver (slave). When idle, both lines are pulled high.

To signal that the master wishes to send a byte to the slave, it pulls DATA low. The slave, seeing the transition when it is ready, clocks in the byte and the master idles DATA again.
<.cut...>

- Dean :twisted:[/quote

Dean,

How do you ensure synchronization during the transfer of the data? If the sending end gets busy it might miss the clocks from the receiver.

This link uses a similar technique but does bit-by-bit handshaking as well.

http://www.cappels.org/dproj/dspage/ds.htm

My old Visioneer sheet feed scanner used a similar technique with the modem control lines on the serial port to achieve faster than normal bit-rates form PC serial ports.

kevin

Top
Jepael
Jepael's picture
Level: Raving Lunatic
Joined: Mon. May 24, 2004
Posts: 6279 View posts
Location: Tampere, Finland
Posted by Jepael: Tue. Dec 14, 2010 - 07:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, that starts to look like 1-wire protocol but with two wires.

Also CEC that is used in HDMI uses just one open-collector wire for communication, multi-master, collision detection and signaling, acknowledge..

So I guess 1 wire is enough if both ends have perhaps a timer interrupt for oversampling and transmission. Otherwise 2 wires is enough.

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Tue. Dec 14, 2010 - 12:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

How do you ensure synchronization during the transfer of the data? If the sending end gets busy it might miss the clocks from the receiver.

Remember, this was something I came up with for my friend, who was just starting out with microcontrollers - so I based in on the assumption that one synchronized, the sender loops waiting for the clock to ensure it doesn't miss any bits. It works great so long as you don't need to perform other actions during the transfer.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top