an FYI: on remapping the Teensy 3 LED and using SPI

stevech

Well-known member
The code below changes the Teensy 3 SPI SCK signal to move to pin 14, and use pin 13 as the normal LED pin. The peripheral gets SPI SCK on pin 14.
However... the code has to run after (or repeat) after the SPI port is first used. Often, an attached device using SPI (such as a wireless radio, or perhaps an SD card), is itself initialized by a call to its library. And that library initializes the SPI hardware port. That "undoes" the pin 13 mapping as above, but not pin 14 remapping. (don't know why).

So one has to repeat the at least the pin 13 remapping after the libraries involved have done their initialization.
(that took a while to figure out)

Code:
	  // Add by Adrien van den Bossche <vandenbo@univ-tlse2.fr>
	  #if  defined (TEENSYDUINO)
	  // First reassign pin 13 to Alt1 so that it is not SCK but the LED still works
	  CORE_PIN13_CONFIG = PORT_PCR_MUX(1); //   Alt1 = PTC5.  chip pin PTC5
	  // and then reassign pin 14 to SCK
	  CORE_PIN14_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2); // Alt2=SPIO_SCK.  chip pin PTD1
	  #endif
 
The recommended way it to use SPI.setSCK(), like this:

Code:
  SPI.setMOSI(7);
  SPI.setSCK(14);
  SD.begin(10);
(which in the case above, disables UART3, but this is just an example of SPI.setxxx()

so this
Code:
SPI.setSCK(14); // added this
CORE_PIN13_CONFIG = PORT_PCR_MUX(1); //   Alt1 = PTC5.  chip pin PTC5
runs OK and is equivalent (and better code) than the original code from Adrien van den Bossche...
Code:
CORE_PIN13_CONFIG = PORT_PCR_MUX(1); //   Alt1 = PTC5.  chip pin PTC5
// and then reassign pin 14 to SCK
CORE_PIN14_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2); // Alt2=SPIO_SCK.  chip pin PTD1

But these don't address the original inquiry here: the init() or begin() of the SPI library (not using SD lib) seems to undo the LED pin mapping on pin 13 so it has be remapped after the SPI init.
 
Last edited:
I'm using Teensyduino 1.20 and wanted to use SPI.SetSCK(14) to change SCK to pin 14 but it didnt't work. I debugged into SPI.setSCK and found the following code in avr_emulation.h at lines 1022 (member function SPCRemulation::enable_pins())

Code:
if ((pinout & 4) == 0) 
{
     CORE_PIN13_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2); // SCK = 13 (PTC5)
}
else 
{
      CORE_PIN14_CONFIG = PORT_PCR_MUX(2); // SCK = 14 (PTD1)
}

Changing the last line to
Code:
CORE_PIN14_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2); // SCK = 14 (PTD1)
fixes the issue for me. If this is a bug, it would be great if it could be fixed in the next Teeensyduino release.

Thanks
Lutz
 
adding PORT_PCR_DSE will enable Drive Strength Enable on pin 14. So perhaps it depends on what device(s) you connected to SPI that it requires the higher drive strength. It does not make sense that if SCK is pin 13, DSE is enabled, but not if SCK is pin 14. So I agree that it should be enabled regardless if it is pin 13 or 14.
 
come to think of it, the DSE is needed on pin 13 due to the LED load. But I don't think it will harm anything if DSE is enabled on pin 14. All digital pin in output mode have DSE enabled by default, not just pin 13.
 
That makes sense. I have two spi slaves on the bus. Estimating 10pF input capacitance on each slave that would give a capacitive load of X=1/(2pi f C), I = U/X which is about 1mA @24Mhz. Might be too large without DSE set.
 
Back
Top