go away spammer

Author Topic: multiple SPI devices on single ATmega  (Read 34710 times)

0 Members and 1 Guest are viewing this topic.

Offline AdminTopic starter

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,703
  • Helpful? 173
    • Society of Robots
multiple SPI devices on single ATmega
« on: February 20, 2010, 04:31:47 AM »
I want to hook up an SPI device to my ATmega, but I'm concerned that when I also hook up my ISP hardware programmer that something bad will happen. When the ISP programmer is connected, I don't want my SPI device getting any data.

Do I just add a pull-up resistor to the CS line of my SPI device, so that it's only selected when an I/O declares it to be so?

All the tutorials show schematics where everything works just fine, but doesn't seem right:
http://www.best-microcontroller-projects.com/spi-interface.html
http://www.arduino.cc/en/Tutorial/SPIEEPROM



Offline dunk

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 1,086
  • Helpful? 21
    • dunk's robot
Re: multiple SPI devices on single ATmega
« Reply #1 on: February 20, 2010, 05:43:43 AM »
your picture there depicts SPI Daisy Chaining.
i don't think this is what you want. using this method data sent to SPI is clocked out to all SPI devices.

what you want is to use the SS pin to enable the devices individually.
look at the picture on your 1st link titled "SPI Interface using separate chip selects".

the SS pins on the microcontroller are just standard IO pins so you can enable internal pull-ups providing your SPI devices are active low.
(most SPI devices are active low but there are exceptions.)


dunk.

Offline AdminTopic starter

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,703
  • Helpful? 173
    • Society of Robots
Re: multiple SPI devices on single ATmega
« Reply #2 on: February 25, 2010, 01:38:35 AM »
Quote
the SS pins on the microcontroller are just standard IO pins so you can enable internal pull-ups providing your SPI devices are active low.
(most SPI devices are active low but there are exceptions.)
Hmmmm but when I have an ISP programmer actively programming my AVR, I can't have internal pull-ups enabled, right?

Offline Ro-Bot-X

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 1,431
  • Helpful? 25
  • Store: RoBotXDesigns.ca
    • Ro-Bot-X Designs
Re: multiple SPI devices on single ATmega
« Reply #3 on: February 25, 2010, 06:17:34 AM »
The programmer does not use any SS pins. Only the MISO, MOSI, SCK, RST, GND and Vcc pins.
So I guess you should be fine. Anyway, the pull ups are enabled only when the pin is set as an input pin. If the pin is in special function mode, the pin is set by that function as needed.


Edit: On the slaves you can use the dedicated SS pin set as input. The master will drive it high except when it wants to communicate with that slave, it drives it low. On the master, you can assign a regular I/O pin for each slave, set them all high to keep the slaves quiet and set low only the pin that signals the specific slave that messages are coming in.
« Last Edit: February 25, 2010, 06:25:24 AM by Ro-Bot-X »
Check out the uBotino robot controller!

Offline dunk

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 1,086
  • Helpful? 21
    • dunk's robot
Re: multiple SPI devices on single ATmega
« Reply #4 on: February 25, 2010, 06:28:17 AM »
the SS pins on all the SPI devices are not connected together.
the pin labeled SS on the AVR is for when the AVR is used as a slave. if you are using the AVR as the bus master then you can use *any* IO pins to connect to the various slave SS pins.
think of the SS pin on a slevae as an "enable" pin. the slave only listens to the SPI bus when it's SS pin is set.
if you have enough IO pins spare then it's probably better not to share pins with the programmer.
http://upload.wikimedia.org/wikipedia/commons/f/fc/SPI_three_slaves.svg

which ATMega are you looking at using?
many use different pins to the main SPI bus anyway.
i think they all use RESET as the SS pin, so are actually programming the AVR while it is in reset.

Hmmmm but when I have an ISP programmer actively programming my AVR, I can't have internal pull-ups enabled, right?
so i have always presumed, as the AVR is in reset while it is being programmed that any internal pull-ups or any other AVR configuration have no effect.
either way, we are talking about the pin going to your SPI slaves SS which shouldn't be shared with the programing pins anyway.


dunk.

edit. Ro-Bot-X beat me to the reply. posting anyway.
The programmer does not use any SS pins. Only the MISO, MOSI, SCK, RST, GND and Vcc pins.
So I guess you should be fine. Anyway, the pull ups are enabled only when the pin is set as an input pin. If the pin is in special function mode, the pin is set by that function as needed.
on *some* AVRs The programmer does not use any SS pins.
« Last Edit: February 25, 2010, 06:29:38 AM by dunk »

Offline GearMotion

  • Supreme Robot
  • *****
  • Posts: 489
  • Helpful? 24
  • Two decades+ of Embedded Design
    • CircuitGizmos
Re: multiple SPI devices on single ATmega
« Reply #5 on: February 25, 2010, 06:41:27 AM »
You can daisy-chain only the simple SPI I/O devices. Things like EEPROM won't work and need individual chip selects. And external resistors to disable the chip selects when the device is powered, but still in reset.

ISP connects to reset, MOSI, MISO, and CLK. The SPI devices should ignore MOSI/MISO/CLK when disabled.

Offline dunk

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 1,086
  • Helpful? 21
    • dunk's robot
Re: multiple SPI devices on single ATmega
« Reply #6 on: February 25, 2010, 07:14:01 AM »
You can daisy-chain only the simple SPI I/O devices. Things like EEPROM won't work and need individual chip selects. And external resistors to disable the chip selects when the device is powered, but still in reset.
you can use internal pull-ups on the chip selects (SS) too.

ISP connects to reset, MOSI, MISO, and CLK. The SPI devices should ignore MOSI/MISO/CLK when disabled.
again,
this is only true on *some* AVRs.
for example, i'm working on the ATmega2561 at the moment which does share CLK but
uses completely different pins for MOSI and MISO.
(i keep repeating this because i wasted a day once trying to workout why i could not program an AVR using the "normal" SPI pins...)


dunk.

Offline GearMotion

  • Supreme Robot
  • *****
  • Posts: 489
  • Helpful? 24
  • Two decades+ of Embedded Design
    • CircuitGizmos
Re: multiple SPI devices on single ATmega
« Reply #7 on: February 25, 2010, 09:10:36 AM »
You can daisy-chain only the simple SPI I/O devices. Things like EEPROM won't work and need individual chip selects. And external resistors to disable the chip selects when the device is powered, but still in reset.
you can use internal pull-ups on the chip selects (SS) too.

No. During reset all bets are off. The registers associated with port operation are reset to 0. So during reset the pull up resistors would go away. The chip select lines may float to 0 and with MOSI/MISO/SCK toggling around during ISP programming, the SPI device would see this as SPI communication.

Relying on the internal pull up which during reset is disabled is specifically why you need an external resistor for the device. You have to design for all conditions that the device will be in, and since reset is one of them, then that condition should be considered.


ISP connects to reset, MOSI, MISO, and CLK. The SPI devices should ignore MOSI/MISO/CLK when disabled.
again,
this is only true on *some* AVRs.
for example, i'm working on the ATmega2561 at the moment which does share CLK but
uses completely different pins for MOSI and MISO.
(i keep repeating this because i wasted a day once trying to workout why i could not program an AVR using the "normal" SPI pins...)

You have made yourself clear and nowhere was I disputing that. The O.P. (Admin) is talking about specifically when the lines are shared (otherwise I don't think he would consider it an issue) and also pointing to an ATmega168 as an example, which has the shared lines.

Again: You need to make sure that the SPI devices are disabled during ISP. Don't rely on the internal pull up during reset.


Offline dunk

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 1,086
  • Helpful? 21
    • dunk's robot
Re: multiple SPI devices on single ATmega
« Reply #8 on: February 25, 2010, 09:44:29 AM »
Again: You need to make sure that the SPI devices are disabled during ISP. Don't rely on the internal pull up during reset.
that is a very good point.
if your AVR uses the same SPI pins as the ISP, internal pull up will not be reliable.

dunk.

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,165
  • Helpful? 111
    • Webbot stuff
Re: multiple SPI devices on single ATmega
« Reply #9 on: February 25, 2010, 10:55:33 AM »
Look at AVR042 page 5 http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf
where you will see ATmel recommend adding series resistors to the SPI bus to protect it from the ISP programmer.

This is discussed on avrfreaks http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=247971 where it suggests that these resistors may effect max communication speed. It also suggests removing them and adding a pullup resistor instead on each slave devices chip select pin.

Here is what that would look like


Note that using the spi code in WebbotLib you can bundle all of your slaves onto one bus. When you select one of the slaves then it automatically de-selects all other slaves on the bus.
« Last Edit: February 25, 2010, 11:02:58 AM by Webbot »
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

Offline AdminTopic starter

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,703
  • Helpful? 173
    • Society of Robots
Re: multiple SPI devices on single ATmega
« Reply #10 on: February 25, 2010, 11:06:47 AM »
And external resistors to disable the chip selects when the device is powered, but still in reset.
When you say 'And', I assume you meant 'Add'? (just making sure)

As I suspected, the CS line would need an external pull-up resistor as pins become tri-stated during reset.

I'll be using a 300kohm unless someone knows a better value for an AVR with a micro SD card. ;D

Offline GearMotion

  • Supreme Robot
  • *****
  • Posts: 489
  • Helpful? 24
  • Two decades+ of Embedded Design
    • CircuitGizmos
Re: multiple SPI devices on single ATmega
« Reply #11 on: February 25, 2010, 11:12:44 AM »
> When you say 'And', I assume you meant 'Add'? (just making sure)

Yes. Apparently my keyboard has a head cold.

> As I suspected, the CS line would need an external pull-up resistor as pins become tri-stated during reset.

> I'll be using a 300kohm unless someone knows a better value for an AVR with a micro SD card. ;D

Personally I tend to use 10k for pull up resistors. But that is from experience designing in noisy environments.

Offline AdminTopic starter

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,703
  • Helpful? 173
    • Society of Robots
Re: multiple SPI devices on single ATmega
« Reply #12 on: February 15, 2011, 06:17:00 PM »
This came up again for what I'm working on . . .

Anyone see a problem with using 3kohm for the SPI CS pullup pin, or is that potentially too strong?


edit: The reason I'm asking is that the ISP programmer won't work as long as I have the uSD card in the slot . . . if I remove the card, it works fine . . . I'm not sure if there is a way around this or not . . .
« Last Edit: February 15, 2011, 06:59:48 PM by Admin »

Offline Soeren

  • Supreme Robot
  • *****
  • Posts: 4,672
  • Helpful? 227
  • Mind Reading: 0.0
Re: multiple SPI devices on single ATmega
« Reply #13 on: February 17, 2011, 08:21:42 PM »
Hi,

Anyone see a problem with using 3kohm for the SPI CS pullup pin, or is that potentially too strong?
Not at all (unless you want to save power), if the controller pin is only driving this.
Regards,
Søren

A rather fast and fairly heavy robot with quite large wheels needs what? A lot of power?
Please remember...
Engineering is based on numbers - not adjectives

 


Get Your Ad Here

data_list