HELP with SPI

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

--------------------------------------------------------------------------------
Hi,
I have to start a new design using nodes connected via SPI (due some external reasons I can not use another bus) and have a few questions:

1. Wich is the maximium practical distance I can transmit data with SPI at rates from 2 to 4 Mbits/s? I want to use flat cable like the one that comes with the STK500 for the In System Programming via SPI, but longer.
2. I found that some small AVR parts (i.e. Tiny) does not have the SS signal in their SPI port. Is this signal essential in order to get the SPI working? For example, I want to use 10 ATMega88 connected with SPI but without connecting the SS line at all.
3. There are four "SPI Modes" (0 to 3) and I do not know for wich applications should I use wich mode.

Thanks in advance for any help you can bring me!
Julián

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

The use of SS is for "slave select". If you are connecting ten AVRs then one will be a master and nine will be slaves. The master will identify which particular slave he wants to respond by taking that slave's SS line low. For the master this is just any PORT pin you choose to use for the task but for the slaves it's a dedicated pin that's part of the SPI interface and is how that particular AVR knows it is the one to receive the MOSI signal and drive it's reply out on the MISO line.

As for the 4 modes - take your pick when they are all AVRs that you are programming - the only reason for allowing the selection is that usually the AVR is connecting to a peripheral in which the mode of operation is cast in stone so the AVR has to be able to adapt

Cliff

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

Thank you very much for your response. I have another question about SS: Can I activate the SS lines in all the slaves so the master sends "broadcasts" to all the them at the same time? Or this may create some kind of conflict in the SPI bus?
Regards,
Julián

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

Did you mention how many nodes, speed, and distance? The 9 bit multiple master uart mode on rs485 sounds like a great way to hook a bunch of nodes together.

Imagecraft compiler user

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

juliandasilva wrote:
Thank you very much for your response. I have another question about SS: Can I activate the SS lines in all the slaves so the master sends "broadcasts" to all the them at the same time? Or this may create some kind of conflict in the SPI bus?
Regards,
Julián

All of the slaves will try to send their responses simultaneously. That can potentially lead to conflict on the MISO line.

Why do you have to use the SPI bus? Because those are the only pins that are free?

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

Hi, thanks for your responses. The project is a small reconfigurable sensor and effector net on an experimental mobile robot platform. We need to use the SPI port for the following reasons:

1. Need up to 4 Mbits/s transfer rate.

2. The devices are must be fully reprogrammable at run-time, and we have bad experience with bootloaders cause some times in some strange conditions in very different projects the M8's flash corrupts and the bootloader does not work anymore (the problem is that the failures were not when the bootloaders were reflashing so we think it's a problem on the mcu itself, not a soft problem). So with the SPI plus the reset signal we can reprogram the AVRs using it's hardware InSystem Programing interface.

3. We do not want hardware addressing (like TWI has), we will use a hi-level human readable soft addressing scheme, and that's because we want to use the SPI with the master broadcasting to all the slaves in the net.

We only have AVRs attached to the device net, so my last question was: Is the SS needed in this scheme, were no slave will answer at least it receives its hi level protocol ID, or there is something I'm not taking in account?

Thanks a lot!

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

If you DON'T use SS or some other kind of chip select sequence, how are you going to recover/resynchronize when every fram is not perfect? (And ALL the frames will NOT be perfect.)

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I'd like to check the calcs that show 4 megabits per second is required. If you send 10 bytes at 100kbps or so that takes 1ms. You could send 1000 commands a sec to the robot. That would make it river dance. Yet you say it needs to be 40 times faster than that?

Imagecraft compiler user

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

Quote:

If you DON'T use SS or some other kind of chip select sequence, how are you going to recover/resynchronize when every fram is not perfect? (And ALL the frames will NOT be perfect.)

That's exactly the kind of problems I'm asking for, due to my no-experience working with SPI, I started the topic asking why SS is so necesary if some tiny parts have SPI interface without the "SS funcionality".

Bob: Regarding the calcs, I understand what you are saying, the problem is that this development is not just for a robot, it's for a set of reconfigurable ones, and the user can add whatever sensor he may want. ie: acceleromenters, a lot of different range, mics and even CCD linear pixel arrays or small CMOS image sensors. So when I found that a so small and cheap interface like SPI can do it and more, I liked it to be used here. More, I have worked with 485 a lot in big security projects and I really don't like it for this project (for many reasons).
Finally: now the main reason to use SPI in this project is what I mentioned about the ISP by hard (of course adding the reset line, taking in account that the transmission distances in these robots are short).

Thanks again.

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

IIRC, ALL slaves will answer (if only with junk) due to the SPI protocol. If you send a message to 10 devices with no SS, then all 10 will place data on the MISO line at the same time. If they all send 00 or FF then I guess there is no problem. However, to get data from one of the units, without SS there is no way to disable the others from responding at the same time. Am I missing something or need some more coffee???

Randy

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

I *suppose* you could work up a protocol with a single SS line from the master (output) to all slaves in parallel (inputs). Each slave could initially have its "transmitter" disabled, by setting the appropriate DDR pin as an input. They could all listen for incoming messages.

Byte 1 might be an "address".
If the address is "broadcast" then all the slaves would simply listen to the remainder of the message.
If a specific slave detects that it has been addressed, then it would set the appropraite DDR setting to make its MISO pin into an output.

Byte 2 might by a "operation type".
At some point during this byte, the addressed slave will be in the middle of changing its MISO pin into an output.

Bytes 3 to the end of the message would be application-specific content, in both directions. The Master might be sending arguments to augment the "operation type" code. The addressed slave might be sending response codes. In either case, the Master is responsible for determining whether or not to continue the transaction, and would be responsible for feeding "dummy" bytes if it runs out of things to say but still has more information to extract from the slave.

As soon as the SS pin is released, the addressed slave would return its MISO pin's DDR configuration to an input state. All slaves would return to the "looking for address" state.

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

Thanks, something like that is what I need to implement. Any other recommendation?

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

I'm not even ready to call that a recommendation. It's more in the "brainstorming" stage right now.

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

juliandasilva wrote:
Thank you very much for your response. I have another question about SS: Can I activate the SS lines in all the slaves so the master sends "broadcasts" to all the them at the same time? Or this may create some kind of conflict in the SPI bus?
Regards,
Julián

If you multiplex the MISO lines then this could be done. Otherwise all the slaves are going to be attempting to drive each other's MISO lines, which would be ugly.

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

nleahcim wrote:
juliandasilva wrote:
Thank you very much for your response. I have another question about SS: Can I activate the SS lines in all the slaves so the master sends "broadcasts" to all the them at the same time? Or this may create some kind of conflict in the SPI bus?
Regards,
Julián

If you multiplex the MISO lines then this could be done. Otherwise all the slaves are going to be attempting to drive each other's MISO lines, which would be ugly.

As a matter of fact, when the SPI subsystem is configured as a slave, the MISO pin's data direction is left under the control of the DDRx register. So that's not strictly true.

You could make all the slaves leave their MISO pins in the INPUT configuration while idle, and then only one slave would turn its MISO pin into an output if it picks up an incoming "packet" addressed for it.