chipKIT SPI and SS pin about chipkit32-max HOT 7 CLOSED

There is a jumper for pin 10. That changes the it to support PWM.

The default position needs to be determined.

--Rick

On May 20, 2011, at 7:29 AM, [email protected] wrote:

Are you using hardware SPI with pre-assigned SS pin?

Arduino uses initSS, setSS, resetSS where you can define any pin for SS, which gives flexibility to make SPI shields when selecting the SS pin (this is the case of the Ethernet Shield, which uses pin 10 for SS, which is hardware SS for ATmega328 but it is not a hardware SS for the MEGA board)

Reply to this email directly or view it on GitHub:
#31

from chipkit32-max.

My question was around SPI... SPI is a bus where the slave selection is done using a dedicated pin. In theory you can have multiple SPI slaves in the same bus, but none sharing the SS pin. In Arduino, the SPI is implemented in a way that the SS pin selection is flexible. If in the chipKIT we fix the SS pin to the one determined by the microcontroller, then we will loose the flexibility.

Let me give an example

The Arduino Ethernet shield, one of the most popular shields, used to get the SPI signals from pins 13, 12, 11 and 10. But in the MEGA, the SPI signals moved to pins 50, 51, 52 and 53, making the Ethernet shield incompatible with the MEGA board. With the newly designed Ethernet shield, the Arduino team decided to get the SPI signals SCK, MOSI and MISO from the ICSP port, leaving SS flexible to pin 10 on the Uno/Duemilanove, which by the way it is the hardware SS pin, but on the MEGA it uses digital pin 10 even if it is not the hardware SS pin.

If we fix the use of the hardware SS pin on the SPI library for the PIC32, we are forcing all SPI based shields to get the signals from the hardware SPI signals, that are located in different places on both boards. The design team decided to bring SS to pin 5 on the ISP port, but the problem is that pin 5 is RESET on the Arduino boards and most shields routes RESET from the 6-pin header to the pin 5 of the ICSP port, making the SPI inoperable on the chipKIT boards (the micro cannot bring LOW the signal, as it is pulled up by a 10K resistor or a dedicated RESET chip).

I am not sure if this is a hardware or software issue, but somebody needs to make a decision. The decision will make the chipKIT boards more like the Arduino or diverge making future shield compatibility an issue.

from chipkit32-max.

The purpose of the reset signal on the ICSP connector is for doing in-system programming of the AVR part. There is a reset signal on the power connector that should be used if for some reason a shield wants to reset the processor. Why woudl the designers have put it there if that wasn't what it was intended to be used for. Given that there appear to be a lot of poorly designed shields in the world that tie together the two resets, the chipKIT boards probably should have a jumper that disconnects the reset/ss pin on the ICSP connector.

from chipkit32-max.

The original arduino did not have the reset signal on the power header, it was added later. I agree that joining both signals is not a good idea, now that the chip kit board is in town, before it was not a problem.

from chipkit32-max.

I didn't know that the early boards didn't have reset on the power connector. I retract my critical comment about shield designers.

However, it would have been nice if I had had the foresight to put in a jumper that could have been used to disconnect the reset/ss pin on the icsp connector. It would, not doubt, have eliminated a set of compatibility issues.

Oh Well....

from chipkit32-max.

Also the missing +5v supply in the icsp header generates incompatibility issues with small shields, that get the power from the small header instead of reaching far from the power header... Many xbee shields has small form factor without a power header.

One solution is to add the jumper for reset and +5v in V2 or create a hack that cuts the pins from then main board and adds a special protoshield board that adds the compatible pins...

from chipkit32-max.

This appears to be a hardware issue instead of code issue. If this isn't the case please feel to reopen.

from chipkit32-max.