Any Chance of a Teensy ++ 3.1?

[deelaleo]

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]

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]

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]

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]

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]

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]

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]

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

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

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]

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]

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.

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

 

[Constantin]

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

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]

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]

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]

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]

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]

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]

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]

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

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]

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]

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]

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]

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!!!!
Bring it on ... @ Duff are you listening?

 

[stevech]

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.