Any Chance of a Teensy ++ 3.1?

Status
Not open for further replies.
My most wanted feature would be, as mentioned, any simple way of being able to update the sketch even by someone who has no clue about this stuff. Ie. copying a prepared hex. While still keeping the proprietary bootloader for obvious reasons.
Explaining the download Arduino/Teensyduino etc. is too many steps for the general PC user.

Can't you already do that today?
i.e. create a self extracting executable image that runs the uploader tool?
Even include a command line up-loader tool executable and any libusb share libraries so that the user doesn't have to have any s/w installed.

--- bill
 
Hi Bill, if it is, I haven't looked into it, to be honest. My real wish would be remote update, but afaik, that's a whole nother ballpark.
 
@FYOD: If you can arrange to write the code in appropriate format to a file on a micro-sd (or suitable simile) by Teensy 3.x over whatever protocol of whatever transport (wifi, gsm, eth, blutu.., ummm...) then someone has taken care of how to write that file into flash appropriately - not that hard to find imho :)
 
Highlights: 120 or 180 MHz, single precision FPU, 2 MB flash, 256K RAM, 2 USB ports (one is 480 Mbit/sec), SDIO, 6 serial, 3 SPI, 4 I2C, 2 ADC (many inputs), 2 DAC, 24 PWM. Everything looks like a perfect superset of Teensy 3.1, so we won't "lose" anything.

The audio library capability will have quadrupled and then some, ram availability on chip is excellent, cpu speed excellent, on board flash is stunning for codebase (plus extras). This is very exciting indeed!! :)

I'm already at the limits of the 3.1 despite it's power ;)
 
My most wanted feature would be, as mentioned, any simple way of being able to update the sketch even by someone who has no clue about this stuff. Ie. copying a prepared hex.

Yeah, I've heard this request a few times. It's on a long list of stuff I'm considering, but only after debug and a high-end Teensy are released.

I think to really make it work well, some sort of dev kit software builder will be needed. You'd give it your own artwork and name and other bits of necessary info, as well as some sort of extra ID info (which the bootloader would need to be able to support). The kit would make a customized copy of Teensy Loader showing all your images and text, and it would only recognize and upload to your boards. It might even bake your HEX file right into the executable and remove the option to open anything else, for an absolutely minimal update application.

Probably best to start a new thread on this on the suggestions section. This can't even go onto my more formal TO-DO list as a message buried in this thread. Feel free to copy this message's text.

Again, I want to emphasize this will not even be considered until after debug and a high-end board are released, and probably not until the 3 planned USB types and another round of audio lib features are at least in beta testing.
 
The audio library capability will have quadrupled and then some, ram availability on chip is excellent, cpu speed excellent, on board flash is stunning for codebase (plus extras). This is very exciting indeed!! :)

Yes, indeed it should be able to really open up a lot of possibilities.

It's too bad it doesn't somehow manage to include more hours in every day... to write software support for such things!
 
I wish I could volunteer to be the 'near-clone' but, OTOH, it would probably mean reading all (at least more of) the tech docs I do my best to avoid like the plague as much as I can get away with so maybe I am glad to have the option of contributing but not really great responsibility to do so :)
 
Freescale's website just updated with info on the K26 chip!

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=K26_180

If we don't wait for a Cortex-M7 (seems pretty likely at this point), this new K26 is looking like the obvious choice for a Teensy++ board. Highlights: 120 or 180 MHz, single precision FPU, 2 MB flash, 256K RAM, 2 USB ports (one is 480 Mbit/sec), SDIO, 6 serial, 3 SPI, 4 I2C, 2 ADC (many inputs), 2 DAC, 24 PWM. Everything looks like a perfect superset of Teensy 3.1, so we won't "lose" anything.

I'm feeling pretty excited about it. ;)

Stop it Paul im drooling here........ And for the love of god make a version with all pins broken out for breadboard friendly use, having pins underneath is a PITA and I would much rather give you money then Tindie for the Breakouts......
 
Stop it Paul im drooling here........ And for the love of god make a version with all pins broken out for breadboard friendly use, having pins underneath is a PITA and I would much rather give you money then Tindie for the Breakouts......
+1 yep, drooling :D

+1 for the love of *goodness, ++ version of this one (much) sooner please, +1 I'd rather give PJRC than others...
 
Paul, I hate to be the person to ask, but would you be able to give us any clue as to when the new Teensy might become available?

I'm currently deciding whether to switch from a Teensy 3.1 to a PIC32MZ in order to get 200MHz / 512KB for a commercial product I'm developing (I've been prototyping a custom board with your MINI54). But those K26 specs look great and I'd love to have an excuse to just wait and use the next Teensy.
 
I'm currently deciding whether to switch from a Teensy 3.1 to a PIC32MZ in order to get 200MHz / 512KB for a commercial product I'm developing (I've been prototyping a custom board with your MINI54). But those K26 specs look great and I'd love to have an excuse to just wait and use the next Teensy.
I'd more than hesitate using that PIC32: EOL tops the list. It's a long list. Plenty of ARM Cortex choices.
 
I'd more than hesitate using that PIC32: EOL tops the list. It's a long list. Plenty of ARM Cortex choices.

The PIC32's are new aren't they - surely it's unlikely they'll be EOL'ed any time soon? And surely the PIC's active user community, much like the Teensy's, would make it one of the best choices? I'm new to the non-Teensy world though - what ARM Cortex choices are you thinking of that you'd recommend over PIC?
 
PIC32... Soon after the ARM CPUs became dominant, Microchip acquired rights to ye ole circa 1980's MIPS RISC.
Wikipedia says:
"In November 2007, Microchip introduced the new PIC32MX family of 32-bit microcontrollers. The initial device line-up is based on the industry standard MIPS32 M4K Core."
It could be said that ARM et al have, er, marginalized the pioneering MIPS RISC work.

How long Microchip can rationalize being the odd-man-out in the 32 bit world... remains to be seen. But they chart their own course and have enough lemmings, so far, it would appear.
 
To me, the MIPS vs. ARM debate is reminiscent of AVR vs. PIC, Intel vs. AMD, PowerPC or 68k vs. x86, 6510 vs. whatever Atari was using, etc. MCUs, CPU's, etc. come and go. Good compilers and higher-level languages make them thankfully less relevant, the best platform doesn't always win, yada yada. Thus we can focus on getting our work done rather than learning the various ways in which one assembly language has to differ from another due to underlying differences in the architecture, designer decisions, and so on.

As far as MCP is concerned, I was less than impressed by their tech support re: issues I encountered with the MCP3901 and similar chips. Known errata are left online (wrong decoupling caps are left in reference design schematics) and even if a chip has 10% of its pins disabled due to a design snafu (MCP3901 MDAT pins), the chip is left unfixed and is continued to be sold. Nuts. I still use the MCP3910 but the forum support over there makes arduino.org look good.
 
Last edited:
I don't see the analogy, due to the market position of ARM.
And I admit an anti-Microchip bias due to their unethical attempted hostile take-over of Atmel. Twice.
 
I have just discovered this thread after several days of search of a tiny board with an FPU. IMHO 48 pins is a bit wide. There are already several boards with a M4+FPU but most of them have a size which makes them unsuitable for wearable projects. A smaller size for a 3.1++ would make the difference.
 
I don't see the analogy, due to the market position of ARM.
And I admit an anti-Microchip bias due to their unethical attempted hostile take-over of Atmel. Twice.

My point is that talented designers at PJRC and Apple manage to design around limitations like marginal chips when things get stagnant. Paul has managed one transition from AVR to ARM with relatively few issues, Apple (with a somewhat larger staff on hand!) has managed this twice, once from 68k to PowerPC and the later transition to Intel. The user base was spared most of the drama, as the code base was transitioned.

I'd wager that no matter what chip Paul decides to use next will enjoy the same widespread acceptance and happiness that the Teensy series has enjoyed so far. There will be errata to work around, there will be the occasional issue, but Paul has a remarkable track record re support and stuff 'just working'. His labor is behind the scenes, creating a infrastructure that the compiler can use to turn code into MCU-specific assembly instructions. We are largely shielded from that.
 
At this moment I'm working on some new features for the existing Teensy boards. I know that's not as exciting to talk about as new hardware, and especially new higher-end hardware.

Cortex-M7 remains the big decision to make, regarding new hardware. If this software work get wrapped up before good M7 options become available, going with that K26 M4 chip seems like the best choice.

There's always a tough trade-off between pins and size. I'm leaning towards a 40 or 48 pin form factor, with as many extra I/O on bottom pads as I can fit (those bottom pads make PCB routing extremely difficult). Some people will always want a smaller board to fit into portable projects, and others will always want more I/O pins. Especially on a more expensive PCB, it's not very economically feasible to make multiple sizes. I need to make compromises and trade-offs.
 
Screw terminals ! Banana connectors ! :cool:
Evrything is better than a type of connection which needs an adapterboard or can not be used directly... it makes no sense. My 2 cents.
 
Status
Not open for further replies.
Back
Top