Attiny10 - Single wire protocol pointers?

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR community - thanks for many previously helpful forum posts and information that have been vital to me over the years as I learn more about AVRs.

 

I'm working on a project where I want a distributed set of ATTiny10 devices that allow a more powerful master bus controller to talk to each one and take analog or digital readings from each slave. I'd like to support some basic enumeration, presence detection, etc much like Maxim/Dallas OneWire, however I have no need for protocol compatability with existing OneWire devices. I do want to try to have this protocol use only one single wire, and I'd like to assess if parasitic power is realistic. I'm targeting the attiny10 due to the small footprint and low cost. I'd want to be able sample on the order of 100 devices around 30 times a second.

 

Right now I'm thinking of a protocol like the following but curious if anyone has tweaks or suggestions. (Even better, if someone already has working code that does something like this!)

 

Wire protocol would be an open-drain bus with a 10K pullup to VCC. Master would initiate bus traffic by pulling bus low for 3X time period, where X is something like 10uS.  All slaves would measure this time period on their own timers, and use the rising edge to synchronize further communication. Maybe every X interval after the initial pulse would be considered a bit, with a HIGH being read as a zero, and a LOW read as a 1. It sounds like I can use the timer with an input capture do this. Frame end would be determined by duration.

 

Alternatively I could go with the OneWire model where the master sends short or long pulses to discriminate ones and zeros, but given than the attiny10 is fairly powerful compared to most Maxim OneWire hardware, I wonder there isn't an easier way and I can't find OneWire slave code that looks like it would fit into the Attiny10. 

 

Any advice or ideas? Are there some best practices here for how to make it more resilient?

 

I've looked at PJON, RS485, etc but I really need a super-low per-unit cost so all of those seem ruled out if I want something like $0.30/each.

 

Jeremy

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgilbert20 wrote:
Alternatively I could go with the OneWire model where the master sends short or long pulses to discriminate ones and zeros, but given than the attiny10 is fairly powerful compared to most Maxim OneWire hardware, I wonder there isn't an easier way and I can't find OneWire slave code that looks like it would fit into the Attiny10.
tiny10 is one of the AVR listed for SWI (PDF and source code) :

Microchip Technology Inc

http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en591208

Microchip

AN_274

Title:

AVR274: Single-wire Software UART on tinyAVR and megaAVR devices

Name:

AN_274

Date:

03/01/2007

Description:

This application note describes a software implementation of a single wire UART. The protocol supports half duplex communication between two devices. The only requirement is an I/O port supporting external interrupt and a timer compare interrupt.

jgilbert20 wrote:
... if I want something like $0.30/each.
Can't beat that price.

I'd recommend the tiny10 follow-on tiny102 but it's a bit more expensive.

Digi-Key appears to have a sale on tiny102.

 

http://www.microchip.com/wwwproducts/en/attiny102

http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en591368 (AT13053: Differences between ATtiny4/5/9/10 and ATtiny102/104)

https://octopart.com/search?&avg_avail=(1__*)&q=ATtiny102&start=0&sort=median_price_1000&sort-dir=asc

 

Edit : first URL

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Mon. Oct 2, 2017 - 09:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgilbert20 wrote:

...and I'd like to assess if parasitic power is realistic...open-drain bus with a 10K pullup to VCC.

 

So, a single tiny, running at 8MHz, needs around 5mA. 5mA through a 10k resistor will drop 50v. Or rather it won't because you've only got 5v to start with. ie it won't work.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sounds like you've just described normal async comms! Using different pulse widths like onewire means you always have a point of synchronisation - thus you can cope with a sizeable variation in each devices clock rate. With the technique you describe, being like normal async, means you rely on the clock rate being stable enough for the length of the byte/message. Any drift gets multiplied by the number of bits.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 parasitic power

Thinking out loud here, untested.

 

What if each Remote Device also had a germanium diode feeding a small cap, 10uF or whatever.

 

The cap would power the Tiny.

The diode would prevent the cap from being drained as Tinies pulled the line low for signaling.

 

One would need a relatively low value pull-up on the data line.

One would, perhaps want an external NFet for the pull down transistor.

 

The data throughput would determine the overall "duty cycle" on the data line, and the time the various Remotes had to charge up their cap, through the pull-up R, D, C network.

 

JC 

Last Edited: Tue. Oct 3, 2017 - 12:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From Maxim Integrated 1-Wire as an illustration :

diode charges a capacitor, NFET pull-down, buffer

https://www.maximintegrated.com/en/products/digital/one-wire.html

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Investigate Manchester encoding!  There is an Atmel App Note with code for that as well.

 

Jim

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgilbert20 wrote:
I'd want to be able sample on the order of 100 devices around 30 times a second.

So that's 3000 "samples" per second.

 

100 devices is going to need (at least) 7 address bits

 

So that's 21k bit/s just for the addresses alone; before any data - let alone any error protection or anything else ...