Webbotlib, SPI, and ATMegas

[mstacho]

Howdy,

just a quick question: has anyone used Webbotlib to connect multiple ATMegas together and communicate between them?  Does it have a simple way to do it, or do I need to write the lower level stuff myself?

I'm using ATMega644s and an Axon for now, but I'll be moving everything into ATMega328s later, if it counts.  There will be at least 4 chips, so I'll have to be intelligent with chip select.

MIKE

[Admin]

At least four mcus . . . hmmm . . .

Will you have a master mcu, or will each need to be 100% be independent?

[mstacho]

Yes, a master.  The way it will work is like this:

MCU_MASTER: connect to PC via USB/UART, connect to the other MCUs via SPI to relay instructions and receive sensor data

MCU_SLAVES: Connect to master via SPI (Or...whatever works, I don't really care as long as I can get all 4 communicating with each other easily), receive motor control commands and send sensor data

I guess I2C can also work...

[Admin]

In that case, I2C will work fine. Just make sure you add in the proper pull-up resistors.

You can also use a multiplexer such as this:
http://www.sparkfun.com/products/9056

It would connect the UARTs together for simple serial data transfer.

[Webbot]

You would be better using I2C as you won't need any extra pins, whereas SPI would need to have a chip select for each slave. Also if memory serves (I'm not near my pc) then the library supports I2C slave mode, but not SPI slave mode. Depending on your hardware board then you also have to slightly careful if you are also using a hardware programmer (like AVRISP MKII) as that also uses the SPI pins.

Note that for I2C my library uses the internal pullup resistors and this seems to work ok with a device or two on the bus - but if you experience any problems then try adding some external ones as Admin says.

[mstacho]

Awesome, thanks guys.  I'm going to try I2C and see what happens.  It also looks easier to work with than SPI anyway.

MIKE

[Webbot]

Ok - so if you I2C then try to use the standard 'registers' view. So in your slave code create a structure that contains the data you want to be able to read/write. Registers tend to be single byte and most significant byte first (unlike that used by the AVRs) so you will need to define some helpers ie something like:

Code: [Select]

typedef struct s_reg16 {
   uint8_t msb;
   uint8_t lsb;
} REGISTER_16bit;
void set16bitRegister(REGISTER_16bit* reg, uint16_t val){
   reg->msb = val >> 8;
   reg->lsb = val & 0xff;
}

Then you will need to define the list of registers

Code: [Select]

typedef struct s_registers {
   REGISTER_16bit position;  // byte/register 0...1
   REGISTER_16bit target;    // byte/register 2...3
   uint8_t foo; // byte register 4
} REGISTERS;


Then you will need to create two sets of the registers:- one that the slave is currently updating, and the second that is being read

Code: [Select]

REGISTERS updating;
REGISTERS reading;

Your slave code will need to update the values in 'updating' ie updating.foo=5. Once the slave has finished one pass of updating the data it will need to copy the data to the 'reading' set e.g. use memcpy to copy from 'updating' to 'reading'. Make sure that you surround this with a CRITICAL_SECTION so that any incoming requests from the host are ignored until its finished (else you'll get some old data mixed with some new data!).

In your slave code that is called under interrupts then it will return the values from the 'reading' section ie reading.foo so that it sends back the last complete value.

If you need to send back variable length data then think WHY - since I2C ain't good at that. ie don't send back a string of text as, say, an error message because that can be any number of bytes long but rather send back an error code and then let the master controller turn that into a string.

Hope that helps! Inter cpu coding is difficult !!

[mstacho]

Hm...this looks like it's going to suck :-P  Can't I just initiate one device as a master, the others as slaves, and register callbacks to the slaves like in the documentation? 

Otherwise, I'll definitely try to implement what you just wrote!

[Webbot]

Well yes you can but all I was trying to get at is that you need to find a way to cope with the requests from the master to the slave.
Assuming that the slave is constantly monitoring stuff and preparing answers that it can return to the master then you need to consider that this request can happen at ANY time. This is trickier but allows the slaves to work in parallel with the master.

Alternatively:- the slave can build the response when (ie at the time when) it is called by the master. But if the master has to wait until this is performed then why bother having master and slaves? ie if the master says 'Give me the position of finger 2 on the hand' and then has to wait until the slave works out the answer then you may as well just do the calculation on the master and get rid of the slaves all together. The only added value you are getting is splitting the code between controllers so that the master needs less program memory - but it won't actually run any faster - in fact it will run slower since there is a comms session to call the code and then wait for the answer.

this isn't a WebbotLib thing:- it's an architectural decision that you need to make. WebbotLib can work either way.

[mstacho]

Hm, excellent point.  Thing is, I have to use multiple MCUs no matter what I do.  My sensors simply have too many data lines for this to work on only one MCU.  I can multiplex, of course, but there are other complications, like the computation that has to take place, that make a *strong* case for doing the processing locally.

I think all this really means is I need to spend more time thinking about how I'm going to set this up.  Thanks for the insights, I'll see what I can do on Monday!

MIKE

[Admin]

It almost sounds like you are doing a sensor network . . .

You've probably already thought about it, but you can go wireless with the Mote and have as many mcu's connected as you want:
http://www.societyofrobots.com/axon_mote/

[mstacho]

Yes, the mote had crossed my mind.  But eventually I want to be able to put this into a PCB with surface mount stuff, so I want to start more or less from scratch.  At the moment, the amount of wiring I need to do about 1/3 of this project is taking up more of my desk than is safe or reasonable, and it's becoming just about impossible to mount onto a moving robot :-P

I had also considered using an ARM Cortex, which can handle the computations needed for all of my sensors, so I'd theoretically only need one.  Only issue is they don't have enough IO for motors, encoders, AND sensors, so I'd have to network them anyway.

MIKE

[Admin]

So, the problem is processing speed, not the linking of multiple mcus?

What about one ARM mcu and one Axon II/ATmega? One mcu does the heavy processing while the other does all the I/O stuff.

Just a thought . . . although programming in two different environments simultaneously might be a pain . . .

[mstacho]

Could be done.  The setup is 6 motors (+ encoders) and at least 6 sensors, each of which requires at least 8 IO pins with multiplexing, 4 of which must be analog.  Without multiplexing it's obviously more :-P.  Each sensor has 16 values that I have to read.

So, if each encoder needs 2 pins, each motor needs 2 for direction and PWM, and each sensor needs 8, then I have 72 pins, of which 6 must be interrupts, 6 must be PWM capable, and 32 (!) must be analog (unless I multiplex the hell out of the sensors, which I guess is possible).

Problem is that I'd need to be able to read and process the sensors at around 50Hz in order for control to work.  Multiplexing and reading 8x16 sensors, while doing all the other stuff, might be a challenge, hence why I was thinking of using multiple MCUs in the first place -- each one can read on its own, control on its own, and just send the data to the central controller at the end of its loop.

The Axon was capable of handling 7 motors and their encoders with 6 much simpler (2-wire) sensors.  But the processing I'm going to need to do on the new sensors, which requires dealing with 16 values and doing fun things like derivatives and division, might be a bit much...

Haha despite the challenges this is actually a lot of fun :-P

[Admin]

hmmmmm understood. I'm thinking a combination of multiple mcus and multiplexers might be best . . . basically what you just said

Years ago I had a similar problem, basically not enough I/O. The crappy mcu's that did exist had no more I/O than today's Arduinos. Like you, I considered a dual mcu system that each did half the job. But in the end I decided to 'invent' the Axon instead.