Remapping pin 13

Status
Not open for further replies.

stevech

Well-known member
Remapping SCK/pin 13 [SOLVED]

From the RF22 library, this code attempts to remap SCK from pin 13 to pin 14 so that the onboard LED on pin 13 can be used without affecting SCK.
What I see via my scope is that SCK appears on both pins. I'm not studied on the K20 pin mapping, so is there a kind soul that has a correction?

Code:
    // Add by xxx (name redacted)
    #if defined (__MK20DX128__) || defined (__MK20DX256__)
    // First reassign pin 13 to Alt1 so that it is not SCK but the LED still works
    CORE_PIN13_CONFIG = PORT_PCR_MUX(1);
    // and then reassign pin 14 to SCK
    CORE_PIN14_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2);
    #endif
Does the Teensy3 AVR-compatible SPI library undo this?
 
Last edited:
The RF22 library uses SPI so I think all you need is this:
Code:
  SPI.setSCK(14);
It is what the Audio library's PlayWavFromSDCard example does.

Pete
 
Well, the RF22 library code has #if defined for Teensy 3.0 and 3.1 but declares a different class for spi, leading to this error
RF22.cpp:102:8: error: 'class GenericSPIClass' has no member named 'setSCK'

when I changed the code shown above to instead be
Code:
_spi->setSCK(pin);
(the author used a class pointer because there can be multiple instances of this hardware (run time new instances) and each has a different CS and interrupt vector. I didn't want to do major surgery on the RF22 library.
 
Last edited:
Solved, as follows:

The code to remap, shown above in this thread was "undone" by code in the Teensy AVR compatibility SPI driver (not the Teensy3 FIFO SPI driver).
Cure was to repeat the code shown above in my application, just after calling the .init() for which in turn calls .begin() in the AVR compatibility code.
This done, pin 13 gets moved back to an I/O output bit rather than being a copy of the SPI SCK function.

I did the duplicate code solution since I didn't want to alter the library source code for RF22. Since the library has the K20 remap pins 13, 14 code in it under an ifdef, I suspect that this pin 13 remap bug has always been there.

The RF22 library has a generic SPI class with virtual references that wind up being the AVR >or< the Teensy3 AVR compatibility code. Kind of confusing.
 
Hello i am new so please put the blade away.
i am a bit confused as to why on earth was the only SPI pinned on Tensy 4.0 saddled with an LED in the first place. i have a major project going that uses the 4.0 and now i am confused as to what to do as i need SCK pin to 6 daisy chained shift registers. do i disconnect the LED or do i do a permanent as described above which i think is bogas for this level of the game in post production.
 
The Arduino UNO processors (from which Teensy derives some of their pinouts) had the same issue with pin 13 being both SCLK and and the built-in LED.

In theory, other than flashing the LED, there should be no problems, since SCLK is an output, just like the LED is. There are some issues if you use pin 13 as an input, since pin 13 has a resistor for the LED. Note, I am a software guy, not a hardware guy, so there may be some issue with using 6 devices on the SPI bus that you don't see with 2-3 devices.

There are two additional SPI buses on the 4.0, but they are harder to get to. The SPI1 bus has 2 pins in solder pads under the Teensy at the back (MOSI1 is pad 26 and SCLK1 is pad 27), plus using pin1 for MISO1 (which means you can't use Serial1). The SPI2 bus has its pins underneath the Teensy for attaching a micro-SD card, but you can use it as a normal SPI device.
 
You may also run into issues when you try to run the SCK to multiple SPI devices. If the SCK (or any of the other signals) are connected directly from the Teensy to all the devices with only separate chip selects, the added capacitive loading can make high SPI clock rates difficult to accomplish. If by "daisy-chained shift registers" you mean that the SCK and other signals go into the first device, then go out of the first device to the next through a driver in the shift register you may be OK.

This issue came up a few months ago in another thread: https://forum.pjrc.com/threads/59942-Teensy-4-0-SPI-transfer-causing-program-to-hang-die-when-connected-to-SPI-peripherals
 
Thank you both for your replies.

mborgerson;

I have 6 shift registers in the circuit and the SCK goes to all 6 and not 34+ like in the link. out of respect for this thread i think i will start a separate thread as i need help on programming anyways as i am new to Arduino and definitely SPI.
 
Status
Not open for further replies.
Back
Top