SPI for 5 slaves - custom PCB design

Hey all,

I am currently designing an own board for a 3D-printer having 5 TMC2130 stepper drivers. The board is based on a SAM3X8E (like Arduino Due or Ultratronics). There is already a discussion about the TMC2130 ....
I don't want to control the TMC2130 via SPI but the standard step/dir/en control. But I want to configure the drivers via SPI on startup and maybe add some custom M-commands for reconfiguring them during runtime or reading some errors or whatever. Therefore I will have to add some custom code in Repetier firmware, maybe using this API. But currently I am not at this point so far, so this is a hardware question:
The thing is the SAM3X8E has actually two HW SPIs, SPI0 and SPI1. Repetier firmware supports SPI0. There is also a SW SPI that is known to be pretty slow but that shouldn't be a problem. When using the HW SPI0 I can connect up to 4 slaves on the lines NPCS0 to NPCS3. That is unfortunately one less than needed. Actually there are only 3 SS available for the Arduino Due: 4, 10, 52. Again this depends on some configuration as the line NPCS0 could be used for Mode Fault detection....

So there are a couple of solutions in my mind right now:

- I could use the SW SPI. But I am not sure how many slaves are supported and as the SAM3X8E has two HW SPIs it would be sad not using them.
- I could connect 3 slaves on SPI0 and 2 slaves on SPI1. I alter the SPI code in HAL.h and HAL.cpp and add SPI1. When transmitting anything via the SPI-class I need to distinguish by the driver number which SPI to use. Therefore this would be a fast solution by (simply spoken) copying the SPI0 code and changing it to SPI1. A little more code here and there and it should be working.
- I could stay with SPI0 and use the "Peripheral Chip Select Decoding"-Feature described on page 687 of the SAM3X8E datasheet. In this case some bits in the Mode and Transmit Data Registers have to be changed so the value of the PCS field represents a binary number corresponding to a certain driver. The NPCS0..3 lines are not connected to the slaves but to an multiplexer chip. The value of the NPCS lines would be something like: 0000 -> no driver selected, 0001 -> driver 1 selected, 0010 -> driver 2 selected, 0011 -> driver 3 selected and so on.
I will have to alter some of the SPI code in the HAL files to change the PCS and PS fields and maybe alter some general logic in it. But this should also work.


Can anyone recommend the best solution? I am not very much in the Repetier Firmware Code right now as I first want to finish my hardware design before getting to the software part. I prefer solution 2 or 3.

I am thankful for any help and recommendations. If there is any interest I will share my custom code to get the driver running as soon as it's working (in a couple of months, I am still designing the schematics of the board....)

Best regards
Stefan

Comments

  • - I could connect 3 slaves on SPI0 and 2 slaves on SPI1. I alter the SPI code in HAL.h and HAL.cpp and add SPI1. When transmitting anything via the SPI-class I need to distinguish by the driver number which SPI to use. Therefore this would be a fast solution by (simply spoken) copying the SPI0 code and changing it to SPI1. A little more code here and there and it should be working.

    I just realized SPI1 is only available in the 217 pin package of SAM3x8E. Seems like it's gonna be option 3.
  • Hardware SPI is currently quite a pain since apart from having 4 hardware SS there are also different speeds and modes and solution s displays/sd card handle all this. So the best solution I think is having software SPI for this. Then you do not get into conflict with existing SPI uses and we only support step/dir/enable anyway for performance reasons. So all it is good for is configuring the drivers and there time is not a factor. When running you have step/dir/enable and the stall guard pin if you start adding usage for this.
  • Thanks for the info. I also came to the conclusion that the software SPI is going to be the best solution as it's still fast enough and communication is only at the beginning and never during printing. 
    I will keep this thread updated...
  • hi,

    sorry to jump in.. why would you use SPI over I2C
    I2C handles collisions and bus much better.
  • 3didd said:
    hi,

    sorry to jump in.. why would you use SPI over I2C
    I2C handles collisions and bus much better.
    Not sure if I understand your question? Why I am using SPI instead of I2C?
Sign In or Register to comment.