Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 63 FirstFirst 1 2 3 4 12 52 ... LastLast
Results 26 to 50 of 1559

Thread: K66 Beta Test

  1. #26
    Senior Member
    Join Date
    Nov 2015
    Location
    Wales
    Posts
    579
    Quote Originally Posted by MichaelMeissner View Post
    Though I suspect that for smart homes, the market has probably to wi-fi over wired ethernet.
    Ethernet to wifi adaptors exist. Or a USB wifi adaptor host could be written but I completely agree with you

  2. #27
    Senior Member fms1961's Avatar
    Join Date
    Jul 2015
    Location
    Northern Germany
    Posts
    148
    Quote Originally Posted by MichaelMeissner View Post
    Though I suspect that for smart homes, the market has shifted to wi-fi over wired ethernet.
    Indeed, but for development purposes, you will be happy to have an ethernet alternative to avoid the "chicken-and-egg-problem".

  3. #28
    Senior Member pictographer's Avatar
    Join Date
    May 2013
    Location
    San Jose, CA
    Posts
    624
    Quote Originally Posted by defragster View Post
    Does this 'Beta Device' have a usable/official name?
    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.

  4. #29
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    1,446
    I really like the idea of a Teensy F1 - like Formula 1

  5. #30
    Member
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    41
    Only use F1 if you want to be sued by Bernie

  6. #31
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,382
    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.

  7. #32
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,382
    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 by manitou; 07-03-2016 at 11:18 AM.

  8. #33
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,022
    Quote Originally Posted by Xenoamor View Post
    Oh wow, I'm really excited for this one! 180MHz rated... I wonder how far we can push it!
    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.

  9. #34
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,022
    Quote Originally Posted by defragster View Post
    Does this 'Beta Device' have a usable/official name?
    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.

  10. #35
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,087
    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?

  11. #36
    Member
    Join Date
    Jul 2013
    Location
    Colorado
    Posts
    86
    Quote Originally Posted by defragster View Post
    Given the MCU has K66 chip and K64 chip how about: T_3.6 (K66) and T_3.4 (K64)?
    +1 I was about to suggest the same.

  12. #37
    Senior Member Ben's Avatar
    Join Date
    Jul 2013
    Location
    Germany
    Posts
    401
    Quote Originally Posted by PaulStoffregen View Post
    Now's the time to go crazy with name ideas.
    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.

  13. #38
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,087
    Quote Originally Posted by defragster View Post
    Given the MCU has K66 chip and K64 chip how about: T_3.6 (K66) and T_3.4 (K64)?
    Quote Originally Posted by fretless_kb View Post
    +1 I was about to suggest the same.
    Since PJRC already has history with the T2 and T++2 :: perhaps T++_3.6 and T++_3.4 would be better?

  14. #39

    Teensy 3.4, 3.6

    Quote Originally Posted by defragster View Post
    Given the MCU has K66 chip and K64 chip how about: T_3.6 (K66) and T_3.4 (K64)?
    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.

  15. #40
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    1,446
    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...

  16. #41
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,428
    I like the simple 3.4 and 3.6. Or alternatively something like 3.45 and 3.4P for 5v versus performance.

  17. #42
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,392
    Quote Originally Posted by Theremingenieur View Post
    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...
    https://github.com/PaulStoffregen/co...y3/mk20dx128.c
    look for __MK66FX1M0__

    You can make your own boards.txt..

  18. #43
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,392
    Quote Originally Posted by PaulStoffregen View Post
    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.
    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 by Frank B; 06-10-2016 at 06:26 PM.

  19. #44
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,628
    Quote Originally Posted by Frank B View Post
    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 ?
    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.

  20. #45
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,633
    Quote Originally Posted by PaulStoffregen View Post
    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.
    For me, these names (Teensy 3.4 and Teensy 3.5) are fine, there is no real need for more complicated naming.

  21. #46
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,087
    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.

  22. #47
    Senior Member Ben's Avatar
    Join Date
    Jul 2013
    Location
    Germany
    Posts
    401
    I added links to the relevant datasheets in Post #3 https://forum.pjrc.com/threads/34808...l=1#post106275
    Can someone please confirm I picked the correct PDFs?

  23. #48
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,022
    Quote Originally Posted by WMXZ View Post
    For me, these names (Teensy 3.4 and Teensy 3.5) are fine, there is no real need for more complicated naming.
    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....

    Quote Originally Posted by Ben View Post
    I added links to the relevant datasheets in Post #3 https://forum.pjrc.com/threads/34808...l=1#post106275
    Can someone please confirm I picked the correct PDFs?
    Yes, those are the right ones.

    Quote Originally Posted by Theremingenieur View Post
    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'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.

  24. #49
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,392
    @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 by Frank B; 06-10-2016 at 09:06 PM.

  25. #50
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,382
    EEPROM looking at eeprom.c, it appears K64/K66 will have 4KB of flash EEPROM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •