Any Chance of a Teensy ++ 3.1?

Status
Not open for further replies.
Unless you could do overnight pcb production with quantity 1 boards in the $1 range, I don't see how custom pcb's would work during development. Sure, once you have the basic design down, then I can see the use of custom pcb's.

Well, playing devil's advocate to myself from earlier in the thread, there ARE moments when custom PCBs are necessary. Since my latest version of this device is almost entirely SMT, there were a couple components that just... didn't have a breakout board. At all. Namely, my cypress USB hub chip, and my FPC connector. The USB hub doesn't have a hobbyist-friendly breakout board for a pretty good reason, which is that a lot of the PCB design specs are pretty stringent (minimum 4-layer board, and USB data line length matching being the major ones), and the FPC connector was an odd size. Simplest way for me to test designs for those components was to make a test board: I just made a one-off board from oshpark that had a few USB connectors, a built-in Teensy 3.1, and the screen connector. Tested the USB hub by making sure that the teensy appeared on my computer, and any device I plugged into the extra usb connectors worked, and tested the FPC connector by having the teensy run some TFT touchscreen code.

Basically would have been out-and-out impossible to try and breadboard everything and expect any kind of real success, due to all the PCB-level design requirements for those components.

Anyway, I suppose that doesn't really contribute to the thread much - no hobbyist wants to deal with that level of headache, I'm sure. (The only reason I did was because NOBODY made a breakout for that USB hub chip. I plan to get working on one myself in the next few months or so, actually).
 
I will be reading this thread, even if I don't answer everything. Please understand Teensy3++ will be a breadboard format board, likely 48 pins, where the left-side tries to be as compatible as possible with the 28 outside pins of Teensy 3.1 and Teensy LC. Alternate form factors or abandoning Teensy 3.1 compatibility are not up for discussion. A high density connector is unlikely, but not totally out of the question.

I hear allways many pins as possible but at least the short breadboards are only 30pins long, and I like to test some thinks on short stuff so I can move it easy. And btw. the more pins it has to harder is it to remove because of the traction so it is like it's hard wired and the pins are mess after it.
 
Assuming the 48 pin form will at least have as many or more I/O then the teensy 2.0 ++. I'm already planning my next project and i'm short a few with the teensy 2.0++. Regardless of how the extra pins are added, pads on the bottom, 1.00 mm pitch though hole pins, whatever, as long as there accessible somehow is all that really matters to me.
 
Was there a plan to reserve a portion of the 3.1pp for one of these user solder able $2 items?

0.54 X 0.55 X 0.07 in (13.8 X 14.1 X 1.83 mm)

t31ppsdpp.png

<edit>
Here is a 44 pin version adding 30 pins to the T3.1 - plus a spot for memory and the flash drive - just a bit much to route through the old 6 end pin spaces with only 6 layers unless lots are dupes.

t31ppsdppSb.png
 
Last edited:
I also want to try some ambitious ideas for adding networking layers into the Arduino system, which is the big reason why I want to go with the chip that has ethernet. That too will likely turn into an absolutely huge software project. Nobody in the Arduino or microcontroller world seems to be really working on such things, despite all the IoT hype. Seems their answer to complexity of networking is to just use Linux.

I recently re-did some ether (100baseT) benchmarking on the mbed LPC1768. It has on-board Ether, 4-wires to a magjack to wire it up. Network software layered from CMSIS and HAL through socket abstraction via lwip. I didn't do extensive testing, but TCP and UDP client/servers worked. TCP send/recv at 25/19 mbs, UDP send at 40 mbs. Only strange benchmark behavior was lossless UDP receive rate was only 2mbs. UDP 8-byte RTT was 292us.

With the ether running, power consumption goes up by 40ma.

This was limited testing, I don't know how robust their implementation is, but there might be something to be learned from the mbed implementation ...
 
Last edited:
Yes, lwIP is a good choice. Its widely used and stable. I think it supports IPV6. It is used by the popular ESP8266 too.
All it needs is to write a "devicedriver".
Some Links:
http://lwip.wikia.com/wiki/Writing_a_device_driver
http://lwip.wikia.com/wiki/Porting_For_Bare_Metal
http://lwip.wikia.com/wiki/LwIP_with_or_without_an_operating_system

http://lwip.wikia.com/wiki/Available_device_drivers
http://savannah.nongnu.org/projects/lwip/
lwIP has a little brother, uIP wich is good too. It is a bit slower but wants less resources.
 
Last edited:
I'm also really interested in this. :)
I also want to try some ambitious ideas for adding networking layers into the Arduino system, which is the big reason why I want to go with the chip that has ethernet. That too will likely turn into an absolutely huge software project. Nobody in the Arduino or microcontroller world seems to be really working on such things, despite all the IoT hype. Seems their answer to complexity of networking is to just use Linux.

Good call.

Since I have technically been doing IoT for a living for 10 years (KNX building/lighting controls with head ends, BMS interfacing, blind control, heat recovery etc.) I can safely say that the robust products are baremetal, dedicated designs.

Anything based on linux (a grand total of about 5 products I've ever used) tends to be essentially unreliable. It's also very hard to maintain an OS once a device is in situe.

The linux devices I've used have been as follows: A) "It's broken, we need to apply a firmware patch and reconfigure it, taking a long time, and for no good reason. Oh look, it works again. So why was it broken? We simply don't know.....blame a memory chip."

The dedicated hardware like PIRs, actuators, wall switches etc. have been typically B) " It's broken. Change the device for a new one, download to the device, Oh look it works again. The device failed due to age or out-of-range exposure to external elements. It was cheap anyway, don't worry about it."

B) is fewer and farther between than A), and that's what you need for controls. The last project I did that had linux based touchscreens; of 9 screens, 6 of them stopped working within 18 months, either frozen or displaying garbage. I patched them with a firmware update and suddenly they would boot again and are currently fully operational. For how long?

And lets be realistic here: IoT is just controls.

Controls interfaces heating, cooling, blinds, lighting, windows, pumps, boilers, extract fans, towel rails, TVs, blu ray players, music systems, IPTV systems and security systems. And all of this linked to a mobile app in your handset.
It's already doing this. You can do all this with KNX and its an open standard and robust products are already on the market. IoT is not new, it's just a buzzword that's popped up in the media in the last 4 years, it's been going on for 25 years or more.

They can be improved upon, but they need to speak the same language over a standard medium, and ethernet seems like a good place to start as those packets can be adapted to Wifi, powerline, and potentially EnOCean and zigbee etc.

But the idea of baking your own, to connect your <insert currently unsupported device here> into your home IoT network is an exciting one for me.
 
Last edited:
IMO the main issue with ethernet and wifi has to do with the timeouts that can arise. Unless the stack is written really well and can handle incomplete transmissions, re-transmits, etc. without hand-holding, I'd argue that something like a beagle-bone that can walk and chew gum at the same time is a better answer.

I.e. use the Teensy for timing-critical measurements while the Linux-based system handles I/O with the internet and perhaps SD-logging too.

For my logger, I have dedicated a MCU solely for talking to the GPRS modem. I have no interest dealing with a Master MCU that is tied in pretzels because our local cell phone provider is having a bad hair day. Instead, have a dedicated GPRS MCU with a watchdog and reset it as necessary. The master sends a payload, the slave deals with getting it onto the internet. Thus, if the slave goes down, the master can continue its work. Redundancy is IMO overlooked far too often.
 
IMO the main issue with ethernet and wifi has to do with the timeouts that can arise. Unless the stack is written really well and can handle incomplete transmissions, re-transmits, etc. without hand-holding, I'd argue that something like a beagle-bone that can walk and chew gum at the same time is a better answer.

I.e. use the Teensy for timing-critical measurements while the Linux-based system handles I/O with the internet and perhaps SD-logging too.

For my logger, I have dedicated a MCU solely for talking to the GPRS modem. I have no interest dealing with a Master MCU that is tied in pretzels because our local cell phone provider is having a bad hair day. Instead, have a dedicated GPRS MCU with a watchdog and reset it as necessary. The master sends a payload, the slave deals with getting it onto the internet. Thus, if the slave goes down, the master can continue its work. Redundancy is IMO overlooked far too often.

The price point for a push button interface is about £13 GBP, marked up sold on to an integrator.
you want to run linux on it? seriously?

On KNX systems the recipient must Ack the command. If it does not ack, it will be resent. This occurs 3 times only. that way it will try and resend if it is not received.

It's good enough for wireless, powerline and custom knx cable (Twisted pair) solutions.

Don't reinvent the wheel guys, you're whacking a peanut with a sledgehammer. But we are going a bit off topic.
 
The IP stack timing, RAM needs, etc. all go away if you use an IP stack offload board as Wiznet makes.
Infinitely simpler.
 
pin 13 opamp
A minor thought for ++3. Not sure of cost/benefit, but you might consider opamp to front pin 13 resistor/LED. That solves the pin 13 input issue and saves a few milliamps from the chip power budget. Arduino Rev3 did this (albeit they had a spare opamp on the PCB). The curious side-effect is the LED will light up if opamp has floating input. Schematic for Arduino ZERO's shows a transistor fronting the LED/resistor, and a pulldown resistor in front of the transistor (to eliminate floating input, i presume).
 
pin 13 opamp
A minor thought for ++3. Not sure of cost/benefit, but you might consider opamp to front pin 13 resistor/LED. That solves the pin 13 input issue and saves a few milliamps from the chip power budget. Arduino Rev3 did this (albeit they had a spare opamp on the PCB). The curious side-effect is the LED will light up if opamp has floating input. Schematic for Arduino ZERO's shows a transistor fronting the LED/resistor, and a pulldown resistor in front of the transistor (to eliminate floating input, i presume).

Or - since there are some unused Pins - a dedicated LED Port.
 
I'm looking forward to more flash and more pins. An easy to use low power standby mode would be nice. Lack of 5 V I can cope with, as I'm using level shifters to provide 5 V signals to LED strips already.

However, the one thing I hope doesn't change is the physical width. The T3.1 is at the limit of what's possible for my application, to the point where I'm having to saw and file a millimetre off the side as is (https://forum.pjrc.com/threads/27844-Teensy-3-1-Physical-Width). Castellation would be great for me, but I recognise that I'm in the minority.

Please don't make Teensy wider.

(I really should get some decent pictures of my Teensy-powered glow staff - it's doing stunning POV images with 3 ms updates, courtesy of APA102 strips and FastLED.)
 
@Paul,
Any leakage on progress for new board?
I assume you are actively working on it, right?
 
Actually, at the moment I'm working on the change from Mini54 to KL02.

The physical space freed up by the smaller KL02 chip is going to be used for a rugged 3.3V regulator chip. Every week we get at least one person who blows up their Teensy. Statistically, that's a tiny fraction of all customers, but it's tremendously painful (for them and for me). Lots of things can go wrong, but by far the weakest part of Teensy 3.1 is the on-chip voltage regulator. I'm going to cram a LDO regulator chip rated for 10 volts and 500 mA onto the free space. Of course you can't sustain both 10V and 1/2 amp, due to limited heatsinking from the copper layers in the PCB, but it will give Teensy the ability to withstand a lot more abuse. My hope is this will dramatically cut down the number of incidents where people blow up their board while trying to use non-USB power.

The higher power available on 3.3V will allow running the W5200 ethernet or ESP8266 Wifi without an external regulator.

Before Teensy++ 3.x, we're going to make a multi-function peripheral board. I'm not ready to "leak" details on that just yet....
 
Before Teensy++ 3.x, we're going to make a multi-function peripheral board. I'm not ready to "leak" details on that just yet....
Interesting.

For my tastes, it would be nice if such a board had through hole mounts for the various buses, that includes power and ground for each item, and where there exist standard pinouts (i.e. for servos) use those. And it should include the 4.7K resistors for the i2c bus. For maximum flexibility, I could see having a 3.3v side and higher voltage side with appropriate level converters (use VIN by default, but allow external voltage). So a couple of rows of 4 pins for the serial ports and i2c buses. A couple of rows of 3 pins for servos/PWM. Two sets of 3x2 ports for SPI. Can and I2S ports (I don't know what cables are used for these). Some rows for analog pins, possibly using AGND instead of the normal ground pin.
 
Last edited:
If we get SDIO, will there be some design decisions made to handle the excessive power draws that the sdcard can do? I forget what someone mentioned in one of the other threads, but I seem to remember occasional ~150mA draw, which might cause instability and/or ADC noise. I know it may not be possible to handle that, but would there be some part that the user could add to handle this? Similar to adding the RTC crystal.
 
Though not on K20's, I'm using 16GB uSD cards and have evaluated about 8 different brands. The write current varies quite a bit among makes/models.
I haven't seen more than about 40-60mA. In die form with wire-bonding (quantity) these are dirt cheap.

Also, in SDIO mode, the on-card OS (on most) can manage auto-power on/off/sleep.
At the moment, I'm using one channel SDIO rather than 4 channel. I use DMA and that's important to use at 24Mbps/channel.

I'm using the vendor's drivers and vendor's distro of Chan FatFS. Made this simple, as the SDIO procedures are rather complex. But the card OS does all the hard stuff about block erases, wear-leveling, etc.
 
Last edited:
I measured my varieties of cards using a 'scope and a nice little USB thing from Adafruit that has a Hall effect "shunt". I can see the current pulses.
It may be too that I was using SDIO, not SPI and that uses a different strategy in the card OS.
 
Status
Not open for further replies.
Back
Top