deschain:
Hi chucktodd,some time passed since your last comment here but I've looked exactly for this topic (SS pin 53 as an output on Mega in communication by SPI e.g. the ethernet shield).
As I studied the datasheet of the ATmega2560 I found an interesting statement in table 21-1 (page 192 in the complete version of the datasheet).
It explains that it does NOT matter ("user defined"), if this pin is defined as in- or output in the MASTER-mode.Are you sure this is an hardware-issue. As the hardware appearently accepts either data direction IMHO it only can be a software- (library-) issue. Maybe only one additional codeline is enough to define the Mega as master before starting every single communication.
I haven't even tried it yet but it seems to be able to be solved easily.
I am sure you have much more experience in the arduino- libraries, so I'd like to know your opinion if it is worth it to dig into their intestines and explore (and maybe fix) the reason for SPI not working with pin 53 as an input.
deschain
DesChain,
Read a little more of the Datasheet, In section 21.1.2 page 200 of 2549P–AVR–10/2012. It tells you the bad things that will happen if the SS pin is INPUT and LOW with the SPI interface enabled in Master mode.
Since this sequence of events changes the SPI hardware from Master mode to Slave mode, AND the SPI library is in a tight loop waiting for:
/* Wait for transmission complete */
while(!(SPSR & (1<<SPIF)))
AND Slave mode changes SCK to input (external Clock), And Since the ARDUINO was the clock source the Library code is FOREVER lock in this tight loop waiting for SPSR (SPI Status Register, SPIF bit (SPI Interrupt Flag, set when a byte is completely shifted out) to be set.
Since the Clock has no one driving it the SPI Hardware never set this flag. So your Arduino sketch hangs.
Chuck.