Multiple AVR in a single circuit

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

This is an theoretical question. Is it possible to have multiple AVR in a given circuit? What is an acceptable approach? Thanks

This topic has a solution.
Last Edited: Thu. Apr 21, 2016 - 10:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yes.

 

But they have to have separate programming lines for ISP.

It's me again...

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

OK, then can they communicate? Lets say I have 2 Atmega328 in a circuit that needs to communicate, share data.

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

Of course. Let them communicate using any of the communication interfaces they have: UART, SPI, TWI (I2C), CAN...

 

Almost all of these generally formulated questions begs the counter-question: What are you trying to accomplish?

 

Why do you think you need two AVRs? It might very well be a viable solution to your problems, but there is also the chance that the problem you're actually facing can be solved in a simpler way. Thell us about the original problem and we might be able to give more specific help.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

And now I see that you're the one asking the "adding more timers question" also. Is this about the same underlying problem? (If so, stick to one thread or you will just get people here irritated...)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Not solving any problem at the moment. Just learning and asking questions. Thanks for prompt replies.

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

Hello

 

Thanks for asking.Not currently trying to resolve any problems and this thread is not related to my timers questions. Do not wish to cause any frustrations, just learning and asking questions as I am a newbie.

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

Why do you think it might not be possible?

 

Many systems use multiple processors; they don't all have to be the same type of processor (eg, AVR).

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Why do you think it might not be possible?

 

Many systems use multiple processors; they don't all have to be the same type of processor (eg, AVR).

  Yep Thanks

 

UART, SPI, TWI (I2C), CAN..

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

I have a multiple processor board sitting in front of me at the moment.

 

It is a (clone) Arduino UNO.

 

The main processor is a M328P.

 

The PCB, however, also has a M16U2 used as a USB to Serial Bridge to connect the PCB to a PC.

 

I believe they use a USART for intra-uC communications.

 

JC

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

I have two boards here.

 

They are chatting over SPI, but the one board (display driver) also works if fed data by RS232 so it will talk also to a PC or almost anything else...

 

Three things I do when making two processors communicate:

 

1) use interrupt driven communications.

 

2) use a circular receive buffer (256 bytes is easy to use).

 

3) If processing received data is slow compared to the comms signal, use a 'busy' signal and monitoring the space in the buffer

 

 

It's me again...

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

It is almost always a worse design to try and make multiple small micros interact to make a combined solution than to pick one micro capable of doing everything. If you split it you have issues with making them all communicate, ensuring they remain synchronised and passing code updates between all of them. A single micro has no such issues. The one time you might use a couple of micros is when you have one "big one" (perhaps a Cortex application (A) processor perhaps?) and then the need to "mop up" some I/O expansion and some simple ports like SPI, I2C, etc. which might warrant a dedicated slave simply to add to what the app processor lacks. 

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

A better approach is to use multicore processors, such as the Parallax Propeller or the XMOS devices:

 

https://www.parallax.com/microco...

 

http://www.xmos.com/

 

They also have the advantage of fully deterministic operation - the Propeller requires assembler for this whilst the XMOS chips use C with extensions.

Leon Heller G1HSM

Last Edited: Sun. Apr 17, 2016 - 02:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

It is almost always a worse design to try and make multiple small micros interact to make a combined solution than to pick one micro capable of doing everything. If you split it you have issues with making them all communicate, ensuring they remain synchronised and passing code updates between all of them. A single micro has no such issues. The one time you might use a couple of micros is when you have one "big one" (perhaps a Cortex application (A) processor perhaps?) and then the need to "mop up" some I/O expansion and some simple ports like SPI, I2C, etc. which might warrant a dedicated slave simply to add to what the app processor lacks. 

 

This is what I think as well. Thanks for the update. What would be a step up from Atmega328? Thanks

Last Edited: Sun. Apr 17, 2016 - 05:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A better approach is to use multicore processors, such as the Parallax Propeller or the XMOS devices:

 

https://www.parallax.com/microco...

 

http://www.xmos.com/

 

They also have the advantage of fully deterministic operation - the Propeller requires assembler for this whilst the XMOS chips use C with extensions.

 

Wow! You hit me hard with new toys ;)

Last Edited: Sun. Apr 17, 2016 - 06:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Stub_Mandrel wrote:

I have two boards here.

 

They are chatting over SPI, but the one board (display driver) also works if fed data by RS232 so it will talk also to a PC or almost anything else...

 

Three things I do when making two processors communicate:

 

1) use interrupt driven communications.

 

2) use a circular receive buffer (256 bytes is easy to use).

 

3) If processing received data is slow compared to the comms signal, use a 'busy' signal and monitoring the space in the buffer

 

 

 

Wow!, Will note this. Thanks

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

What would be a step up from Atmega328? 

Well that sort of depends what your requirements are? Do you need 4 UART? Or 7 SPI? Or 50 I/O? Or what? 

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

I'm still fairly proud of a board I made some years ago with seven AVRs on board, six of them (tiny2313s) in parallel for speed (the board was fundamentally six channels.  The 7th was a 32U4 that summarized the results and dumped them out via USB).

 

The interface between the chips was an eight-bit wide parallel bus, with 'read' and 'ready' and 'chip select' signals.  The really clever part entailed TOGGLING the control lines because that could be done in one instruction, while pushing them low (or high) and waiting for an ACK took many many cycles.  Furthermore, the fast six could delay result reporting if they became busy while it was happening.

 

And yes, the six parallel chips had to be programmed in another board and then plugged into sockets.  The 32U4, being SMT, had its own ISP header.

 

S.

 

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

I made a board two years ago with a 20x4 LCD display, eight 7-seg and 24 leds, an atmega32 to command the LCD and the 24 leds and an 328 to command the eight 7segs. This two avr are connected in the same I2C bus and reaceive commands from a third uC outside the board. The third uC can be any project that I'm working, usually a uC on a breadboard.

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

clawson wrote:

It is almost always a worse design to try and make multiple small micros interact to make a combined solution than to pick one micro capable of doing everything. If you split it you have issues with making them all communicate, ensuring they remain synchronised and passing code updates between all of them. A single micro has no such issues. The one time you might use a couple of micros is when you have one "big one" (perhaps a Cortex application (A) processor perhaps?) and then the need to "mop up" some I/O expansion and some simple ports like SPI, I2C, etc. which might warrant a dedicated slave simply to add to what the app processor lacks. 

 

One exception, I would argue, is modular design. For example I have several display drivers (from 2x16LCD to QVGA TFT) that can be incorporated in the main chip (if it has enough I/O & resources) or can happily bumble along in a second processor, lightening the load. The more advanced of these can run keyboard other I/O on behalf of the main processor. (OK, I confess I was totally inspired by the BBC Micro's Tube interface).

It's me again...

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

clawson wrote:

What would be a step up from Atmega328? 

Well that sort of depends what your requirements are? Do you need 4 UART? Or 7 SPI? Or 50 I/O? Or what? 

 

The limitation I have is with IO yet afraid I would need to move to a NON DIP device

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

Scroungre wrote:

I'm still fairly proud of a board I made some years ago with seven AVRs on board, six of them (tiny2313s) in parallel for speed (the board was fundamentally six channels.  The 7th was a 32U4 that summarized the results and dumped them out via USB).

 

The interface between the chips was an eight-bit wide parallel bus, with 'read' and 'ready' and 'chip select' signals.  The really clever part entailed TOGGLING the control lines because that could be done in one instruction, while pushing them low (or high) and waiting for an ACK took many many cycles.  Furthermore, the fast six could delay result reporting if they became busy while it was happening.

 

And yes, the six parallel chips had to be programmed in another board and then plugged into sockets.  The 32U4, being SMT, had its own ISP header.

 

S.

 

 

These are so scalable, I like it.

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

Stub_Mandrel wrote:
BBC Micro's Tube interface

 

Cool! I sense a new AVR freak in the making ;)

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

I am contemplating a modular data logger. The modular part is I/O with pluggable serial, wireless (in various formats), MicroSD card, and more. I am seriously considering a micro ON the module that would handle the "stack" and interfacing to the main MCU so that that MCU would only have a single I/O protocol for these devices that have various interface needs. This would allow a single program in the main MCU and a device-specific (often a Tiny, I hope) MCU to service the I/O channel. This would allow the user to field-swap I/O and not have to do hardly anything more than the mechanical change.

 

Carefully implemented, a modular system like this can be very powerful. Insufficient care can turn it into a nightmare. So, it is not "free" and it is not for the faint-of-heart nor is it for the implementer who does not have lots of time. 

 

There are fewer drivers to non-modular systems. In the case of Arduino, it was, I suspect, largely psychological (untrained users "working on" a simple micro) though there are clearly pragmatic arguments to putting certain functions behind a wall that is hard(er) for users to mess up. 

 

I did one, years ago, for a big 8051 project where we needed an additional serial port and all we had available was SPI. I used a 2313, as I recall, as a drop-in "UART" and it worked like a charm. Had a stand alone UART with the appropriate features been available, we would have used that. But, there was none, and the 2313 worked well. That was a multiple-MCU project that did not look like a multiple-MCU project!

 

It is an interesting discussion and one that helps to get thinking about multiple micros clarified in one's mind.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Pierreb7 wrote:
The limitation I have is with IO yet afraid I would need to move to a NON DIP device

Your best bet is probably just to get over that fear!

 

Otherwise, there are plenty of SPI and I2C IO Expanders - they would, as the name suggests, give you more IO without the need of extra processors.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Pierreb7 wrote:
The limitation I have is with IO yet afraid I would need to move to a NON DIP device

Your best bet is probably just to get over that fear!

 

Otherwise, there are plenty of SPI and I2C IO Expanders - they would, as the name suggests, give you more IO without the need of extra processors.

 

The fear is about learning to solder non DIP devices ;) But yes, I had a look at the 74HC595. Thanks

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Get an Arduino Mega from eBay for $5..10. It's got tons of I/O and comes as a mega2560 already soldered to a very capable circuit board. 

 

Oh and before you ask, no, just because it's called "Arduino" does not mean you are tied to their software and programming methods. It's just a mega2560 soldered to a board at the end of the day. 

Last Edited: Mon. Apr 18, 2016 - 09:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The limitation I have is with IO yet afraid I would need to move to a NON DIP device

The ATmega1284P comes in a 40-pin DIP version.

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

clawson wrote:

It is almost always a worse design to try and make multiple small micros interact to make a combined solution than to pick one micro capable of doing everything. If you split it you have issues with making them all communicate, ensuring they remain synchronised and passing code updates between all of them. A single micro has no such issues. The one time you might use a couple of micros is when you have one "big one" (perhaps a Cortex application (A) processor perhaps?) and then the need to "mop up" some I/O expansion and some simple ports like SPI, I2C, etc. which might warrant a dedicated slave simply to add to what the app processor lacks. 

 

If your design can sensibly fit into one device, then yes.

 

However, there are also many cases where multiple MCUs is the best and cheapest solution.

* Cable wires can easily cost more than a MCU, so you will find many designers use the least numbers of wires, and a slave MCU on user interface panels.

* Hard real time requirements can dictate many cores, that one monster CPU running 50 interrupts is going to be a deterministic nightmare....

* Test coverage sign off. Some blocks can be defined and tested, and then that code frozen.

   With one monster CPU, you never really know what side effects that latest code patch may have, in unexpected areas. ie Sign-off testing can cost more.

 

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

clawson wrote:

It is almost always a worse design to try and make multiple small micros interact to make a combined solution than to pick one micro capable of doing everything...

 

I'd like to add a caveat to that of "Unless you really really know what you are doing."

 

I have a design here, just waiting for someone to push the GO button, that has 14 (!) microcontrollers on the same PCB. Thirteen of them are there to interface with things like multiple LCD displays, switches, external communications ports, etc etc. By connecting them together over a simple serial bus which is arbitrated by the 14th uC, and having them pass messages onto the bus rather than data I can partition the design into 14 distinct blocks each of which can be implemented and tested as a stand-alone entity. Each uC will be sited next to the other circuits it is interfacing to. Effectively, I am making 13 intelligent peripherals which I have complete control over. The 'trick' to such a design is learning to think in terms of 'messages' and not 'data'.

 

Would I recommend such an approach to anyone starting out? No.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

OK, I'll admit it. I was the designer/project manager of this:

http://www.minidisc.org/images/amstrad_mcr2500md.jpg

We made that back in the very late 90s when iTouch and other MP3 players were merely a twinkle in the eye of others. What's in there is a 60 CD changer. The idea is that you opened the panel at the left, slotted each of your CDs into it in turn and it would take them and put them into an empty "parking slot". In the process it would read the CD to see if it contained "CD text". If so it added the details of the album and the tracks automatically to a Nand based database. If the CD were old, without CD text then the user was invited to use the (PS/2) keyboard to type in the details on that 10 line LCD display on the front. It would then categorise the music so you could later play "3 hours of jazz" or "anything by Frank Sinatra" or whatever. As such I like to think it predated MP3 players/iTunes etc cheeky

 

Any how, the way we did it was that there was a Mitsubishi M16C (16 bit micro) at the very core of everything on the main circuit board. As the device also contained FM radio there was a RDS chip from ST micro on that board too (something like a TDA7706/8) - either way it was like a STM8 micro with a dedicated function. The 60 CD changer was a unit from NEC and was some kind of uPD7 series 8 bit micro. As a package deal we also got another 8 bit micro from NEC to do the LCD and buttons on the front panel (that could be hinged down to reveal access to the CD rack in case of "emergencies" ;-) so we just implemented a simple synchronous serial link down very few wires between the M16C on the main board and that micro. Of course the keyboard itself was PS/2 and contained a Holtek keyboard processor which is effectively another 8 bit micro. Even the IR remote handset would have had a small micro.

 

So, yes, I'll admit it that you can make designs with distributed processing but this really was the case of the main M16C that did all the "thinking" talking to slave processors with very dedicated/fixed jobs. Some of them (the TDA for RDS and the NEC uPD7 for the CD etc) were more like "peripherals" than actual micros as we didn't have a lot of control over the code that they were running. So I suppose the micros I really chose for this were the M16C and the NEC on the front panel and the only real reason for splitting that was that this was an audio unit at the end of the day and we wanted to reduce any electrical noise so couldn't have loads of parallel LCD driving wires going straight from the M16C to the LCD/buttons on the front.

 

If this thing taught me anything it was "always try to reduce the number of CPUs in a design!".

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

Fear not! 64-pin TQFPs can be hand soldered, but I have a rework gun now :-)

 

 

> keyboard itself was PS/2

 

With the custom Amstrad character codes you used on the emailer? ;-)

It's me again...

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

clawson wrote:

Get an Arduino Mega from eBay for $5..10. It's got tons of I/O and comes as a mega2560 already soldered to a very capable circuit board. 

 

Oh and before you ask, no, just because it's called "Arduino" does not mean you are tied to their software and programming methods. It's just a mega2560 soldered to a board at the end of the day. 

 

Cool. Very tempting indeed!

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

Stub_Mandrel wrote:
With the custom Amstrad character codes you used on the emailer? ;-)

I spent AGES working out the key codes when I designed the emailer. I was trying to adhere (both for the keys but across the board) to ISO-8859-1 as much as possible but I think my solution may have involved ISO-8859-16 in the end in fact. What I wanted to ensure was that when the user typed a Æ or whatever and sent it to a mate in an email that what was received would show Æ where they had put one. It's a surprisingly tricky juggling act to get keyboard/font/data transmission to agree!

 

But you are right that I used the same Holtek PS/2 keyboard controller in the emailer. We cut our teeth with it doing the MCR2000 above and then just adopted the same into the emailer design. That worked fine for BSI and Gamma but when we came to do Delta and switched from our own (WIN16 like!) OS to Linux we hit all kinds of problems as Delta (the colour emailer with videophone) was implemented on top of Linux 2.4 and the Holtek PS/2 controller is a clock master so you have to respond to its clocks in a very timely fashion. With our own OS/interrupt system we were able to implement that fast service easily. However earlier versions of Linux did not make this (realtime OS response) that easy and we ended up doing it using the ARM NMI interrupt in the TI OMAP 5910 as it was the only thing we could use that guaranteed a fast enough response.

 

Ah, happy days!

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

awneil wrote:
Pierreb7 wrote:
The limitation I have is with IO yet afraid I would need to move to a NON DIP device

Your best bet is probably just to get over that fear!

A bit callous.  Some of us are just plain clumsy.

Soldering DIPs was already at the limits of our abilities.

awneil wrote:
Otherwise, there are plenty of SPI and I2C IO Expanders - they would, as the name suggests, give you more IO without the need of extra processors.
clawson wrote:
Get an Arduino Mega from eBay for $5..10. It's got tons of I/O and comes as a mega2560 already soldered to a very capable circuit board.
Greg_Muth wrote:
The ATmega1284P comes in a 40-pin DIP version.

Iluvatar is the better part of Valar.

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

clawson wrote:

Get an Arduino Mega from eBay for $5..10. It's got tons of I/O and comes as a mega2560 already soldered to a very capable circuit board. 

 

Oh and before you ask, no, just because it's called "Arduino" does not mean you are tied to their software and programming methods. It's just a mega2560 soldered to a board at the end of the day. 

  Its on the way. And yes this was marked as the solution.

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

Brian Fairchild wrote:

I have a design here, just waiting for someone to push the GO button, that has 14 (!) microcontrollers on the same PCB.

 

I will go find my hat and put it on so I can take it off to you.

 

Of course, my seven AVR board has not only been made, it has been in regular production for some years, and has a self-rolled eight-bit bus parallel interface (rather faster, I'd say), but hey...  ;-P

 

I agree with you on another matter, that being that you should know what you are doing.  I came up into AVRs from writing PLDs in ABEL, and even assembler still strikes me as a high-level language.  Caring about data setup and hold times (nanoseconds they may be) is not optional.

 

S.