Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 3 1 2 3 LastLast
Results 1 to 25 of 52

Thread: Extended Pin Numbering

  1. #1
    Member
    Join Date
    Aug 2018
    Location
    Fort Worth, TX
    Posts
    38

    Extended Pin Numbering

    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.

    Code:
    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

  2. #2
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    584
    Maybe this helps visualize things, I added undefined signal pins in red and the Teensy 3.6 pin numbers.
    Code:
    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

  3. #3
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    584
    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?

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,734
    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

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,069
    Undecided, but I definitely will not merge anything that accesses PTA0-PTA4.

  6. #6
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    584
    Quote Originally Posted by PaulStoffregen View Post
    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.

  7. #7
    Junior Member
    Join Date
    Mar 2017
    Location
    Germany
    Posts
    18
    Quote Originally Posted by brtaylor View Post
    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...

  8. #8
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    584
    Quote Originally Posted by MichaelB View Post
    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.

  9. #9
    Member
    Join Date
    Aug 2018
    Location
    Fort Worth, TX
    Posts
    38
    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.
    Last edited by finchamp; 10-22-2018 at 08:56 PM.

  10. #10
    Member
    Join Date
    Aug 2018
    Location
    Fort Worth, TX
    Posts
    38
    Quote Originally Posted by brtaylor View Post
    Maybe this helps visualize things, I added undefined signal pins in red and the Teensy 3.6 pin numbers.
    Code:
    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.

  11. #11
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,909
    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.

  12. #12
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,096
    I'm with WMXZ. Perhaps this is better kept in an extra library. With extra functions for pinMode (pinModeX, digitalWriteFastX etc...)

  13. #13
    Member
    Join Date
    Aug 2018
    Location
    Fort Worth, TX
    Posts
    38
    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.
    Last edited by finchamp; 10-24-2018 at 09:53 PM.

  14. #14
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,931
    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

  15. #15
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,069
    Quote Originally Posted by finchamp View Post
    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.

  16. #16
    Member
    Join Date
    Aug 2018
    Location
    Fort Worth, TX
    Posts
    38
    Quote Originally Posted by KurtE View Post
    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.

  17. #17
    Member
    Join Date
    Aug 2018
    Location
    Fort Worth, TX
    Posts
    38
    Quote Originally Posted by PaulStoffregen View Post
    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.

  18. #18
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,734
    Quote Originally Posted by defragster View Post
    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:
    Quote Originally Posted by finchamp View Post
    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.

  19. #19
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,909
    Quote Originally Posted by finchamp View Post
    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.

  20. #20
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,591
    Quote Originally Posted by WMXZ View Post
    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.

  21. #21
    Senior Member
    Join Date
    Oct 2015
    Location
    Roma (IT, EU)
    Posts
    339
    Quote Originally Posted by finchamp View Post
    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.

  22. #22
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,909
    Quote Originally Posted by Theremingenieur View Post
    Thus, a kind of abstraction layer might be helpful.
    Is that not what non-Arduino systems do, having a HAL?

  23. #23
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,591
    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.

  24. #24
    Member
    Join Date
    Aug 2018
    Location
    Fort Worth, TX
    Posts
    38
    Quote Originally Posted by WMXZ View Post
    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?
    Last edited by finchamp; 10-25-2018 at 08:04 PM.

  25. #25
    Member
    Join Date
    Aug 2018
    Location
    Fort Worth, TX
    Posts
    38
    Quote Originally Posted by XFer View Post
    Makes sense to me.
    Glad to hear it!

    Quote Originally Posted by Theremingenieur View Post
    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.

Posting Permissions

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