PDA

View Full Version : Any Chance of a Teensy ++ 3.1?



Pages : [1] 2 3

melstav
12-09-2013, 07:36 PM
I was wondering if you had any plans to make an expanded pin-count version of the Teensy 3.1, in the same vein as the Teensy++ 2.0.

I've got a project that's been back-burnered for a while that'll involve replacing a DIP-40 chip in an existing device with something more modern and programmable. (Specifically, replacing the controller in an old IBM Model-M keyboard)

The Teensy++ 2.0 is near-ideal for the application, but the MK20DX256 on the 3.1 is so much sexier.

MichaelMeissner
12-09-2013, 08:02 PM
Over at tindie.com, Tall Dog LLC has two break-out boards that give you access to the pins under the Teensy 3.0 (and now 3.1):


Teensy 3.0 breakout mark 2: https://www.tindie.com/products/loglow/teensy-30-breakout-mark-ii/?pt=directsearch
Teensy 3.0 mini-breakout: https://www.tindie.com/products/loglow/teensy-30-mini-breakout/?pt=directsearch (back ordered)


I have both, but I need to improve my soldering skills before I tackle these. The mini-breakout is the same width as the Teensy, and the mark 2 breakout is 0.1" wider on each side. You will need some additional headers for the mini-breakout (see the comments section for the mini-breakout).

Obviously, it would be more convenient if Paul offered a Teensy 3.1++.

PaulStoffregen
12-09-2013, 08:12 PM
Obviously, it would be more convenient if Paul offered a Teensy 3.1++.

I've actually been working on Teensy++ 3.X. It's too early to discuss the details, but I can assure you, I am indeed working on a Teensy++ 3.1 and I'm pretty sure you'll like it. ;)

bperrybap
12-14-2013, 08:55 PM
Could you take into consideration additional room for the 32kHz crystal?
I was so bummed when I realized the crystals I have won't fit on the Teensy3.

All ones I have are 8.2mm or 0.320 in length and 2.9mm or .115in in diameter.
The ones on the DS1307 i2c modules I have also use that same sized crystal.
Maybe that size is more common than the 6mm citizen crystal needed for Teensy3?


--- bill

PaulStoffregen
12-14-2013, 09:36 PM
I'm considering a LOT of things for future products, but I can't comment at this time.

Nantonos
12-15-2013, 01:34 PM
I've actually been working on Teensy++ 3.X. It's too early to discuss the details, but I can assure you, I am indeed working on a Teensy++ 3.1 and I'm pretty sure you'll like it. ;)

I'm aware that Paul will not be able to comment, but here is my speculation. Paul has said before that he is working on a new product, and is unable to discuss the details because it uses an unreleased chip (so presumably, it is under NDA). The chip used in the Teensy 3.1`is 72MHz and has two ADCs; there was an announcement of K20 72Mhz chips with 2 ADC on Nov 15, 2011 (http://media.freescale.com/phoenix.zhtml?c=196520&p=irol-newsArticle&ID=1630706&highlight=) with full production scheduled for Q2 2012. Thus, the Teensy 3.1 is not the new upcoming very powerful product with an as yet unreleased chip. (Its a very nice mid-life upgrade for Teensy 3.0, to be sure).
Just my speculation of course.

jbliesener
12-16-2013, 01:30 PM
I would really LOVE to see accessible JTAG Pins.

On the other hand, I was thinking about other debug options, maybe running the OneWire protocol (or something similar) on the PROG line to send commands to the Mini54 that would then forward them to the JTAG port on the Kinetis. This would be a simple firmware-update. Actually, a SECOND Teensy could be used to translate JTAG debug commands from GDB into this OneWire protocol... Anyone knows if the speed of 15.4 kbit/s (standard mode) or 125 kbit/s (overdrive mode) of OneWire imposes any serious restriction for JTAG debugging?

Paul, I know that you consider the Mini54 firmware proprietary, but do you see a chance for this?

melstav
04-22-2014, 02:12 PM
I've actually been working on Teensy++ 3.X. It's too early to discuss the details, but I can assure you, I am indeed working on a Teensy++ 3.1 and I'm pretty sure you'll like it. ;)

I can haz details nao? KTHXBAI!

:D

christoph
05-03-2014, 02:50 PM
Probably not before maker faire...

ZackRR
05-14-2014, 05:05 PM
I've actually been working on Teensy++ 3.X. It's too early to discuss the details, but I can assure you, I am indeed working on a Teensy++ 3.1 and I'm pretty sure you'll like it. ;)

Any update of when we could expect the Teensy++ 3.X??? I'm anxiously waiting another great product (and not needing a breakout board to conveniently access all the pins) :)

Thanks!

BenDanville
07-09-2014, 04:49 AM
Any update of when we could expect the Teensy++ 3.X??? I'm anxiously waiting another great product (and not needing a breakout board to conveniently access all the pins) :)

Thanks!

I second this sentiment! This has been such a great product it's hard not to be greedy for more developments ;)

PaulStoffregen
07-09-2014, 05:20 AM
What do you imagine the price of a Teensy++ 3.1 might be?

nlecaude
07-09-2014, 06:00 AM
29$ would seem to be a logical price given the teensy2++ is 24$ and the Teensy 3 is 19$.

BenDanville
07-09-2014, 06:14 AM
29$ would seem to be a logical price given the teensy2++ is 24$ and the Teensy 3 is 19$.

This seems very reasonable, I've gone through about 10 Teensy 2++ and Teensy 3.1 depending on the application, for a few bucks more I'd just buy the 3.x++ 'just in case'

stevech
07-09-2014, 07:44 AM
Keep the Teensy ++, teensy!
Lots of T2++ and bigger boards out there.

onehorse
07-09-2014, 08:15 AM
Keep the Teensy ++, teensy!

+1 Small is all, Paul!

christoph
07-09-2014, 08:49 AM
$29 if there's a second SPI, $24 otherwise ;)

Really depends on what it can do, but I'm pretty sure it's going to be a great thing.

BenDanville
07-10-2014, 01:18 AM
+1 Small is all, Paul!

Paul! Too small appalls, but tall enthralls overall!

stevech
07-10-2014, 01:33 AM
small makes 'em unique.

Nantonos
07-10-2014, 01:55 AM
It very much depends on what extra it offers.

Looking at why I use Teensy++ 2.0 in a project, Teensy++ 2.0 costs 50% more than Teensy 2.0 and gives
* 4x the flash
* ~3x sram
* 4x eeprom
* ~2x digital IO pins including 3 complete 8-bit port sets (A, C, F) while leaving I2C and SPI free (or 5 ports, including B and D).

In my project that let me dispense with port expanders and manipulate lots of IO fast while having lots of room for lookup tables. So it was much better than Teensy 2.0 or Teensy 3.x in that regard.

Teensy 3.1 costs about $20. So about $30 would seem reasonable and follow that precedent; depending on what ++ 3.1 would let you do that 3.1 does not. Some desirable things from my point of view:

* more pins conveniently available
* some contiguous ports to allow bunches of pins to be read or set together
* floating point
* better ADC (higher ENOB, more simultaneous channels/comparators/PGA)
* more and/or better DAC
* twin I2S to controll two Audio boards
* USB host capability

If the price tends towards only 25% more than 3.1 then it would sell like hot cakes. If it tends towards 75% more than 3.1 than it faces (possibly unfair) comparison with larger, faster, but connectivity-challenged linux-based boards like Beaglebone Black at $55.

But it really all depends on what extra it can do over 3.1.

hexodin
07-10-2014, 08:52 PM
I just want more pins that can be accessed like AVR PORTS and correctly sequenced as the sexy Teensy ++ 2.

I think I'll make a breakout for Teensy 3.1 like the tall-dog one. Good idea!

PaulStoffregen
07-15-2014, 03:14 AM
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:


ARM Cortex-M4F (Floating Point Unit)
Under $30
More I/O pins
More serial & SPI ports
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.

daperl
07-15-2014, 03:28 AM
Sounds excellent. Can you tell us how much memory you're predicting for the Cortex-M4F chip? If so, how much?

stevech
07-15-2014, 04:09 AM
Without compromising PJRC's protection from counterfeits, some of us really need a way to do code in flash upgrades remotely, e.g., via a wired/wireless network connecting to an unattended device that may by quite distant.
Preferred way is to have an SD card or better, a low cost flash chip which can also be used for data logging. Less preferred but do-able is a custom bootloader in a never-overwritten sector of flash that does an in-place down-load and rewrite flash, without bulk storage. I've done this, using a CRC check so that a disrupted download will case the bootloader to start again. Worked well.

The USB-only precludes M2M type applications.

Here's an example of a board with a very low cost flash chip for bulk storage. (scroll down to schematic)
http://www.anarduino.com/miniwireless/
That chip is 16MB of fast bulk flash, via SPI. Cost $1.40 @ 100ea

PS: a board like that with a Cortex Mx instead of the too-small RAM mega328 would be a good seller, with Teensyduino libraries. Based on quantities of Anarduino's board sales, mostly for M2M apps.

EDIT: added flash chip info above

MichaelMeissner
07-15-2014, 04:49 AM
Unfortunately, you probably are constrained to having the pins in the same location as the Teensy 3.x, but it would be nice if Vin and Vusb were adjacent to each other, so we could use a standard 2 pin jumper. However, that is low on the list of priorities.

Nantonos
07-15-2014, 08:43 AM
Here are 5 things that are absolutely certain about Teensy++ 3.x:

ARM Cortex-M4F (Floating Point Unit)
Under $30
More I/O pins
More serial & SPI ports
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
07-15-2014, 11:45 AM
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
07-15-2014, 12:02 PM
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 (http://en.wikipedia.org/wiki/UEXT).


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
07-15-2014, 12:06 PM
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
07-15-2014, 12:54 PM
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
07-15-2014, 01:18 PM
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
07-15-2014, 02:00 PM
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
07-15-2014, 05:31 PM
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
07-15-2014, 05:49 PM
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
07-15-2014, 06:03 PM
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
07-16-2014, 02:06 PM
+1 for micro sd card socket.

KurtE
07-16-2014, 03:19 PM
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
07-16-2014, 04:18 PM
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
07-16-2014, 04:46 PM
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
07-17-2014, 12:21 AM
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
07-17-2014, 02:44 AM
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
07-17-2014, 10:43 AM
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 (http://www.pjrc.com/teensy/external_power.html) but pre-fitted.

MichaelMeissner
07-17-2014, 01:46 PM
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
07-17-2014, 04:49 PM
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
07-17-2014, 05:30 PM
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
07-18-2014, 03:08 PM
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
07-21-2014, 02:04 AM
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
07-25-2014, 08:47 AM
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
09-17-2014, 09:46 PM
*pokes his head in*

Darn. Santa still hasn't been here.

Constantin
09-18-2014, 12:33 AM
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.

deelaleo
09-27-2014, 08:50 AM
Can't wait for this!

Love the idea of longer board with more connections and if the board itself is more powerful, it is a more than welcome feature!

My main interest would be in connectivity; so if there is extra space, I would LOVE to see some sort of wireless communication on the board; like Bluetooth or Wifi; SD card would be nice too, altho for the application that I have in mind, I would benefit more from a quick and reliable wireless connection, compared to a bunch of storage on the board itself.

Another nice thing that I feel it is missing, is a way to connect to 3.3V sensor, without having to do a voltage divider with resistors. If there was a way to select the output voltage on the pins between 5V and 3.3V, it would be so much easier to hook up a lots of sensor!

Another item on the wish list is an extra I2C channel (or 2), and also a multiplexer on board; so I don't have to use an external one, if I want to hook up more sensors of the same time to the board.

Last but not least: a LiPo charger, to use batteries and recharge them without the need to take them out.

I know that most of these are not possible, not planned or does not interest the majority; but I thought that it may be useful to put them as "wish list" in case there is any future plan.

Price is not a problem, if I can save hassle to connect multiple boards to get what I need, and mostly space; I am fine to pay more.

Besides my BeagleBone Black, this is my favorite board, but if you start to stack multiple boards to the Teensy, then the advantage start to fade (and I understand that maybe it was not made with certain kind of uses in mind, so it could be me having too many expectations).

Can't wait to see the new board :)

CheapB
09-27-2014, 02:34 PM
I realize there are some FCC complications, but i would love to see a T3.x with built-in wifi. I think there is a huge demand for some thing like this for IoT and other applications. Also support up to 500mA (like uno) for addon boards or shields would be great. I have had a couple of situations where the benefits of a small form factor is eliminated due to an addition of a power board.

MichaelMeissner
09-27-2014, 03:46 PM
Digistump came out with the DigiX that was an Arduino Due clone with built-in wi-fi (http://digistump.com/products/50). It is out of stock now, but I assume it will eventually be available again.

Now, I bought the DigiX during its initial kickstarter campaign, but I've never used it. A lot of it is due to the amazing support that Paul does with the Teensy with frequent updates, compared to no real updates to the DigiX. Part of it is just the size of the Due board is so big that I keep coming back to the Teensy.

CheapB
09-27-2014, 05:58 PM
Digistump came out with the DigiX that was an Arduino Due clone with built-in wi-fi (http://digistump.com/products/50). It is out of stock now, but I assume it will eventually be available again.

Now, I bought the DigiX during its initial kickstarter campaign, but I've never used it. A lot of it is due to the amazing support that Paul does with the Teensy with frequent updates, compared to no real updates to the DigiX. Part of it is just the size of the Due board is so big that I keep coming back to the Teensy.

Thanks for the link, but I feel the same way as you - I am not going to add to the pile of boards I never use.

melstav
09-28-2014, 12:04 AM
Some of us can't help ourselves. I keep hoping I'm going to simultaneously find the time and energy to do something with the various boards that I come across that look really nifty. Even when I have a project in mind when I come across a new board.... I'm still acquiring nifty, awesome boards that I've GOTTA HAVE faster than I can put them to use.

eduardo
09-29-2014, 09:37 AM
Hi Paul.
Please allow me some suggestions for a new HW.
Whenever you use small ceramic caps in parallel to a cap in the 1..10µF range please use 10nF instead ot 100nF. (See teensy 3.1) The reason is that 0603 size 100nF caps behave very poor in the RF domain. You get a much (!) better overall EMC behaviour with 1nF or 10nF. (I don't give you all the details here but you may ask me if you're interested.)
I recommend Murata BLN ferrites or equivalent. Always take the type that barely supports the 2x rated max current Never ever use a normal inductor instead of a ferrite.
By the way. VCC traces do not (!) have to be "the thicker the better". EMC is better if they are just wide enough for the max. current. Since the block-caps are always placed close to the chips's power pins the RF part of the current will stay in the local area between the cap and the chip. Narrow VCC traces act as RF barries.
Good luck with the new design. If I can be of any help just send a message.

eduardo
09-29-2014, 04:03 PM
What about a simple MK22FX512VLH12 version of teensy 3.1?
HW needs no changes at first sight.
SW may start with FPU support for a start and add new clock rates after a while.

Constantin
09-29-2014, 05:38 PM
...Whenever you use small ceramic caps in parallel to a cap in the 1..10µF range please use 10nF instead ot 100nF. (See teensy 3.1) The reason is that 0603 size 100nF caps behave very poor in the RF domain. You get a much (!) better overall EMC behaviour with 1nF or 10nF. (I don't give you all the details here but you may ask me if you're interested.)

I'd love more info on this. Please share as the reference manual gives somewhat different advice... or perhaps you recommend the use non-0603-sized ceramic caps? My recollection here is different - I thought I read somewhere that smaller 0603 decoupling caps are preferable over larger 0805, etc. I'll have to dig up that source. The below is quoted from the ADC section in the reference manual, see p. 695 (http://www.pjrc.com/teensy/K20P64M72SF1RM.pdf):

The best external component to meet this current demand is a 0.1 μF capacitor with good high-frequency characteristics. This capacitor is connected between VREFH and VREFL and must be placed as near as possible to the package pins. They do recommend 0.01uF caps on analog input pins, however. on p. 697, the manual goes on to say "
The ADC accuracy numbers are guaranteed as specified only if the following conditions are met: There is a 0.1 μF low-ESR capacitor from VREFH to VREFL. There is a 0.1 μF low-ESR capacitor from VDDA to VSSA. If inductive isolation is used from the primary supply, an additional 1 μF capacitor is placed from VDDA to VSSA

In the in it's cookbook for SAR ADC measurments (http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4373.pdf?fasp=1&WT_TYPE=Application%20Notes&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation&fileExt=.pdf), Freescale writes:

To achieve the best performance from an ADC, the overall system must be designed and configured correctly. The hardware setup must carefully follow data sheet recommendations, for example:
• Place 0.1 µF capacitor positioned as near as possible to the package power pins (one capacitor for each power pins pairs)
• Place approximately 100 µF capacitor to power pins
• PCB trace lengths should be minimal
• It is necessary to consider all parasitic passive components due to PCB traces in your application
• Special care must be taken to minimize noise levels on the analog power and reference pins
• Use separate power and ground planes for digital and analog supply pins
• If the analog and digital circuits are connected to the same power supply a small inductor (or ferrite) should be connected between digital and analog pins
• Separate analog components from noisy digital components by ground planes (not in parallel), and place the analog ground trace around the analog signal trace

In addition the aforementioned recommendations, special attention must be paid to the design and selection of the external RC components. Minimum values for the external RC components must be considered in final calculations. See MC56F825x/MC56F824x Digital Signal Controller (document MC56F825X) (http://cache.freescale.com/files/dsp/doc/data_sheet/MC56F825X.pdf)

The above suggests that 0.1uF caps are recommended for optimum ADC performance, the arena where such decoupling likely will make the biggest difference. I am happy to educated differently, however. What I found particularly interesting was the much higher 100uF of recommended local IC power storage...


I recommend Murata BLN ferrites or equivalent. Always take the type that barely supports the 2x rated max current Never ever use a normal inductor instead of a ferrite.
Very interesting. I couldn't find a BLN series, but Murata does list a BLM series. Are there particular models you would recommend using in a Teensy application?

eduardo
09-30-2014, 09:12 AM
Hi Constantin.
Let's not put too much of analog/EMC special aspects into this thread. I fear we miss the topic.
In short. You are right. BLM ist the prefix. As I said, chose the type that carries twice the max current for a thumb's rule. http://www.murata.com/en-sg/products/emc/emifil/bl
Capacitors degrade as the strength of the electric field in the dielectric rises. This happens if high capacitance must be realized in small geometries. The dieletric gets thinner and thinner and the cap gets non-ideal. High epsilon ceramics also degrade the linearity. Rule of thumb is NP0 or X7R ceramics, cap values the smaller the better if a bigger cap is placed in parallel. This is not the case in the ref or ADC section. Please reread my last post and observe the teensy 3.1 schematics in parallel. Generally speaking, power supply decoupling for digital sircuits is done with 10nF instead of 100nF in parallel to 1..100µF nowadays. 100nF (see freescale coockbook) are out of fashion so to say. RF decoupling is 10pF // 1nF // 1µF f.e. just to show you that the choice of block caps is not general. But that's another story. Please google capacitors, block cap, cap ceramics, cap non-linearity, NP0, X7R, decoupling, simulation of passive components, ...
You may open another topic "HW Decoupling & Coupling" and I will be glad to post some info.

PaulStoffregen
09-30-2014, 09:45 AM
Just want to chime in for a moment...

For the last several months, I've been focusing pretty much only on software. The audio library has taken a pretty tremendous amount of time. I'm pretty happy with the result so far. Likewise, a number of new features in 1.20 took quite a bit more time than anticipated. My intention is to release Audio version 1.0 later today. Likewise, I'm going to make a 1.20-rc5 release with Audio 1.0, FlexCAN (Teachop's work), and a couple small fixes.

My intention for October and November is to swing back to hardware development. I can't make any specific promises, so this general plan is the most I can really say.

Probably early next year, after a couple more PJRC products are released, I'll get back into the audio library in a really serious way and implement much of this stuff on the roadmap (http://www.pjrc.com/teensy/td_libs_AudioRoadmap.html).

If only there were more hours in each day......

Constantin
09-30-2014, 02:29 PM
Let's not put too much of analog/EMC special aspects into this thread. I fear we miss the topic.

Well, you are the one that brought it up. Moreover, while you stated that smaller / larger cap combos are needed for better EMI performance, you didn't include examples of where the current Teensy design is deficient in terms of it's real life EMI performance. From a design point of view, actual measurements would be extremely helpful instead of posting what you think are good guidelines to follow. Based on Paul's description of the events, designing the Teensy 3 was a very time consuming event, so I would not expect him to change anything unless there was a very good reason.

That is not to say that your points of view aren't 100% valid, they very well may be. However, when you are ask Paul to invest his time to accommodate your recommendations, it makes sense to show the difference between a design that meets your recommendations vs. one that does not. Since you seem to be learned in the craft, I suggest a test with a MK20DX128 and a Mini54: One layout should be able to accommodate both design philosophies (i.e. yours and that of the manufacturer) simply by having two capacitor slots next to each power pin. In one design, you'd decouple power pins with a single 0603 0.1uF cap (leaving a slot empty) while your recommended layout can have your suggested 10nF / 1uF cap per power pin combination. Other accessories should be left 100% similar, i.e. the large vout3.3 cap, VUSB input cap, ferrites, and so. Finally, test the two rigs for EMI performance…

I bring this up because to date no one on this forum to my knowledge has complained regarding EMI-related issues re: the Teensy 3. Where I would expect to see the issues the most (i.e. ADC performance), forum members like JBeale have documented RMS noise levels around 50 uV (http://forum.pjrc.com/threads/25111-Decreasing-noise-on-Teensy-ADC/page2) with a very basic setup (i.e. no fancy external voltage reference and so on), though using a lot of averaging. I'm pretty sure Paul documented the 13bit performance of the ADC somewhere, but I can't find the reference right now, apologies.

Looking around the net a bit, I found this interesting article over at Dallas/Maxim regrading rated vs. actual performance of ceramic capacitors (http://www.maximintegrated.com/en/app-notes/index.mvp/id/5527). The data is eye-opening and illustrates nicely how relying on a spec such as "X7R 1uF 0603 6.3V ceramic" is simply not good enough. The author demonstrates how smaller-sized ceramic caps can have actual capacitances that are a fraction of the rated one... and it's not an easy problem to solve, you need to review the data sheet for a specific capacitor to be sure it does what its marketing pitch implies it can. Not so much an issue at a typical decoupling value like 0.1uF but definitely an issue with 'larger' capacities in ceramic caps.

In closing, your advice may be spot-on so please consider documenting any issue per Paul's forum rule "Always post complete source code & details to reproduce any issue!" If there is a significant performance improvement that you can demonstrate, he'll likely do it (he has in every other instance I can think of). But the need for a redesign has to be demonstrated before you can expect him to embark on that quest. Cheers and thanks!

stratosfear
10-03-2014, 10:51 AM
I'm excited about a ++3.1 and have put a design on hold until it's released.

There are two things I particularly like about the ATSAM3X on the Due that are not available with the MK20. One is per-channel programmable gain on single-ended ADC channels. The other is the ability to modify ADC channel sequence. Does the MCU you're considering have these features?

Around $30 sounds great if it doesn't need an expansion board for extra pins. A Teensy and Tall Dog's breakout come to the same price and create a bulkier project.

Jon

eduardo
10-07-2014, 10:59 AM
If teensy++3.1 is basicly a K22 board with 48 DIL pinning I expect ~ $25.
A good price point would make all "power users" specially of the audio lib migrate to the T++ which would make support for you/Paul easier. Otherwise I see a lot of your time going into projects or functions that run well in T++ and close to the edge on T3.1.

Markus_L811
10-08-2014, 08:00 PM
I set a bet on something like the T 3.1 with integrated Ethernet support also with more space to store programs like an LwIP-Stack or so

stevech
10-08-2014, 10:08 PM
I set a bet on something like the T 3.1 with integrated Ethernet support also with more space to store programs like an LwIP-Stack or so The mbed gang struggled for months and months to get LwIP stack to run reliably for TCP and UDP with non-trivial use cases. I read lately that it still isn't stable enough - race conditions, etc.
That's why WizNet and equivalent IP stack off-loading NICs are THE way to go.

But owning to Teensy's size and uses, I'd vote for a good 802.11g/n interface for IP networking. Certainly not an RJ45.

Markus_L811
10-09-2014, 09:41 AM
The mbed gang struggled for months and months to get LwIP stack to run reliably for TCP and UDP with non-trivial use cases. I read lately that it still isn't stable enough - race conditions, etc.
That's why WizNet and equivalent IP stack off-loading NICs are THE way to go.

But owning to Teensy's size and uses, I'd vote for a good 802.11g/n interface for IP networking. Certainly not an RJ45.

Yeah on the Due it's the same the Lwip is there also unstable.

PaulStoffregen
10-09-2014, 09:55 AM
As I recall, even Linux was plagued by an unstable network stack until late-1995, where the remote system would suddenly get "connection reset by peer" while using telnet & ftp. It's easy to take TCP/IP networking for granted, but there's a lot of complexity and fine details in the code to really get it right.

MichaelMeissner
10-09-2014, 03:19 PM
Yes, I remember carefully having to tune the MTU setting in Linux to avoid bugs in either the Linux stack or the routers I was using. Fortunately, that is mostly a thing of the past.

As I said either in this thread, or one of the others, I tend to think using an embedded Linux arm box (Rasberry Pi, BeagleBone Black, etc.) is better long term for dealing with the network stacks for both ethernet and wi-fi, and use embedded processors like the Teensy for dealing with hardware. Obviously, you can get the support to work on a Teensy, but you generally will be behind the curve to keep up with changes/fixes in the stack and do the backports, worry about memory issues, etc.

stevech
10-09-2014, 07:29 PM
... I tend to think using an embedded Linux arm box (Rasberry Pi, BeagleBone Black, etc.) is better long term for dealing with the network stacks for both ethernet and wi-fi, and use embedded processors like the Teensy for dealing with hardware. . I wholeheartedly agree. However, if one uses WizNet 5100/5200 based TCP/IP/ARP/ICMP off-load, and the MCU like Teensy has only to handle a socket interface and streaming for HTTP, then it can be reliable.

Most people don't realize how hard TCP/IP et al really are. E.g., the mbed gang as above. I fielded quite a number of systems with 5100 chips (812J modules) and with carefully done code, and INTERRUPT-DRIVEN 5100 chip interface, it has been very reliable for unattended operations for a long time. Most don't appreciate the difference between an off-load like WizNet or Lantronix, and the crappy Microchip NIC which offloads virtually nothing.

What amazed me is that WizNet's IP stack on the 5100/5200 is in ROM. No re-flashing is possible. Bugs in their code just weren't a problem. They don't support dynamic TCP window sizing, but that's not a show stopper. Good stuff.

Constantin
10-13-2014, 02:54 PM
Now for something completely different... I wonder if it wouldn't be better for the next Teensy to feature a pair of adjacent pads for connecting Vout3v3 to 3.3V instead of the current VUSB-Vin pad combination. Here is why:

Allowing the Vout -3.3v connection to be cut would also allow folk to operate the Teensy on a much wider range of voltages, i.e. battery operations, for example. Whenever the USB cable is inserted, Vout is powered up via USB (irrespective of the current CPU voltage) and the chip can communicate over USB, that part then goes back to sleep whenever the USB bus is disconnected. To be clear, I can't take credit for the idea, it was suggested in the Freescale manual describing how the USB portion of the chip works. Seems like a good idea for long term battery-operated Teensy's logging away, for example.

Additionally, those who seek to wring the best performance out of the ADC can easily isolate the USB-induced EMI of the chip from the rest of the system... simply cut the pad, use your own VREG to power 3.3V from Vin. But you can also hang a bigger set of caps off the USB, 3.3V buses, etc. ameliorating most of the USB-ADC issue. So that can be done either way.

Last but not least, I wonder if AREF shouldn't have it's own power supply and hence perhaps should not be connected to 3.3V at all (ferrite notwithstanding). That said, the 470 Ohm resistor is easy enough to find and remove on the current teensy for those that care. Having AREF be a external-edge pin would certainly help with giving it a dedicated quiet power supply, even if it's reliant on a shunt to AGND system. Perhaps make AGND and AREF adjacent to make it really easy to implement on a breadboard... i.e. AREF, AGND, A0,A1, etc. ? Or perhaps a set of 0805 or 1206 pads that would allow a user to solder on a small shunt reference?

Nantonos
10-13-2014, 04:00 PM
Good points, although my preference for the next teensy would be that pad and track cutting not be required for reasonably forseeable uses like battery or external power operation; same for removal of SMD components. Both operations limit the potential audience.

AGND and AREF adjacent and easily accessible would be a positive change, certainly.

PaulStoffregen
10-13-2014, 05:59 PM
One of my major goals is to keep the form factor similar between Teensy 3.1 and near-future boards.

Every decision on pinouts involves a lot of difficult trade-offs. Keeping pin compatibility places a lot of limits on what can be changed. But the huge benefit is (more or less) the ability to plug different boards into the same project, depending on your needs. Historically, this was a problem with the older boards, where you couldn't go from Teensy 1.0 to Teensy 2.0 to Teensy++ 2.0 without pretty much redoing the project at each step.

My current plan for Teensy++ 3.1 has 48 "outside" pins, where the 28 on the left side (the USB side) very closely mimic Teensy 3.1's pinout. The idea is you could put the new board into a project originally using Teensy 3.1, assuming there's room for the extra 1 inch of PCB to hang over. Or if you design something with Teensy++ 3.1 and later want to step down to a less expensive board, the others will be mostly pin compatible.

There is a lower cost (approx $12) board also planned, which will also use the same 28 pin form factor.

Constantin
10-14-2014, 07:40 PM
Got it and makes sense. Still, if you could consider the adjacent 3.3v-Vout pad approach as a possibility in case there is room, that would be great.

t3andy
10-18-2014, 11:37 PM
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.



There is a lower cost (approx $12) board also planned, which will also use the same 28 pin form factor.


ARM Cortex-M0+ = very low power = battery operation in years!!!! :D
Bring it on ... @ Duff are you listening?

stevech
10-19-2014, 01:32 AM
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. ]
I hope it's 128KB flash, or more.
KL46?
64KB not enough.

PaulStoffregen
10-19-2014, 06:35 PM
The low cost board will have 60K flash (4K will be reserved for EEPROM emulation). Sorry Steve, but trade-offs had to be made to keep the cost low. We're absolutely locked into 60K at this point in time.

Overall, I think it's going to be a great product. Today there are a lot of low-cost dev boards featuring the ATTINY chips, which are terribly feature poor. The intention of is to offer a LOT more capability "for only a little more $$" than boards like Adafruit Trinket & Gemma and Chinese clones of Arduino Nano & Leonardo. It will have good USB performance (DMA-based) and still a rich peripheral set (3 serial, I2C, SPI, 10 PWM, many ADC pins, etc) and enough memory to allow for excellent compatibility with nearly all Arduino libraries.

You can't have everything on the cheaper low-end product. 5V tolerance, large memory, and CPU speed will be the main differences.

stevech
10-19-2014, 06:49 PM
well, a low cost board WITHOUT the <expletive> (Harvard) dual address space and bank-switching of the PIC/AVR will be great.

Keep an eye to the competition...
$29 but to some, that's not cheap http://www.mikroe.com/mini/stm32/ 1MB flash, large RAM. Form factor is larger of course. Design 2yrs old. (just bare metal, not much usable in libraries and Mikroe's compilers are not so hot).
http://www.mouser.com/ProductDetail/mikroElektronika/MIKROE-1367/?qs=PTWijy4SnDFg2IeD44rscw%3d%3d (Mouser's mark-up is probably 30% or more)

Nantonos
10-19-2014, 07:00 PM
The low cost board will have 60K flash (4K will be reserved for EEPROM emulation).
It will have good USB performance (DMA-based) and still a rich peripheral set (3 serial, I2C, SPI, 10 PWM, many ADC pins, etc) and enough memory to allow for excellent compatibility with nearly all Arduino libraries.

That sounds pretty good. I did look at ATTINY and yes, inexpensive but very feature poor plus library support is patchy at best. Wide library support at launch will probably be very important. Libraries do have a lot of __MK20DX256__ and __MK20DX128__ tests, but some of that code might work anyway with an additional elif.

For SPI peripherals which have to be monitored constantly but only reacted to occasionally (when certain events happen) or which produce a small volume of derived data (last 100ms running average, etc) one of theese could talk over I2C to a T3.x master controller thus freeing up the main T3.x SPI bus more more important tasks. A few "helper" examples would be good to develop during the beta phase, I suspect.

Potential product names: Itsy, Bitsy, Weensy, Polka, Dot.

Nantonos
10-19-2014, 07:22 PM
(fails to find 3 UART devices, then realizes that UART and low-power UART are counted separately)

PaulStoffregen
10-19-2014, 07:25 PM
Freescale's documentation leaves a lot to be desired.

PaulStoffregen
10-19-2014, 07:39 PM
Keep an eye to the competition...


Oh, believe me, I do try to follow the competition. But I also try not to spend too much time doing so. Seems like there's something new almost every day.

Nantonos
10-19-2014, 08:04 PM
I notice MKL26Z64VFM4 has 64k Flash, 8k SRAM, I2C, SPI, 2 UART+1 low power UART, 16bit ADC w/13ENOB, 12-bit DAC :D (whee!) and, oddly, I2S :confused:. Potentially, 2 useable I2C channels. One and a half SPI :rolleyes:

QFN32 and 48Mhz. So it could potentially be T3.1 pinout compatible, right down to DAC/A14 on the end.

stevech
10-19-2014, 08:18 PM
Oh, believe me, I do try to follow the competition. But I also try not to spend too much time doing so. Seems like there's something new almost every day.
Yes, but very few in the realm of the Teensy form factor. That's the discriminator now.

Frank B
10-28-2014, 09:02 PM
A dedicated "debug" LED (red color) which lights when an exception (e.g. bus fault) occurs would be fine. It could be used for debugging too.
Or, it could be a nice "playground" with two LEDs on board :-)

PaulStoffregen
10-28-2014, 09:17 PM
A dedicated "debug" LED (red color) which lights when an exception (e.g. bus fault) occurs would be fine.

You can have this right now, with just a little bit of hacking, and of course connecting a LED and resistor.

Edit mk20dx128.c, around line 54.



void fault_isr(void)
{
while (1) {
// keep polling some communication while in fault
// mode, so we don't completely die.
if (SIM_SCGC4 & SIM_SCGC4_USBOTG) usb_isr();
if (SIM_SCGC4 & SIM_SCGC4_UART0) uart0_status_isr();
if (SIM_SCGC4 & SIM_SCGC4_UART1) uart1_status_isr();
if (SIM_SCGC4 & SIM_SCGC4_UART2) uart2_status_isr();
}
}


Just add a line before that while() loop to turn your LED on. Easy!

Frank B
10-28-2014, 10:23 PM
Hi Paul, i thought of an otherwise unused GPIO of the new Teensy (if there is a "spare" GPIO).

t3andy
11-01-2014, 01:12 AM
@Paul S ... Any updates on the new Teensy++ 3.x? :confused:

Frank B
11-12-2014, 06:07 PM
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:


ARM Cortex-M4F (Floating Point Unit)
Under $30
More I/O pins
More serial & SPI ports
More memory




Does more memory mean more RAM ? How much ?

I ask because decoding aac-HE (aac+) needs ~100 KB RAM :-)

Nantonos
11-12-2014, 09:19 PM
If for example the Teensy++ 3.x were to use the MK22FX512VLH12 or MK22FN1M0VLH12 then it would have 128k SRAM (and 512k or 1M Flash). Those are 64 LQFP parts.

Frank B
11-12-2014, 09:27 PM
If for example the Teensy++ 3.x were to use the MK22FX512VLH12 or MK22FN1M0VLH12 then it would have 128k SRAM (and 512k or 1M Flash). Those are 64 LQFP parts.

MK24FN1M0VLL12 is 100 LQFP with 256 k SRAM.

Paul, what chip it is? :-)

stevech
11-12-2014, 09:44 PM
Intended as a point of comparison only - hoping to not trigger a my-ARM-is-best scuffle...

From a competitive marketplace viewpoint, hardware alone, MapleLeaf Mini was good for its day, and the current Mikroe ST mini-M4 board is a good value (Mikroe's software not viable).

Not so much the board, but the chip's peripherals and H/W FPU are appealing.
Lots of goodies for the price.
But for teensy to make a change from Freescale now would likely be a lot of work.
Still, this $30 board with STM32F415RG is impressive - and would be moreso if designed/sold by other than Mikroe.

http://microcontrollershop.com/product_info.php?products_id=5403
http://www.mikroe.com/mini/stm32/


Key Features


Core: ARM 32-bit Cortex™-M4 CPU with FPU, Adaptive real-time accelerator (ART Accelerator™) allowing 0-wait state execution from Flash memory, frequency up to 168 MHz, memory protection unit, 210 DMIPS/1.25 DMIPS/MHz (Dhrystone 2.1), and DSP instructions
Memories
Up to 1 Mbyte of Flash memory
Up to 192+4 Kbytes of SRAM including 64-Kbyte of CCM (core coupled memory) data RAM
Flexible static memory controller supporting Compact Flash, SRAM, PSRAM, NOR and NAND memories
LCD parallel interface, 8080/6800 modes
Clock, reset and supply management
1.8 V to 3.6 V application supply and I/Os
POR, PDR, PVD and BOR
4-to-26 MHz crystal oscillator
Internal 16 MHz factory-trimmed RC (1% accuracy)
32 kHz oscillator for RTC with calibration
Internal 32 kHz RC with calibration
Sleep, Stop and Standby modes
VBATsupply for RTC, 20×32 bit backup registers + optional 4 KB backup SRAM
3×12-bit, 2.4 MSPS A/D converters: up to 24 channels and 7.2 MSPS in triple interleaved mode
2×12-bit D/A converters
General-purpose DMA: 16-stream DMA controller with FIFOs and burst support
Up to 17 timers: up to twelve 16-bit and two 32-bit timers up to 168 MHz, each with up to 4 IC/OC/PWM or pulse counter and quadrature (incremental) encoder input
Debug mode
Serial wire debug (SWD) & JTAG interfaces
Cortex-M4 Embedded Trace Macrocell™
Up to 140 I/O ports with interrupt capability
Up to 136 fast I/Os up to 84 MHz
Up to 138 5 V-tolerant I/Os
Up to 15 communication interfaces
Up to 3 × I2C interfaces (SMBus/PMBus)
Up to 4 USARTs/2 UARTs (10.5 Mbit/s, ISO 7816 interface, LIN, IrDA, modem control)
Up to 3 SPIs (42 Mbits/s), 2 with muxed full-duplex I2S to achieve audio class accuracy via internal audio PLL or external clock
2 × CAN interfaces (2.0B Active)
SDIO interface
Advanced connectivity
USB 2.0 full-speed device/host/OTG controller with on-chip PHY
USB 2.0 high-speed/full-speed device/host/OTG controller with dedicated DMA, on-chip full-speed PHY and ULPI
10/100 Ethernet MAC with dedicated DMA: supports IEEE 1588v2 hardware, MII/RMII
8- to 14-bit parallel camera interface up to 54 Mbytes/s
Cryptographic acceleration: hardware acceleration for AES 128, 192, 256, Triple DES, HASH (MD5, SHA-1), and HMAC
True random number generator
CRC calculation unit
96-bit unique ID
RTC: subsecond accuracy, hardware calendar


Lists like the above, for the practical-sized chip package on a small board, list more peripherals than can be simultaneously used. But the inventory and flexibility is key.

Frank B
11-12-2014, 09:55 PM
Thats not so much more than some kinetis devices.
Take a look at K64 for example (i like the SDHC interface).
K64 is available with QFP too.

stevech
11-12-2014, 11:07 PM
K64.. I have looked at it - but I assume from prior posts that this sophistication isn't on the teensy product map.

I need the 64KB or more RAM, fast 8+ channel 12 bit ADCs at 32Ksps, 2+ SPI interfaces, some way to do serial protocol LEDs without CPU hogging. And with a proper modest packet radio such as the RFM69 and RadioHead, over the air reprogramming with/without an SPI flash chip memory is a must have.

This is a well funded commercial project - but quantities are only about 300 in the next 6-12 months, more in ramp-up.

Nantonos
11-12-2014, 11:37 PM
Thats not so much more than some kinetis devices.
Take a look at K64 for example (i like the SDHC interface).
K64 is available with QFP too.

Yes, K64 is available in any size from 100 to 144 pins. Thus, as we know that Teensy++ 3.x will be a 48-dip with the 28 pins closest to the USB same as Teensy 3.1, clearly it is not using a 100-pin chip when Teensy 3.1 uses a 64LQFP.

This is why I thought a K22_120 was the only reasonable choice here (from the models on Freescale's site. Unless Paul is waiting for some new chip to exit from the murk of NDA land)

Nantonos
11-12-2014, 11:40 PM
Summarising what we know from what Paul has said in this thread (in green) and what seems likely to me based on the spec sheets for the likely chips and the functions exposed on their 64-pin (++) and 48-pin (--) versions (in amber).
2933

stevech
11-13-2014, 12:07 AM
I didn't see in the data sheet if the package 64 LQFP has two SPI ports to map for simultaneous use. Anyone know?

Nantonos... thanks much for the great table.

Nantonos
11-13-2014, 01:17 AM
I had checked and it does, which is why I put two SPI in the table for the ++. I believe Paul also confirmed that there will be dual SPI (complete sets of SPI, not "one and a half" SPI like on the chip used on Teensy 3.1).

I found it hard to keep track of info scattered over the thread so jotted down a table. And having done so, might as well share it. Note that the chip choices are unconfirmed, so if either product uses a different chip the speculative items may be way off.

stevech
11-13-2014, 03:38 AM
Great... so you might edit the table to say that the peripherals listed are for the 64 pin version of the K22.
The data sheets these days say "up to xxx" for everything and the prospective buyer has to pore over way too much detail to find out the "does have" instead of "up to".

MichaelMeissner
11-13-2014, 07:15 AM
Great... so you might edit the table to say that the peripherals listed are for the 64 pin version of the K22.
The data sheets these days say "up to xxx" for everything and the prospective buyer has to pore over way too much detail to find out the "does have" instead of "up to".
When Paul first began hinting about Teensy 3.1++, he said that the chip had not been announced yet, and he couldn't be too specific without breaking the terms of the NDA. I don't know if the chip that he intended to use has been announced since then (in which case we can intuit features from the datasheet), or if it still hasn't been announced (in which case, we are still guessing).

christoph
11-13-2014, 09:49 AM
I'd say it's the K22FN512VLH12 (http://cache.freescale.com/files/microcontrollers/doc/data_sheet/K22P121M120SF7.pdf), which is in "rapid growth" life cycle state according to the part details page (http://www.freescale.com/webapp/search.partparamdetail.framework?PART_NUMBER=MK22F N512VLH12). Or was this part ruled out before for some reasons?

WMXZ
11-13-2014, 10:16 AM
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.

christoph
11-13-2014, 10:22 AM
You might try ordering an up to date mini54 and try to hook it up. Maybe it can already program the new chip...

MichaelMeissner
11-13-2014, 12:38 PM
I'd say it's the K22FN512VLH12 (http://cache.freescale.com/files/microcontrollers/doc/data_sheet/K22P121M120SF7.pdf), which is in "rapid growth" life cycle state according to the part details page (http://www.freescale.com/webapp/search.partparamdetail.framework?PART_NUMBER=MK22F N512VLH12). Or was this part ruled out before for some reasons?
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.

christoph
11-13-2014, 01:11 PM
The part has 3 UARTs and an LPUART (low-power UART), which adds up to four. The signal multiplexing table also shows that all can be used with the 64-pin LQFP, including SPI0 and SPI1.

One example pin map I've found in http://cache.freescale.com/files/microcontrollers/doc/data_sheet/K22P121M120SF7.pdf :
UART0 on pins 23, 24
UART1 on pins 1, 2
UART2 on pins 59, 60
LPUART on pins 46, 49
SPI0 on pins 50, 51, 52
SPI1 on pins 62, 63, 64

Nantonos
11-13-2014, 07:22 PM
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.
Yes and no:

(fails to find 3 UART devices, then realizes that UART and low-power UART are counted separately)
It has 3 UARTs and 1 low-power UART, totalling 4. That is why my speculation table lists 4 Serial.

MichaelMeissner
11-13-2014, 07:56 PM
Ok, I guess I missed the low-power UART.

christoph
11-13-2014, 07:58 PM
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!

PaulStoffregen
11-13-2014, 08:35 PM
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'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?

MichaelMeissner
11-13-2014, 08:55 PM
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?
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).

PaulStoffregen
11-13-2014, 09:02 PM
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.

christoph
11-13-2014, 09:11 PM
Do you think we really deserve 1 GHz? The extra potential would soon be eaten up by inefficient libraries and sloppy code.

Nantonos
11-13-2014, 09:14 PM
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?

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!

Frank B
11-13-2014, 09:14 PM
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.

PaulStoffregen
11-13-2014, 09:20 PM
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.

christoph
11-13-2014, 09:30 PM
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.

Nantonos
11-13-2014, 09:37 PM
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.

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.

Nantonos
11-13-2014, 09:46 PM
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.

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.

MichaelMeissner
11-13-2014, 10:03 PM
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

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

christoph
11-13-2014, 11:36 PM
packages range from LQFP100 to TFBGA216 (!!) which I have a hard time visualizing on a Teensy-style DIP form factor board.

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
11-14-2014, 10:11 AM
Yes, we "deserve" more speed. :)


Obviously power consumption will increase also.

Constantin
11-14-2014, 04:41 PM
Obviously power consumption will increase also.

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.

eduardo
11-14-2014, 05:16 PM
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.

stevech
11-15-2014, 03:09 AM
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++

christoph
11-15-2014, 10:36 AM
Steve, would you mind having a look at your private messages?

jakorten
11-27-2014, 06:09 AM
@eduardo: Tag-Connect is a great concept, I use it for my custom BLE modules to flash the firmware.

LenSamuelson
11-30-2014, 06:17 PM
"Replying" to KurtE to add a voice to his request for a true reset pin, preserving the PROG as a pushbutton. in increasing order of frequency of use:


Used the PROG signal exactly once in >1 year;
Used the PROG pushbutton every few weeks;
If it were available, would use the RESET signal from external control system regularly.


If a new device were to support D/A, two channels would be great, and it would be great if D/A pins were on the edges of the device to simplify use of a protoboard.

626Pilot
01-28-2015, 08:29 AM
You know what would be great? A lot of people choose which Arduino board to buy based on whether it runs at 3.3 or 5 volts, because of their peripherals. Those of us who use Teensy boards have the same problem! Being able to talk to 5V peripherals without having to use an external voltage translator, or OctoWS2811 boards, would give the Teensy access to tons of 5V peripherals without the irritation of having to use an external level translator. There's a way it could be done that would be pretty cheap, and very low-footprint!

Bidirectional voltage translators are inexpensive (I have a preassembled SparkFun board with four of them that cost something like $4) and tiny (maybe 1-2mm across). Add 2-4 of them to the new Teensy, using some combination of cuttable traces and bridgeable solder pads. By default, the pins they're for would still run at 3.3 (to keep stock compatibility) - but if you cut traces and/or jump the right pads, the level translators get looped into the circuit. Now, you can talk to 5V peripherals natively!

The OctoWS2811 boards are pretty great, but they're also too big for lots of applications (including mine), and have eight data lines; I think most people would need between zero and five 5V I/O pins, at most.

Another idea would be to sell a breakout board that exposes all the pins, has selectable 5V capability (at least on some of them), a 32KHz crystal, clip for a button cell battery, and provisions to solder a 32KHz crystal, DS1307 (not DS1302) and a button cell battery clip. The DS1302 is popular, but the '07 is FAR more accurate. Maybe don't solder those things in place - many people who need 5V peripherals don't care what time it is. These components would sit in the middle of the breakout board, taking up space not used by anything else, so it wouldn't "cost" anything to put them there.

Whether on the Teensy or a breakout board, micro-SD card support would be super great!

Whatever you do, try to keep it well under $30, which is the cost of an older A-model Raspberry Pi with exponentially better features. Yes, the Teensy's footprint is much smaller, but the features are important too. Teensy doesn't give an advantage over Arduino's form factor, as you can get Arduino boards in the same size as a Teensy. What brings us here is the features, which make regular Arduinos look like they're standing still for the last five years. (Which, let's be honest, they have been.) The closer the cost is to a Raspberry Pi, the less attractive it looks, except to people with tight space/power constraints. For people doing projects that aren't tiny and don't have to run on a battery, the Teensy isn't a good deal if it costs as much as an older Raspberry Pi.

MuShoo
01-28-2015, 11:23 AM
Sorry, but there are things Teensy is far, far better suited to than a Pi. Just because it's similarly priced and technologically more powerful, doesn't mean it's the best tool for the job. I've been struggling to come up with a project that would make sense to do with a Pi, but I have tons of idea for Teensy-based devices. Most of the time, if I'm making something in hardware, I want that hardware to be doing exactly and only what I tell it to - none of this overhead from Linux, no need for an HDMI port, or (from what I hear) the odd timing issues that can crop up with a Pi.

Teensy/arduino is far simpler in terms of telling it 'do this, and only this.' Even if it's a complex program (mine are pretty hefty), it's... closer to the metal.

bperrybap
01-28-2015, 03:57 PM
626pilot,
The teensy 3.1 is 3v but 5v tolerant so it already works with most 5V peripheral chips.
So I'm not understanding what you are wanting there.
I prefer it the way it is without additional level shifters to save cost, size, and power.

The comparison to Pi makes little sense.
"Better" is in the eye of the beholder.
There are things that each board and environment can do that the other will never be able to do.
The boards are very different and used for very different purposes.

626Pilot
01-29-2015, 02:59 AM
Sorry, but there are things Teensy is far, far better suited to than a Pi.
You don't have to be sorry. I agree with you. The Teensy's advantage over the Pi is that it costs less, is smaller, has easy Arduino IDE support, and requires a little less power. The Pi's advantage is that it's exponentially more capable (far out of scale with the price difference) in terms of speed, RAM, I/O, and choice of operating systems and compilers. I would be using it, but it's awfully bulky for the enclosures I want to use, and even the $10 price difference between a 3.1 and an A-model RPi matters. If I was on the Pi instead, I wouldn't have to use the Arduino IDE. I could use straight C, C++, C#, PHP, Java, Bash scripts, Python, etc. I have coded for both platforms (wrote the native WS2812 driver so people wouldn't have to use Arduinos anymore) and I appreciate what both of them bring to the game.

I would never try to say that the Pi is "better" than the Teensy in all cases. Of course it isn't. BUT, it is competitive for a LOT of use cases where you need a relatively fast, low-power CPU. Being able to code in C# alone, rather than Arduino's weird hobbled "C++" that has non-standard behavior and doesn't support lambda functions, was what drew me to it first.


The teensy 3.1 is 3v but 5v tolerant so it already works with most 5V peripheral chips. So I'm not understanding what you are wanting there.
What if you have to WRITE to a 5V peripheral that doesn't know what to do with 3.3V signals (like a WS2811/12 LED)? A few of them can run at 5V line and 3.3V signal, but the vast majority will have bad flickering and may not work at all. The line and signal voltages have to be within a certain tolerance, so you have to either run both at 5V, or both at 3.3V and give up a significant amount of brightness.


I prefer it the way it is without additional level shifters to save cost, size, and power.
I'm sure a lot of people would prefer their own custom Teensy with exactly everything they want, and exactly nothing they don't. That's fine. I'm just putting my ideas out there for the guy who actually makes the decision to consider them. Adding a few microscopic level translators to gain compatibility with hundreds of 5V peripherals isn't such a bad deal, is it? Even if it is, I proposed a breakout board that could be sandwiched with the Teensy and do the same thing, but without the bulk of the OctoWS2811 board with its Ethernet ports and inline resistors. (Those resistors are good for the WS2811/12 LEDs, but some other applications would be better off without them.)

MichaelMeissner
01-29-2015, 06:18 AM
What if you have to WRITE to a 5V peripheral that doesn't know what to do with 3.3V signals (like a WS2811/12 LED)? A few of them can run at 5V line and 3.3V signal, but the vast majority will have bad flickering and may not work at all. The line and signal voltages have to be within a certain tolerance, so you have to either run both at 5V, or both at 3.3V and give up a significant amount of brightness.


In this case you use a MOSFET, that sits between your 3.3v device and your 5v device. You would need to make sure the MOSFET can handle the input voltage trigger, the output voltage and the amount of watts that you need to control the device. At higher watts you may need a relay instead of a MOSFET. If you need the remote device to be electrically separated, you would want an opto-coupler that attaches to a MOSFET.

You can get voltage level converters that are setup for Arduino/Teensy like devices that have the MOSFETs inside. There are many such on the market. Most are setup for controlling i2c devices, but are not fast enough for neopixels. In order to control neopixels, I've looked at: https://www.pololu.com/product/2595 and http://dsscircuits.com/sale/product/dssc0105. For one way translation that is fast you can use: https://www.adafruit.com/products/735.



I'm sure a lot of people would prefer their own custom Teensy with exactly everything they want, and exactly nothing they don't. That's fine. I'm just putting my ideas out there for the guy who actually makes the decision to consider them. Adding a few microscopic level translators to gain compatibility with hundreds of 5V peripherals isn't such a bad deal, is it? Even if it is, I proposed a breakout board that could be sandwiched with the Teensy and do the same thing, but without the bulk of the OctoWS2811 board with its Ethernet ports and inline resistors. (Those resistors are good for the WS2811/12 LEDs, but some other applications would be better off without them.)
In terms of the Teensy-LC, it would presumably add to the cost of the chip.

WMXZ
01-29-2015, 10:44 AM
Adding a few microscopic level translators to gain compatibility with hundreds of 5V peripherals isn't such a bad deal, is it?
As I understand it, the future in in 1.8V systems (smaller footprint, higher speed and lower consumption).

I, personally, avoid 5V peripheral devices, also, because they require higher supply voltage in order to get good low-noise 5V levels.(I consider 5V USB as not low-noise, even I have no prove). OK, sometimes I have to use 5V devices, e.g. Cirrus ADC/Codec.

Also, how many two-cell lithium (ion/poly) loader are around that charge 7.4 V batteries? most of the one I have seen are for single cells, or special products. I have seen a shop with multiple 7.4V power packs for RC models, but could not find a loader for a reasonable price.

Future may be different, but the tendency to smaller, lower-power and cheaper will IMO not result in more 5V devices.

PaulStoffregen
01-29-2015, 12:28 PM
Bidirectional voltage translators are inexpensive (I have a preassembled SparkFun board with four of them that cost something like $4) and tiny (maybe 1-2mm across). Add 2-4 of them to the new Teensy, using some combination of cuttable traces and bridgeable solder pads. By default, the pins they're for would still run at 3.3 (to keep stock compatibility) - but if you cut traces and/or jump the right pads, the level translators get looped into the circuit. Now, you can talk to 5V peripherals natively!


I'm not a fan of bidirectional level translation.

I believe an overly optimistic attitude is prevalent in the Maker and hobbyist electronics community, regarding the capability and usefulness of such circuits.

For example, this Adafruit product (https://www.adafruit.com/products/757) is described as:



While we designed it for use with I2C, this works great for SPI, TTL Serial, and any other digital interface both uni-directional and bidirectional.


The problem is it does NOT work great for SPI. In fact, it's absolutely terrible for SPI. Likewise for serial at baud rates above 9600.

Adafruit's page does admit "10K's do make the interface a little more sluggish than using a TXB0108 or 74LVC245". That's quite an understatement. It's very slow, and the slowness is difficult to predict, since it depends on the capacitance of whatever you're connecting, plus stray capacitance of wiring, which is often significant in DIY projects.

The slowness isn't uniform. Falling edges propagate quickly and predictably, but rising edges are slow and can vary quite a lot. The result can be very significant waveform distortion. That's really horrible for PWM signals. Protocols like WS2812/Neopixel, which depend on pulse shapes, can be badly corrupted. Even clocked digital protocols, like 74HC595 shift register control, can be ruined if the clock connects to many chips using long wires (much slower rise times) but the data connects to a single pin with a short wire.

A particularly painful aspect of the slowness is that corruption of waveforms can go unnoticed, where signals that should have plenty of timing margin are just barely working. Unreproducible, infrequent and unpredictable problems can be the most painful of all.

But slow performance is only part of the trouble....

Numerous forum threads have shown novices do not understand the weak high level output. Plenty of people have purchased these, intending to drive blue LEDs, or long wires, or the gates of mosfet transistors, or even small relays & motors! The result for pretty much anything other than open collector protocols like I2C is often somewhere between poor performance and simply not working at all.

A lesser issue is the gate to source capacitance. It's another hidden "gotcha" in this circuit.

However, for hobbyists who aren't electrical engineers, language like "works great for ... any other digital interface" prompts them to adopt these products as a general purpose mixed-voltage interfacing strategy. The thinking often goes that it'll be a handy item to have laying around, whenever 2 digital things with different voltages need to talk to each other.

In reality, it's really only a good idea for a very limited class of signals, with I2C being the only very common case.


The more expensive TXB0108 and similar chips solve much of the slowness issue by implementing a one-shot timer that turns on a strong pullup or pulldown transistor briefly when the direction is detected as changing. But it's important to realize the output is still a very weak drive after the one-shot timer. It's poor at driving loads. It's also susceptible to noise falsely triggering a change of direction, which is a problem not present with the simple transistor circuit. Unintended direction changes can be really tough to diagnose, especially if connecting a scope or multimeter changes the nature of the noise problem!


So I don't like the idea of promoting bidirectional logic level conversion as a general purpose solution. Certainly the simple transistor circuit and fancy TXB0108 have their uses, but promoting them to makers and hobbyists as general purpose digital interfacing solutions is not something you'll see PJRC doing.

I know Adafruit, Sparkfun and everyone else does. I really wish they'd give their customers more realistic expectations.

onehorse
01-29-2015, 05:55 PM
I have been bit with the traditional (Sparkfun) bidirectional logic level translators since in my case the 10K on resistance was larger than the input impedence of my circuit and the voltage dropped below the necessary operating voltage. I found this (https://www.tindie.com/products/onehorse/lsf0108-logic-level-translator/) Texas Instruments LSF0108 device and made a breakout board since it has a very low on resistance and claims to handle 100 MHz signals with minimal degradation. I haven't tried it with SPI yet but according to the data sheet it ought to work well, certainly much better than the traditional MOSFET + resistor network solution.

This is great Paul, you have given me a whole list of things to test for with this device. I was just going to try out I2C and PWM and call it good but now I see that I can push the LSF0108 to its limits (if it has any) and report more honestly what its capabilities are. Thanks from one of the


hobbyists who aren't electrical engineers.

But even I know translators are for digital (logic) signals not load carrying signals.

Constantin
01-29-2015, 06:05 PM
I have successfully used the TXB series for serial signal voltage translation on my GPRS board and SPI for SD cards. The latter was likely pretty slow on account of a 1284P doing the driving. I think it was Nick Gammon that showed how the BSS138 bi-directional shifter approach only works pretty well if you use it with 2.2k resistors or lower if the signal is 'fast'. Otherwise, the digital signals look more like shark fins than a square wave. I can't find a link right now, however.

I avoid the use of voltage translators wherever I can. The world of embedded MCUs like the Teensy and assorted sensors, ADCs, etc. is presently centered around 3.3V. Thus, I would not look backwards to 5V devices and instead find alternatives that happily work at 3.3V.

Soon enough, the Intels of the world will try to convince us to go 1.8V! I expect sensors to follow the lead of MCU manufacturers and eventually produce native versions at 1.8V also. However, for now, the world of 3.3V sensors is pretty plentiful, it's also what SD cards use, USB, etc.

onehorse
01-29-2015, 06:11 PM
the world of 3.3V sensors is pretty plentiful

This is true but I have noticed many of the sensors have pushed their operating limits to 1.71 V digital and, in some cases, their analog sections can operate at 1.8 V too. Many GPS modules already require 1.8 V or internal voltage regulators that will allow 3V3 in. Writing is on the wall, 5 V is so last century!

626Pilot
01-30-2015, 04:53 AM
For one way translation that is fast you can use: https://www.adafruit.com/products/735.
There's a lot of stuff like this, but what I've seen so far has been "too much." I wish there was a small, single-channel, ready-to-use device I could use to translate 3.3 to 5. There doesn't seem to be, so I think I'll use a diode to drop the NeoPixel drive voltage to slightly less than 4.7 volts. (Signal has to be at least 0.7 times drive, so if signal is 3.3 and drive is ~4.5, it should work reliably.)

mxxx
01-30-2015, 08:59 AM
i'm not quite following your 5V argument either. i think the few times i actually had to resort to voltage translators (TXS0102) was to shift down to 1.8V

at any rate, as others have said, the obviously nice thing about something teensy is that it makes it easy to integrate an ARM mcu with circuits that do what you want, with the peripheral devices you need...? as far as i am concerned, i don't need voltage translators in every project, nor SD cards, nor LED drivers, nor this or that sensor, nor X.

PaulStoffregen
01-30-2015, 09:07 AM
I wish there was a small, single-channel, ready-to-use device I could use to translate 3.3 to 5.

The upcoming Teensy-LC board includes a SN74LV1T125 chip to drive WS2812 / NeoPixel LEDs.

As for the actual chip, it is small and single-channel. On Teensy-LC it'll certainly be "ready-to-use". If you buy just the chip from Digikey, it's a tiny surface mount part, which might or might not be "read-to-use" depending on how you prefer to prototype your project.

Constantin
01-30-2015, 11:59 AM
That is a very nifty single-package solution to the voltage translation problem. Here is the data sheet (http://www.ti.com/lit/ds/symlink/sn74lv1t125.pdf) for those that want to take a closer look.

Some time in the future, I would like to base a clock on a teensy 3.1 or the LC using APA102 LED (http://dangerousprototypes.com/2014/09/22/apa102-aka-superled/)s.

duff
01-30-2015, 06:55 PM
Here is the data sheet (http://www.ti.com/lit/ds/symlink/sn74lv1t125.pdf) for those that want to take a closer look.


I wonder if paul tied the OE pin to ground or we have control of it, and also won't this be sucking up power all the time? I didn't see any nominal current consumption data.

626Pilot
01-31-2015, 01:28 AM
i'm not quite following your 5V argument either. i think the few times i actually had to resort to voltage translators (TXS0102) was to shift down to 1.8V
This is a 5V character LCD. (http://www.amazon.com/RioRand-trade-Module-Arduino-White/dp/B00GZ6GK7A/ref=sr_1_1?ie=UTF8&qid=1422667495&sr=8-1&keywords=arduino+display&pebp=1422667496691&peasin=B00GZ6GK7A&pebp=1422667496697&peasin=B00GZ6GK7A) I doubt it would be able to differentiate useful data out of a 3.3V signal. The same problem exists with NeoPixels, as I stated above. Perhaps 20% or so of them can handle 5V power and 3.3V data. The rest will handle it only intermittently, with unsightly flashing and data corruption. It's not pretty.


The upcoming Teensy-LC board includes a SN74LV1T125 chip to drive WS2812 / NeoPixel LEDs.
I think I'd probably run out of RAM on that :( Still, it is a nice board. I think I'll just reduce the drive voltage to the LEDs instead.

Jensen567
02-01-2015, 07:24 AM
New member, but I just wanted to say I am on board for waiting a bit longer on a Teensy++ 3.x in order to get Cortex-M7 support. I have been waiting for an M7 development board to be released since the announcement of the M7, and a Teensy would be even better.

stevech
02-01-2015, 10:09 PM
I've read some people say, and I tend to agree, that the M7 with 1 or 2MB of flash, and 200KB or so of RAM, the M7 may be in a bad place. Overkill for M0+ and M4 upward migration, too crude for people accustomed to x86 operating system environments.

But we shan't be the next one to say: No one will need more than 64KB of memory, paraphrasing you-know-who.

Frank B
02-02-2015, 10:37 AM
I would imagine that the M7 whith enough ram could be great for real-time audio, maybe video and other kinds of realtime signalprocessing - and certainly things that we currently do not even think..

MuShoo
02-02-2015, 10:47 AM
Stevech, if it's fast enough 200KB of RAM and that much flash storage would probably make for a very, very nice, relatively large screen driver. Full 640x480 touch display with Alpha, mmm.

instrumentek
02-02-2015, 07:09 PM
Hey Paul;
Are you going to put the 3.0++ up on the kickstarter site?

Robin
02-02-2015, 07:13 PM
Hey Paul;
Are you going to put the 3.0++ up on the kickstarter site?

No. Future product releases will most likely be handled like what we are doing with the Teensy-LC

stevech
02-02-2015, 11:21 PM
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.

626Pilot
02-03-2015, 01:07 AM
But is a newer/better ARM chip with more flash, more RAM, more SPI ports, and optional use of Single Wire Debug.
I always miss having a proper debugger on these embedded environments, something that lets me watch the registers and changes in memory locations.

MuShoo
02-03-2015, 06:53 AM
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
02-03-2015, 08:46 AM
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.

Nantonos
02-03-2015, 11:29 AM
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.

Nantonos
02-03-2015, 11:32 AM
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.

Nantonos
02-03-2015, 11:35 AM
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.

instrumentek
04-13-2015, 02:53 PM
Running 95% usage on flash memory of 2.0++, Any updates on the 3.x++?

Nantonos
04-14-2015, 09:32 AM
Running 95% usage on flash memory of 2.0++, Any updates on the 3.x++?

In the short term, did you see the 3.1 breakout board? (https://forum.pjrc.com/threads/28345-Teensy-3-1-Breakout-updated-25-discount-for-PJRC-forum-members)

instrumentek
04-14-2015, 07:16 PM
In the short term, did you see the 3.1 breakout board? (https://forum.pjrc.com/threads/28345-Teensy-3-1-Breakout-updated-25-discount-for-PJRC-forum-members)

I did see it unfortunately i need more I/O, i use every pin on teensy 2.0++. Perhaps I should get one so i can start porting my programming over in anticipation for 3.x++. I'm assuming the programming changes from 3.1 to a 3.x++ will be significantly less then 2.0++ to 3.x++.

MichaelMeissner
04-24-2015, 08:35 PM
(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.

PaulStoffregen
04-24-2015, 09:44 PM
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....

GremlinWrangler
04-25-2015, 01:42 AM
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?

stevech
04-25-2015, 03:19 AM
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.

melstav
05-01-2015, 01:29 AM
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.

stevech
05-01-2015, 01:44 AM
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.

GremlinWrangler
05-01-2015, 02:24 AM
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'.

Frank B
05-08-2015, 09:45 PM
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:


ARM Cortex-M4F (Floating Point Unit)
Under $30
More I/O pins
More serial & SPI ports
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/26305-Highly-optimized-ILI9341-%28320x240-TFT-color-display%29-library?p=72490&viewfull=1#post72490

mike95826
05-18-2015, 07:06 PM
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

stevech
05-18-2015, 09:08 PM
Access to use SW debug pins - when bootloader is finished.

Paraglider
05-27-2015, 10:38 AM
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:


ARM Cortex-M4F (Floating Point Unit)
Under $30
More I/O pins
More serial & SPI ports
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.

robsoles
05-27-2015, 01:25 PM
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 ;)

PaulStoffregen
05-27-2015, 05:00 PM
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.

ipaq3115
05-27-2015, 07:24 PM
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

DaQue
05-27-2015, 07:49 PM
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.

Constantin
05-27-2015, 08:10 PM
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.

ipaq3115
05-27-2015, 08:29 PM
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.

That's been done in the form of an expansion board. Not as compact as a dedicated board, but a pretty good solution. https://www.tindie.com/products/loglow/teensy-31-breakout/?pt=full_prod_search

Cosford
05-27-2015, 09:23 PM
I agree, T3.1++ will be beneficial to more people than both debug capability and sorting pin 33, not to mention, likely pulling more people into the PJRC and Teensy ecosystem.
Then again, we aren't PJRC's board of directors ;D

DaQue
05-27-2015, 09:23 PM
Yes that's what I should have said instead of using the term header board. I will end up buying a couple of them I'm sure. A 3.1 long version would still be my preference. It would be smaller/narrower and hopefully cheaper than the 2 pcb solution with extra headers between them. I do get that being tiny is important but not at the expense of making some pins hard to use in practice. If small is the top priority then double rows of pins would be better (IMHO) than pins out the bottom and in the middle somewhere. Maybe stick microsd card holder pads in the extra space where you could use solder ball jumpers to connect to the proper pins if you soldered one on.

duff
05-27-2015, 10:17 PM
I'm on the other side of the fence and think that debug would be better before any new teensy. Since all the hoopla with the Zero and its debug features that looks like it might be a bust I think it would make PJRC a leader in the maker movement and drive them more business if there is a decent debug capabilities especially with existing products. Remember the teensy 3.1++ would be like 30 bucks so new to electronics users would probably just buy an LC anyway but having such a cool feature for the 3.1 and LC that could compete with the Zero would be a splash with the Arduino community I think.

Constantin
05-27-2015, 10:39 PM
Wouldn't adding debug would likely require a redesign of the 3.1? After all, how to get to those pins / SWD traces unless components get moved around? Then, where to find the space for a connector? It's not as if the Teensy is teeming with PCB space lying fallow.

Seems to me that the transition to the new boot loader chip for the 3.1 may present the best opportunity to consider a change (i.e. potential addition of a debug connection) since the PCB will have to be redesigned anyway. I've argued before that the tag-connect system seems like a pretty good potential choice since its smallest version only takes up the room of about an 0805 component and adds almost zero cost to Pauls board.

I'll also argue again that a 3++ rollout with the new debug may be the best opportunity to allow the debugger to be beta-tested in a high-end board that has more room to accommodate it before transitioning the debugger to legacy designs.

PaulStoffregen
05-27-2015, 10:45 PM
Then again, we aren't PJRC's board of directors ;D

Those "board meetings" are usually at a local restaurant/bar's Happy Hour. ;)

But I do take these conversations into consideration. Ultimately, I do try to make choices that will give the most people the most benefit, using the limited time & resources I have.

My general feeling is debug first would help more people. If I do a high-end PCB first, the design will need to be revisited soon when I do debug stuff. As things are now, I only have the Teensy 3.1 & LC boards to consider.

I'm also still holding out a small hope Freescale will make an awesome Cortex-M7 chip, rather than the limited motor-oriented one they've announced so far. If they do, I'd really want to use that. But if they haven't soon, then it's looking like the K22F will be the best choice. Doing debug first will (maybe) give more time for a Cortex-M7 option.

PaulStoffregen
05-27-2015, 10:46 PM
I've argued before that the tag-connect system seems like a pretty good potential choice

Does it require a patent license & royalty payment?

Frank B
05-27-2015, 10:54 PM
Paul, regarding the M7 (KV5?), what limitations have these chips ?
From the "fact sheet" they're looking good, at first glance.

PaulStoffregen
05-27-2015, 10:59 PM
Well, the Freescale KV5 chips are missing important peripherals... like USB!!!

Frank B
05-27-2015, 11:01 PM
oops.......

robsoles
05-27-2015, 11:47 PM
lol (re.. USB!)

I should probably have mentioned in my previous post that I wouldn't like my suggestion about a Teensy+ 3.1 to get in the way of any work currently being done on a ++

If fixing the pin 33 boot issue isn't akin to blinking I think it can be back-burnered due reasonably well documented nowadays.

Constantin
05-28-2015, 12:56 AM
Does it require a patent license & royalty payment?

As best as I can tell, no, see this page (http://www.tag-connect.com/what-do-you-gain). "The marginal cost of using Tag-Connect - the extra cost per board you incur by incorporating the Tag-Connect footprint - is zero." They also allow free downloads for all connector pads, for CAD packages including altium, cadence, eagle, KiCad, etc. see this page. (http://www.tag-connect.com/tag-connect-downloads) However, to be sure re: the royalty payment issue, I'd contact them and confirm (http://www.tag-connect.com/contact).

What I like about their selection of connectors is that they support multiple debugger / flash programmers right out of the box. Very nifty. When I called them once for pre-sales support (I ended up buying one), I got a knowledgeable engineer in like 20 seconds. Thus, even though I have yet to use their product (have to learn first!) I'm already impressed with their performance re: tech support.

GremlinWrangler
05-28-2015, 09:51 AM
As noted before, it isn't a democracy but I'm +1 for a debugger if it follows the PJRC track record of 'just working'.

PaulStoffregen
05-28-2015, 03:02 PM
I'm pretty sure there will be many beta test copies where it falls short of "just working"!

Frank B
05-28-2015, 09:13 PM
I'd like debugging too, but more memory is more important for me...

Constantin
05-29-2015, 12:33 AM
Does it require a patent license & royalty payment?

OK, I followed up with Tag-Connect and spoke to Neil in Tech support on the phone. He seemed somewhat amused by the question, but confirmed that
1) There are no patent licenses to sign
2) There are no royalty payments
(he thought the web site was clear enough)

Naturally, you may consider an oral statement over the phone to not carry the same weight as a written statement from the company. In that case, you should contact them directly for confirmation.

PaulStoffregen
05-29-2015, 02:23 PM
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. ;)

Cosford
05-29-2015, 02:33 PM
0.o

2 DACs too?

Awesome.

instrumentek
05-29-2015, 02:36 PM
My vote is for the 3.x++

instrumentek
05-29-2015, 02:48 PM
Looks like the K26 is not going to be 5V tolerant, but still looks very nice.

Constantin
05-29-2015, 03:37 PM
I'm feeling pretty excited about it. ;)

Totally agree, an awesome chip. My only concern based on a recent thread here is the built-in encryption. I wonder if it's allowed for export without hoops to jump through...

ipaq3115
05-29-2015, 03:46 PM
Unless I'm mistaken, that could hold two full frames of a 220x220 screen in RAM and still have almost as much space left as the Teensy 3.1 has to begin with :D

4389

Frank B
05-29-2015, 04:56 PM
SDHC Controller !


A Datasheet:
http://cache.freescale.com/files/32bit/doc/data_sheet/K26P169M180SF5.pdf

linuxgeek
05-29-2015, 05:21 PM
SDHC Controller !


A Datasheet:
http://cache.freescale.com/files/32bit/doc/data_sheet/K26P169M180SF5.pdf

Oh Yeah! That'll be nice.

PaulStoffregen
05-29-2015, 07:15 PM
Yeah, I noticed the lack of 5V tolerance just after posting. Not sure how I feel about that yet. Looks like we can't have everything.

Robin's looking into the export stuff. This one probably will require us to do the export control stuff.

Fyod
05-30-2015, 07:45 AM
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.

bperrybap
05-30-2015, 07:50 AM
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

Fyod
05-30-2015, 08:03 AM
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.

robsoles
05-30-2015, 02:06 PM
@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 :)

Pensive
05-30-2015, 11:10 PM
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 ;)

PaulStoffregen
05-31-2015, 11:41 PM
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.

PaulStoffregen
05-31-2015, 11:50 PM
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!

robsoles
06-01-2015, 01:06 AM
...

It's too bad it doesn't somehow manage to include more hours in every day... to write software support for such things!More hours in a days equ more time for people to find reasons to post equ more posts to sift through equ no real gain :p

PaulStoffregen
06-01-2015, 02:04 AM
More hours in a days equ more time for people to find reasons to post equ more posts to sift through equ no real gain :p

I want to do All The Things. ALL of them!!!!

stevech
06-01-2015, 04:34 AM
Hire a near-clone! Even part time!

robsoles
06-01-2015, 04:59 AM
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 :)

Donziboy2
06-02-2015, 01:04 AM
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......

robsoles
06-02-2015, 01:18 AM
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...

stevethese
06-23-2015, 02:10 AM
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.

stevech
06-23-2015, 02:37 AM
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.

stevethese
06-23-2015, 10:47 AM
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?

stevech
06-23-2015, 05:24 PM
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.

Constantin
06-23-2015, 06:01 PM
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.

stevech
06-23-2015, 10:08 PM
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.

amundsen
07-09-2015, 09:09 AM
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.

Constantin
07-09-2015, 01:05 PM
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.

PaulStoffregen
07-09-2015, 01:54 PM
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.

stevech
07-09-2015, 08:37 PM
Wish:
Small board to stay Teensy
Expansion connector, not via header pins.

PaulStoffregen
07-09-2015, 10:28 PM
Expansion connector, not via header pins.

Intel Edison style?

Frank B
07-09-2015, 10:41 PM
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.

onehorse
07-09-2015, 10:46 PM
Please keep the Teensy appallingly small...

stevech
07-10-2015, 04:10 AM
Intel Edison style?
Something like double-sided flex at 0.5mm or less pitch.
Like the Raspberry Pi has for its camera, but more conductors or double sided flex for same size but 2x signals.

http://www.molex.com/molex/products/family?key=premoflex&channel=products&chanName=family&pageTitle=Introduction&parentKey=copper_flex_products

Can be cheap
http://www.adafruit.com/products/2087 (but these have large pitch/low density)

defragster
07-10-2015, 05:12 AM
Smaller - the 40 pin sized. Edison (70-pin?) connector or similar style:
4654

That was 40 pins with a 32 pin connector - and not shown the 144 pin K26 - you suggested the 13x13mm BGA might be the one
4655

PaulStoffregen
07-13-2015, 01:40 AM
Of those 4, the 13x13 is the only size that works with standard PCB processes.

MuShoo
07-13-2015, 02:06 AM
The 144 (.5mm pitch) wouldn't work? I mean, i'm assuming it wouldn't work due to the sheer size of it, but .5mm pin pitch isn't bad at all. The current 3.1 chips are .5mm pin pitch.

Edit: the .65mm/.4mm BGA pitch would be a nightmare to route - vias-in-pad would be the only way I could think of doing it.

potatotron
07-13-2015, 03:55 AM
The 144 (.5mm pitch) wouldn't work?

It would be tough. Just the bare chip is wider than the current T3.x, and the widest you can go while still being able to fit in a standard breadboard (about 23.5mm) only gives 2mm from end of pins to end of board

4667

using the 2nd pins from the edge on each side -- you can go wider by using the outside-most pins but that means you'd have to pull the board off every time you wanted to add/change a jumper. I suppose you could require double-wide breadboards ....

MichaelMeissner
07-13-2015, 06:21 AM
Something like double-sided flex at 0.5mm or less pitch.
Like the Raspberry Pi has for its camera, but more conductors or double sided flex for same size but 2x signals.

http://www.molex.com/molex/products/family?key=premoflex&channel=products&chanName=family&pageTitle=Introduction&parentKey=copper_flex_products

I find the Raspberry Pi camera cable comes out quite often. Sure it is fairly simple to put back in, but it isn't what I would call secure.

MuShoo
07-13-2015, 06:34 AM
I've been using these: http://www.digikey.com/product-search/en?keywords=HFZ040CT-ND in a product. They certainly aren't cheap, but they work very well and keep a very strong connection once locked. Pain in the ass to hand-solder, though.

stevech
07-13-2015, 06:35 AM
The Molex and many others have secure mechanical mating
http://www.molex.com/molex/products/..._flex_products

defragster
07-13-2015, 08:18 AM
I copied those p#227 images from thread Is-there-a-market-for-a-Teensy-3-1-48-pin-ARM-stamp (https://forum.pjrc.com/threads/28835-Is-there-a-market-for-a-Teensy-3-1-48-pin-ARM-stamp?p=75303&viewfull=1#post75303) ... that 32 pin connector is used on this device family: https://tiny-circuits.com/tiny-shield-proto-board-all-159.html - as noted they offer a $4 minimal proto board with two connectors installed (https://tiny-circuits.com/tiny-shield-proto-board-all-160.html).

Putting one of those on each side of the K26 might ease routing to the primary pins & the takeoffs - and give options for twin connects (bias one to Analog?) w/larger number of exported I/O from the 144 pins:
4675- but they may never be used and would add to cost - and any project using them would need the mate. A ribbon board to board is $15 (https://tiny-circuits.com/ribbon-cable-6inch.html).

PaulStoffregen
07-13-2015, 01:12 PM
I don't want to completely rule this out, but I'm not a fan of these high density connectors.

I know Intel Edison uses one. I know others have gone down this path, some more successfully (https://www.kickstarter.com/projects/kenburns/tinyduino-the-tiny-arduino-compatible-platform-w-s) than others have tried (https://www.kickstarter.com/projects/fairduino/smartduino-open-system-by-former-arduinos-manufact?ref=discovery).

Some of my reservation is a concern this doesn't fit PJRC's business model. Teensy has never been about making a comprehensive collection of "shields", or whatever you'd call such a plug-in peripheral board. If I were to start down this path, odds are very likely the dev time that I currently put into creating more advanced software (OctoWS2811, Audio, PulsePosition, ILI9341_t3, SD_t3, SerialFlash, Biopotential, new USB types, FreqMeasureMulti, etc) would almost certainly be consumed by making and supporting lots of hardware. Many other companies in this "maker market" do this, and indeed it seems to be far more profitable than PJRC's approach. My decision making is really not about what will make the most money or conquer more of the market, but rather how to maximize (or at least sustain and continue to fund) my ongoing efforts to develop awesome stuff.

I'm also reluctant to create yet another plug-in form factor. Teensy is probably among the more successful "unofficial" Arduino compatible boards, at least in terms of actual usage in real projects. But so far, to the best of my knowledge, Teensy's pinout & form-factor has yet to be adopted by any other board. Even Arduino Zero clones that could have benefited (https://www.kickstarter.com/projects/rabidprototypes/neutrino-the-tiny-32-bit-arduino-zero-compatible/comments) from Onehorses's many "appallingly small" peripherals haven't been swayed to align their power and signals similarly.

So to even begin to consider this, I'd really want to be interchangeable with an already-established format. (hint, hint... to anyone who wants to persuade me....)

Cost is also a concern. I've always tried very hard to keep Teensy affordable. These connectors vary considerably in cost. Some of the cheaper ones may be designed for only a very low number of "cycles".

PCB real estate is also a possible issue. There are a lot of possible ways to use the space. One space-hogging idea I have in mind involves using the right hand side for the same SD socket we currently put onto the audio board and Wiz820 adaptor, with wiring to the native SDIO pins on this K26 chip. I also really want a convenient way for people to connect to the other USB port (the 480 Mbit/sec one), which probably will end up being a location to solder a 4 or 5 pin header that mates with the common USB-to-motherboard cables made for PCs. These, plus the large 13 mm chip and other stuff required all add up to not much PCB space left over.

defragster
07-13-2015, 08:38 PM
Lots of Pros & Cons to see and weigh. A T3k26 would offer awesome compute power - new fast protocols in larger number. Though: too big with unused pins is as bad as not enough pins depending on the use case.

Teensy seems to be the DIY for DIY'ers - I wasn't suggesting a PJRC emulation of that 'Tiny' ecosystem (https://tiny-circuits.com/products.html) - just the ability to get needed pins from a smaller format - while largely preserving the T3.1 layout. No matter what the layout is it will be new and need adapted to.

If you decided to design it with a mind to make a 52 pin T_monster version for bench use and design, then lop off the end for a 40 pin T_svelte version. Of course the width limits routing options and only gains 12 pins. In which case the T_svelte 40 pin with a 32 pin connector would beat that handily, and a sample daughter card could be designed with 5v tolerance built in - a perfect 16 pin onehorse project.

Constantin
07-13-2015, 10:22 PM
Another issue is cost. I'd wager that the BGA version would likely require a 6-layer board to maintain the skinny form factor yet extract all those signals.

vitormhenrique
07-16-2015, 06:16 PM
Paul,

One thing that I would love to see on the following teensy is a mix of Castellated holes and Through holes for the pins. Making easy to install teensy permanently on other boards (without using the headers).

The Particle Photon has something that is very interesting.

4709

Vitor Henrique

Constantin
07-16-2015, 06:19 PM
I second that. I think it's a great idea and the cost should be close to zero as long as the fab house is OK with creating castellated holes.

jbliesener
07-16-2015, 06:26 PM
Are there any ZIF sockets for the castellated holes? For those who want to install the Teensy NOT PERMANENTLY and without pins...

JBeale
07-16-2015, 08:02 PM
I'd really want to be interchangeable with an already-established format.
FWIW- maybe not so established, but there are 25 or so add-on boards available for the "Jeenode" port, a simple 6-header-pin arrangement with Vin, +3.3V, GND, Analog In, DIO, and a rarely-used interrupt line. The two I/O pins are often used as bit-banged I2C.
http://jeelabs.org/2013/10/02/flashback-ports-and-i2c-in-jeelib/
http://moderndevice.com/product-category/jeelabs/

PaulStoffregen
07-16-2015, 08:33 PM
Castellated holes were discussed here:

https://forum.pjrc.com/threads/28847-Request-Castellated-Edges-on-Teensy-3-1-PCB

There are 2 issues.

#1 - Teensy is made with V-score for the horizontal edges. See the photo in reply #15 (https://forum.pjrc.com/threads/28847-Request-Castellated-Edges-on-Teensy-3-1-PCB) on that thread.

#2 - The intended path for SMT build involves buying the Mini54 chip. Castellated make a lot more sense when you're selling a RF module, where people need to avoid their own PCB design, and where the board is based on a special part which can't be purchased by ordinary people / companies.

vitormhenrique
07-16-2015, 09:06 PM
Paul, I understand that you would need to find a new process for manufacture teensy, but I don't think I'm alone wanting to embed teensy directly on a final product without the header.

I'm a chemical engineer and a electronic hobbyist, I don't have enough time and effort to put on developing my own pcb for a custom teensy, I think there are more people like me here.

But more important, Teensy is amazing, and this is just an idea, keep in mind for future versions as it would only open more doors for this amazing board. I think it would be worth a talk with your pcb manufacturer :)

Vitor Henrique

stevech
07-16-2015, 09:14 PM
Paul, I understand that you would need to find a new process for manufacture teensy, but I don't think I'm alone wanting to embed teensy directly on a final product without the header.

I'm a chemical engineer and a electronic hobbyist, I don't have enough time and effort to put on developing my own pcb for a custom teensy, I think there are more people like me here.

But more important, Teensy is amazing, and this is just an idea, keep in mind for future versions as it would only open more doors for this amazing board. I think it would be worth a talk with your pcb manufacturer :)

Vitor Henrique

+1

There are some microprocessor modules out there with Castellated edge connections.
Example
http://www.espruino.com/
http://www.espruino.com/Pico

PaulStoffregen
07-16-2015, 09:41 PM
If you look carefully at the espruino photos, you can see the 3 "mouse bite" locations, 1 in the center of the USB area, 2 on the far side.

Teensy isn't made this way. You can see the raw panels in the photo (https://forum.pjrc.com/threads/28847-Request-Castellated-Edges-on-Teensy-3-1-PCB?p=75543&viewfull=1#post75543) I posted.

Normally you never need to worry about how PCBs are actually fabricated and assembled on panels. You get the board after it's been broken out of the panel, and all secondard processing and testing and programming has been done. Likewise when you buy food at a grocery store, you have no need to concern yourself with how it was grown, harvested and processed.

stevech
07-16-2015, 09:42 PM
If you look carefully at the espruino photos, you can see the 3 "mouse bite" locations, 1 in the center of the USB area, 2 on the far side.

Teensy isn't made this way..
But, we're discussing a future Teensy! ;)

embedded-creations
07-17-2015, 05:50 PM
@PaulStoffregen I'm guessing it's a big effort to switch the Teensy 3.1 to using routed instead of V-score edges, is the effort on the manufacturer's side, or your side because of panelized testing or programming?

For the new Teensy 3.1++, it should be possible to switch, right? There's no guarantee you'd start to get quantity orders customers wanting to do a their own custom PCB, but if it's not a ton of engineering effort, it's a good way to test the waters. You might also want to survey existing MINI54 purchasers, or people who have built a product prototyped with the Teensy to get their take on the idea.

From my perspective, I thought the price of the MINI54 chip in quantity 100 was too high. By the time you add up all the costs of the components on the Teensy 3.1 at qty 100 sourcing from PJRC, Digikey, and Mouser, you're only a couple bucks away from the qty 100 price of the Teensy 3.1. (based on old quotes from PJRC, your pricing may be different and I'm not going to post it here). Some of these parts will be scrapped or fail testing during manufacturing, where the yield on the Teensy 3.1 should be higher (could be wrong), so the average BOM cost will be higher. Given the choice between purchasing a Teensy 3.1 with castellated edges and the MINI54, I'd go with the Teensy 3.1.

It's significant engineering effort (as you know) to try to fit all the components into the small space of the Teensy 3.1. I would rather use a 2-layer custom PCB, and not have to go through that effort.

I would seriously consider putting castellated edges and suitable pads for extra signals on the underside of the Teensy 3.1++, and to pick a couple potential mid-volume customers to get feedback on the idea/design. If this feature turns out to be a winner, you could think about a Teensy 3.1 rev with castellated edges.

PaulStoffregen
07-17-2015, 09:56 PM
Over the last 4 years, we've tried several different panel designs. The one you see in that photo is relatively new, and I believe it's the first one we've ever used that is actually working very well. Getting to this point has taken a lot of work, many incremental improvements. This may sound easy, but let me tell you, it's quite difficult to accomplish as a small company (or even a big one) while dealing with the constant challenge of scheduling purchasing and production, and keeping up with same-day shipping, and customer service, and sometime even developing new stuff. Quality improvements are particularly challenging, because of the long lag times from initial design, through the purchasing and production cycle, and then more lag because customers waiting for products or unanswered email and forum messages are always more urgent.

With too much tab routing and too many slots, the panel loses rigidity and vibrates during high speed pick & place assembly. Obviously others are making their boards with hardly any mechanical connection from the board to its panel. Maybe they have finely turned assembly? Maybe they're experiencing lower first pass yield and enduring more rework (which is cheaper in China). From everything I've experienced over the last 10 years, I'm pretty sure the later is more likely. Hardly anyone airs such "dirty laundry" in public!

High first pass yield and low tolerance for rework are huge goals for PJRC. Much of that is driven by PJRC's purpose, which is to facilitate developing technology. Dealing with moderate fallout and quality issues is probably a net-win for many companies, if it substantially lowers cost. But I can tell you from years of painful experience, even moderate fallout becomes huge drain on development here at PJRC. It probably is for other too... but how many of the other companies in this market do you see developing so much software relative to their total revenue?

So I'm really reluctant to try a weaker panel design. Teensy3++ will be our first board with a BGA, which makes me doubly fearful of risking a less rigid panel... right after we've *finally* achieved a really good panel design that solves the long-standing problems.

I'm also skeptical castellated will improve sales. If you're feeling the Mini54 price is too much, how can you possibly think you'll enjoy the pricing for fully assembled Teensy boards?

EK701
07-18-2015, 06:26 AM
As someone who has dabbled with developing my own Teensy 3.1 PCB for a project I'm working on, but here are my thoughts for a ++:

- If the 3.1 would have had all the pins broken out in a manner where they were easily usable, I wouldn't have even considered building my own (conversely, building my own has been considerably more difficult than I anticipated).
- For a ++ product, a 50% larger form factor is ok, as long as all the pins are broken out in a manner that makes them easy to use
- Please use a processor with built in floating point hardware - M4F or better
- A second SPI bus should be high on the priority list.
- Consider a decent size (128k or better) NVRAM built in. The Adesto CBRAM chips are pretty inexpensive and work well.
- Include the RTC crystal
- Multiple serial ports with FIFO buffer would be useful
- I could see a second DAC being useful

Hope that helps!

stevech
07-18-2015, 07:23 AM
...while dealing with the constant challenge of scheduling purchasing and production, and keeping up with same-day shipping, and customer service, and sometime even developing new stuff. Quality improvements are particularly challenging, because of the long lag times from initial design, through the purchasing and production cycle, and then more lag because customers waiting for products or unanswered email and forum messages are always more urgent.
To grow and expand, one needs to give some of the hats that one wears to others!

http://www.smartva.co.uk/stuck-in-one-man-band-rut/