Extended Pin Numbering

[finchamp]

I'm working on a Teensy 3.6 standalone application (with PJRC's MKL02) where I'll be using IO not currently defined in Teensyduino. I'm sure I'm not the only one, so I figured there might be others who would want to standardize an extended pin numbering scheme, or be willing to share what they have used. Any interest?

For reference, I organized all of the port addresses that are already available on 3.6 for easier identification of unused IO.

PTA_5
PTA_12
PTA_13
PTA_14
PTA_15
PTA_16
PTA_17
PTA_26
PTA_28
PTA_29

PTB_0
PTB_1
PTB_2
PTB_3
PTB_4
PTB_5
PTB_10
PTB_11
PTB_16
PTB_17
PTB_18
PTB_19
PTB_20
PTB_21
PTB_22
PTB_23

PTC_0
PTC_1
PTC_2
PTC_3
PTC_4
PTC_5
PTC_6
PTC_7
PTC_8
PTC_9
PTC_10
PTC_11

PTD_0
PTD_1
PTD_2
PTD_3
PTD_4
PTD_5
PTD_6
PTD_7
PTD_8
PTD_9
PTD_11
PTD_12
PTD_13
PTD_14
PTD_15

PTE_0
PTE_1
PTE_2
PTE_3
PTE_4
PTE_5
PTE_10
PTE_11
PTE_24
PTE_25
PTE_26

[brtaylor]

Maybe this helps visualize things, I added undefined signal pins in red and the Teensy 3.6 pin numbers.

MK66 Pins               Teensy 3.6 Pins
PTA0			N/A Programmer / JTAG
PTA1			N/A Programmer / JTAG
PTA2			N/A Programmer / JTAG
PTA3			N/A Programmer / JTAG
PTA4			
PTA5			25
PTA6			
PTA7			
PTA8			
PTA9			
PTA10			
PTA11			
PTA12			3
PTA13			4
PTA14			26
PTA15			27
PTA16			28
PTA17			39
PTA24			
PTA25			
PTA26			42
PTA27			
PTA28			40
PTA29			41
PTB0			16
PTB1			17
PTB2			19
PTB3			18
PTB4			49
PTB5			50
PTB6			
PTB7			
PTB8			
PTB9			
PTB10			31
PTB11			32
PTB16			0
PTB17			1
PTB18			29
PTB19			30
PTB20			43
PTB21			46
PTB22			44
PTB23			45
PTC0			15
PTC1			22
PTC2			23
PTC3			9
PTC4			10
PTC5			13
PTC6			11
PTC7			12
PTC8			35
PTC9			36
PTC10			37
PTC11			38
PTC12			
PTC13			
PTC14			
PTC15			
PTC16			
PTC17			
PTC18			
PTC19			
PTD0			2
PTD1			14
PTD2			7
PTD3			8
PTD4			6
PTD5			20
PTD6			21
PTD7			5
PTD8			47
PTD9			48
PTD10			
PTD11			55
PTD12			53
PTD13			52
PTD14			51
PTD15			54
PTE0			N/A Built In SD
PTE1			N/A Built In SD
PTE2			N/A Built In SD
PTE3			N/A Built In SD
PTE4			N/A Built In SD
PTE5			N/A Built In SD
PTE6			
PTE7			
PTE8			
PTE9			
PTE10			56
PTE11			57
PTE12			
PTE24			33
PTE25			34
PTE26			24
PTE27			
PTE28			
ADC0_DM0			
ADC1_DP0			A10
ADC1_DM0			A11
VREF_H			AREF
VREF_L			AGND
ADC1_SE16			
ADC0_SE16			
VREF_OUT			
DAC0_OUT			A21
DAC1_OUT			A22

[brtaylor]

Paul, if we agree on an extended pin numbering scheme, would it be possible for us to pull-request this and have it added to the core?

[defragster]

IIRC these SD pins were given numbers when KurtE made a PCB adapter for the SD slot and wired to them during K66 Beta - the numbers escape me though:

PTE0 N/A Built In SD
PTE1 N/A Built In SD
PTE2 N/A Built In SD
PTE3 N/A Built In SD
PTE4 N/A Built In SD
PTE5 N/A Built In SD

perhaps #'s 58-63:

#define CORE_PIN58_BIT 0
#define CORE_PIN59_BIT 1
#define CORE_PIN60_BIT 2
#define CORE_PIN61_BIT 3
#define CORE_PIN62_BIT 4
#define CORE_PIN63_BIT 5

[PaulStoffregen]

Undecided, but I definitely will not merge anything that accesses PTA0-PTA4.

[brtaylor]

Undecided, but I definitely will not merge anything that accesses PTA0-PTA4.

Hi Paul, that makes a lot of sense for PTA0-PTA3, there's no reason to access those pins. Is PTA4 used by the Teensy Core? All of the ARM documentation I've seen show it as NMI and configurable to a standard GPIO. I haven't seen it used on the Teensy schematics and am wondering why that would be a no-go.

[MichaelB]

Is PTA4 used by the Teensy Core? All of the ARM documentation I've seen show it as NMI and configurable to a standard GPIO. I haven't seen it used on the Teensy schematics and am wondering why that would be a no-go.

Recently I read a lot about custom teensy's so I think I am aware of Pauls thoughts about PTA4:
https://www.pjrc.com/store/ic_mkl02.html (search for PTA4 here)

Though I think about using the unused pins too in my custom design I appreciate the idea of numbering those pins...

[brtaylor]

Recently I read a lot about custom teensy's so I think I am aware of Pauls thoughts about PTA4:
https://www.pjrc.com/store/ic_mkl02.html (search for PTA4 here)

Though I think about using the unused pins too in my custom design I appreciate the idea of numbering those pins...

Thanks, that makes sense. Seems like the policy is to prevent a user setting it as NMI.

[finchamp]

If we want to have this merged into Teensyduino public releases, I think we'd better expect to require a special preprocessor definition for the extra pin numbers.

Say, #define MK66_extended_pins or #define Teensy_3.6_Pro

It doesn't even have to be included in the main documentation. As long as it's documented here, anybody doing serious development would run across it. Just my thoughts.

[finchamp]

Maybe this helps visualize things, I added undefined signal pins in red and the Teensy 3.6 pin numbers.

MK66 Pins               Teensy 3.6 Pins
PTA0			N/A Programmer / JTAG
PTA1			N/A Programmer / JTAG
PTA2			N/A Programmer / JTAG
PTA3			N/A Programmer / JTAG
PTA4			
PTA5			25
PTA6			
PTA7			
PTA8			
PTA9			
PTA10			
PTA11			
PTA12			3
PTA13			4
PTA14			26
PTA15			27
PTA16			28
PTA17			39
PTA24			
PTA25			
PTA26			42
PTA27			
PTA28			40
PTA29			41
PTB0			16
PTB1			17
PTB2			19
PTB3			18
PTB4			49
PTB5			50
PTB6			
PTB7			
PTB8			
PTB9			
PTB10			31
PTB11			32
PTB16			0
PTB17			1
PTB18			29
PTB19			30
PTB20			43
PTB21			46
PTB22			44
PTB23			45
PTC0			15
PTC1			22
PTC2			23
PTC3			9
PTC4			10
PTC5			13
PTC6			11
PTC7			12
PTC8			35
PTC9			36
PTC10			37
PTC11			38
PTC12			
PTC13			
PTC14			
PTC15			
PTC16			
PTC17			
PTC18			
PTC19			
PTD0			2
PTD1			14
PTD2			7
PTD3			8
PTD4			6
PTD5			20
PTD6			21
PTD7			5
PTD8			47
PTD9			48
PTD10			
PTD11			55
PTD12			53
PTD13			52
PTD14			51
PTD15			54
PTE0			N/A Built In SD
PTE1			N/A Built In SD
PTE2			N/A Built In SD
PTE3			N/A Built In SD
PTE4			N/A Built In SD
PTE5			N/A Built In SD
PTE6			
PTE7			
PTE8			
PTE9			
PTE10			56
PTE11			57
PTE12			
PTE24			33
PTE25			34
PTE26			24
PTE27			
PTE28			
ADC0_DM0			
ADC1_DP0			A10
ADC1_DM0			A11
VREF_H			AREF
VREF_L			AGND
ADC1_SE16			
ADC0_SE16			
VREF_OUT			
DAC0_OUT			A21
DAC1_OUT			A22

That is extraordinarily helpful, thanks! Can anyone think of a reason not to go numerically down the remaining pins? For example (I haven't double-checked these): new pin 58 on PTA6, new 59/A25 on PTA7, new 60/A26 on PTA8, etc.

[WMXZ]

IMO, only pins that a PJRC teensy can access should be within core. All other pins that custom boards are using have nothing to with core.
They only are source for confusion.

[Frank B]

I'm with WMXZ. Perhaps this is better kept in an extra library. With extra functions for pinMode (pinModeX, digitalWriteFastX etc...)

[finchamp]

I appreciate the input all. Whether or not anything from this thread gets merged into the TD core is currently beyond the scope of this thread, and immaterial to me. I'd like to steer us back to the original topic, if that's alright with everyone. I wanted this thread to be a place to share and gather our collective thoughts on pin extended definitions for those developing standalones and "bare metal" projects around the MK66 and PJRC's MKL programmer micros (i.e. Teensy 3.6 code-compatible).

Can anyone think of a reason not to go numerically down the remaining pins? For example (I haven't double-checked these): new pin 58 on PTA6, new 59/A25 on PTA7, new 60/A26 on PTA8, etc.

[KurtE]

Personally If I built a new board with new pins, I would personally prefer to set it up, where they are REAL pins. Otherwise they may be semi useless. That is probably could not use them with any normal library and the like.

Preferably it would be nice if you could somehow define them as a new board type. That is for example I would have hated it if when Paul came out with a Teensy 3.2 which maybe had more pins then Teensy 3.0, that I would have to remember to use pinModeT32(pinX, OUTPUT)... And then remember to call pinModeT35 for the new Teensy 3.5 pins...

But that is just me

[PaulStoffregen]

Can anyone think of a reason not to....

Extra unnecessary flash memory usage for all Teensy users with the standard hardware, due to larger lookup tables for pinMode and the non-inline versions of digitalRead & digitalWrite, would be the main reason.

[finchamp]

Personally If I built a new board with new pins, I would personally prefer to set it up, where they are REAL pins. Otherwise they may be semi useless. That is probably could not use them with any normal library and the like.

Preferably it would be nice if you could somehow define them as a new board type. That is for example I would have hated it if when Paul came out with a Teensy 3.2 which maybe had more pins then Teensy 3.0, that I would have to remember to use pinModeT32(pinX, OUTPUT)... And then remember to call pinModeT35 for the new Teensy 3.5 pins...

But that is just me

That's my thought as well. For now, I expect to include an extra header file in my projects to add the remaining definitions.

[finchamp]

Extra unnecessary flash memory usage for all Teensy users with the standard hardware, due to larger lookup tables for pinMode and the non-inline versions of digitalRead & digitalWrite, would be the main reason.

My apologies for not being clear with my question. I wasn't referring again to adding pins to the public Teensy core. I'm not concerned with actually merging them, honestly! A special header file is fine with me.

That question was to do with the numeric order of the *extra* pin definitions for those using the PJRC toolchain on standalone boards. I was thinking about just going sequentially down the remaining port addresses to define "friendly" pin numbers. Now I'm thinking it would make more sense to just define them per the datasheet, i.e.: PTA6, PTA7, etc, with the proper ADC and interface flags.

[defragster]

IIRC these SD pins were given numbers when KurtE made a PCB adapter for the SD slot and wired to them during K66 Beta - the numbers escape me though:
perhaps #'s 58-63:

I appreciate the input all. Whether or not anything from this thread gets merged into the TD core is currently beyond the scope of this thread, and immaterial to me. I'd like to steer us back to the original topic, if that's alright with everyone. I wanted this thread to be a place to share and gather our collective thoughts on pin extended definitions for those developing standalones and "bare metal" projects around the MK66 and PJRC's MKL programmer micros (i.e. Teensy 3.6 code-compatible).

Can anyone think of a reason not to go numerically down the remaining pins? For example (I haven't double-checked these): new pin 58 on PTA6, new 59/A25 on PTA7, new 60/A26 on PTA8, etc.

There is a lot of work and overhead with all the pieces and parts to be defined [good work on getting all the right and handy Paul for pins/ports/etc in use! ] - will require effort and care. As noted in post above pins 58-63 are already allocated.

Indeed as also noted - it would need to be outside normal install case to include it - but then be effective 'to the core' and all related functions.

(re KurtE) In some DIY cases a few pins are added - the extreme case of adding all available pins would be a large effort and take special effort ( like Brian is considering ) to make them all available.

[WMXZ]

I wanted this thread to be a place to share and gather our collective thoughts on pin extended definitions for those developing standalones and "bare metal" projects around the MK66 and PJRC's MKL programmer micros (i.e. Teensy 3.6 code-compatible).

If I ever have a custom application where I need to build a custom Teensy with other pins than in official Teensy, my preference is to give them the name that is close to desired functionality (as I do in PCB schematics) i.e. I2S0_MCLK etc. I do not see any need for having custom teensies being standardised (including pin numbering), after all they are customised. But I still may not get the purpose of (agreed) extended pin numbering.

[Theremingenieur]

If I ever have a custom application where I need to build a custom Teensy with other pins than in official Teensy, my preference is to give them the name that is close to desired functionality (as I do in PCB schematics) i.e. I2S0_MCLK etc. I do not see any need for having custom teensies being standardised (including pin numbering), after all they are customised. But I still may not get the purpose of (agreed) extended pin numbering.

That risks to be difficult... Example: The Teensy Pin 3 which might be PTA12 or I2S0_TXD0 or FTM1_CH0 or CMP2_IN0 or CAN0_TX or FTM1_QD_PHA, depending on how the MUX will be set in code. Thus, a kind of abstraction layer might be helpful. Not sure if an Arduino-like numbering system is best, since there are dualisms like digital pins 14 to 23 being at the same time A0 to A9 which already leads sometimes to confusion.

[XFer]

Now I'm thinking it would make more sense to just define them per the datasheet, i.e.: PTA6, PTA7, etc, with the proper ADC and interface flags.

Makes sense to me.

[WMXZ]

Thus, a kind of abstraction layer might be helpful.

Is that not what non-Arduino systems do, having a HAL?

[Theremingenieur]

A complete HAL would be exaggerated, eat up too much memory and slow down compiling. That makes only sense if you have to develop code intended to run on very different hardware.

I thought of a much simpler "just-the-pins" abstraction layer, similar to the Arduino/Teensyduino pin numbering scheme, but perhaps a little more logical and intuitive, even if this might break Arduino compatibility.

[finchamp]

But I still may not get the purpose of (agreed) extended pin numbering.

The purpose is the same as all open-sourcing: to save future developers time, effort, frustration, and to educate and lower the barrier to entry. If we can avoid it, why have a dozen people doing redundant work? That seems like a waste.

I also hope that this may benefit PJRC (and all of us in turn) by encouraging product development projects on the Teensy platform, and increasing bulk sales of Paul's programming co-processors.

Individuals may not prefer the scheme determined here, but it is more than likely that they would be well served to adjust their tastes to take advantage of pre-existing work (pending its quality) than to re-engineer something fundamental like this. I did ask for input here in the hopes that we could make it flexible and workable for the largest contingent of Teensy developers.

Direct port manipulation is certainly still available if you need to squeeze every clock cycle for all it's worth. I do not, and would prefer rather to streamline my code while making my particular device very flexible in the field.

This thread wasn't intended to start a debate on the merits of extra pin definitions. I have to define at least a few extra pins for my project, so we can either share our efforts, or burn up our time with redundancy. I mean all of this to be friendly and helpful, so I hope I do not offend.

-------------

Changing gears, I'm leaning toward defining pins as port addresses per the datasheet (as stated earlier), and creating a spreadsheet -- similar to the PJRC pin reference card -- with color coded documentation of what each pin is capable of. Thoughts?

[finchamp]

Makes sense to me.

Glad to hear it!

I thought of a much simpler "just-the-pins" abstraction layer, similar to the Arduino/Teensyduino pin numbering scheme, but perhaps a little more logical and intuitive, even if this might break Arduino compatibility.

I'd be curious to see what you have in mind, and how it differs from the current definitions. I'm flexible as to how we accomplish this, and I'm certainly open to hearing a better best-practice.