Any Chance of a Teensy ++ 3.1?

Status
Not open for further replies.
Reset as pin, D/A on edges

"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.
 
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.
 
Last edited:
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.
 
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.
 
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.)
 
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.
 
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.
 
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 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.
 
Last edited:
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 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.
 
Last edited:
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.
 
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!
 
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.)
 
Last edited:
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.
 
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.
 
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. 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.
 
Last edited:
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.
 
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.
 
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..
 
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.
 
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.
 
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.
 
Status
Not open for further replies.
Back
Top