Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 9 of 9

Thread: Gray pins

Hybrid View

  1. #1
    Junior Member
    Join Date
    Jul 2016
    Posts
    3

    Gray pins

    On the pin assignment card, what do the grayed-out pin names mean? For example on the 3.6, pin #5 has TX1 and MISO1 grayed.

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,432
    It means, that the pin CAN do that function, but it is not the default pin to do that function.

    Example Pin5, the default for TX1 is pin 1, but you can use pin 5 instead. But you must, first do: Serial1.setTX(5);

    Likewise it CAN do be the MISO pin for SPI1, but the default for that is pin 1. So again to use, you must first do SPI1.setMISO(5);

  3. #3
    Junior Member
    Join Date
    Jul 2016
    Posts
    3
    Thank you!

  4. #4
    On a (possibly) related note: When there are pin duplicates in black (not gray) such as pins 20 and 21 on a Teensy 3.6, and both are marked as CS0,...that means that both pins have the same primary function by default,...right? I just have this obsessive *thing* about being absolutely sure...

  5. #5
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,685
    CS means chip select, so multiple SPI devices will share clock, Master out/slave in and Master in/slave out data pins but each have their own chip select that only connects to them to indicate when they should be using the bus. So it is normal to have multiple chip selects running, one for each SPI device in use. If you have not allocated that chip select pin to any SPI device (or more precisely, to a library controlling a device) then you can use it for whatever else you want and the rest of SPI functions normally.

    If you are using random Arduino libraries the convention is to default chip select to pin 10 unless otherwise specified, and some basic libraries don't allow it to be changed at all so keep that in mind when working out where to put things.

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,029
    The SPI chip select pins are a special and somewhat complicated case.

    The pins labeled as chip selects are the special ones which can be automatically controlled by the SPI hardware. Only a very small number of libraries actually use the hardware chip select feature. For most cases, little to no actual speedup results from hardware CS control (and in some cases the added complexity of using the hardware feature can end up slower that just using GPIO to control the CS pin). Almost all libraries just use digitalWrite or direct GPIO registers, so any digital pin can be used with normal SPI code. These no need or advantage to using the special CS pins with all the normal SPI code out there.

    However, some libraries like ILI9341_t3 do use this special SPI hardware feature (together with the FIFO) for a very dramatic speedup. ILI9341_t3 actually uses 2 of those pins, one for the CS signal and another for the display's DC signal. So with ILI9341_t3, you're limited to connecting those 2 signal to any of the CS0 pins.

    To make matters even more complicated, there are actually alternate pins for the CS0 signals. We tried showing those on the early versions of the Teensy 3.0 reference card. But it was just complicated. The 5 CS0 pins would more properly be called actually CS0_0, CS0_1, CS0_2, CS0_3, CS0_4. There are alternates for CS0_0, CS0_1, CS0_2, CS0_3. But if you're using a library like ILI9341_t3, nothing will work if you connect to CS0_0 and the alternate pin for CS0_0, because it depends on using two *different* CS0 pins. Likewise for the very unlikely case where you find two different libraries both using the special CS hardware feature. Trying to show both the SPI port number and also which of the special pins within each port gets to be too much complex information to pack onto that small card, especially for a hardware feature that isn't actually used by nearly all the SPI programs and libraries.

    Showing only the primary hardware-enabled pins works out pretty well. The common usage model for SPI is 3 signals shared by all SPI chips on the same bus, and then a dedicated control signal for each chip. The card shows you can connect 5 such signals, implying up to 5 SPI chips on the bus, and it guides people to use the chips which can be controlled by hardware, even though very few libraries actually make use of that hardware feature.

    If you *really* want to dig into the finer details, the signal mux chapter (chapter 11 starting on page 181) in the reference manual has much more detail about the capability of every pin. You can use the schematic to translate between the Arduino pin numbers of Freescale's native names which appear in the reference manual. The pinout card shows only a subset, which fits onto the card and fits within the simplified model of hardware that people understand from Arduino.

  7. #7
    Okay, Paul...now I have to ask this...but...are you psychic, or something? No, really...! !! !!!
    I love how it says "Do not program the same function to more than one pin" in the documentation.
    Last edited by ariesboy571; 01-03-2018 at 03:11 AM.

  8. #8
    The reason I was asking the question is this:
    I have an Adafruit Feather M0/LoRa, and an Adafruit Feather M0 Breakout. I was testing connecting a MCP3008 A/D converter (8 channels, SPI interface) to the Feather LoRa, and...got nothing, even with the radio classes not instantiated, and the recommended I/O pin 8 set to LOW. There is something about that radio, that makes the SPI bus unusable on all the Feather LoRa's I've tried. However, when I tested the same chip with the Feather Breakout (nothing at all on the SPI bus) the MCP3008 chip worked beautifully. My understanding of SPI is, admittedly, rather low today. I'll bet that's different by this time next week, and I'm honestly looking forward to this next phase of education rather a lot!
    I did, however, have to change the architecture of the project to use Teensy 3.6's all round though. Thank you, Paul, for putting three SPI buses on that thing...it was, and continues to be, a work of art...!

  9. #9
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,685
    A useful place is
    https://www.pjrc.com/teensy/td_libs_SPI.html
    Common failure modes with multiple SPI devices include:
    Libraries not properly resetting chip select when finished with data
    Libraries assuming SPI settings will be unchanged between sends (where another library makes changes)
    Code that allows partial SPI send (say writing pixels to a display) to be interupted by something else without handling settings and chip select
    Hardware that does not handle slave out/master in correctly - when not chip selected this should be high z/off to avoid interfering with other devices - Some ILI displays do this, and prevent use of the onboard SD card - this may be what is happening with your LORA board.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •