Any Chance of a Teensy ++ 3.1?

[Nantonos]

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

Those are all good things. I see that some of the K2x chips have up to six UARTS, 3 SPI and 2 I2C. Some have dual 12-bit DAC as well.

FPU is particularly exciting. Question about that: if there is hardware single-precision FPU, does that provide any benefit for double-precision floats or do they fall back on a software-only implementation?

I'm guessing that the recent work to support higher clock speeds like 120MHz and so on will pay off for the new board as well.

Is it fair to say that 5V tolerance (like Teensy 3.1), I2S, and high accuracy low drift 5ppm or better crystal (like all current Teensies) are also certain? I'm mentioning the last one in the hope that doesn't get downgraded because no-one appreciates it.

I'm leaning towards a 48 pin form factor, with an extra 3.3V & GND pair.

OK so one pair of pins longer than Tensy++ 2.0.

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.

Making AREF easier to get at makes it more likely that it will be used; either bringing it out to use as a reference for other circuitry or bringing in an external AREF.

Having lower-noise differential inputs easily available is also a definite plus. I can see that you might be concerned that on all Arduino boards to date, its true that "any analog pin can also be used as digital I/O" but I think clear documentation on the pin-out card would go a long way to eliminating any confusion there. So I would encourage doing both the external AREF and the external analog-only differential pins. As you say, Teensy 3.1 already has those, just not on the outside. I haven't seen anyone be confused by this (but being harder to get to, less people use them).
I can also see that you might want to put those in the exact same place as Teensy 3.1 for compatibility, though.

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.

Fair enough. It would be good to have that far away from the best analog input pins, since digital breakthrough on analog pins due to SD card use has been reported in these forums.
On the other hand a cluster of pins could be used for minute shield-like add-ons (similar to the 10-DOF accelerometer and gyro one) where one option would be a micro SD add-on.

Talking of pins, I assume the pinout will be such that the existing Audio board would fit right on without modification? Which means the relative positions of those pins that the Audio board actually uses would remain constant.

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.

That would be very welcome and would address the sort of application that $10 Arduino Pro Mini or ATTiny84-based boards currently cover. It also makes easier multi-MCU projects with a Teensy 3.1 master and one or more smaller, lower cost slave MCUs (perhaps communicating over I2C) where Teensy 2.0 is the current obvious choice but needs 5V to 3V3 I2C-safe logic conversion.

 

[Camel]

Thanks goodness for the FPU!! I was so close to jumping onto the STM32 bus, but I suspected a Teensy with an FPU might be here soon. Definitely keen to get my hands on a few.

 

[PaulStoffregen]

OK so one pair of pins longer than Tensy++ 2.0.

Actually, 4 pairs of pins (0.4 inch, or about 1 cm) longer than Teensy++ 2.0.

In other words, Teensy++ 2.0 is considered a 40 pin form factor, because the shape of the PCB has two rows of 20 pins on the top and bottom. Teensy 3.1 is a 28 pin form factor. My current plan for the shape of Teensy++ 3.x is a 48 pin form factor.

Like Teensy++ 2.0, extra space in the interior of the PCB will likely be used for a set of through-hole pads to give extra signals. I'm hoping to cram 10 pins at 0.1 inch spacing, probably using the UEXT pinout.

Thanks goodness for the FPU!! I was so close to jumping onto the STM32 bus, but I suspected a Teensy with an FPU might be here soon. Definitely keen to get my hands on a few.

Soon is relative.... but it definitely is coming!

 

[PaulStoffregen]

FPU is particularly exciting. Question about that: if there is hardware single-precision FPU, does that provide any benefit for double-precision floats or do they fall back on a software-only implementation?

Sadly, a single precision FPU doesn't help at all for double precision.

I've been considering added a compiler flag that causes all unspecified float constants to be automatically treated as float rather than the compiler default of double. This might break some code, but nothing designed for regular Arduino, where all double variables are implemented with single precision. If we're going to have a FPU eventually, it should really help avoid unintentional slow double precision math.

 

[MichaelMeissner]

Well there is the old '-Ddouble=float' hack, but that doesn't address constants, nor math library functions. Unfortunately, the ARM compiler does not have an option to make doubles the same as float (this will make the compiler non-standards complaint, and you need to specify a multilib that is built with this option).

 

[Nantonos]

Paul, thanks.

Michael, I know you were involved in C/C++ standardization. Is there a reason that there are not explicit-sized types for IEEE single and double precision (as there are for 32, 16 and 8bit integer types) rather than "float means whatever it means on this platform and may or may not be the same as double"?

 

[MichaelMeissner]

I was involved in the initial C standard (ANSI C89/ISO C90). I was on the committee from its founding in 1984 through 1994, representing initially Data General, and later OSF (Open Software Foundation). I have not been involved in the standards process since then. Annex F (which is optional) of the C11 standard says that float must match the IEEE 754 32-bit binary format and double must match IEEE 754 64-bit binary format. It is recommended practice, but not required that long double use the IEEE 754 128-bit binary floating point format.

In terms of the original standards committee, at the time, several of the members did not use IEEE floating point (Burroughs, Univac, IBM, Cray) and several others used the format, but didn't support full IEEE 754 (MIPS, DEC), and there was no active proposal to tie it more tightly to IEEE 754. After C89, as the C99 standard was being crafted, most of the non-IEEE floating point vendors had faded from the scene or had added IEEE 754 support to later generations of hardware, and there was more sense to incorporate IEEE 754 support in an annex.

Even in the original C89 standard, the AVR compiler decision to make double the same as float was non-standard, since the C89 standard required a minimum precision size for double larger than IEEE 754 32-bit binary floating point. I would imagine the AVR maintainers made the decision due to the lack of memory in the 8-bit AVR chips, and the thought that most users would not be using floating point.

As an aside, I have been working for the last 2 months on adding IEEE 754 128-bit floating point to the PowerPC compiler, but at present, this will use a new keyword (__float128), which the x86 GCC compiler also uses, since both x86 and PowerPC have long double implementations that are not based on IEEE 754.

 

[stevech]

Data General! In my early engineering years, I wrote a zillion lines of code in assembly for the Nova 800! We had it connected to a Floating Point Systems box that was about 6 in. of rack space.

 

[KurtE]

Looking foreword to the new chip! Will definitely make a breakout board/shield for these when they come out!

As for floating point and library functions and the like. I know that for a lot of the floating point functions like sin, cos, there is a version of the functions sinf, cosf... that take floating point values. I know from some code I am playing with that this really does speed things up.

I was told by a friend up on Trossen, that with the Linux compilers, the math functions are defined in such a way as the compiler detects that it has floating point or double coming in and if it is floating point, it automatically uses that version. I did do a little looking through the header files and it appears like they do have stuff in them to detect stuff, but I have not yet verified by actually compiling test cases to actually see what it does. But if it is true, would be great if the compiler for the Teensy did the same.

Kurt

P.S. - Looks like a few of us have been around for awhile. I will just say that my high school had a hand me down IBM 1620, which I learned Fortran 2 on :lol: and I did my masters project using a Franklin Ace.

 

[MichaelMeissner]

Data General! In my early engineering years, I wrote a zillion lines of code in assembly for the Nova 800! We had it connected to a Floating Point Systems box that was about 6 in. of rack space.

I wrote most of the front end for the Data General C compiler (in PL/1) for the Eclipse and later MV/Eclipse processors. Man that machine was hostile to most of the code that C programmers write.

Later, when they moved to the Motorola 88000, I started the ball rolling for Data General to support and use the Gnu C compiler for the 88000. The majority of my jobs since then have been at various companies supporting the GCC compiler. Note, I have nothing to do with Arm and AVR backends in the compiler, though the AVR folk are using an extension I put in for the Cell processor for the PROGMEM support in later compilers.

 

[duff]

+1 for micro sd card socket.

 

[KurtE]

I also like the idea of a SD card, however hopefully it can be done to minimize compatibility issues. That is for example: I and probably some others will create breakout boards with Arduino headers (who knows maybe even Mega). I would then for example probably plug in something like an Adafruit TFT display, example 2.8" TFT with touch (and SD). These shields have fixed pins for what the CS is for each of these components. So hopefully the CS (and potentially which SPI), used for the onboard SD card will not interfere with the shields...

Wish list: Hope the reset pin is to a real pin. I tore the pad off of one of my Teensy 3.1s...

Kurt

 

[onehorse]

I know these microshields I am using are a small niche, but I really appreciate that several pairs of power and ground pins are available on the Teensy 3.1; I would hope the ++ version maintains this feature which is essential for any kind of modularity.
Also, one set of SPI on Teensy 3.1 is a little constraining, I would really like a second SPI port physically separated from the other...

 

[bperrybap]

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.
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 ducts. 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.

What about some kind of sd card adapter kind of like the other one?
Maybe some kind of board that mounts without pins and solders to the bottom of the board if there are still pads
on the bottom.

--- bill

 

[linuxgeek]

I like the idea of a microSD card built-in, but if so, would it be possible to also have some circuitry (suspect power draw issues) to minimize issues with the analog reads on other pins? Or a spot to solder on a capacitor or some other IC that would help?
Would be nice to have a buffer for the differential ADC inputs, but I know that's not a typical want.

It sounding awesome, and do agree that the software improvements (current and upcoming) are the best value for the user base.

 

[stevech]

all these peripherals (chips, SD cards, ...) that use SPI/SS should have a hardware way to choose among about 4-8 SS bit options. Even default trace with easy cut to add a jumper wire to run to a place where the 4-8 options are lined up, would be good. This is hacky, but cheaper/smaller than some elaborate plug that you wire up and insert.
Of course, in a perfect world, there'd be a software selectable mux for such. But soldered jumpers would do for experimenters as we are.

 

[Nantonos]

Speaking of trace cuts, is it possible to have the 5V and VUSB pins already connected with a SMD Schottky diode (to avoid having to do trace cuts or use special powerless USB cables)? Like option 3 here but pre-fitted.

 

[MichaelMeissner]

In terms of micro-SD card, I can see where it might be useful, but I might worry about it consuming resources/chip real estate, even if you don't use it. If removing the card meant you could go down from a 48 pin package, to say a 40 pin package that might help other projects where the size is more important (though I suspect those projects would use Teensy 3.1 unless they needed floating point). A 48 pin package pretty much takes up an entire 1/2 size breadboard (24 rows out of 30).

I do welcome the cost reduced Teensy's, as it would replace things I would consider using 32u4's for instead (like Pololu's astar line). I've flirted with the ATtiny85's and while they are fine for some things, it is just too restrictive for me (not enough pins, not enough memory, having to use TinyWireM.h instead of Wire.h, no serial support). Similarly the Arduino Pro mini clones just don't do it for me, because I prefer having serial debug always available without extra cables (and i2c pins in the main pin breakout).

 

[MichaelMeissner]

One other thing, as an i2c user, it would be nice if the chip had room for solder jumpers to enable 4.7K pull-ups for each of the i2c buses. I haven't yet used SPI buses, but if those need special pull-up/pull-down resistors, having solder jumpers might be useful as well.

 

[onehorse]

The thing I like about the Pro Mini is that the FTDI Serial board is external to it; this reduces size in the application. Similiarly, would it be possible to have the MINI54T bootloader off-board that could be used for programming but not sit idly when installed in the application. Then maybe we could have our 48 pins but not sacrifice small size too much.

If removing the card meant you could go down from a 48 pin package, to say a 40 pin package that might help other projects where the size is more important

Agreed!
I like SD card access but would prefer to be able to configure this capability myself. That is, I would prefer a peripheral-capable ++ without the constraint of having the peripheral choice already being made. SD on board is not the right solution for every application.

 

[slomobile]

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.

Definitely appreciate a clean analog section. No need to bring it out to the edges. 4(Agnd,Aref,Aleft,Aright) surface mount pads on the upper interior surface make them accessible while breadboarded, avoid vias, and could potentially permit foil sheilding over the analog section.

Dustin

 

[instrumentek]

Oh boy oh boy!!!! i am jumping with excitement. I love the idea of a micro SD card. Is it normal for an adult to feel the excitement and anticipation like a child at Christmas? I assume it will have a similar can controller to 3.1?

 

[christoph]

Is it normal for an adult to feel the excitement and anticipation like a child at Christmas?

Yes. It means you're still alive.

 

[melstav]

*pokes his head in*

Darn. Santa still hasn't been here.

 

[Constantin]

Another option is a compact option like the yamaichi pjs008u series of through-hole SDHC card connectors that can be hand soldered, just like the RTC crystal. The downside is the greater area affected by the pins for signal routing and the added vertical height the reader imposes.

But this connector could offer a SDHC card reader option without having to build one into every product. Just a thought. I like the thing, use it in my designs.