K66 Beta Test

Status
Not open for further replies.
defragster said:
Does this 'Beta Device' have a usable/official name?
Click to expand...

My preference is simple names. "Teensy 4.0" would be my favorite. "Teensy F1" if you want something more different than "Teensy 3.x". Not a fan of '++' because it is reminiscent of 1984 and C++, it's a little harder to type, maybe harder to search for, and versioning gets ugly, e.g. Teensy++ 4.2 with confusion regarding which other PJRC product is most similar.
 
Well, my vote for names is for Teensy K66, and it's cheaper sister, Teensy K64

The Etherenet, me thinks, will require a PHY chip/shield -- a power consumer. The mbed K64 (@120MHz) that I did some pre-K66 testing on has a PHY chip on board, and the lwIP Ethernet stuff worked just fine, though it uses mbed RTOS to manage all the TCP/IP tasks, see K64 testing, which includes some single-precision hardware float tests, and RNG and CAU tests.
 
NXP/Freescale has library for the K66/K64 crypto acceleration unit (CAU), but it's GNU assembler (.s). I got it compiled for the mbed, and just now tried compiling in the Arduino IDE in anticipation of the K66. Changed names to .S, but IDE wasn't happy with the .include xx.hdr file in the .S files. I assume the build commands needs a -I for assembler includes, sigh. The other thought was using the lib (cau.a) that I built for the mbed, but I don't know how to tell the IDE to use a .a file ? Any hints?

I ultimately just pasted the included .hdr file in each of the .S files to get the CAU sketch to compile.

The NXP/Freescale library only provides API to access the transform function for each of the crypto operations, additional coding would be required to manage multiple blocks, pad the hashes, and provide the various encryption modes (CCB, etc)

EDIT: an alternate build solution worked. i copied libcau.a to hardware/tools/arm/arm-none-eabi/lib/ and in boards.txt changed to
teensy35.build.flags.libs=-larm_cortexM4lf_math -lm -lcau
 
Last edited:
Xenoamor said:
Oh wow, I'm really excited for this one! 180MHz rated... I wonder how far we can push it!
Click to expand...

Good question. I did a little experimenting with 192 MHz, which seemed to work fine.

The chip actually has a special HSRUN mode for faster than 120 MHz. Freescale isn't very specific, but it appears to slightly increase the internal voltage regulation inside the chip. Like the VLPR modes, HSRUN has some restrictions about turning more things on/off. So far I haven't adapted code to follow these closely. This is one of several areas that'll take some time to get everything implemented fully.
 
defragster said:
Does this 'Beta Device' have a usable/official name?
Click to expand...

Actually, the name is one pretty big unresolved question at this point.

First, I want to put the kibosh on "4.0". This is very much a 3.x product. Sure, we're getting a big step up in performance, a FPU and a few awesome new peripherals, but this is still a Cortex-M4 that very similar to Teensy 3.2 with excellent compatibility. Perhaps "4.0" will be meaningful when we get a Cortex-M7 in 65 or 40 nm silicon.

Second, we're going to make this board in 2 versions, one with the K66 chip and another with a K64 chip. The main reason is 5V tolerance, which the K64 has but K66 does not. Other than max speed, memory size, and the extra USB host port, these 2 chips are very similar in feature set. So 2 names are going to be needed.

I've been leaning towards Teensy 3.4 and Teensy 3.5, which keeps 3.3 available for a possible upgrade of 3.2 to a faster chip but keeping the same 28 pin form factor. Earlier I was thinking "Teensy+ 3.x" and "Teensy++ 3.x".

Now's the time to go crazy with name ideas. ;)
 
Given the MCU has K66 chip and K64 chip how about: T_3.6 (K66) and T_3.4 (K64)?

That leaves room for a 5V T_3.4 upgrade to a T_3.5 as well?
 
PaulStoffregen said:
Now's the time to go crazy with name ideas. ;)
Click to expand...
Teensy 3.x HE (High end)
or
Teensy 3.x HP (High performance)
You could start with 3.0 HE for a fresh start or 3.2 HE (or HP) to keep it consistent with the current T3.2, and you won't run into already-taken names when upgrading the T3.2
The K64-based models could be named Teensy 3.x HE 5V or Teensy 3.x HP 5V.
 
Teensy 3.4, 3.6

defragster said:
Given the MCU has K66 chip and K64 chip how about: T_3.6 (K66) and T_3.4 (K64)?
Click to expand...
I agree- I like the idea of something like "Teensy 3.4". Simple and straightforward.

I won't say that the ++ nomenclature is double-plus-ungood, exactly, but it seems awkward to me.
 
I'd really like to see the updated boards.txt. Knowing about available F_CPU and more important, F_BUS values would greatly help me to prepare my test environment...
 
I like the simple 3.4 and 3.6. Or alternatively something like 3.45 and 3.4P for 5v versus performance.
 
PaulStoffregen said:
Second, we're going to make this board in 2 versions, one with the K66 chip and another with a K64 chip. The main reason is 5V tolerance, which the K64 has but K66 does not.
Click to expand...

A name that indicate the 5V tolerance /3 Volt only would make sense - easier for newbies and less questions (less destroyed teensys...)

edit: something like Teensy 3.3 3V, Teensy 3.4 5V ?
 
Last edited:
Frank B said:
A name that indicate the 5V tolerance /3 Volt only would make sense - easier for newbies and less questions (less destroyed teensys...)

edit: something like Teensy 3.3 3V, Teensy 3.4 5V ?
Click to expand...

I still think users will get confused, as it still runs at 3.3v, just the digital input pins can handle 5v. If you try to run ws2812b/neopixel or apa102/dotstar LEDs directly on the Teensy (or anything else that needs 5v data signal), it may not work. I tend to like KurtE's suggestion, perhaps adding a V or F suffix, i.e.
  • 3.4V (the K64 product that is 5v tolerant);
  • 3.6F (the K66 product that is fast).

Or maybe:
  • 3.64;
  • 3.66.
 
PaulStoffregen said:
I've been leaning towards Teensy 3.4 and Teensy 3.5, which keeps 3.3 available for a possible upgrade of 3.2 to a faster chip but keeping the same 28 pin form factor.
Click to expand...

For me, these names (Teensy 3.4 and Teensy 3.5) are fine, there is no real need for more complicated naming.
 
Easily confusing - T_3.2 compatible - but in a ++ size.

The more powerful one can't handle high 5V, but the lower speed unit is 5V tolerant like T_3.

At least having some ref to the CPU Model in the name K66 and K64 gives some SOLID reference when looking at MK64FX512 or MK66FX1M0 in the sources.

Also not having a T_3.5 with a '5' in for the not 5V tolerant makes sense, and models T_3.6 and over could all be the 3.3V only variants.
 
WMXZ said:
For me, these names (Teensy 3.4 and Teensy 3.5) are fine, there is no real need for more complicated naming.
Click to expand...

Originally I was thinking "++", but lately I've been leaning towards simplicity. Definitely not wanting to make the number complex with a suffix or extra digits.

Still undecided....

Ben said:
I added links to the relevant datasheets in Post #3 https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106275&viewfull=1#post106275
Can someone please confirm I picked the correct PDFs?
Click to expand...

Yes, those are the right ones.

Theremingenieur said:
I'd really like to see the updated boards.txt. Knowing about available F_CPU and more important, F_BUS values would greatly help me to prepare my test environment...
Click to expand...

I'll post a boards.txt file next week, when we ship the first 10 boards.

But F_BUS isn't in boards.txt. It's in kinetis.h, which you already have.
 
@paul, in mk20d128, you write:
"// config divisors: 180 MHz core, 60 MHz bus, 25.7 MHz flash, USB = not feasible"

Isn't it possible to use the IRC48 as clock for USB ?

Edit: The new chips are a chance to switch to higher F_BUS... some time ago we learned that F_BUS can be overclocked much much more..
Edit: I'll try to get 240MHz or more out of this beast.. :)
 
Last edited:
Status
Not open for further replies.
Back
Top