Future Teensies!

Current sensing circuitry for the 3.3v regulator.

About sensing too, USB power detection option (get a 3.3v level out of the VUSB maybe add a small mosfet there?).
About smart power switching maybe also add space for very small MBR120VLSFT1G diodes after 5V and VUSB (simplifications are possible after that change again saving space), that I prefer instead of the 1N5817 option documented elsewhere as they cause less voltage drop.
 
Last edited:
I'd like to see a version available with the Ethernet magjack and host USB is already mounted. Maybe move most of the I/O to a surface mount socket that a cable could be connected to for a daughter board since the allowed ampacity is very low per pin from the processor. Possibly a lipo battery connector with charge circuits. Exchange the type micro B socket for a type C socket on the USB device connector. I feel there is a large hobbiest and higher education student market for people that have a hard time with soldering. After all, there are very limited solutions for wired ethernet IOT right now.

On the software side, I'd like to see more work done to have fully working Ethernet libraries with example code included with TeensyDuino. Possibly induding examples incorporating things like the REST API, MODBUS TCP, and MQTT protocols. (Homekit, Google Home, and Amazon Alexa kind of goes with this, but needs a lot of extra code to handle mandatory encryption.)
 
Whitebengal, no offense but you pretty much just described the rpi. To me the teensy is just what it says - teensy. If I want internet, bluetooth or that other stuff I'll just use a pi, it's almost the same price. I would like to see perhaps a 44 pin qdip with the 8MB memory and pads for two more devices. But most of all I'd like to see an all in one teensy that has a quality audio i/o section right on a 32 or 48 pin flatpack like the 4.0 or 4.1

Here's an idea: the audio PC97 connector on the audio shield is exactly .050 off the centers of the teensy. That means I can't solder the two together and pogo them on a 0.1" prototype board. It would be great if this could be fixed in the next revision (assuming another run is ever made of these).
 
Ribbon connector from the LCD pins in whatever pitch is most popular with the LCDs it could reasonably drive.

Other ribbon connector to expose more pins.

5V in + 3.3 -> 5 level shifter for driving WS281x LEDs at full voltage, on some PWM pin. A jumper would select whether you want that pin to be 3.3 or 5 volts.
 
A raspberry pi is essentially a full computer with security risks, a drastically larger physical footprint, and significantly higher power dissipation needs than what I am discussing. The last two are big problems with almost all forms of IOT and a large part of why Espriff is popular right now. 16 cubic centimeters with mains power supply and a power budget under 1W isn't remotely possible with any full RISC computer.
 
You can add easy to use WiFi to your project with an ESP8266 for < $2. It's kinda nuts how cheap that is.
 
Hi there!

I would definitely vote for REAL debug capabilities, now that we have super powerful CPUs. Teensy 4.2 with 1062RT and JTAG, or SWD?

It was really great to have that sort of debug possibility on the last STM32 board I worked on. All included in Vscode. No more ugly printf statements... ;-)
 
It was really great to have that sort of debug possibility on the last STM32 board I worked on. All included in Vscode. No more ugly printf statements... ;-)
To me, it's not a proper programming workflow unless I can double-click the gutter next to some line of code, a red dot shows up there, and I know execution will pause there the next time it runs. Being able to step into and over things is so much better. Doing everything with printf() is for the birds.
 
To me, it's not a proper programming workflow unless I can double-click the gutter next to some line of code, a red dot shows up there, and I know execution will pause there the next time it runs. Being able to step into and over things is so much better. Doing everything with printf() is for the birds.

While I agree having h/w support is nice, have you used the software GDB support on the Teensy 4.0/4.1?
 
While I agree having h/w support is nice, have you used the software GDB support on the Teensy 4.0/4.1?

The last thing a developer wants to do is to debug the tools... I read that the proposed SW solution works, but not very stable on 3.X versions, and not so clear about robustness using 4.x either. A proper debug environnement needs to be rock solid.

I know IO pads are scarce on the Teensy ( real estate issue), and a tint 10 pin 1.27mm pitch/ 50 milm would be great. Now, the tricky thing is to protect the bootloader, as we all hate cheap chinese clones ( full of bugs of course). Can Paul manage to secure the bootloader while having SWD accessible on the I.MXRT?
 
Back
Top