Any Chance of a Teensy ++ 3.1?

Status
Not open for further replies.
Awesome.

[EDIT] I've just re-read the original post again and realised that this has already been covered, so this post is a bit redundant.

oh, so parallel headers is out already? too bad. the mechanical/dimensional compatibility thing apart, i fail to see to advantage of an onboard SD card. even if i need one, there's so many cases where i'd like the SD card to be somewhere else physically so it can protrude from the panel / casing / whatever; that may be a horizontal socket or it may be vertical. that may just be me .. but it's always easier to add stuff than having to cope with things that aren't essential.

or was that ("already covered") re castellated?
 
Paul,

MAPBGA or LQFP? (my money is on LQFP but its much larger)
MAPBGA will likely fit in the existing Teensy 3.1 footprint, the LQFP is much larger.

With LQFP there is a chance the slightly better then average user can solder to a custom PCB, with the MAPBGA its much harder.

Edit....

oh, so parallel headers is out already? too bad. the mechanical/dimensional compatibility thing apart, i fail to see to advantage of an onboard SD card. even if i need one, there's so many cases where i'd like the SD card to be somewhere else physically so it can protrude from the panel / casing / whatever; that may be a horizontal socket or it may be vertical. that may just be me .. but it's always easier to add stuff than having to cope with things that aren't essential.

or was that ("already covered") re castellated?

I agree about not having an SD Card socket on the Teensy, SD Cards are not something that everyone needs and usually you want access to it which would be a problem if the Teensy gets stuffed in some obscure corner of your build.
 
Last edited:
+1 for smd pads on the bottom. I will find lots of uses for them especially if, like the Teensy 3.1, there are a power and I2C port available there.
 
I will state once again that using something like the Yamaichi PJS008U PTH SD card connector may be a better option than a hard install of a typical flat SD-card reader.

Like the RTC, its installation is optional, it can be located in the center of the board, etc. It does add some height, however.
 
I will state once again that using something like the Yamaichi PJS008U PTH SD card connector may be a better option than a hard install of a typical flat SD-card reader.

Like the RTC, its installation is optional, it can be located in the center of the board, etc. It does add some height, however.

SD can be up to 50 MHz. Are longish wire connections ok with the new, fast device ?
I addition, most of the Arduino-SD-Breakouts are not usable (not to speak of 5v/3v problems), and a special one is needed (4Bit transfer). So placing the slot directly on the teensy is a very good decision! Much more easy, less newbie questions "SD does not work".. Even the existing Teensy-extensions with this slot can not use this mode (am i correct?)

I did'nt look at the datasheet so far, but perhaps it is possible to map the signals to other pins, if one really wants another location. Or, maybe solderpads in parallel.

Project that don't need SD...ok...there's no must to use it! All others will benefit . Remember, Arduino is for beginners and for ease of use. For hobbyists.


Edit: :) Ok, i mis-interpreted your link :) sorry. are there other sources for it than mouser ?
 
Last edited:
Indeed, with this chip SD will use 7 completely different non-SPI pins.

The vertical though-hole connector as an optional user-soldered add-on is an interesting idea. Seems like it could really interfere with the ability to add other boards on top, though. So many trade-offs to consider.....
 
Yes , if it can be bought without problems worldwide.
Mouser:
Delivery Restrictions:
icon_ar_red.gif
Mouser does not presently sell this product in your region.
 
Last edited:
SD card/chip ... SDIO, 1 bit mode, 24Mbps or more. w/DMA.
That's quite viable if 4 bit SDIO is too pin-hungry.

I've used both and frankly, speeds w/1 bit mode are good enough for most all use cases. Esp. with DMA, so the CPU isn't tied up looping.
 
Freescale's website has complete specs and documentation for their MK66FX1M0 chip. Some highlights: 180 MHz Cortex-M4F (single precision FPU), 1M Flash (with 8K cache), 256K RAM, 4K EEPROM, 2 USB ports, ethernet, SDHC, 2 ADCs (many pins muxed), 2 DACs, 3 SPI, 4 I2C, 2 CAN, 6 serial, 20 PWM, touch sensing.

That looks like a nice chip!

These chips have about 90 available I/O pins. Only about half will be able to come to the breadboard-friendly edges. I haven't decided what we'll do with the others. A high density connector is unlikely. I'll probably try to bring as many useful signals as I can to bottom side pads, similar to Teensy 3.1.

Please, for the love of dog, no bottom pads! They really are not that easy to use and are almost a waste. I really wouldn't mind a significantly larger form factor for this much more powerful processor.

One minor downside is that none of these newer chips offers 5 volt tolerance.

I think this becoming less of a concern that it was a year ago. Not a big deal in my opinion.

The other change is power consumption. For speeds above 120 MHz, the chip uses a special "high speed run" mode, which consumes quite a bit more power. It's looking like approx 90 to 100 mA. If the 2nd USB port is used, quite a bit of extra current is required for 480 Mbit/sec speed.

I don't see the next iteration of the Teensy as needing to be super low power conscious - that's why you have the LC and to a lesser extent, the 3.1.

Once you have the ++ you will have a nice suite of microcontroller boards with the LC, 3.1 and the ++ and you should consider marketing them that way. Need something small, low power consumption and inexpensive? The LC fits the bill. Need heavy duty processing power and lots of I/O? The ++ fits the bill. The 3.1 will fit nicely in between.
 
Last edited:
If the choice is between not bringing I/O signals out at all versus bottom-side pads, well, I think you can see which way that will go.

Then again, Arduino doesn't bring lots of signals out on Mega, Due, and Zero.
 
If the choice is between not bringing I/O signals out at all versus bottom-side pads, well, I think you can see which way that will go.

Would it be useful/possible to have the bottom-side pads combined with thin through-holes, so that,alternatively to surface mounted headers, one can solder more robustly thin connecting wires to them?

Then again, Arduino doesn't bring lots of signals out on Mega, Due, and Zero.

I hope that T3++ will not only be more powerful but also much more flexible than Arduino.
 
As I recall, one of the big issues with the Arduino DUE was the sheer number of pins that were not brought out to a usable header due to the slavish obsession with sticking to the Mega form factor. No pads as an alternative either. That decision in turn meant that external memory and other features that advanced users were very excited about could not be implemented.

So my vote would be to bring out the pads, if possible.
 
Here is an example of a slightly bigger footprint:

https://www.youtube.com/watch?v=BkJ2WbzO6dI

A Teensy ++ with a 22x9 pin dimension would be good. Or, stop worrying about breadboard compatibility (sell a ++ specific bread/breakout board?), which frees you up quite a bit when it comes to form factor.

PIC! OMG. Run!

On discussing big footprint w/header pins for T3++.

I've used this
http://www.mikroe.com/mini/stm32/ (US distributor:microcontrollershop.com
SWD (JTAG) debugging, erased their in-flash bootloader, used GCC C/C++ instead of their mutant C that has no C++.

Pin header/breadboard... time to move on.
 
Last edited:
The feature I miss the most of my Teensy 3.1s are mounting holes. In my current target applications the board as is have all the IO i need at levels that work for me so I will connect wires directly to the teensy. No headers. But mounting then becomes an issue so Might have to make a board to plug in to just for mounting. This increases volume needs to a point not quite acceptable.
 
I have personally never used a teensy on a breadboard. I can see the benefits, but I just dont like them. The wires/connections can be flimsy and cause confusion.
 
I've only ever used a teensy on a breadboard for prototyping (and then designed a custom board around the Teensy 3.1 schematic). For prototyping, breadboards are... there's nothing better. Keeping the option for a teensy to sit in a breadboard is very, very important. It doesn't need to last long in the breadboard, just enough that I can put together my schematic, test it and fix any stupid mistakes in the schematic - my design actually uses two teensys (one for MIDI, and one to drive a touchscreen) and my breadboard is HUGE. It's a big bundle of wires, but it's still more manageable than trying to solder jumper cables to a board that's not meant for breadboards.
 
At this point, I'd like to share with you the tough decision making.... prioritizing which of the extra pins to make available.

Here's the list of not-yet-allocated pins, with their peripheral functions. Duplicate functions of already-allocated pins are lowercase, but still might be useful as alternates. Of course, the uppercase ones are functionality that will be unavailable if not brought to an accessible pin.

Code:
Pin     Alt0            Alt1            Alt2            Alt3            Alt4            Alt5            Alt6            Alt7
---     ----            ----            ----            ----            ----            ----            ----            ----
                        PTA10/LLWU_P22                  FTM2_CH0                                        FTM2_QD_PHA/TPM2_CH0
                        PTA11/LLWU_P23                  FTM2_CH1                        i2c2_sda        FTM2_QD_PHB/TPM2_CH1
?       Analog1         PTB10           spi1_pcs0       UART3_RX                                        ftm0_flt1
?       Analog1         PTB11           spi1_scK        UART3_TX                                        ftm0_flt2
?       Touch           PTB18           can0_tx         FTM2_CH0        i2s_tx_bclk                     FTM2_QD_PHA/TPM2_CH0
?       Touch           PTB19           can0_rx         FTM2_CH1        i2s_tx_fs                       FTM2_QD_PHB/TPM2_CH1
?       Analog1         PTC8                            FTM3_CH4        i2s_mclk
?       Analog1         PTC9                            FTM3_CH5        i2s_rx_bclk                     FTM2_FLT0
?       Analog1         PTC10           I2C1_SCL        FTM3_CH6        i2s_rx_fs
?       Analog1         PTC11/LLWU_P11  I2C1_SDA        FTM3_CH7        I2S_RXD1
                        PTC14                           UART4_RX
                        PTC15                           UART4_TX
                        PTC16           CAN1_RX         UART3_RX        enet_1588_tmr0
                        PTC17           CAN1_TX         UART3_TX        enet_1588_tmr1
                        PTD8/LLWU_P24   i2c0_scl                                        LPUART0_RX
                        PTD9            i2c0_sda                                        LPUART0_TX
                        PTD11/LLWU_P25  SPI2_PCS0                                       LPUART0_CTS
                        PTD12           SPI2_SCK        FTM3_FLT0
                        PTD13           SPI2_SOUT
                        PTD14           SPI2_SIN
                        PTD15           SPI2_PCS1
                        PTE8            I2S_RXD1                        i2s_rx_fs       LPUART0_TX      ftm3_ch3
                        PTE9/LLWU_P17   i2s_txd1                        i2s_rx_bclk     LPUART0_RX      FTM3_CH4
                        PTE10/LLWU_P18  I2C3_SDA                        i2s_txd0        LPUART0_CTS     FTM3_CH5        USB1_ID
                        PTE11           I2C3_SCL                        i2s_tx_fs       LPUART0_RTS     FTM3_CH6
?       Analog0         PTE24           CAN1_TX         UART4_TX                        i2c0_scl        ewm_out
?       Analog0         PTE25/LLWU_P21  CAN1_RX         UART4_RX                        i2c0_sda        ewm_in
                        PTE27                           UART4_RTS
                        PTB20           SPI2_PCS0                                                       c0_out
                        PTB21           SPI2_SCK                                                        c1_out
                        PTB22           SPI2_SOUT                                                       c2_out
                        PTB23           SPI2_SIN        SPI0_PCS5                                       C3_OUT
                        PTE12                                           i2s_tx_bclk                     FTM3_CH7
                        PTB8                            UART3_RTS
                        PTB9            SPI1_PCS1       UART3_CTS
        Analog1         PTB4                                            ENET_1588_TMR2                  FTM1_FLT0
        Analog1         PTB5                                            ENET_1588_TMR3                  FTM2_FLT0
        Analog1         PTB6
        Analog1         PTB7
                        PTE6/LLWU_P16   SPI1_PCS3       UART3_CTS       i2s_mclk                        ftm3_ch1        usb0_sof_out
                        PTE7                            UART3_RTS       i2s_rxd0                        ftm3_ch2
        Analog0         PTA7                            ftm0_ch4                        rmii_mdio
        Analog0         PTA8                            ftm1_ch0                        rmii_mdc        ftm1_qd_pha/tpm1_ch0
                        PTA9                            ftm1_ch1                                        ftm1_qd_phb/tpm1_ch1
                        PTC18                           UART3_RTS       ENET_1588_TMR2
                        PTC19                           UART3_CTS       ENET_1588_TMR3
                        PTC12                           UART4_RTS       ftm_clkin0                      FTM3_FLT0       tpm_clkin0
                        PTC13                           uart4_cts       ftm_clkin1                                      tpm_clkin1
                        PTA6                            ftm0_ch3                        clkout
                        PTD10                                                           LPUART0_RTS
                        PTA24
                        PTA25
                        PTA26
                        PTA27
                        PTA28
                        PTA29
                        PTE28

I believe 10 of these will route to the outside edge. The ones marked "?" are likely candidates. Perhaps 6 to 14 more may route to bottom-side pads or a location to solder a connector. Maybe....

The point of this list is to talk about which of these signals are most important. Not up for discussion are large form factors or special connectors or ways to have all signals. In a world where you can't have everything, you have to prioritize the things that matter most.
 
Pretty good!
Sometimes it is useful to have 8 pins (better more) of the same port, for example PTA0..7 or such. So that they can be switched or read all together in one instruction.
 
Paul, could you post the ALREADY ASSIGNED pins as well, please? I guess the mapping is different on the K66, so it would be interesting to know what alternate assignments are possible...
 
Thank you for already assigning ENET0_1588_TMR0 and ENET0_1588_TMR1 though I guess you don't have much choice given they are I2C0_SCL and I2C0_SDA as well.

Given that all 4 1588 timers appear to be identical, I'd say 2 1588 timer pins is enough if you aren't able to expose ENET0_1588_TMR2 and ENET0_1588_TMR3.

I'm really looking forwards to showing the world a bunch of Teensy all performing an action at exactly the same time using ethernet synchronization!
(though I suppose more relevant to having these 2 pins exposed is the ability to clock an external IC like an ADC or WS2811b, as all 4 1588 timer interrupts will be available in software regardless of how many external pins exist. Also the ability to timestamp an external event easily.)

My vote for bottom pad candidates:
USB0_DP, USB0_DM, USB1_DP, USB1_DM
 
Last edited:
I'm really looking forwards to showing the world a bunch of Teensy all performing an action at exactly the same time using ethernet synchronization!

That would be pretty awesome!

Realistically, it'll probably be quite a long time until a really usable network stack is written and debugged.

Also, is perfect sync possible with RMII interface? Or does anyone care about a fraction of a microsecond latency?
 
Status
Not open for further replies.
Back
Top