Connecting 2 or more Avrs together Awsome!

[santiago]

Is it possible to connect 2 or more AVRs together? I think you can do this with the ARM ucontroller.

If possible how would one go about doing this?

Finally, what would be the benefits of doing this and the downside of doing this?


Any comments concerning the above would be extremely appreciate!

[Nyx]

I'm no microcontroller expert, but you'd think you can just connect one of the in/out port of one processor to an in/out port of another... And you might be able to daisy chain them.

Upsides:
- More processing power
- More total usable I/O ports

Downsides:
- Communication delay
- More programming work
- Less usable resources per processor

Each microcontroller would have to have its own programming, including some kind of communication system.

[izua]

what are you trying to achieve?
you can connect anything to anything else as long as they don't short eachother and they are aware of some protocol.

use i2c for example, or some form of serial (if only 2 peers are needed). You can also use more pins, in some form of parallel communication advantages, tasks will be divided by the numbers of avrs (think multicore). disadvantages, well, you need to rule out some protocol, who's who, and so on, and design the main program around that protocol.

[santiago]

I am aware that one can connect one chip into another by the input and output, however i thank you anyhow for the feed back. I was just tinkering with this question specifically about the avr ucontrollers because i have not seen on this website at least any project that has connected 2 or more avr in any of their robots. I was just fishing for info the lazy way i guess. I am going to build a robot with many sensors (touch,feedback,surface,tilt,vision ect...)
and decided on using the avr ucontroller because it is cheap and has decent power.

I am well familiar with the ARM7 but just decided on using the avr which is more popular too. I got inspired to use more than one ucontroller with the pleo robot that uses several ucontrollers:

camera-based vision system (for light detection and navigation) two microphones, binatural hearing
beat detection (allows pleo to dance and listen to music) - this feature was removed but may be added on again.
eight touch sensors (head, chin, shoulders, back, feet)
four foot switches (surface detection)
fourteen force-feedback sensors, one per joint
orientation tilt sensor for body position
infrared mouth sensor for object detection into mouth
infrared transmit and receive for communication with other Pleos
Mini-USB port for online downloads
SD card slot for Pleo add-ons
infrared detection for external objects
32-bit Atmel ARM 7 microprocessor (main processor for Pleo)
32-bit NXP ARM 7 sub processor (camera system, audio input dedicated processor)
four 8-bit processors (low-level motor control)

Well I'am off to desingn and build.

[Nyx]

If your microcontroller has memory to spare, you could implement some kind of a "hub" system, where each CPU has its own id number, and all the CPUs broadcast messages to one another through specific ports... Some kind of a simplified network protocol. Perhaps you can connect all the AVRs to the same bus, and have them send messages in a round-robin fashion?

The reason people avoid this is it's complicated, and you can probably find better tricks if you want more output ports, such as a multiplexer? If what you want is more CPU power, you might just want a more powerful CPU, like an ARM instead... Probably simpler than a huge grid of atmegas!

[airman00]

What I've done is a dual ucontroller system; this allows one microcontroller to do all the big processing and the other is basically the "supervisor" and does a bit of processing. The reason I did this was just because I was able to do it, no other reason, I was merely curious.

[Nyx]

I am well familiar with the ARM7 but just decided on using the avr which is more popular too. I got inspired to use more than one ucontroller with the pleo robot that uses several ucontrollers:

camera-based vision system (for light detection and navigation) two microphones, binatural hearing
beat detection (allows pleo to dance and listen to music) - this feature was removed but may be added on again.
eight touch sensors (head, chin, shoulders, back, feet)
four foot switches (surface detection)
fourteen force-feedback sensors, one per joint
orientation tilt sensor for body position
infrared mouth sensor for object detection into mouth
infrared transmit and receive for communication with other Pleos
Mini-USB port for online downloads
SD card slot for Pleo add-ons
infrared detection for external objects
32-bit Atmel ARM 7 microprocessor (main processor for Pleo)
32-bit NXP ARM 7 sub processor (camera system, audio input dedicated processor)
four 8-bit processors (low-level motor control)

Well I'am off to desingn and build.

Well in this case, it's practical to use microcontrollers for motor control because they have more I/Os (I would think) than an ARM processor.

[paulstreats]

heres a board that I use sometimes.



Its 2 pic18f2525's joined by a common i2c link, 1 is chosen as the bus master and the other is chosen as a bus slave with an address.

The master device is used for logic functions.

The slave device connects to motor drivers and servos etc...

When the master device wants to move the bot forwards, it just sends a command to the slave mcu, the slave mcu then controls the motors using pwm etc.. meaning that the master mcu can carry on with what its doing independantly and without having to lose clock cycles doing its own pwn controls.

Analog sensors can be fitted to either device. But i usually fit them onto the slave mcu and have it periodically update so the latest reading is always available for instant i2c transfer. i2c sensors can go on the same i2c bus as the master/slave mcu's

Both pics have independant icsp headers and also both have independant rx/tx ports for debugging straight into a terminal.

Although it works and works well, im looking at changing this board completely and incorporating the motor h-bridges on board to cut down on the amount of wires flying about everywhere

I was also considering connecting some of the port pins together too so if port pin b0 on the master unit was connected to port b0 on the slave unit as well as to a header pin, then the master unit can monitor when the slave unit is turning on and off.

Also if a 3rd mcu is used as a monitor controller and connected then to all of the pins, it cn continuously refresh it pin states and create a virtual model of what the robot is doing and be utilised for much higher level functions. I would prefer this set up for mapping etc because the monitor mcu can move a virtual model around the map based on encoder information and motor output information without disrupting any other program flow (it the same as giving it the opportunity to see itself or imagine itself rather than just see a load of code and maths)

[santiago]

Thats nice paulstreats.
Any schematics.

Has anybody tried to connect an AVR and a ARM7 before?

[Steel_monkey]

Is it possible to implement camera-besed vision in ARM7? As I know, ARM7 speed is limited with 80 MHz. And ARM11 can do 1000 MIPS.

[paulstreats]

The camera vision problem has many solutions. here are the most common problems:-

#1) Reading the image into memory. Whatever mcu is responsible for reading the image from the ccd array into the memory has to work fast enough in order to read the full from. Usually it has to be done with a buffered system that reads into a buffer and starts streaming the data back out into external memory. Obviously if the mcu is too slow it wont be able to read the data and write it at the same time but maybe using a buffer with the mcu internal memory might help. Another solution around this problem is to use a lower resolution ccd array(camera) so there is less data to have to read. Also you can occasionally get a good camera that lets you reduce its own clock and therefore stream images out at a slower rate.
if the camera is operating at say 800x600 resolution then maybe you only need to read every 2 bytes of 1 row into a buffer and stream them out into memory while ignoring the next row. The resulting data will be an image of 400x300 resolution but you can succesfully aquire images like this with slower processors. (maybe you only need to read every 3 pixels etc....)

#2)processing the data. This is the part that really takes the time but is not as critical as getting the image in the first place. This ll depends on what processing that you are trying to do. Also remembering that the lower resolution image that you have means less data to have to process. so comparing a 640 x 480 image is going to take a lot longer than processing a 160x120 image.

Its all about only getting and using as much data that your processor can handle, I doubt you will need crystal clarity pictures to start working with but its a trade off between speed and data richness

Its easy to think that you need a faster processor to work with cmeras but sometimes its best to think out of the box and look at other ways of doing it (such as only reading every 2 or 3 pixels to allow your slower mcu to cope with it or when you process the data, rather than work on the full images maybe the parts you are compring or processing is guaranteed to be in the top left of the image so you only need to work with  quarter of the image at most and sicard the rest. Youve just quadrupled the productivity)

[anggie]

i've heard several time about the I2C. but i still can't use it. i only have limited source about it. will u mind to share the program? using the C Language please. Thanx b4.

[lkik]

paulstreats  do you have any scmatics for that board with the 2 chips

[Webbot]

This attachment may give some software tips

[Admin]

I've connected two of my Axon microcontrollers to communicate data together using the UART. No documenation up right now for it though . . .

[paulstreats]

I made the board without schematics (i have a bad habit of doing this with proto boards).

The 2 controllers are both wired with their own oscillators / icsp connections and then their relevant pinouts. The i2c is the main way of communicating but this is literally connecting the i2c pins together from both of the controllers.

If you really want a schematic i will happily make you one if you give me a week or so

The latest board that i am making incorporates a pic18f4550(usb compatible), a motor driver ic(along with ballast/load capacitor) and an external memory module (connected through 2 i/o extenders). I have decided to get this one made professionally and so im creating/updating a schematic for it. (Ive decided to also add some onboard mosfet outputs to drive series led's such as when you want 5 leds in series to turn on with 1 pin so you can modulate ir leds aswell as producing a lot of ir light). I 3want to make ultimately a board that is used or geared up specifically for robotics.

Thinking about my last post, i think that i might have to add another mcu into the equation as a port monitor to provide higher level functions (its all to do with the component footprint to keep the board small, Surface mount components are good but im concentrating on through holes at the minute. The company im working for is looking at getting into the consumer market and were trying to develope products that can be used as education tools in british schools as well as the general market so an all in 1 board is my current focus)

[Private reid2]

lol
so you could connect like 2 AVR168's and be super fast! what about 3 or 4 ?
still possable