Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 10 FirstFirst 1 2 3 4 ... LastLast
Results 26 to 50 of 243

Thread: Teensy 4.0 (hypothetical) pin assignments

  1. #26
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,385
    Thank you, MichaelMeissner, for that additional info. I’m unable to locate the DAC pins in Paul’s list, though. But if the the DACs are there, I’m sure that Paul will bring the pins out. Are these and the ADCs still 12bit or might we expect true 16bit?

    Edit: Just went through the reference manual searching for „DAC“. Could only find the 6bit DACs for the analog comparators mentioned.

  2. #27
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,380
    @Thierry … Same findings … : 6 bit DAC for comparator feeding was all I saw - no external pin reference …

    KurtE - from p#22 - was this in reference to UARTS I assume? :: "few projects that really needed/used more than 3 of the T3.2, so having 5 is more than sufficient"

    After asking tonton81 about his SPI and the creation of SPI_MSTransfer - that turned out to be a great way to have a Teensy connect at SPI Speeds to other Teensy's. The offers bidirectional transfers on the order of 50 uS for 10 DWORDS. So having a spare SPI port on the new T_4.0 could make it easy to interconnect slave Teensy's for added pins. And that protocol included support for control of Slave: with Data messages and I/O, USB, I2C, USB, …

  3. #28
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,929
    I'm sad to say this chip does not seem to have any DACs, other than the 6 bit ones built into the analog comparators. I'm pretty sure the info on page 212 is a mistake. I've found dozens of other mistakes. This first version of the manual appears to be riddled with errors where info from other chips was copied.

    Also missing is the 1.2V internal reference, and the ability to use an external reference. The diagram on page 481 also seems to be a mistake. The reference signals appear to be connected to VCC and GND inside the chip, not actually brought to any pins. The ADC also does not appear to be nearly as good. They calling it 12 bits, but there's info saying 10 ENOB, and even that appears to be specified with a very low 1K source impedance. While disappointing, this shouldn't be too surprising. It's well known trend that small process nodes give dramatically more capable digital circuitry but aren't as good for analog circuits as the older processes.

  4. #29
    .

    Will there be any option to boot from SD (some jumpers/switches), or only from QSPI?
    I suppose there will be no hyperflash.

    About SPI, I would prefer that there were two available in the 24 pins. Or if it is not possible, that is as in the Teensy 3.6, one of quick access in the 24 pins, and the other in the internal contacts.

    .

  5. #30
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,929
    Quote Originally Posted by LuisHS View Post
    Will there be any option to boot from SD (some jumpers/switches), or only from QSPI?
    This is one of many issues I've been considering. Of course it depends on whether the 6 signals for SD cards manage to come to pads on the bottom side, and if you somehow add a SD socket. There's no way a SD socket can fit onto the small 1.4x0.7 inch form factor.

    I'm actually considering selling 2 versions. The main/default version will come with the boot fuses set to only boot from QSPI. All the essential settings will be permanently fixed, so people can't brick their board.

    An alternate "lockable" version, probably to appear ~6-12 months later (definitely not launched at the same time), will come with all the fuses unprogrammed. In fact, it won't be able to boot up at all, so to initially program it you'll have to press the button to go into bootloader mode. You'll be able to set the fuses any way you like. You'll be able to turn on security, even set up encrypted high-assurance boot, so people can't copy your code from the QSPI flash (or SD card). But the stakes are very high with this chip, because the fuses are true one-time programmed without any way to erase. The "lockable" version will come with very strongly worded warnings and a no-returns, no-refunds "you're on your own" policy.

    I suppose there will be no hyperflash.
    Definitely no hyperflash!

    The chips are too expensive, they're too large to fit, and this first board won't have the 1.8V power supply they need.

    Initially I'm probably only going to support running from TCM. Later we'll probably add support for XIP from QSPI with a software update. If you think only of hardware, this probably doesn't seem like a big issue, but some special things planned on the software side...

    About SPI, I would prefer that there were two available in the 24 pins. Or if it is not possible, that is as in the Teensy 3.6, one of quick access in the 24 pins, and the other in the internal contacts.
    It's looking like we'll have only one full SPI on the outside pins, and another with MISO & CS on the outside but MOSI & SCLK on the bottom pads.

    This is one of the many choices I've reconsidered over and over. Two full SPI would be nice. But then we get 2 less XBAR (not enough to use all 4 quadrature decoders), 2 less FlexIO, and we lose the extra SAI1 signals for 6 channel audio. Since the FlexIO can also implement a limited feature SPI, losing all those features seems like a painful choice just to get the 2nd SPI.

  6. #31
    Quote Originally Posted by PaulStoffregen View Post
    But the stakes are very high with this chip, because the fuses are true one-time programmed without any way to erase. The "lockable" version will come with very strongly worded warnings and a no-returns, no-refunds "you're on your own" policy.
    I understand that you mean that the configuration of boot can only be done once and can not be changed anymore?.

    I have the NXP evaluation board of the RT1050, and it has some microswitches, to be able to configure everything, and I understand that with the option to change all the configuration at any time. It does not seem that those fuses can only be programmed once and they are left like this forever with no option to reconfigure them.

    I understand that putting so many microswitches in such a small space is not possible in the 24-pin Teensy 4.0, but you could put some SMD solderable jumpers in bottom side to configure and allow it to be changed as many times as the user wants.

    I think that with only two weldable SMD jumpers to choose between starting from QSPI or SD would be enough, if access to the SDIO pins is available. Or maybe it's better to leave this for a future version of Teensy 4.0 48-pin with SD socket, like the Teensy 3.6

    In these diagrams of the evaluation board NXP RT1050, there are the microswitches that allow the boot configuration and the boot mode (QSPI, SD or Hyperflash).


    Click image for larger version. 

Name:	ScreenHunter_122.jpg 
Views:	34 
Size:	51.1 KB 
ID:	14041

    Click image for larger version. 

Name:	ScreenHunter_123.jpg 
Views:	27 
Size:	22.1 KB 
ID:	14042

    Click image for larger version. 

Name:	ScreenHunter_124.jpg 
Views:	28 
Size:	40.5 KB 
ID:	14043

    Click image for larger version. 

Name:	ScreenHunter_125.jpg 
Views:	33 
Size:	79.8 KB 
ID:	14044

  7. #32
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,929
    No, the fuses inside the chip control the boot process. The pins are read only if the fuses are unprogrammed.

    Inside the chip is fuse called BT_FUSE_SEL. It's described on page 323 of the rev 1 reference manual. Once this fuse is programmed, the pins are forever ignored. Like all the fuses, once programmed there is no way to erase or restore to their original state.

  8. #33
    Senior Member
    Join Date
    Dec 2014
    Posts
    306
    It's too late in the day and my head is too fried to process the sheer quantity of trade-offs to make. But the only consideration I might suggest would be that whilst the new audio hardware signals (S/PDIF, Redundant I2S pins etc) are useful to some users, if you're not using the T4 for audio, they're not of any use. On the flip side, many users will be looking at the T4 as a replacement for the T3 (with a shed load more processing power and ports available). Therefore, my suggestion is to ensure that the inclusion of these pins (whilst cool, but unused by 95% of users), doesn't result in the loss of functionality elsewhere which would be useful. Meanwhile, those highly specific signals, could be better brought to underside pads, where users who really need them will have no problem with diving in to get them.

    Beyond that, your decisions have delivered a catalogue of excellent products - I'm sure that 95% of users will be happy with the decisions you make, regardless.

    EDIT: I've just seen that this chip doesn't have DACs... In that light... Ignore everything except the last line. =']

  9. #34
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,872
    Not a lot to add to the process, since most of my projects fit into a LC or 3.2 with room to spare other than to ask how many current libraries actually support pointing them at a second SPI/I2C port? Obviously something that can and hopefully will change as more Arduino folk move to devices beyond 8 bit AVR but at least for my (single data point) purposes being able to stuff a small board in a small package and directly twiddle stuff using the on chip hardware(rather than via slave Ics) seems a good fit in the Teensy ecosystem.

    A Teensy product that has very limited direct IO but plenty of connections for high spec RAM, displays and other special hardware (maybe on a unique headers) starts to sound like an Intel Edison.

  10. #35
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,157
    playing now with the audioboard (see other thread on sgtl5000), it would be really great if T4.0 could be used directly with the audioboard.
    Maybe providing outer pins also for a second audioboard, so that only short wires are needed on audioboard to connect RX,TX to T4.0.

  11. #36
    Quote Originally Posted by grease_lighting View Post
    I would like to see a full port worth of pins available. 8 and/or 16 bits.
    Yep, mostly the same thing, but I'd like to see one 16 bit port (addr) and one 8 bit port (data). If that's not doable, I could settle for two 8 pin ports. Or just one.

    Another thing I would *really* like to see is an accessible and usable JTAG port (I think 5 pins) in some shape or form. One that doesn't require a highly non-trivial mod to the board.

  12. #37
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,380
    ... answered in post #14 ??

    Quote Originally Posted by PaulStoffregen View Post
    The GPIO chapter says this chip doesn't support 8 or 16 bit access, so that probably won't be very useful.

    It's also one of the major issues I'm trying to work around for Arduino compatibility with older libraries....

  13. #38
    Good point. Should've read everything before posting.

    However, it's still possible to make it to work. Say, the upper 16 bits are NC and the lower 16 bits are all brought out, so 32 bit R/W will still work on those 16 pins, one just need to know that when writing the upper 16 bits will have no effect, and when reading, the upper 16 bits will be garbage that need to be ignored. (value & 0x0000ffff)

  14. #39
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,929
    It's not going to happen, at least not on this first small form factor board. There just isn't any group of 8 pins, not to mention 16, which can be brought out without compromising other really important features... like having enough XBAR pins to access all 4 quadrature encoders.

  15. #40
    Senior Member
    Join Date
    Jul 2014
    Posts
    139
    Looking great, I didn't see any reference to ethernet MAC pins but I assume they're accounted for. Hopefully also the ability to access 1 or more 1588 related timers? (If this SKU has a hardware timestamping block that is.)

    Edit: Quick look in the reference manual looks positive for 1588 support and that you've exposed 2 of the 3 event timers already. The only other thing is; the more SPI ports, the better (2 is excellent already). SPI is probably the easiest way of shifting a high bandwidth of data in and out for the hobbyist.

  16. #41
    Senior Member
    Join Date
    Jan 2014
    Posts
    141
    Quote Originally Posted by PaulStoffregen View Post
    They calling it 12 bits, but there's info saying 10 ENOB, and even that appears to be specified with a very low 1K source impedance. While disappointing, this shouldn't be too surprising. It's well known trend that small process nodes give dramatically more capable digital circuitry but aren't as good for analog circuits as the older processes.
    Agree. Probably not gonna find much robust and capable analog stuff buried in a powerful digital glob. So if we need this level of GPIO and processing power, one would probably goto external stuff such as your nice audio boards, or some of the increasingly cheap 18 to 24 bit ADCs and DACs.

    Example - my one and only project that truly needs a T 3.5 or T 3.6 is my calibration bench. Responding to state-change interrupts of 20 to 30 digital lines while talking to some 24bit ADCs, while streaming data to a laptop, while doing other stuff with several async IO channels. So my 'big' stuff will want to control and respond to multiple banks of GPIO.

    But, having said I do not care, will admit that this does crimp some styles that wanna do fancy on-board DSP stuff without much external other than an opamp or two.

  17. #42
    A really difficult compromise, I don't envy your task Paul.
    I use both Can ports (and think Teensy is the only board available with Dual native controllers), but understand that something like audio capability would have more use/scope/leverage and hence importantly, sales.
    (Please forgive me if the following is naive)
    What other options are available for the bottom pads? Can double density pads be used, compromising ease of use for some of the 'Nice to have' pins while retaining 0.1" spaced pads for the 'must have' pins? My guess is that the bottom pads are not breadboard freindly, so why stick to a breadboard pitch?
    Could pads be 'shorted' to two pins with a small cut-trace so that configuration can be modified with one or two careful blade cuts? Could solder-jumper pads route some alternative pins? Could the board be somehow modifyable in order that Value Added Resellers could add $0.5 of components to the underside of the board and then add their $5 to the resale price? Teensy 4.0 vanilla sold by PJRC, 4.0A, 4.0B and 4.0C available from other sources?
    EDIT: sorry just seen that switches and configuration is discussed above. Read thread before posting lesson learnt...
    Last edited by Darcy; 06-21-2018 at 08:26 AM.

  18. #43
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,228
    For what its worth - I do a lot of robotics projects and typically I may be using 3-4 serials, two I2Cs, maybe 1 or 2 SPIs and a varies of PWM pins since I will use wheel encoders, 4 or 5 sonar sensors, servos, etc. I am a lousy solderer so those bottom pin pads are a killer for me, sad to say (so Paul if you ever offer boards with the underside pins soldered on count me in ). I am just beginning to get into the CAN so having those on the top side is good for me. I am also now interfacing a ESP32 to a T3.2.

    So the bottom line is that the Pin configuration list in post #20 looks reasonable for a T3.2 type of form factor from my perspective.

  19. #44
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,380
    Frank B - and others - made simple to solder bottom castellated addon's PCB for T_3.x's, ideally those would work to grab these as well - with 14 or fewer pads it would extend the board 0.2" to bring out to through hole pins. And if only a subset of 7 were needed it could extend only 0.1". That makes the bottom pads a usable extension when needed - which was what my misinterpreted post #4 was looking to get at to take up the slack extending the main 24 pins.

    Paul - assuming the shorter version is coming out first as it is easier to get it done in a usable way - and the follow on larger board would share those pins and then need even more difficult effort to pick the extended pins?

  20. #45
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,569
    My 2 cents is I did my own castellated board for the T3.6 and assembled one of them. I added the new pins as 2nd rows, so the thing got wider. I would not do that again. Also not sure if the soldering with castellated was much easier as you needed to have the boards flush and in at least my case, you then needed to solder longer pins on both sides for all of the standard pins... Maybe it it sticks out one end you would not need to do this... Preferred to use the ones by Tall Dog on Tindie.

    My guess is that assuming a second larger (T3.5/6 footprint?) comes out. It would be likely that all of the pins that went to the bottom pins on this board would likely show up as top pins on the extended board?

  21. #46
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,228
    Didn't mean to get this thread sidetracked with the underside pins but I completely forgot about the castellated boards for the underside pins that @defragster noted. Giving some thought to those before I posted and saw @FrankB's comments I think I would tend to agree with him on the soldering the castellated boards and longer pins required. Don't mind the larger footprint though. Probably would still be easier than soldering the pins. Tend to use the T3.5 mostly because of access to the pins on the board edges.

  22. #47
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,952

    Cool

    Interesting that the introduction starts at page 200

    Finally it looks like we have hardware double precision support and for this chip at least we can drop -fsingle-precision-constant.

  23. #48
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,929
    Quote Originally Posted by MichaelMeissner View Post
    Finally it looks like we have hardware double precision support and for this chip at least we can drop -fsingle-precision-constant.
    Maybe, but maybe not.

    Looks like float & double are not created equal in the new FPU.

  24. #49
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,952
    Quote Originally Posted by PaulStoffregen View Post
    Maybe, but maybe not.

    Looks like float & double are not created equal in the new FPU.
    Pity. I see other documents now where it says the FPU is optional, and if you have the FPU, there are two options, single precision only, and both single/double precision.

    And no hardware IEEE 128-bit floating point.

  25. #50
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,228
    I know this may sound like a silly question at this point but which i.MX RT version will the new T4 be using, 1050 or 1060. Looking at the pins I am assuming it will be a 1050, and you know what they say about assuming. Reason I am asking is that I was curious if CAN FD was going to be available (really just curious). From what I saw on NXP only the 1060 will have it available.

Posting Permissions

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