Any Chance of a Teensy ++ 3.1?

Status
Not open for further replies.
Isn't uTasker a one-time fee of $485 or $765? (and thereafter, you use it royalty free, regardless of how many copies you ship) Does a "low cost retail product" mean something that's manufactured in China in at 50,000 to 250,000 quantity? If you think $500 is too much for a one-time expense, and you really are developing a high-volume retail product, I'm sure you'll have plenty of unpleasant experiences along the way!

But if you really want free, I believe Frank is working on this right now and just published something yesterday. Maybe you should give Frank's code a try. If it doesn't fully meet all your needs, maybe you could help to improve it?

As far as PJRC is concerned, I hear your "have a leg up on the Arduino camp" thought. Really, I do. I've seen you're asking the same thing on their forum too.

Just to be perfectly clear, I'm not planning to work on this feature, at least not anytime soon. Part of my reasoning is uTasker and Frank are already on it. But mostly, I have an incredibly long list of other far more urgent things in development. Some examples: USB MTP & Audio, Teensy++ 3.x, completing the SD library optimizations, further pre-fetching and DMA optimizations on SD when we get Teensy++ hardware, ways to enable SWD/JTAG debug, about 100 feature requests on the Audio library, and the upcoming motion+light+sound peripheral board (oh, look, another new product hint leaked....)

FWIW, uTasker has been around for a very long time and has a very impressive list of features. Until recently, much of that stuff didn't have any usable free alternatives. Arduino and FreeRTOS and other projects are slowly changing the landscape, much like how Linux shook up the commercial Unix marketplace 15+ years ago. Long term, I and Frank and many others will probably do all this stuff and much, much more. But it's a very long and slow process. Much of the work is open source contributions by unpaid volunteers, and people like me who are financially supported by sales of low-cost products. With cheap Asian clones and subsidized hardware from semiconductor manufacturers flooding the market, it's a very indirect and slow approach (burdened with running a hardware company) compared to traditional software licensing revenue. The way this open source stuff works is you roll up your sleeves and contribute.
 
>Does a "low cost retail product" mean something that's manufactured in China in at 50,000 to 250,000 quantity?
No. My product will have low volume production and sales market (<1000). Very narrow vertical market. I'm doing the manufacturing myself and in the US, not China.

>But if you really want free
I never said I wanted free. Where on earth did you get that from? I said companies are entitled to an ROI. Just like you are.

>Just to be perfectly clear, I'm not planning to work on this feature.
Now we know...thanks for the answer.

>The way this open source stuff works is you roll up your sleeves and contribute.
I would love to do that but I don't think my skill set is high enough for a project like this (in other words, I'm not smart enough). As you may have seen in another thread I responded to someone who said there isn't much memory available to do this kind of thing and I said I have several years of assembly language experience and if someone could help guide me on where to focus I wouldn't mind rolling up my sleeves and taking a crack at writing some small assembler code. The response was that 'C would be better' and have about a 4 times smaller foot print than assembler. That didn't make sense from what I've learned and have read re assembly code vs C generated code, but I figured maybe he knows more about that than me.

Anyway, thanks for jumping into the thread Paul with your thoughts.
 
Maybe I misunderstood, but if you mean http://forum.arduino.cc/index.php?topic=351358.msg2423222#msg2423222 then "1-2 KLOC in C" to me means between one and two thousand lines of C code. But usually 1 line of C code != 1 line of assembly code.

Right, that is correct. But it isn't how many lines of code that is the primary concern, it's what is the end result memory foot print? If a boot loader off of the SD card can be done in assembly with a small enough foot print, then I think its worth the extra lines of asm code (yes, many extra lines). In fact, in some hardware cases, it may be the only way to make it happen.

Again, I don't have a PHD in computer science, but I have programmed for a few years in C and a few years in 8088/8086 assembler, so I know how tedious assembly is to code. But I guess I'm an odd duck, because I loved to write code in assembly when I was doing it. Something about having the absolute control down into the bowls of the CPU registers...I just loved it. I used Borlands Turbo Assembler and Microsoft's MASM and Tlink.
 
Sounds like you've misunderstood that uTasker's project price is one time - not recurring per board.

I have absolutely no problem paying for hardware/software and I've bought lots of both. Companies are entitled to earn some ROI for their time and their products. However, uTasker is on another planet with their commercial pricing for their SD card boot solution. Maybe they assume everyone who is using a Teensy for a commercial product is charging $1,000.00+ for their product.

If you value your time do develop a bootloader with proper IP rights, you'll sped a lot more than the < $500 license fee.
 
>Sounds like you've misunderstood that uTasker's project price is one time - not recurring per board.

Nope, I understand their pricing structure.
 
Based on looking at the many (and there a lot!) add-on hardware products that are available for both the Ardunio and the Teensy boards, they all seem (a general statement) to have prices in in the range of $10.00 to $50.00 or more, depending. I think for our tiny board community, we are 'used' to these lower price points for an add-on/shield. I would say an SD Card shield that would allow loading a .hex file off of the card at power up, $25.00 to $50.00 would be a reasonable price point.

However, that being said, you're building one for the market, so you obviously know a lot more about the details of it than I do. Perhaps it turns out that it cannot be done for that price range. If so, it just means I will have to do without one and figure out something else to update my code in the field.
 
rfresh737@ The bootloader is only a piece of software (Of course it needs a sd-slot, but it can be shared with the application).
What's a fair price for such a solution ?

$25-$50: Perhaps it would be more easy/cheap to send a new teensy to your customers (?!)
 
k64f.png
Cortex 4 play with the NXP/Freescale FRDM-K64F? Teensy 3.5

I'm thinking of playing with mbed cortex-M4F (MK64FN1M0VLL12),
https://developer.mbed.org/platforms/FRDM-K64F/
same family as MK66FX1M0. One could build some tests with the "modest" mbed libraries, but maybe if teensyduino had a 120 MHz build option for the MK66FX1M0, then one could drag-and-drop the teensy bin onto the mbed K64F ...

UPDATE:
I'll update this post with my experiences on K64F (sticky post)
  • Clocks: cpu/bus/ram 120/60/24 MHz, 32khz RTC crystal, 25mhz ether crystal provides 50mhz to MCU
  • measured PULLUP resistance on a few pins, 42Kohms
  • hardware RNG, speed 7.5 mbs, NIST tests look good
  • Ethernet just worked, static IP or DNS, ARP, ICMP, UDP 8-byte latency 288us, TCP xmit 26 mbs, recv 21 mbs, UDP xmit 52mbs, recv 4mbs, UDP line-speed burst of 1000-byte packets, only 7 received, ping rtt min/avg/max/mdev = 0.169/0.174/0.178/0.010 ms. multicast/IGMP worked (though not with -O3 for CRC/hash)
  • linpack: float 12.9mflops, double 0.9 mflops (hardware float)
  • memcpy() 1143 mbs, quadword DMA memory-to-memory 1424.7 mbs
  • teensy 3.1 SPI FIFO speedups work, get 27.3 mbs with 30MHz SPI CLK, SPI DMA works
  • FastCRC lib works benchmark
  • Frank B reports K64F can overclock F_BUS
  • SDHC module for microSD access, early tests
  • POWER: loop() 139 ma with hacked USB cable, Revised 1/31/17 142.5 ma, jumper JP20 measure just MCU current = 42.2 ma; consumers ? ether PHY 46ma, SDA 17ma, ?LDO, USB, LEDs ....??
coremk64a.png
Ethernet hardware has lots of accelerator options, but I don't know how much of that HAL libraries utilize. The mbed board has a PHY chip and RJ45 connector. lwIP provides TCP/UDP/IP services with thread/mutex/mbox from CMSIS-RTOS

There is also a crypto-acceleration unit (CAU) that can speedup software DES/AES/SHA/MD5. Freescale has an assembler wrapper at
http://www.freescale.com/products/a...ion-unit-cau-and-mmcau-software-library:CAUAP
The CAU speeds the time-critical crypto operations, and the library only accesses those basic operations, so you still need to add logic for padding hash input and doing CBC encryption. The Freescale library is in GNU C/assembler so it doesn't work with MBED on-line compiler. I exported the GNU GCC MBED build environment to test the CAU library on K64F @ 120MHz.
Code:
                 CAU        C     TLS
MD5 (KBs)      10964      5471   6693
SHA256(KBs)     3322      2165   2090
AES set key(us)    3        25      7      128-bit key
AES CBC (us)      11       189     74       64 bytes
  12/10/18 NXP now supports CAU in mbedtls and wolfssl. mbedtls with and without CAU
                 CAU      no
SHA256(KBs)     2546     1674
AESCBC(KBs)     3002      772

The fusion sensor algorithms for the prop shield are very float-intensive. In the table below are times for Paul's NXP kalman filter and the Madgwick and Mahony algorithms on the Teensy 3.2 and the mbed Cortex M4f (hardware floating point) NXP K64f (120MHz) and NUCLEO (180MHz).
Code:
                               Time (microseconds)
Algorithm                  t3.2@120mhz      k64f     nucleo@180mhz
Kalman                        3648           467       308
Madgwick                       224             8         6
Mahony                         127             6         3
Madgwick (onehorse)            216             6         5
Mahony                         133             5         3
The mbed MK64F also has an onboard FXOS8700Q (also on teensy prop shield)

Unlike the LC, this MCU is very close to teensy3.1, so not very many porting issues IMHO. MK64F digital pins are 5v tolerant, but no capacitive touch pins.

Ethernet config:
Uses lwIP with RTOS. ring descriptors (16 RX, 8 TX), 1522-byte buffers 16-byte aligned. zero-copy for transmit. etherperf sketch uses 67KB flash and 55KB RAM. Board's PHY is micrel KSZ8081RNACNA.

some of the hardware registers
Code:
        MPU->RGDAAC[0] 0x61f7df    7/19/16
       SIM->SOPT2 0x211000
       SIM->SCGC2 0x1
       ENET->PALR 0x4e408c86
       ENET->PAUR 0xfed8808
       ENET->EIR 0x0
       ENET->EIMR 0xa000000
       ENET->ECR 0xf0000102
       ENET->MSCR 0x130
       ENET->MRBR 0x600
       ENET->RCR 0x5f2c124
       ENET->TCR 0x4
       ENET->TACC 0x1
       ENET->RACC 0xc0
       ENET->MMFR 0x607a0116
       ENET->TFWR 0x100     fifo
       ENET->RSFL 0x0
       ENET->RSEM 0x0
       ENET->RAFL 0x4
       ENET->RAEM 0x4

Paul is also considering the MK64FX512 for Teensy 3.5

RSAsign performance and floating point performance comparison

Code:
 cm/s    K64F/T3.5 CoreMark iterations/sec
283.69   mbed on-line compiler ARM CC 5.6.075  -O3
253.12   mbed cli gcc 7.3.1 -O3
283.64   NXP SDK mcuxpresso gcc 9.3.1  -O3
277.43   Teensy 3.5 gcc 5/4/2  -O3
.

See coremark plots and comparative performance numbers

Teensy K66 beta testing announced 6/9/16 and K66/K64 kickstarter August, 2016.
 
Last edited:
FWIW, over in the Adafruit forum, a user asked for the maximum number of analog inputs he could access from a Raspberry Pi via i2c controllers (24 using 4 boards that provide 8 inputs was his current solution). I mentioned the Teensy 3.2 had 21 inputs, and he was intrigued by it (particularly since a Teensy 3.2 cost less than one of the devices that only gave 8 inputs).

So while most of the discussion for the Teensy 3.1++ has been on more buses (i2c, spi, i2s, etc.), there are some potential users that want more analog input pins. I didn't re-read the entire thread, but it looked like the most analog inputs of the K66 would be 25, but only 14 had been allocated to pins. For those users, the Teensy 3.2 may be more appropriate than the Teensy 3++.
 
For those users, the Teensy 3.2 may be more appropriate than the Teensy 3++.

The current plan has 23 analog pins, with 19 exposed on the outside breadboard-friendly edges.

That's not a huge step up from 21 analog pins, but only 10 of those are exposed on the edges on Teensy 3.x.
 
The current plan has 23 analog pins, with 19 exposed on the outside breadboard-friendly edges.

That's not a huge step up from 21 analog pins, but only 10 of those are exposed on the edges on Teensy 3.x.

Are we entitled to see that current plan, even if it is only scribble by hand? Please accept my apologies for being curious!
 
The current plan has 23 analog pins, with 19 exposed on the outside breadboard-friendly edges.

That's not a huge step up from 21 analog pins, but only 10 of those are exposed on the edges on Teensy 3.x.
Thanks for the update.

I look forward to the new processor as well as the new shield/cape/whatever you mentioned in another post.
 
There is also a crypto-acceleration unit that can speedup software DES/AES/SHA/MD5.

Freescale has an app note about power line harmonic analysis which hints that the crypto unit can be programmed to accelerate 2nd and 3rd order polynomial interpolation.

One of the *many* things I'm excited to try is using the crypto unit to efficiently resample between 44.1 & 48 kHz audio rates.
 
so as i begin to understand how the Ethernet might work, will the board include a PHY chip or at least the PHY GPIO pins accessible?
the MBED K64F mentioned above has a 25MHz crystal to the PHY chip, the PHY provides the 50MHz external clock to the Cortex MCU. How will the ++3 be clocked?
 
Last edited:
Have you guys seen the new SparkFun SAMD21 Mini Breakout?
Despite is not even close to the power of Teensy 3.X (the microcontroller is more close to Teensy-LC costing almost twice) I like that it comes already with RTC crystal and an integrated LiPo charger.
I would love to see those on Teensy 3.X++
 
Have you guys seen the new SparkFun SAMD21 Mini Breakout?
Despite is not even close to the power of Teensy 3.X (the microcontroller is more close to Teensy-LC costing almost twice) I like that it comes already with RTC crystal and an integrated LiPo charger.
I would love to see those on Teensy 3.X++

I don't think that more than 1% users need a lipo-charger...
 
I don't think that more than 1% users need a lipo-charger...

Well, I think is very difficult for you to guess the percentage of users that need / want a feature unless you sell / provide both options and have a real world data to talk percentages.

Another thing is that, adding a feature, by adding a 10 cents part (on my opinion) doesn't hurt.
 
Status
Not open for further replies.
Back
Top