Teensyduino 1.22 Features

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 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, and in the past digistumps record for software support hasn't impressed me, and 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.

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.

Great Idea..
this would make it possible to build a complete webradio in Teensy-size ;-)
But, the WLAN needs much current, so an on-board power supply for Wlan is needed. In addition, an antenna (perhaps on the backside? Could that work ? ), and the ESP needs an "external" flash-chip too.
I wonder if all this is possible with this small form factor..
But hey, it would be a dual-cpu board.. (where both are programmable) :) Fantastic !
 
Sorry about moving the thread, I thought it was more logical in the teensy 3.1++ thread.

I just wandered over to the Adafruit site, and noticed Adafruit has entered into the fray with its own $10 ESP8266 unit that is programmable (https://www.adafruit.com/product/2471), FCC certified, etc. The main special sauce that the Oak has is it can be remotely loaded from anywhere on the internet, which for some things is important. On the downside, it is a kickstarter project, and dates on KS tend to be on the fuzzy side. Of all of the KS projects I've backed, the 3.0 Teensy that Paul did is the only one that shipped near the promised date. Digistump's last KS project was 6 months late for most of the components, and 9 months late for one item (the lipo battery charger shield). Frankly, by the time the Digispark Pro shipped, I had lost interest in it, given both the Adafruit Trinket Pro and then the Teensy LC occupied the same head space as the Digispark Pro was designed for.

Granted the Adafruit Huzzah is not in stock, and it probably will be in short supply for awhile, I still imagine it will be a hard road for Digistump to compete in now that Adafruit has entered the fray.
 
Last edited:
Wow - announced April 24, 2015 AT 6:58 pm and out of stock 4/25? I wonder how many they had? Expect they'll show soon enough.

They don't give code space specs or many details - they just repacked a pre-made module mounted to a breadboard adapter (like has already been selling out on Tindie). It seems Digistump has the same set of I/O onboard - but has double the supply current capacity. [Adapter page notes the module can take 300mA - and Adafruit supplies 250mA] OAK shows a smaller Ceramic antenna on KS - but will compare to the board based trace antenna and choose the best 'fit'. The OAK uses the 'EX' core chips - but is providing perhaps a higher speed and larger Flash - that may allow OC Adafruit can't, and also have room store a backup boot_Stack in the event of bricking - still leaving 300KB for code & data.

The OAK can also be Serial Programmed - it would just take wiring (all the pins are there) as with the OTA update you don't need the header space devoted to that. OAK extends the system to OTA as noted - and also claims to be resolving known and ongoing issues with the packaged versions - not sure if that includes the Adafruit repacked unit? Also the OAK notes you can dump their OTA_Stack and go 'bare metal' - meaning you'd have 1024MB to start with rather than 512MB (if they use the same package as the Tindie offering) and be able to revert to the code base of your choice?

OAK gives a Micro USB as a common power source. And will be buying their own FCC certification for a custom build. It seems OAK has been in development for a bit to be as far along as it is - but with FCC and other details TBD - Sept may be closer than it seems - at least the Chinese new year won't be involved this time.

I'm wondering if the Adafruit level converters are good (only for programming pins?) - or if they suffer problems like other ones Paul noted have at higher speed.
 
Michael: Moving it wasn't bad - I just shared link the since your post that was already quoted and 1.22 is a done deal - and this is really it's own topic. Some PJRC OTA update scheme for "Teensy 4.0/3.2/3.1++ (or whatever)" would satisfy lots of folks - but is probably farther off than even OAK, especially since it will be a bigger change than the LC was - more pins and more speed and more issues that Paul will perfect.

As noted elsewhere - I like the ESP8266 as a generic WiFi attachment device that just happens to be a co-processor to take the NET stack to a separate device where it can stall or hang all it wants without hurting the teensy - more than delaying serial I/O chatter for data transfer not actual hardware responsiveness.

If the bigger/better Teensy is fast and wonderful - but gets fitful controlling WiFi it would be ugly. If it can add a coprocessor and get OTA & WiFi that would be cool - but that would add a couple dollars in hardware, and won't help 3.1 or LC. Maybe the OTA/WiFi would best be an optional addon - like the OAK it may be worth the price of an LC for what it would bring to the party - but not built onto every board.

I have a box of routers that stopped working in a year or two - not sure why that is? Maybe they need firmware updates? Or were just old school tech? Hopefully the ESP8266 won't run for 12 months and then drop out and die all the time. I buy lots from Newegg - and have yet to see the perfect router - even the most rated ones have their share of 'lemons' like the ones in my box.
 
Last edited:
If the bigger/better Teensy is fast and wonderful - but gets fitful controlling WiFi it would be ugly. If it can add a coprocessor and get OTA & WiFi that would be cool - but that would add a couple dollars in hardware, and won't help 3.1 or LC.

Personally, I would support a more powerful concept that costs some dollars more, and why not, allows the 3.1 or LC be integrated as, say co-processor or I/O expander.
 
Sorry, I think a breakout board makes more sense. Reason being that the FCC-certified breakout board (very cool BTW) uses a lot of board space. Creating a FCC-certified solution costs a lot of money and think of the length that a Teensy 3++ would have to be in order to make room for the breakout. Even if Paul switches to a 2-sided board solution, it would likely expand the footprint significantly.

What I would prefer is that if a externally-programmable solution should exist for the teensy that Paul simply make the pins available that would allow such in field re-programming. That would keep the board dimensions modest for the 90% that do not need the breakout board, yet allow the 10% that have to re-program Teensy's in the field as needed.
 
Well in terms of higher speed, I imagine all of these serial devices are limited to the max. speed of your UART (which was roughly 1M bits/second for one device I looked at). For IoT (internet of things, smart sensors, etc.) that is fine, you really don't need that much bandwidth. Other things like video desire higher bandwidth.
 
Well in terms of higher speed, I imagine all of these serial devices are limited to the max. speed of your UART (which was roughly 1M bits/second for one device I looked at).

I have been running a Hardware Serial test between two Teensy3.1's (@96Mhz) configured their Serial @ 6MHz and its works! Teensy(1) sends ~7500 bytes of readable data to Teensy(2) which prints it to serial monitor (USB). Below is the simple receiving code, readBytesUntil is really efficient and the only way i found to reliably print the received data to serial monitor.
Code:
#define HWSERIAL Serial1


void setup() {
  HWSERIAL.begin(6000000);
}


void loop() {
  char buffer[8192];
  int bytes = HWSERIAL.readBytesUntil(0,buffer,8192);
  if (bytes) Serial.write(buffer, bytes);
}

The one caveat for the code above is that your input buffer needs to be as large as what your sending. I really was skeptical when other reported Hardware Serial running at these speeds so I had to see for myself. I'm not doing any error checking except I know what I'm sending and doing a visual check when its printed to the serial monitor and I don't see any problem yet. I'll make a more robust test with error detection later and post a follow up.
 
I'd also verify with an oscilloscope that the transfer speed is indeed 6MHz. IIRC there have been instances where the MCU was configured for one speed but the actual transfer speed is lower.
 
I'd also verify with an oscilloscope that the transfer speed is indeed 6MHz. IIRC there have been instances where the MCU was configured for one speed but the actual transfer speed is lower.
I'll do that also to be sure. Though it doesn't send anything with F_CPU @ 24 or 48 MHz.

Wow, I would not have expected 6 Mbit/sec to work... but then, I've really only ever tested to 1 Mbit/sec.
Pretty amazing if this pans out to be 6Mbit/sec!
 
Interesting that the USB Monitor can keep up with that at the same time? I'll have to look at the code and try it.

What does the Send_Sketch look like? A quick Timing of the transfers [write and readBytesUntil] and some math for a sanity check. Would that be 6 bits per micro second? 6M/1K/1K?

I did a quick test of the serialEvent1() in another thread - the LC seemed to stop a bit over 220000 and I didn't take the 3.1 over 921600, now I have to faster! I was doing short messages - looping in one Serial# and out another first on one Teensy - then the same code on two Teensy's with four wires that ran for days .
 
I would have to imagine that with its 8 byte FIFOs on Serial1/Serial2, the 3.1 would be better for high speed serial than the LC. Speaking from somebody who used to use real serial ports on computers with 9/25 pin connectors to download code to embedded computers, it is a shame that many of the serial devices these days are 2 wire (RX/TX + power/ground) and not 4 wire (add RTS/CTS to allow for each side to indicate when it can't receive any more data). I know back in the day, we used to have problems with data over run on those much slower CPUs. But if you crank it up to 6Mbit, you are likely to see similar lossage.
 
Last edited:
This was telling :
readBytesUntil is really efficient and the only way
and
doesn't send anything with F_CPU @ 24 or 48 MHz

That is a dedicated polling wait to read - the fact that it works is great - for short messages that fit hardware FIFO with good wires that could be useful. But if your back is turned a half a millisecond you just overran (3,000 - 64) bits?
 
It's actually sending at 6 Mbit/sec, I have my scope setup to decode serial though I couldn't figure out how to show the scopes serial settings. If anyone knows how Rigols quick save with the current screen let me know!

Teensy 3.1 Serial receive at 6Mhz



Here are the current setup params for the scope too which show the baud rate:
Code:
Model:DS1104Z
SN:DS1ZA161651250
Manufacturer:RIGOL TECHNOLOGIES
Board Ver:0.1.1
Firmware Ver:0.2.3.6
BOOT Ver:0.0.1.0
CPLD Ver:1.1
SoftWare Ver:00.04.00




    DSO Vertical System 
CH1:On
Scale:1.000000V
Position:-2.020000V
Coupling:DC
Bandwidth Limit:OFF
Probe Ratio:10X
Unit:V


CH2:Off
Scale:0.020000V
Position:-0.043200V
Coupling:DC
Bandwidth Limit:OFF
Probe Ratio:10X
Unit:V


CH3:Off
Scale:1.000000V
Position:0.000000V
Coupling:DC
Bandwidth Limit:OFF
Probe Ratio:10X
Unit:V


CH4:Off
Scale:1.000000V
Position:0.000000V
Coupling:DC
Bandwidth Limit:OFF
Probe Ratio:10X
Unit:V


DSO Horizontal System
Delay:Off
Time Mode:YT
Time Scale:2.000000e-06S
Delay Time Scale:5.000000e-07S
Time Offset:3.880000e-06S
Delay Time Offset:0.000000e+00S


DSO Acquire System
Acquire Mode:Normal
Memory Depth:24000
Average Num:2
Sampling Rate:1000000000Sa/S


DSO Trigger System
Trigger Mode:RS232
Trigger Source:CH1
Trigger Edge Slope:Rising
Trigger Sweep:Single
Trigger Coupling:DC
Trigger Noise Reject:On
Trigger HoldOff:1.600000e-08S


CH1 Level:0.000000V
CH2 Level:0.000000V
CH3 Level:0.000000V
CH4 Level:0.000000V


Pulse Condition:Positive More
Pulse High Time:0.000002S
Pulse Low Time:0.000001S


Slope Condition:Positive More
Slope High Time:0.000002S
Slope Low Time:0.000001S
Slope Win:Win Up
Slope Level1:2.000000V
Slope Level2:0.000000V


Video Polarity:Positive
Video Sync:All Lines
Video Standard:NTSC
Video Line:1


Runt Polarity:Negative
Runt Condition:Do not care
Runt Win:Do not care


Windows Type:Rising
Windows Pos:Enter
Window Time:0.000001S


NCycle Edge:Fall
NCycle Time:0.000001S
NCycle Num:2


Pattern CH1:H
Pattern CH2:H
Pattern CH3:H
Pattern CH4:H


Delay A:CH1
Delay B:CH2
Delay A Slope:Rising
Delay B Slope:Rising
Delay Range:More
Delay High:0.000002S
Delay Low:0.000001S


TimeOut Slope:Rising
TimeOut:0.000000S


Duration Type:More
Dura. High:0.000002S
Dura. Low:0.000001S


Setup/Hold Clk:CH2
Setup/Hold Data:CH1
Setup/Hold Slope:Rising
Setup/Hold Patt.:H
Setup/Hold Type:Setup
Setup Time:0.000001S
Hold Time:0.000001S


RS232 Source:CH1
RS232 Type:Frame Start
RS232 Stop Bit:2
RS232 Parity:Odd
RS232 Data Bit:8
RS232 Baudrate:6000000
RS232 Data:90


IIC Clock Source:CH1
IIC Data Source:CH2
IIC Type:Start
IIC Address:1
IIC Direction:Read
IIC Address Length:7
IIC Byte Length:1
IIC Data:82


SPI SCLK:CH1
SPI SDIO:CH2
SPI Mode:CS
SPI CS Mode:Low
SPI Edge:Rise
SPI Timeout:0.000001S
SPI Data Length:8
SPI Data:82


    LA System
D0~D7  Threshold Type:TTL
D0~D7  Threshold Value:1400.000000V
D8~D15 Threshold Type:TTL
D8~D15 Threshold Value:1400.000000V
D0~D7  Status:0000 0000
D8~D15 Stauts:0000 0000
 
not fully on-topic, but I want to try and get the dhrystones of the teensy :
https://classes.soe.ucsc.edu/cmpe202/benchmarks/standard/dhrystone.c

It's not what we want :

But sure its fun to know the rank of the teensy is this list (?):
Code:
 *----------------DHRYSTONE VERSION 1.1 RESULTS BEGIN--------------------------
 *
 * MACHINE	MICROPROCESSOR	OPERATING	COMPILER	DHRYSTONES/SEC.
 * TYPE				SYSTEM				NO REG	REGS
 * --------------------------	------------	-----------	---------------
 * Apple IIe	65C02-1.02Mhz	DOS 3.3		Aztec CII v1.05i  37	  37
 * -		Z80-2.5Mhz	CPM-80 v2.2	Aztec CII v1.05g  91	  91
 * -		8086-8Mhz	RMX86 V6	Intel C-86 V2.0	 197	 203LM??
 * IBM PC/XT	8088-4.77Mhz	COHERENT 2.3.43	Mark Wiiliams	 259	 275
 * -		8086-8Mhz	RMX86 V6	Intel C-86 V2.0	 287	 304 ??
 * Fortune 32:16 68000-6Mhz	V7+sys3+4.1BSD  cc		 360	 346
 * PDP-11/34A	w/FP-11C	UNIX V7m	cc		 406	 449
 * Macintosh512	68000-7.7Mhz	Mac ROM O/S	DeSmet(C ware)	 625	 625
 * VAX-11/750	w/FPA		UNIX 4.2BSD	cc		 831	 852
 * DataMedia 932 68000-10Mhz	UNIX sysV	cc		 837	 888
 * Plexus P35	68000-12.5Mhz	UNIX sysIII	cc		 835	 894
 * ATT PC7300	68010-10Mhz	UNIX 5.0.3	cc		 973	1034
 * Compaq II	80286-8Mhz	MSDOS 3.1	MS C 3.0 	1086	1140 LM
 * IBM PC/AT    80286-7.5Mhz    Venix/286 SVR2  cc              1159    1254 *15
 * Compaq II	80286-8Mhz	MSDOS 3.1	MS C 3.0 	1190	1282 MM
 * MicroVAX II	-		Mach/4.3	cc		1361	1385
 * DEC uVAX II	-		Ultrix-32m v1.1	cc		1385	1399
 * Compaq II	80286-8Mhz	MSDOS 3.1	MS C 3.0 	1351	1428
 * VAX 11/780	-		UNIX 4.2BSD	cc		1417	1441
 * VAX-780/MA780		Mach/4.3	cc		1428	1470
 * VAX 11/780	-		UNIX 5.0.1	cc 4.1.1.31	1650	1640
 * Ridge 32C V1	-		ROS 3.3		Ridge C (older)	1628	1695
 * Gould PN6005	-		UTX 1.1c+ (4.2)	cc		1732	1884
 * Gould PN9080	custom ECL	UTX-32 1.1C	cc		4745	4992
 * VAX-784	-		Mach/4.3	cc		5263	5555 &4
 * VAX 8600	-		4.3 BSD		cc		6329	6423
 * Amdahl 5860	-		UTS sysV	cc 1.22	       28735   28846
 * IBM3090/200	-		?		?	       31250   31250
 *
 ...

Whow.. cray had 105Mhz ?? did not know this..
I remember fotos .. they were round and seats on it :)

dhrystone v1.1 and v2.1a
I found some mbed code for the old dhyrstone benchmark that i got running on Teensy, here are some results
Code:
dhrystone     v1.1     v2.1a (per second)
   UNO 1284p  18832    11116  16mhz
   ZERO       66143    42068  48mhz
   DUE       113561    86770  84mhz
   maple      61927    84922  72mhz
   STM32L476 156041   112068  80mhz
   T3.2      176896   145145  96mhz
   T3.5      223232   185719 120mhz
   T3.6      359746   391853 180mhz  -Os  slower for others
   TLC        67724    43295  48mhz  25x25
   LPC1768   331907   267409  96mhz
   K64F      398417   333333 120mhz  mbed -O3
   F446RE    717967   615976 180mhz
   F469NI    714890   615976 180mhz  mbed (star otto)
 
   T3.6  v1.1    1.6.13 gcc 5.4
        fastest LTO 318882 /sec  ms: 10000   -O3
        fastest 97883 /sec  ms: 10000
        faster LTO 348066 /sec  ms: 10000    -O2
        faster 281517 /sec  ms: 10000
        fast LTO 93275 /sec  ms: 10000       -O
        fast   107540 /sec  ms: 10000
        small LTO  114042 /sec  ms: 10000    -Os
        small    359746 /sec  ms: 10001

I got really slow performance on T3.6@180MHz (IDE 1.6.12/TD1.31) 51527/sec?? at 120mhz ok at 320531/sec.

See newer comparative coremarkish data
 
Last edited:
Back
Top