Questions about pin modes at ARM level

[chase_c]

Hi all,

I have been using Teensy, and the Teensyduino libs, for a proof of concept device and the team I am working with have presented a couple of questions related to the ARM chip and pin modes. If someone could clarify some of these questions it would be greatly appreciated.

So far I have pointed them to “core_pins.h” in hopes that it will at least provide more context as to what is happening. Here are their questions:

1. In the ARM side there are pins name PTA0 to PTA19 and PTB0 to PTB19, PTC0 to PTC11, PTD0 to PTD11. These are multiplexed pins. There are multiple alternate definitions for those in the ARM manual. The port control module selects which mode the pins operate in (pages 207-210 in the K29P64M72SF1RM manual). I am guessing by looking at the table that the mode selected is ALT1.
2. If we confirm it is ALT1, then it looks like all the pins are mapped as they are to the system. Somehow they need to be interpreted internally. Who does that?
3. What happens to analog input pins in our design for example PTC1, PTC2. I would assume they need to be converted to digital through an ADC. But under the ALT1 mode there are no ADC connections. But these connections exist in other modes. But If you choose the other modes, there are different interfaces assigned to other pins like SPI, I2C, UART etc., which are not needed for the functionality of the buttons. So I would like to understand what mode and how these inputs into the pins are interpreted on the ARM/firmware side – Meaning what functionality are these pins actually performing on the ARM side?

Again, any help would be greatly appreciated and I really enjoy using Teensy for my projects! Thank you for your time.

Cheers,
Chase

 

[Theremingenieur]

By default and after reboot, all pins are in default mode, which means ALT0 (tri-state for most, analog for the A pins). Only when you call pinMode() for a specific pin, its MUX configuration will be set to ALT1. All pins which have digital pin numbers on the Teensy 3.2 card (but not A10 - A14 which have no digital pin numbers) can be muxed as digital pins. So, no conversion or whatsoever needed. The correspondance between the internal pin designators (i.e. PTBx) and the Teensy pin number can be found on the Teensy schematics page of the PJRC website. Note, not all K20 pins are routed to the Teensy outside pins or the pads underneath, a trade off had to be done to "export" a maximum of internal hardware building blocks (SPI, I2S, I2C, CAN, FTM and so on) and to maintain Arduino compatibility with the limited space and outside pin count.

When you call analogRead(), the pin will remain in ALT0 but the ADC MUX (a thing a part) will route the pin to the ADC.

 

[chase_c]

Thank you so much for this explanation. I'll pass this along to the team!

 

[PaulStoffregen]

If we confirm it is ALT1, then it looks like all the pins are mapped as they are to the system. Somehow they need to be interpreted internally. Who does that?

I don't fully understand the context of this question, but I can try to answer "who does that".

Normally if you'll use the pin for digital I/O, you would use the pinMode() function to first configure the pin. The code inside pinMode() takes care of configuring these settings.

When you use the pins for their alternate functions, normally you'd call a library's begin() function which configures the pins. For example, SPI.begin() will configure pins 11, 12 and 13 to work as the SPI port. Or Serial1.begin() will configure pins 0 and 1 to work as Serial1.

Of course if you want to write your own driver-level libraries or just tinker with direct access to the hardware, you certainly can. Then the answer to "who does that" is you, you do it. But normally the way Teensy is used involves leveraging the many libraries. Then the normal answer is the library does it.

Likewise when you use your PC, normally those sorts of things happen inside the device drivers. Normally most programmers developing for PCs don't write their own drivers. But if you *really* want to dig into those low-level details, you certainly can.

 

[chase_c]

Hi Paul, thanks for the further clarification. If there are any additional questions from the team I'll point them to this thread so they can provide the necessary context to get the answers they need. Thank you for your time!