X2 SPI: 2 slave setup

Gents,

I’m currently trying to attach SPI-based nRF24L01 module to X2 robot controller. I’ve noticed that mega644 and mega168 don’t use SS line during communication. If I’m correct, can it be changed?

PB4 (SS) signal on mega644 is broken out into a JP9 and PB2 (SS) of mega168 is available on JP3 so once those connected with air-wire this should fix the actual hardware link between the micros. But can you modify the firmware on mega168 so it will only communicate over SPI when it has SS asserted?

I’ve validated my code to work on Proteus VSM and actual hardware setup on AVR STK500+nRF24L01 minus mega168 but once I put it on X2 it stops working. So it seems once there are two SPI slaves on the bus things go awry.

I suspect ‘chatter’ from mega168 is getting in the way but I might be wrong. Can you please elaborate if 2nd SPI device can be attached to X2?

Thanks in advance.

Hello,
The SS pin on the mega168 has a pull-down resistor, enabling its SPI by default. To disable the mega168, just bring this line high by connecting it to any output on the mega644. You could use SS/PB4 for controlling either the mega168 or for controlling your RF chip, but there is no particular reason to do so - any output should work. Please note, however, that SS/PB4 should not be used as an input when in SPI master mode!

-Paul

OK, great. I’ll give it a try.

I’m not sure why I didn’t factor in the pull down resistor on mega168 SS line but it’s pretty obvious now once you mentioned it.

Thanks.

Sounds good. Please let us know how it goes!

By the way, how do you like the Nordic chips for wireless? Are you using a carrier board (like one of the Sparkfun boards?), and what are you trying to get the X2 to communicate with? We planning to start doing some things with wireless over here in the next few months, but we have not settled on a chipset yet.

-Paul

DONE and DONE. Works like a charm. :slight_smile: Thanks for your help

Just to re-iterate for whose who will be dealing with the same issue in the future. You need to run an air-wire from mega644 PB4 (or any other pin for that matter you’re using to do slave select) to SS pin of mega168. You will ensure that MISO line stays clean of unnecessary chatter by doing hands-on control of mage168 SS pin.

Q&A:

By the way, how do you like the Nordic chips for wireless?
Well, since you asked… :wink:
Excellent for most of inter-mcu communication as long as you have available SPI pins. I haven’t gotten into situations where I had to push the limits of throughput on them but shuttling byte/char/int arrays from one mcu to another works REALLY well. What made these modules attractive to me originally was an idea of being able to use RFL remote or SPE’s FOB with my bots. I don’t have to follow my robot around and can simply shut it off at a distance. But once I got through the grind of getting basic functionality to work I discovered another feature that I really liked - ‘Multiceiver’ capability. nRF24L01 module has six different data pipes with unique addresses. This translates into ability of receiving data from six different sources (simultaneously) while running one a single frequency. This feature gets useful when you’re setting up bot swarm or some local multi-unit wireless network. Last but not least nRF24L01 has 5V tolerant pins. It becomes indispensable little gadget when moving between different micros/boards running at different logic levels. I have bunch of AVR boards and only two SPE nRF24L01 modules. Some of those boards run at 3V and others at 5V. nRF24L01 modules work with any of them without any peripheral level shifting staff. Just plug-and-play.

Are you using a carrier board (like one of the Sparkfun boards?),
Yes - robotcraft.ca/webshop/Wirele … _info.html. I believe SPE pID # WRL-00691.

and what are you trying to get the X2 to communicate with?
I’m working on a similar setup to this one here robotcraft.ca/webshop/p26/No … pages.html but using X2 instead of Baby Orangutan. As of now I’m done with RFL remote to robot communication portion of the project. Now I can correct the bot ( in case it heads in the wrong direction or does something undesirable) without constantly following it.

The next phase of the project will be adding 2nd remote station - PC/Laptop. It will be used as a relay point by the bot to send/receive debugging, directional, and other bots communication data.

I hope this helps.

mazx:

Thanks for this post! I have a set of these transceivers and was thinking about implementing the communications arrangement that you describe. It would be very useful to me, and others on the board, if you could post some sample code. The “bot swarm” sounds pretty cool.

Cheers, Jim