Interconnecting multiple AVRs

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

Hello guys ,

So I'm going to be making a project where I will be using multiple AVR micros ( 4-20) and I need them to be able to talk with each other .

I Haven't got the chance to use any of the AVR communication peripherals since i'm new to Micros.
I know from reading the datasheet that My atmega32 has 3 of those : The USART , SPI (serial peripheral interface ) and the TWI (also known as I2C?? )

Could someone explain the diffrence between them and what each one is good for?
I can see that they all allow for inter-avr communication.
Could someone suggest the most simple to learn/use of those peripherals that I can learn and use to control my swarm of AVR? They will need to be able to communicate very basic information . Perhaps pass on an 8 bit array of values and some other simple stuff, nothing hardcore for now.

Normally what I'd do is learn all of them , but in this case time is an issue. I need to learn to use at least one of these peripherals in the next week

Anyone know some good tutorials that I can refer to ?
I did some reading in the datasheet on the TWI and it doesn't look too complicated , should I go with it?

Thanks in advance!

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

Shagas wrote:
Hello guys ,

So I'm going to be making a project where I will be using multiple AVR micros ( 4-20) and I need them to be able to talk with each other .

I Haven't got the chance to use any of the AVR communication peripherals since i'm new to Micros.
I know from reading the datasheet that My atmega32 has 3 of those : The USART , SPI (serial peripheral interface ) and the TWI (also known as I2C?? )

Could someone explain the diffrence between them and what each one is good for?
I can see that they all allow for inter-avr communication.
Could someone suggest the most simple to learn/use of those peripherals that I can learn and use to control my swarm of AVR? They will need to be able to communicate very basic information . Perhaps pass on an 8 bit array of values and some other simple stuff, nothing hardcore for now.

Normally what I'd do is learn all of them , but in this case time is an issue. I need to learn to use at least one of these peripherals in the next week. I study 6-8 hours a day.

Anyone know some good tutorials that I can refer to ?
I did some reading in the datasheet on the TWI and it doesn't look too complicated , should I go with it?

Thanks in advance!

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

Quote:

since i'm new to Micros.

And you are trying to connect 4..20 devices? This should be interesting! (it is almost always easier to use one large micro than many small ones if they are all on the same board).

Your first question is how far apart the 4..20 micros are going to be. If all on the same PCB then SPI is easiest (but most wires), TWI is next easiest and UART is not really appropriate unless you are going to use 9bit addressing mode and RS485 so widely separated micros.

As I say SPI is easiest but you need one "slave select" to each slave device so the master can say which of the other 19 it is trying to talk to at any one time (only one slave should be selected at once).

TWI is more of a "floating bus" so all devices can listen to the traffic and just respond to data addressed to them - so there's no need for separate selects but the protocol and electronics are a little more complex.

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

Well the first project is going to have 5 same micros. They will all be performing more or less the same function .
They will be about 15-25 cm apart physically.
The project that I'm making is Multiple-Multiple channel pwm .
I've finally managed to make a program that can support 8 (maybe 16 if I optimize the code) channels of software PWM.
I need to controll 40-100 Leds all with independant PWM so that's why I was thinking of dedicating 1 avr to 8 or 16 leds (or a number in between) and having them communicate with each other .

I'm sorry Clawson , I did not fully understand which peripheral I should use from your answer :)
So if I use SPI , I'll need a master AVR which can controll all the other slaves ? I think that would be a good idea .
By the way , why does the distance matter ?
The TWI transmitts at 100-400khz so there shouldn't be any stray inductance/ interference problems no?

EDIT:

Also , now that I read your answer for the 4th time I realised that I don't need intercommunication , I need a master and many slaves :) . The slaves opinion on things doesn't matter . Just the master will be sending out 8-16 bit arrays and the slaves will be doing the work with no feedback.

So based on that , what do you reccomend?
Thanks for your reply

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

Note that both SPI and TWI have master and slave modes which is great if you have one AVR controlling all the others. If you want all of them to be equal, then this could be a problem. So you should also tell us what topology you need. Typical ones are Star (one master node at the "center" and many slaves nodes at the points), Ring (each node connects to only two others, one in front and the other behind), and fully connected (every node connected to every other). For the ring topology you can use USART.

Edit: Look here for an explanation of topologies.

Regards,
Steve A.

The Board helps those that help themselves.

Last Edited: Wed. Aug 21, 2013 - 02:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Distance is rather critical. Capacitance/inductance, stray coupling, interference and ground bounce are real problems. Twi/i2c and spi are fine for interconnect on the one board. Across multiple boards you need to be careful.

If you want to control large numbers of leds, there are specific chips for that.

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

Thanks for the replies .

So:

Cartman you meantioned specific chips for controlling multiple leds . Could you mention any specific ones ?
You don't mean serial shift registers do you?

Koshchi:

Well the topology that I was thinking about is that a master would send traffic out on a bus and the slaves would all be sitting on that bus. A master sends out an adress packet to adress a specific slave and then it will send out a data packet, in this case an 8 bit array of data. And this cycle would repeat constantly .

I just checked my local shop and I'm thinking about the ATTINY4313-PU,. I can get 10 of them for abit over 12 Euros , but it only has USI and Full duplex USART. Would USI or USART be a viable choice for what I need ?

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

Quote:

I've finally managed to make a program that can support 8 (maybe 16 if I optimize the code) channels of software PWM.

There are projects that show how you can basically do as many soft PWM as there are IO pins on a micro. So a 100 pin AVR might be all you require - perhaps two. For something as sluggish as LED dimming (humans don't care because of POV) then you don't need dramatic update rates.

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

Hmm from your topology link I can see the following potentially viable choices:

Line (since the data can be sent to the slaves in the same order )

Star

Bus

As I mentioned , the data will be sent at regular intervals and in the same order to all 10 (or however many micros i'm going to be using ) at a certain refresh rate (100 hz perhaps)
so perhaps Line is a good choice? Or the bus?

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

clawson wrote:
Quote:

I've finally managed to make a program that can support 8 (maybe 16 if I optimize the code) channels of software PWM.

There are projects that show how you can basically do as many soft PWM as there are IO pins on a micro. So a 100 pin AVR might be all you require - perhaps two. For something as sluggish as LED dimming (humans don't care because of POV) then you don't need dramatic update rates.

Could you introduce me to such a project?
My current software pwm program has a refresh rate of 60hz which seems to be working fine with no flicker .

Edit : I found an ATmega128L-8AU which has 53 IO
so I guess one or two of them would be a good start.
I can try to see if my code will support more io pins but i'm not very confident with it :/ + I don't know/can't find tutorials on how to do simulation in AVR studio so I can't know how many clock cycles a certain routine will take which makes it very difficult for me to determine anything . Any help with that? Or if you can point me to a ready made project then I can take some ideas out of that .

Thanks in advance.
Tim

Last Edited: Wed. Aug 21, 2013 - 03:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TI have led drivers with pwm methinks. They're normally accessed as serial shift registers.

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

Hmm so with this
http://www.ti.com/lit/ds/symlink...
I can independently controll each pwm channel if I understand it correctly ..Also it says a maximum of 30ma . Is that per channel or total? I'm guessing total . Each led will have to have it's own transistor anyway no matter how I do it

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

So if I was going to go with the multiple microcontroller solution , would the USI be a viable choice for communication?

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

Shagas wrote:
I need to controll 40-100 Leds all with independant PWM so that's why I was thinking of dedicating 1 avr to 8 or 16 leds (or a number in between) and having them communicate with each other .
Recently updated was
Atmel AT01244: DALI Slave Reference Design
"This application shows DALI slave LED module function that compliant with standard IEC62386.
Stack is in common->services folder, drivers in mega->drivers, and others are application.
The slave should be controlled by master."
mega88PA, DALI interface, Atmel LED driver.
Shagas wrote:
Just the master will be sending out 8-16 bit arrays and the slaves will be doing the work with no feedback.
No feedback - consider failures at the slaves: power supply, LEDs, LED drivers.

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

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

Thanks for the link . I'll check it out now .

This is a decoration project so if an led driver / power supply fails it won't be catastrophic ..

Thanks for the input !

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

Also , I want to mention that I can have the Avr's right near each other will minimal distance so that is not going to be an issue

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

The output current is 30mA max per output - it would be next to useless otherwise.

Do not discount signal integrity issues. If you use flat cable have the odd numbered wires tied to 0V to avoid crosstalk.

USI is the budget version of a usart. Avoid if possible. Using the TI drivers you only need one micro.

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

Excuse me, but did you decide whether your slaves and your master should be the same processor? (ex : your slaves could be a 4313 and your master ... an atmega 328, having more storage -> more sophisticated animations?)

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

Quote:
Do not discount signal integrity issues. If you use flat cable have the odd numbered wires tied to 0V to avoid crosstalk.

Not sure I understand what you mean there .
I'm planning to have everything on a single PCB , the only wires will be power wires which will be feeding the LED's which will be on separate PCBS.

Also I would need to use at least 2 of these drivers so I will need at least 2 slave micros and 1 slave or something like that so they need to be able to interchange info .
If I have only two micros then I can get more expensive ones with other communication peripherals.
So which peripheral do you suggest I use?
You say USI is budget USART , but the ATTINY4313-PU has USART , so can I use that ?
I'm sorry if it sounds stupid but I can't find a source which explains the diffrence between these communication peripherals , that's why I'm asking .

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

You can daisy chain the ti drivers. You would only need one micro then. You would use spi to talk to the ti chips and the usart to talk to a pc.

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

dbrion0606 wrote:
Excuse me, but did you decide whether your slaves and your master should be the same processor? (ex : your slaves could be a 4313 and your master ... an atmega 328, having more storage -> more sophisticated animations?)

Yes thats what i've been saying , that I can choose a more sophisticated master like an atmega 328 , but the slaves have to be cheaper since there are going to be more than 4 of them .

So my question was and remains : What communication peripheral should I use?

The ATTINY4313-PU which is a good choice (economically) for the slave micros has only USART and USI .

Could I use that with the master avr considering a bus or star topology ?

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

Kartman wrote:
You can daisy chain the ti drivers. You would only need one micro then. You would use spi to talk to the ti chips and the usart to talk to a pc.

Great!!
so just to clarify:

Suppose I went with the option of using these drivers:
I can daisy chain these drivers and I can controll the PWM of EACH channel independantly right?

Also , does USART requires some max 232 chip to raise voltages if I'm going to communicate with a pc ?
Which port in the pc would I be using ?
Is communication with usart possible through USB?

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

According to the ti datasheet- yes. What port on the PC? The serial port. The new PCs usually wont have one. So there's usb - get a usb->serial adapter or get an Arduino and a number of your problems are immediately solved. Google arduino tlc5947

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

Okay thanks alot Kartman .
I'm probably not going to implement communication with the PC and just going to leave it at a few simple animation programs inside the avr .

But just in case I do consider it I just need to get a usb to serial adapter like this ?

http://www.amazon.com/TRENDnet-R...

I'm assuming that the cable has a chip inside which makes the magic happen

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

So I decided to go with these TLC5947 drivers :

http://www.ti.com/lit/ds/symlink...

I'm going to be using some Atmega as the controller .
So which communication protocol should I use to talk with these drivers? The simplest and easiest is preferable .

Or should I just use a timer/counter and communicate manually using i/o pins?

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

Well,tlc5947 seems 2 times more expensive than a Xal-less 4313 (and 4313 candrive LEDs, but maybe with low current : each pin can support up to 20 mA but the summ of the currents should not go beyond 60 mA)... If price were not important, tlc would be ideal, here, I do not see (if you need extra transistor for your LEDs, exact economical computations would be interesting)...

4313 can be a SPI slave kind of a star , with extra wires to select which slave- http://www.atmel.com/images/doc8... page 160, but "only" as USI -more complicated-; if you want to use TWI kind of a bus (more complicated than SPI), you have to use USI, too...

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

Quote:
I just need to get a usb to serial adapter like this ?

NO : it is a RS232 (+ca 10V, -ca 10V) to USB adapter, nor a TTL (0/5v -some can be 0/3v, switchable-) to usb adapter... I bet and hope you can find cheaper ones....
If you buy an Arduino UNO, you have an USB <-> adapter into your board (and Xal is already soldered, power supply is decoupled and soldered....)

According to http://www.adafruit.com/products..., tlc5497 -very difficult to solder if alone- uses SPI and has a Arduino library -which uses bit banging instead of HW SPI-...

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

4313 will drive only 8leds at less than 10 ma which is inadequate .

I think I'm going to go with a solution of one micro and 2 TI 24 channel driver chips .

Yes I saw that link from adafruit . Why do you think it's going to be difficult to solder? :)
I have some experience with smd soldering .

Thanks for the info :)

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

I am terrified with SMD (and my old eyes shead lots of tears at the very idea).
The main issue I see with their library is they use bit banging, with Arduino way of denoting pins : this is very flexible, easy to read -and maybe to adapt- , but eats a lot of cycles -it your Arduino/328 has nothing else to do... why not?)

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

dbrion0606 wrote:
I am terrified with SMD (and my old eyes shead lots of tears at the very idea).
The main issue I see with their library is they use bit banging, with Arduino way of denoting pins : this is very flexible, easy to read -and maybe to adapt- , but eats a lot of cycles -it your Arduino/328 has nothing else to do... why not?)

Heh :)
What library do you mean ? the TLC5947 ?
By the way I don't use an arduino , I just use discrete avr chips .
I'm planning to get the PSOP package of TLC5947 , not the quad flatpack.

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

I'd suggest you look at using an arduino or arduino like board or even a model of avr that is supported by arduino. In terms of an arduino board, the issue of usb to serial, bootloader and a known stable platform will avoid a number of potential problems. It means you don't start from ground zero. If anything, use it to start prototyping. If you use a mega328,1280 or 2560 you gain the benefit of being able to use the arduino infrastructure if you so choose. Realise the arduino is just an avr chip, popped onto a pcb with the bare minumum support hardware to get you going. The arduino software is simple a layer ontop of the gcc compiler and avrdude to program the device along with numerous libraries to do useful things. The whole thing is open source so there is no hidden magic - you can look at the source code and change it if you so desire. Arduino code is C/C++ but with it's use of libraries, the evil is cloaked. If you don't want to do things the arduino way, you just write your code to avoid using the specific libraries.

For me, if i want to prototype up something, i can pull out my arduino board hook up, say ,a realtime clock chip, scour the web for some example code, load up the code and test the system in minutes. Doing it the 'hard' way, i would have to carefully read the chip datasheet, write an i2c driver then write code to talk to the rtc chip. Stuff I've been doing for years but it would take me a couple of hours at least otherwise.

You're still asking questions that could've been answered in greater detail if you did some research. I gave you some googling that would yielded a lot of information from people that have done much the same as you're wanting to do. Arduino or not - its all much the same.
Case in point is usb->serial - has been discussed here zillions of times. For the cost of your example, you could probably get a arduino copy from china for the same dollars or thereabouts. What interface to use for the tlc chips? What did they use on the arduino examples? Are they any things you need to be aware of with the tlc chips? They seem to be popular, so someone has written something about them.

So, Google first, ask questions later.

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

What library do you mean ?
Adafruit_TLC5947 library (seems resource greedy, but easy to understand).
BTW, using an Arduino will things easier in the long term (you have alreasy soldered HW, preexisting libraries -maybe they are not perfect, but people already tested them : someone who sells electronic cards would not knowingly give a buggy library, would he?). If you are in a harry, you can just program and solder *your * idea (the other details have been solved); then you can decide to adapt things, one at the time but you will -at most- have one wrong thing at the time (easier to fix)

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

Thanks kartman for the info .
Yeah I should admit I should have googled that last bit about how to use those driver chips .

I'm abit reluctant to touch arduinos though , don't know why . But I guess what you said makes sense and I might be ordering one sometime soon.

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

dbrion : Yes what you are saying makes sense. I do things in that was sometimes aswell.

Guess I'm going to have to join the "arduino club"

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

By the way , would something like this work to connect my avr to a pc ?

http://www.ebay.com/itm/USB-2-0-...

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

Yeah that'd be fine but it does seem to be extremely expensive?

Here's one with cables for $1.56 inc P&P:

http://www.ebay.com/itm/USB-To-R...

or if you insist on CP2102 rather than PL2303 (some people report problems with PL2303) then the cheapest CP2102 based one seems to be $2.38:

http://www.ebay.com/itm/New-CP21...

EDIT: Oh I get it. The one you linked is in the States. So they buy it for $2-$3 then sell it to you for $6 and make a tasty profit. I suppose it's fine if you want delivery a bit quicker than waiting for Hong Kong post and are willing to pay their mark-up.

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

Yes clawson , thanks for the link . I found that second one that you linked about half an hour ago and had already ordered it immediately :)

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

How many receivers can you feasibly have on a UART line before they start to cause serious signal degradation? I assume it worse than for I2C.

I would certainly prefer one or the other over SPI for such an application. They're not as pin-hungry and are very easy to expand; with SPI you'd have to assign another NSS line every time you wanted to add another driver.

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

Well I guess OPs architecture is the following:

PC <-> AVR master (-> tlc s) n tlcs, daisy chained -slow- or activated through SPI : tlc s are SPI
Only the PC <-> AVR master is UART and is optional

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

dbrion0606 wrote:
Well I guess OPs architecture is the following:

PC <-> AVR master (-> tlc s) n tlcs, daisy chained -slow- or activated through SPI : tlc s are SPI
Only the PC <-> AVR master is UART and is optional

Yes , exactly like that . I will be daisy chaining 2 TLC driver chips.

I've got a guy who is coming over in the evening to shed some light on the AVR communication peripherals because I didn't really understand the characteristics of each peripheral and their diffrences .

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

You should have a look at Arduinos library for tlc (a good sample of bit banging) and at wikipedia+SPI.

Then asynchronous transmission (which is optional) is easy to understand (you do not have a clock: both sides, PC -it has- and AVR, should have a Xal: for SPI/TWI, clock is a separate wire/PCB trace and can vary if the masters is in his mood...)

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

By the way If I used an arduino and the library for TLC , then could I program it into the atmega and use it without the arduino board?

Is there any way of using the arduino library without actually getting an arduino?

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

You have several options with Arduino code. Perhaps the easiest is simply to use any algorithm they implement as a template for your own separate implementation. That way, if the code relies on Arduino library function like digitalWrite() then in your own implementation you use a more traditional "PORTx |= (1 << n)" mechanism to set the output bit instead.

If the micro you plan to use is one that is supported by Arduino (mega8,168,328,1280,2560, etc) then you should be able to take what the Arduino IDE builds and run it in the stand-alone chip but watch for it making assumptions about the environment. Arduino thinks it can use the UART - does your circuit have a UART connection? Arduino assumes the chip is running at 16MHz from a fairly accurate crystal. Does your circuit have a crystal and is it 16MHz? Arduino thinks it can use both timer0 and tiemr1 for its own purposes. Does your code need to use those for something else and so on.

If you don't have an Arduino then to use the code "as is" you are probably going to effectively end up building one - so why not just buy one?

Alternatively, as I say just "steal the ideas" from the Arduino code and re-implement the algorithm in any AVR you choose making adjustments as necessary to port it to the solution.

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

Thanks Clawson for your input .

Mm yeah I could buy it .. but I'd like to leave that as a last resort .

I like the stealing ideas suggestion abit more...
I think I'll try that first.
The TLC chips should be arriving from germany on monday so I'll try it out then

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

You can have 127 device addresses on I2C. It's an open collector protocol so all the devices are doing is pulling down the signal to ground (or nearly so). I'm sure there's I2C specs out there talking about length of wire (basically the bus has a resistance so at one end of the bus "ground" is actually a different potential than the master end but it'd surely have to be a really long wire before the voltage drop exceeded the Vlo threshold. Right? I'm trying to think why the number of devices would matter. Maybe there are some limitations due to capacitive effects.

I love I2C for running many devices from a single MCU, personally and have been working on it quite a bit lately due to a number of projects. Will help if I can.

It should work - bot-thoughts.com

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

With the currents involved, voltage drop on i2c is rarely an issue. Capacitance is the killer. Refer to the i2c spec that philips/nxp publish. I2c is fine for what it was designed for, but one issue is the tendency for it to lock up when you get a glitch, so timeouts are required to recover gracefully.