Any Chance of a Teensy ++ 3.1?

Status
Not open for further replies.
Noting that Paul is resisting to give us un update on processor and/or expected time of marketing, my hunch is that Teensy 3.1++ is not comming soon (at least not befor Xmas).
I, myself, speculated that it will be based on a K22FN512VLH12 and got me a FRDM board to start programming it.
 
MichaelMeissner said:
According to the datasheet, the MK22FN512VLH12 part has 3 UARTs. Since Paul has said it will have more serial and SPI ports than the current Teensy 3.1, I suspect it rules out the MK22FN512VLH12.
Click to expand...
Yes and no:
Nantonos said:
(fails to find 3 UART devices, then realizes that UART and low-power UART are counted separately)
Click to expand...
It has 3 UARTs and 1 low-power UART, totalling 4. That is why my speculation table lists 4 Serial.
 
To be honest, Michael, I only found the LPUART because I wanted to "win". It was a small win, though, but still the highlight of my day!
 
WMXZ said:
Noting that Paul is resisting to give us un update on processor and/or expected time of marketing, my hunch is that Teensy 3.1++ is not comming soon (at least not befor Xmas).
Click to expand...

I've probably already said more than I should, but.....

First of all, the low cost board is coming first, based on a Kinetis L-series chip. I know many of you want higher performance hardware, and that will happen, but I feel it's important to get a solid product out that really allows good 32 bit Arduino compatibility at approx $12 retail.

Teensy++ 3.1 will definitely not be released this year. The simple truth is I've spent most of this year on software. Hopefully a lot of good has come from all that effort, but it has pushed back plans for new hardware.

Until recently, I had planned on using the K22 chip. The K22 very well may still be used. In fact, I have a (not yet working) K22-based prototype on my desk right now.

However, I'm seriously considering delaying Teensy++ 3.x, for a new chip Freescale will be releasing next year. Obviously I can't talk about anything that's under NDA. But I can tell you I have only minimal technical info (not a datasheet or reference manual), but what info I do have says it will be very well worth the wait!

Freescale and ARM have already made press releases about Cortex-M7 coming soon. So far, I don't have pretty much any technical info about it, other than what's publicly available. But it certainly looks like it's going to be awesome... and perhaps worth delaying a Teensy++ 3.x board?
 
PaulStoffregen said:
Freescale and ARM have already made press releases about Cortex-M7 coming soon. So far, I don't have pretty much any technical info about it, other than what's publicly available. But it certainly looks like it's going to be awesome... and perhaps worth delaying a Teensy++ 3.x board?
Click to expand...
For the people who need floating point, I suspect the M7 is more to their taste, since it supports both single and double precision while the M4F only supports single precision. People trying to do high speed GPS tend to need floating point, and I assume most of those people either are migrating towards the Navspark, the Linux sbc's (Raspberry Pi, Beagle Bone Black, PCdunio), or Linux/arduino combos (Yun/Tre).
 
Many of the M7's features are optional, much like M4. But I'm really hoping for a FPU that supports double.

I'm *really* excited by some of the other optional features, though it may be a few years until we see semiconductor manufacturers using 20-some nm silicon processer for microcontrollers (eg, clock speeds approaching 1 GHz). In the near term, we're probably going to get only 200 to 400 MHz speeds.
 
Do you think we really deserve 1 GHz? The extra potential would soon be eaten up by inefficient libraries and sloppy code.
 
PaulStoffregen said:
Freescale and ARM have already made press releases about Cortex-M7 coming soon. So far, I don't have pretty much any technical info about it, other than what's publicly available. But it certainly looks like it's going to be awesome... and perhaps worth delaying a Teensy++ 3.x board?
Click to expand...

http://www.arm.com/products/processors/cortex-m/cortex-m7-processor.php
http://otp.investis.com/clients/us/free_scale/usn/usnews-story.aspx?newsid=18164&cid=896

Sounds more like a Teensy 4 to me!
 
There's an Cortex-M7 from STM.. i don't want to give the link here :)
The FPU is single-precision only. More technical details are given on thier webpage, easy to find.
 
Yes, we "deserve" more speed. :)

Look at OctoWS2811 and the new audio library, or the work Bill is doing on SdFat and Danial & Mark are doing on FastLED.

Over the next several years, I'm going to do MUCH more with powerful libraries to really leverage the more capable hardware, with relatively easy Arduino style "sketch" programming.

In fact, that's a big part of my motivation to wait for Cortex-M7. I can realistically only release one or maybe 2 new Teensy hardware products per year. I really want to get an early start on M7. Faster chips run existing code only marginally faster, but designing new libraries will open up amazing possibilities.
 
Of course, those who are capable of and willing to write great code will keep publishing great libraries. I think there will be more asynchronous code, because there's simply more CPU time to be wasted, and more peripherals that can mind their own business. And that builds up on something that you've already been working on, which is a good way of sharing peripherals. Mainstream arduino will probably stay behind a bit, but we're used to that.
 
MichaelMeissner said:
For the people who need floating point, I suspect the M7 is more to their taste, since it supports both single and double precision while the M4F only supports single precision.
Click to expand...

I suspect you are right.
I see GCC is getting Cortex-M7 FPU support:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02058.html
plus suport for the 6-stage pipeline
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01146.html

Although, a fast CPU with hardware double would end to imply a whole new audio library based on internal double (like with WebAudio) rather than internal uint16-t. Although clearly that would be some way out in time. The potential of the current audio library is only starting to be explored and is already way ahead of what is available for comparable MCUs like the Cortex-M3-based Due.

There is also a grey area where faster CPU and larger memory makes it collide (price and performance-wise) with the Linux sbc's, as you said. Although those tend to not work well as microcontrollers, with with an OS in the way.
 
Frank B said:
There's an Cortex-M7 from STM.. i don't want to give the link here :)
The FPU is single-precision only. More technical details are given on thier webpage, easy to find.
Click to expand...

On the plus side, things like Dual Quad SPI , SPDIF, and three I2S sound great (all "up to" of course).
On the minus side, packages range from LQFP100 to TFBGA216 (!!) which I have a hard time visualizing on a Teensy-style DIP form factor board.
 
Nantonos said:
I suspect you are right.
I see GCC is getting Cortex-M7 FPU support:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02058.html
plus suport for the 6-stage pipeline
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01146.html
Click to expand...
Of course to use this, you likely will need to use GCC 5.0 when it comes out (and whatever the new binutils release number is). Lots of stuff is going in right now, since stage1 for gcc 5.0 is closing this week (stage1 is where you can put in new features).
 
Nantonos said:
packages range from LQFP100 to TFBGA216 (!!) which I have a hard time visualizing on a Teensy-style DIP form factor board.
Click to expand...

That is the reason why I have the "fascinator" in mind: A teensy hat for the RPi A+ and B+. (Or other SBCs, but their add-on boards aren't called "hats" and the pun wouldn't work.)
 
WMXZ said:
Obviously power consumption will increase also.
Click to expand...

Not only that. Heat issues, serious EMI potential, etc. also beckon. The good news is that these chips allow operation across an incredibly wide range of input clock speeds, so it's up to the user to decide how high to crank the juice to get acceptable performance. Will it necessarily lead to bad code? Potentially, but SRAM and other limits usually impose some sort of straightjacket re: sloppy coding. What more RAM may end up doing is making it harder to pin down memory leaks (if extant) because it may take longer to cause a collision.
 
The K22 may well surpass the K20 in market volume achivineg a lower price and giving pjrc a better margin. I would be happy to see a K22 board, specially since I do not see great SW changes necessary for it. This helps gain stability in the libraries and saves Paul time for other tasks on the list.

Regarding SWD I have seen something really interesting on electronica this week. A industry standard definition of pads for a miniature JTAG cable. The advantage is that almost no space on the board is needed and it's definitely no cost. This for the people asking for SWD access.

http://www.tag-connect.com

Edit: I meant SWD instead of JTAG. Sorry. The idea is to provide a debugging interface at no cost.
 
Last edited:
Lots of small boards are now using DebugWire. The long term issue with JTAG is that in most cases, it's many pins conflict with pins you must use in your app. I hope to try debugWire soon on an ST ARM board, and the IAR IDE. I suppose OpenOCD supports DebugWire too. And Teensy 3++
 
Last edited:
Status
Not open for further replies.
Back
Top