Any Chance of a Teensy ++ 3.1?

Status
Not open for further replies.
stevech - I'm in the opposite boat. I'd actually prefer if the 3.1 was a bit longer, so it didn't need to have those pads on the underside (which generally means I then need to also buy an adapter if I want to breadboard with them and not destroy the board when I yank it from the breadboard). The ++2.0 was a perfect size for me, I tend to use ALL the pins available to me. (My current project actually uses two 3.1's connected via serial - I needed one to drive my touch screen, partially for speed concerns, partially because there are literally no unused pins on my main Teensy).
 
stevech - I'm in the opposite boat. I'd actually prefer if the 3.1 was a bit longer, so it didn't need to have those pads on the underside (which generally means I then need to also buy an adapter if I want to breadboard with them and not destroy the board when I yank it from the breadboard). The ++2.0 was a perfect size for me, I tend to use ALL the pins available to me. (My current project actually uses two 3.1's connected via serial - I needed one to drive my touch screen, partially for speed concerns, partially because there are literally no unused pins on my main Teensy).
I can't say I've ever needed the bottom-side connections post-development.
Lots of different needs. But things I do favor small in size, hence Teensy. But, that's just my world.
 
I like Teensy 3.1's physical size. The ++ size is too bigga.

I hope for a Teensy 3.3 or 4.0 or some such that is same size, not larger, than T3.1. But is a newer/better ARM chip with more flash, more RAM, more SPI ports, and optional use of Single Wire Debug.

It sounds like you are asking for more pins and the same pinout. That either means more pin function overloading, or more interior pins/pads. Both make it harder to use, juggling functionality in the one case and making repeated insertion/removal from a socket harder/risk tearing off pads in the other.

I would much prefer the format discussed earlier - a longer board where the shared portion has T3.1/T-LC pinout and the extra stuff on extra, exterior pins.
 
I can't say I've ever needed the bottom-side connections post-development.
Three out of four projects sitting on my bench right now use the interior pins and one also uses the bottom pads (and is a commercial kit). Separately using the two on-board ADCs requires the bottom-side connections.
 
Having said which, T-LC has two I2C and two SPI and I would hope a 3.x++ would share the pin positions for all of them.
 
(I originally posted this to the Teensydunio 1.22 thread, but I thought this thread was more appropriate).

As a backer of digispark in the past, I got a notice of their new kickstarter project (OAK) which some 32-bit MCO, has wifi (presumably similar to the ESP8266), and is programmable via wifi, and it uses rootcloud as the glue with a $13 unit price. Now, I have some issues with Digispark and Oak (for an IOT type server, it is restricted due to number of pins, particularly one analog; in some places you might not have general wifi access, in the past digistumps record for software support hasn't impressed me, their claims about all of the digistump shields need to be tempered with things like voltage level conversion, and fewer analog pins, and also what happens if rootcloud goes belly up).

As I was thinking about it, in a Teensy context, I could imagine the Mini54 being replaced with something that does wifi, ala the ESP8266, and then connect the Teensy 4.0/3.2/3.1++ (or whatever) to that. Obviously you would need to do FCC compliance, etc. But it would answer the people that have a need/desire to remotely upgrade their Teensy's software. If that is the case, I would prefer a fallback, that you could still program the Teensy 4.0 via USB.

Perhaps it might be as simple as having 2 pins/solder pads dedicated to a UART connection that we could add our own ESP8266's, and the MINI54++ would talk to the ESP8266, and provide it as another serial channel to the Teensy 4.0/3.2/3.1++, and have some EEPROM in the Mini54++ to remember connection information.

Or perhaps we just need something that has something that has a wifi controller and a USB plug, and it emulates a USB stream over wifi, and you would use the Teensy without modification.
 
One crazy idea I've been considering is replacing the Mini54 with a much larger (memory wise) chip, which would allow me to add bootloader support for various peripherals. Aside from the incredible amount of software development needed, the main technical limitation is simply not having lots of extra code space to create a huge bootloader that supports hardware serial, SPI and other stuff, plus different peripherals connected to those pins.

But a bigger chip will add to the hardware cost, which I'm not convinced is a good path in these times of ever decreasing hardware prices....
 
I'd say +1 for the Mini54 equivalent offering more bootloading options. While you can use uTasker and similar to support remote code loading, a Teensy that offered wireless and remote wired (from SD card?) code loading while leveraging two CPUs to keep things orderly in event of failure would be nice. Do wonder how many of the shiny new IOT platforms can be fixed when the power glitches halfway through the download or when user code overruns the wireless mem space. Another current kickstarter is onion who have done the interesting step of offering interactive demos https://onion.io/livelab Which is a refreshing case of showing that real hardware (or a reasonably convincing fake) actually exists at launch.

That said I'm thinking I'll still be buying Teensy's in bulk for all those things that don't actually need to be making posts to Facebook on their own.

Edit: if you allow the bootloader chip to use an external interface would that allow a single USB connected on a master to download code to all of the slave Teensyies in things like large Octo matrixs?
 
But if/when non-PJRC methods to download the T3 proliferate, the T3/LC clone makers spring up. This was OK for Arduino boards back in the day when it was an benevolent non-profit endeavor. But PJRC has bills to pay, and more.
 
I have what may be a dumb question...

But why build one single monolithic bootloader? If someone wants to use SPI or a UART to reflash the application code, it's because the USB port is not in use in the deployed application. I think interface-specific bootloaders are the way to go. I think it'd be perfectly reasonable to, at installation time, flash a bootloader-updater via USB (or even jtag if necessary) to get bootloader support via a different interface.

Another possible idea would be to use a 2-stage bootloader. --After timing-out on an update via USB, check for one via the secondary interface was configured by the programmer.
 
There is at least one "two-stage" bootloader for T3. In the broader MCU world these are often called a "Secondary Bootloader", meaning there's a Primary that always runs at power-up/reset. The primary may elect to invoke the secondary. The secondary is often written by the MCU vendor's customer, and stored in flash.

Example: ARM vendor X has in MCU on-chip-ROM (not flash) a primary bootloader that senses whether there's an attempt being made via either UART, SPI, I2C, USB per the DFU standard. If so, the primary runs that session. Otherwise, the primary checks to see if a secondary exists (a jumper and/or valid code in flash) and if so, the the Secondary is invoked and it might use a medium like wireless or Ethernet or external bulk flash memory. Indeed, I did this years back my own Secondary loader that was everpresent in low flash memory and used a cellular modem to check for new firmware. And the application per se could update the Secondary bootloader - for a goal of no travel to sites.

This flexible primary is fine if one is selling MCU chips, rather than boards, as such a board can be easily cloned and sold to the disadvantage of the board product maker.
 
Last edited:
The bootloader question is a tricky one since it's central to the PJRC business model of 'unbrickable arduino' and stays on a leash to ensure Paul and Robin get to keep eating. It's stated elsewhere but the magic sauce is the fact that the secondary CPU clears and then downloads known good USB code to the main CPU each time the download button is pressed. Now there is nothing stopping that bootloader supporting other methods than USB for getting the data into the main CPU but some serious time would need to be invested:
Getting it wrong breaks an entire product line https://www.sparkfun.com/news/1575
Current chip is fully utilised meaning a cost increase to support (and potential impact to low power capability)
Any plan will break existing Teensy standard, either by adding more pins or locking pins to a role, at least during boot (search teensy pin 33)
Failure during download needs to be 100% handled. This gets interesting when supporting wireless or ethernet.

Currently Teensy does what it does really well and while doing new things is good the cheap micro controller space is crowded and getting it wrong is expensive.

One thing that may make all this moot is the continued expansion of http://www.utasker.com/kinetis/TEENSY_3.1.html which adds a software bootloader for a range of non USB download options. Does mean that if things go wrong you need to physically access the teensy and reload uTasker via USB but sensible fallback is always going to be a problem in any device that doesn't have a enough memory to keep multiple copies of itself on hand 'just in case'.
 
Maybe it's time to share (or "leak") a few Teensy++ 3.x details, even though the product is still pretty much in the planning phase.

Here are 5 things that are absolutely certain about Teensy++ 3.x:

  1. ARM Cortex-M4F (Floating Point Unit)
  2. Under $30
  3. More I/O pins
  4. More serial & SPI ports
  5. More memory

I'm leaning towards a 48 pin form factor, with an extra 3.3V & GND pair. I'm still debating whether AREF should be brought to the outside breadboard-friendly edges. Likewise, I'm considering whether the to bring out some analog-only pins (like A10 & A11 on Teensy 3.1), which offer perhaps lower noise and differential analog signal input, but they can't be used for digital. Total number of digital pin on the outside edge could range from 35 to 40 or even 42, depending on whether some pins are extra power and analog only stuff.

I'll very likely put a Micro SD card socket on the end of the board. The "large" applications where you use such a powerful microcontroller often need storage, so that seems like a good use of the extra space (from making the board longer). But perhaps that extra room could be more useful as lots of through-hole pads for extra digital signals? In theory, you could always add an adaptor for storage, but my gut feeling is in practice many applications use storage media.

Also, while I'm spilling rumors, PJRC is working on a lower cost Teensy 3.x based on an ARM Cortex-M0+ chip. It will feature similar I/O and peripherals as Teensy 3.1 (except the bottom pins), with less memory and a slower processor, but a retail price in the $12 to $14 range.

We don't have any hard deadlines for these new products. I can tell you I'm very committed to working on the software support side, which often comes at the expense of working on making new hardware, so it's quite possible both of these may slip for quite some time.

Hi Paul,
i know, you just released the LC and perhaps it's a bit early to ask..

I'm reaching a point where I need more RAM and Flash(Yes, flash.. I "lost" another 100KB this evening for graphics.. SPI is too slow)
And since there are some new Kinetis (like K20_120) which might be Teensy 3.1 compatible..
Is there any release-date on the horizon ? This year ?

https://forum.pjrc.com/threads/2630...display)-library?p=72490&viewfull=1#post72490
 
Last edited:
One addition to the next Teensy would be to bring back a header pin compatible thru hole for the RESET again. I work a lot on projects that may be many miles drive away so they have to be fault tolerant and an external hardware watchdog is a must. Adding a tack soldered wire to the pad works but it is not the best answer.

thanks
 
Maybe it's time to share (or "leak") a few Teensy++ 3.x details, even though the product is still pretty much in the planning phase.

Here are 5 things that are absolutely certain about Teensy++ 3.x:

  1. ARM Cortex-M4F (Floating Point Unit)
  2. Under $30
  3. More I/O pins
  4. More serial & SPI ports
  5. More memory

Two other things might be very interesting for a new Teensy 3.1++: The possibility to upload firmware simply in saving the new firmware as a hex file on an SD card. So for the end customer this will result in very simple firmware updates. Additionally to that it might also be very useful that the Teensy 3.1++ acts just like an USB stick, enabling simple drag and drop of files from and to the SD card. When analyzing data that has been measured with a Teensy 3.1++ based electronics then it would no longer be necessary to remove the SD card, use an SC card reader and connect to the PC. Just simply plug in the Teensy 3.1++ and read out the data.

Both features might enhance the market for Teensyduino / Teensy, especially when designing electronic products with embedded MCU's.
 
I like Teensy 3.1's physical size. The ++ size is too bigga.

I hope for a Teensy 3.3 or 4.0 or some such that is same size, not larger, than T3.1. But is a newer/better ARM chip with more flash, more RAM, more SPI ports, and optional use of Single Wire Debug.
I do not agree about the ++ size being too big at all, there is no need to boo the larger model with more accessible IO and goodies if all you really want is the next generation of Teensy to come out :smart-alec-grin:

On the other hand, if Paul slapped a pin compatible 'bigger brother' MCU on a Teensy 3.1 PCB and then PM'd me an invite to participate in beta testing it for the all time low price of $25~30(US) and the commitment to submit at least one decent pull request relating to getting it ready for release per week till released; he'd probably get an offer of $50~60(AU :p) from me to make it once a fortnight instead ;)
 
Right now, a fix for the long-standing pin 33 bug is my top priority.

After that, I'm still debating whether to take a path of making debug versions of current products, or make a bigger Teensy3++ first, before seriously working on debug.

The sad reality is I must concentrate on one before the other. So if we get real debug capability sooner, than means delaying Teensy3++. If I work on a more powerful board, that'll mean pushing back work on debug versions of Teensy-LC and Teensy 3.1.
 
Well if you're looking for votes on which way to go I'm more excited about the Teensy 3++. More UARTs and 16 pins on the same register (for driving LCDs) would be awesome :D
 
The 3.1 looks pretty good to me but something half way between an all new 3.1++ that brought all the pins out to the sides like the header board does would be better for me on the interim. All the same software and hardware but a 100% breadboard friendly pcb layout.

Freescale makes some chips that allow you to put function(s) on the pin(s) you want, that would be neat to see too. MicroSD card would be neat too.
 
Last edited:
Right now, a fix for the long-standing pin 33 bug is my top priority.

My suggestion: Eliminate pin 33. Perhaps heresy, but IMO, the pin won't be missed by many and the effort to make the bootloader work even if the pin is held low is unlikely to be worth the effort.

My suggestion would be to focus on the 3++ and then follow on with debug. The debug benefits a limited population and could be pioneered on the 3++ (i.e. have a debug connection / interface available) even if you don't use it initially, tag-connect comes to mind). I'd also consider the micro-SD Yaimichi SDHC card reader as a user-installable option.
 
Status
Not open for further replies.
Back
Top