"networking" ATTiny's?

Using Arduino Microcontrollers
1

I'm planning a project that would involve a number of snap-together modules, each of which would contain an ATTiny85 and an LED driver (probably just a shift register), and later some alternate modules that do other actions. These would all be connected to each other, with the idea that commands are relayed between the modules.

My plan is to use the Arduino software and use the Arduino as an ISP through that and have verified that I can program the ATTiny's without problem.

My current question is how best to do the communication between the attiny's. Is there a good existing method of doing this (or a open-source project that does something similar)? I'm pretty sure I could write custom interconnect code (I'm a professional software engineer, I've written network protocols before) but figure there's something already out there. What would you folks recommend?

2

Distance?

Electrical or magnetic noise?

Common power supply?

3

Distance?

Probably a total of less than 6 inches

Electrical or magnetic noise?

This should be negligible.

Common power supply?

Yes

4

I would be tempted to use I2C, but I haven't used it on that chip. I2C gives you addressability, so you can send a message from one device to another one, or broadcast it.

5

Yeah, I was just starting to look at that, it does seem like some people have done I2C on the ATTiny85: http://www.arduino.cc/playground/Code/USIi2c

I'm not set on the particular chip, I just happen to have some and would rather make these as cheaply as possible for the functionality I need.

6

Edit: corrected since I had typed I2C where I meant SPI, and of course that means you can have master and slave comms. Thanks Coding Badly

Hi,

I've used simple bit-banging to do SPI on an ATtiny85 using a pair of TPIC6B595 shift registers so that part is quite achievable. Are there any examples of using SPI for master and slave in that sort of relay set-up? I'd be keen to read through one myself.

Cheers ! Geoff

7

Probably be a whole lot easier to do bit-banged SPI communications to a shift register from the left side of the processor.

8

strykeroz:
Equally wouldn't it need to switch from slave (to listen to the relay uplink) to master (to talk to the relay downlink)? Are there any examples of using I2C for master and slave in that sort of relay set-up? I'd be keen to read through one myself.

I2C is a lot smarter than that! SPI has the problem you talk of, but I2C is a true peer-to-peer, multi-master bus.

First, it's driven by open drain outputs sinking to ground. This means that any number of devices can be hooked to the outputs at the same time. This is also why pull-ups are needed -- without pull-ups, nothing puts the voltage high!

Second, because it's open-drain, if any chip wants to output a 0, a 0 will be on the bus. This is used for arbitration. If two chips happen to put data on the bus at the same time, then both of them will monitor the actual signal, and if the signal is 0 while the chip is not opening its drain, it means another master is on the bus, and that master will "win" arbitration, and the "losing" master will switch to "slave" mode and look for its own address. (If two masters want to address the same slave at the same time, arbitration will continue into the data packet!)

I use I2C for inter-board connections on my robot, and it works fine. The data rate is slow-ish (400 kHz) but for the amounts of data I'm dealing with (10-100 Hz status updates of up to 16 bytes,) I'm doing fine. I use the standard motherboard/CD-player 4-pin connector wires that came with computers a few years ago; about 12" each, connecting 4 boards and 2 additional I2C sensors. You can connect them in a star or a daisy-chain; it doesn't really matter -- a benefit of the low bit rate! I also make each board terminate the bus with 10 kOhm each, so the more boards (and thus capacitance) I add, the more current is available to drive those capacitive gate inputs. (Standard I2C pull-ups are 4.7 kOhm, so with 2 boards, I'm in spec, and with the 4 boards I have, I'm driving it hotter than spec, but in a distributed fashion)

That being said -- if you need RF networking, affordable wireless two-way connections can be made with the nRF24L01+ chip. It can run at up to 2 Mbps, and runs in the unlicensed 2.4 GHz band. Simple chip-antenna versions are about $5, and will reach several feet. Dancier, long-distance versions are $15 and reach hundreds of feet, through walls. There are some libraries out there, but I ended up writing my own.

9

jwatte:

strykeroz:
Equally wouldn't it need to switch from slave (to listen to the relay uplink) to master (to talk to the relay downlink)...

I2C is a lot smarter than that! SPI has the problem you talk of, but I2C is a true peer-to-peer, multi-master bus.

Thanks so much for this. I've re-edited my post now as it was SPI I was using...just had a brain-fade when I typed that. I'll definitely check your library for your example also.

Thanks also for your news on the range of the chip-antenna nRF24L01+ - I've bought a half dozen of those (right price, no loss) but clearly the longer range one is what I need for the application I had in mind.

Cheers ! Geoff

10

You could daisy-chain all the processors using the USI interface as is, so no bit banging, just one long shift register.

Rob

11

Are you going to use bi-directional communication, or just broadcast communication? Bi-directional uses more resources but lets you verify that the commands were recieved. Broadcast is simpler - just expect each device to have gotten its command - but you can continuously broadcast and if a device misses one cycle it will catch up on the next.

Just curious - Are you using tinys instead of other logic? Program the tiny to do a function and simplify the interfaces?

12

kf2qd:
Are you going to use bi-directional communication, or just broadcast communication? Bi-directional uses more resources but lets you verify that the commands were recieved. Broadcast is simpler - just expect each device to have gotten its command - but you can continuously broadcast and if a device misses one cycle it will catch up on the next.

I intend for it to be bi-directional. I both want acknowledgement of commands, and all nodes will also need to be able to issue commands.

kf2qd:
Just curious - Are you using tinys instead of other logic? Program the tiny to do a function and simplify the interfaces?

I'm planning to use tiny's because I'm fairly familiar with Arduino and they can be programmed in a similar manner. I have no doubts in my ability to code this project (ie I have 20+ years of programming experience) but my hardware skills aren't anywhere near the same level.

13

I have an update on I2C on Tiny's with USI.
It appears to be impossible to effectively detect the STOP condition on the bus.
This means that a Tiny slave will stay addressed potentially forever once initially addressed.
Common sample code on the web (like Don Blake's sample) may also not detect being un-addressed through a repeated start.
If you just read serial bytes as a stream, that's not a problem, but if you are using packetized transmissions, it's a real head-ache.

Using I2C with atmegas doesn't have this problem, because the TWI properly detects STOP on the bus.

14

Bit 5 – USIPF: Stop Condition Flag
When two-wire mode is selected, the USIPF Flag is set (one) when a stop condition has been detected. The flag is cleared by writing a one to this bit. Note that this is not an interrupt flag. This signal is useful when implementing two-wire bus master arbitration

...doesn't work?

15

Oh, that flag "works" as in it goes true if the STOP condition is seen on the bus.
The problem is that there is no good place to test that flag, because it doesn't generate an interrupt.
Thus, if you want to perform some action when you see STOP, after the last byte has been received, you're SOL.