Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 63 FirstFirst 1 2 3 4 5 13 53 ... LastLast
Results 51 to 75 of 1559

Thread: K66 Beta Test

  1. #51
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,509
    Yes, the manual confirms this.

  2. #52
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,584
    teensy3/analog.c : I may not be looking at the latest github file, but it doesn't seem that analogWriteDAC0 is defined for K64/K66, nor is the pin mapping set up for the internal ADC channels (temperature, VREF). When the K66 arrives, the truth will be revealed.

    EDIT: I was wrong. ugly hack does map K66 to teensy 3 internal pins OK.
    Last edited by manitou; 06-17-2016 at 11:24 PM.

  3. #53
    Senior Member
    Join Date
    Oct 2012
    Location
    Portland OR
    Posts
    582
    "Ethernet MAC with IEEE 1588 capability" is very cool. I've got a good collection of embedded devices with ethernet, but AFAIK I don't currently own any capable of IEEE 1588 (which apparently can achieve sub-microsecond time synchronization across a LAN). I do not actually have an application for that capability, but just thought it was interesting.
    Last edited by JBeale; 06-11-2016 at 01:03 AM.

  4. #54
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,831
    Paul - the Beta boards will be the K66 - will they have SD socket and other expected shipping hardware config mounted ? Any open 'ports' that might need added hardware to use - like Ethernet? Just wondering what extra hardware might be good to have on hand, and wondering how to plan to set it up.

    Batch one [ (approx 3x3 inch) board with the TQFP version of the chip, with sockets at the intended final form factor ] will fill and obscure half a 2"x6" protoboard. Perhaps two of those mounted side by side for usable pin area? Will the underside pads be present, and in your expected locations (i.e. T-3.2 layout, added pads)?

  5. #55
    Senior Member
    Join Date
    Jan 2013
    Posts
    154
    Quote Originally Posted by defragster View Post
    Just wondering if there was a simple fun thing to do with the FPU I came across this with some functional notes:
    10 useful tips to using the floating point unit on the ARM« Cortex«-M4 processor
    { and license required Fast FP for ARM and Thumb2: GoFast Floating Point Library - Micro Digital }
    Thanks for posting this!

  6. #56
    Senior Member
    Join Date
    Jan 2013
    Posts
    154
    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.
    Me too. Simple is good. Remember that we are going to be typing and speaking the name a lot.

  7. #57
    Junior Member
    Join Date
    Apr 2015
    Posts
    10
    Quote Originally Posted by PaulStoffregen View Post
    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.
    I Paul, just hearing about this offering. That description above kinda says this isn't your basic 3.x product. You are suggesting a serious number of enhancements over the previous iterations. You might end up confusing customers if you try to sell it as another 3.x board.

    I don't have a good suggestion for names but when it comes to dogs I love Husky's. They just love to run and run.
    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'd rather see 5 volt tolerance accomplished in some other fashion. Honestly I'd like to see some buffered I/O with the idea of supporting such uses as step and direction to stepper motor controllers. Maybe 8 bits with such buffering. 3.3 volt I/O isn't a big deal for many of the pins. However if you want to drive some of the larger commercial stepper drives you can really benefit from 5 volt buffered outputs.

    The other problem is having two boards that are almost identical except for voltage tolerance leave with bad vibes. I would go with one or the other to avoid people accidentally destroying the boards.
    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".
    If you change the number of I/O pins it is even less of a 3.x device. In any event "++" is a no go for search engines. At least it has been in many cases when searching for C++ related materials.

    Speaking of I/O pins I would love to see far more available. I don't know what your intentions are here but 44 pins would be a nice bump (16 more pins). . If they are arranged linearly so we can use breadboards or other prototyping solutions to get to all I/O pins it would be golden.
    Now's the time to go crazy with name ideas.
    Yeah I wish I had some good ideas, El Capitan is already taken. If the board does indeed have more pins then we need to look for something that suggests a larger fatter Teensy. How about Teensy BigFoot as more pins implies a bigger board.

  8. #58
    Junior Member
    Join Date
    Apr 2015
    Posts
    10
    Quote Originally Posted by PaulStoffregen View Post
    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....
    It is kinda funny because I was prompted to visit the forum due to a thread I was involved in over on Reddit. Part of the discussion concerned I/O as I was hoping you guys had a board in the works that would be ideal for CNC use. My thought over there was I/O pins, really outputs, dedicated to step and direction with 5 VDC tolerance. This plus more I/O in general.

    In any event I'm off on a tangent here. In another post you implied more I/O (hope this is true) which implies more pins. Honestly the more the better as long as you avoid expensive high density connectors. The point I'm getting at here is that you really need to define a new board format, effectively another standard for larger devices. The low pin count Teensy 3.x series is great until you need more I/O. I'd like to see at least 16 more pins with all pins dual inline for easy breadboard use and ideally plug gable into a standard IC socket. The new format should have only one voltage tolerance level.


    Yes, those are the right ones.



    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.

  9. #59
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,831
    Quote Originally Posted by wizard69 View Post
    I Paul, just hearing about this offering.
    Check out the now passÚ 22 page wishlist: Any-Chance-of-a-Teensy-3-1


    "Well, it's a little late for this kind of feedback"
    Bill Murray - Scrooged (1988)

    Quote Originally Posted by wizard69 View Post
    I'd rather see 5 volt tolerance accomplished in some other fashion.
    The 5V tolerance is native to the Processor - just like the current Teensy 3.1 and 3.2 (not the T_3.0)- it is only the K66 that loses this in trade off for faster/fuller featured CPU - Paul made a great explanation of related issues in a recent post.
    Last edited by defragster; 06-11-2016 at 08:03 AM.

  10. #60
    Junior Member
    Join Date
    May 2016
    Posts
    1
    Hi All,
    first of all sorry if my questions are out of topics but I am not really an expert.
    I am using the teensy 3.2 for my projects and I am very curios and interested in this new board.
    Will it have a battery management chip?
    Something like :
    https://www.tindie.com/products/oneh...for-teensy-31/

    This is very helpful and will simplify the life to people coming more from software that want to use the Teensy for some wireless project.
    It will be even better if a version of the board will add some wireless connectivity to allow a mesh of wireless teensy to comunicate. For example a version with NRF24L+

    Finally my take on the name: I will strongly prefer Teensy 4/Teensy 4 5v to Teensy 3.5/Teensy 3.6.
    Having a little fun I will suggest Teensy One, I like it because reading One in Italian is the augmentative form of the name, will be something like Mega Teensy but more on the fun side.

  11. #61
    Junior Member
    Join Date
    Apr 2015
    Posts
    10
    Quote Originally Posted by defragster View Post
    Check out the now passÚ 22 page wishlist: Any-Chance-of-a-Teensy-3-1

    I can see I don't spend enough time on the forums, never saw that.

    The 5V tolerance is native to the Processor - just like the current Teensy 3.1 and 3.2
    Yes that is why I mentioned 8 bits of buffered outputs. You can read buffers as level shifters if you want.
    (not the T_3.0)- it is only the K66 that loses this in trade off for faster/fuller featured CPU - Paul made a great explanation of related issues in a recent post.
    Honestly I'm a strong believer in one or the other here. Especially if the board will be standardizing a new foot print. Frankly long term what is on the board isn't as important as what the boards foot print is. The chips may change in the future but you really can't have the functions of the pins changing. Changing the voltage tolerance is changing the functions of the pins. This is bad for third party boards. Having one well defined set of pins for 5VDC interfacing is one way to deal with this but other wise 3.3 VDC interfacing is a smarter move.

  12. #62
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,831
    To the best of Paul's ability - and my memories from excessive time reading here - that linked thread should suggest this: The pins common to the T3.1/T3.2 will be functionally similar with the K64 including 5V tolerance - the K66 processor version offers the same layout and more horsepower and capacity, but the processor to do that loses all 5V tolerance. All new and added pins from the new processors are in the extended one inch area beyond the T3.x pin area. Both are expected to be drop in replacements for the T_3.2 - but longer, except when 5V is present. That's probably why two boards at once - only room for level shifters is external to Teensy

  13. #63
    Mostly compatible teensy-family plus new prozessor family/typ plus boardversion:

    3.64.0
    3.66.0

    (No version 3.6 or higher ever)

  14. #64
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,509
    Buffers: Maybe, but most users don't need level-shifters, so why add them (?) That's a perfect task for add-on boards.

    Footprint: The footprint will be compatible (Like with the Teensy LC which is not 5V tolerant, too)- But having a fixed footprint which never changes means no development, no progress.. no way to add new features. Ok, this might be important for industry, but where's the point for hobbyists (and the Teensy is a product for hobbyists, today called "makers")
    The past discussions showed that most users want new features, more pins, more xyz.. all that would'nt be possible .

  15. #65
    Junior Member
    Join Date
    Apr 2015
    Posts
    10
    Quote Originally Posted by Frank B View Post
    Buffers: Maybe, but most users don't need level-shifters, so why add them (?) That's a perfect task for add-on boards.
    Possibly! In my case I'm thinking in terms of hardware to control a wide variety of step and direction stepper drives.
    Footprint: The footprint will be compatible (Like with the Teensy LC which is not 5V tolerant, too)- But having a fixed footprint which never changes means no development, no progress.. no way to add new features. Ok, this might be important for industry,
    I don't buy this! A well defined I/O foot print is very good for hobbiest. It means a wide array of daughter cards are possible and can be affordable made. Think about Arduino here a well defined and maintained foot print is exactly why so many Arduino cards are in circulation right now. It means hobbiest can buy just about any board they need and plug it in reliably. Think about why some of the older cards are preferred to some of the less popular cards that have come out of Arduino.cc.
    but where's the point for hobbyists (and the Teensy is a product for hobbyists, today called "makers")
    This is so simple a wide array of daughter cards that are always pin compatible.

    I can understand the need to expose new features in new controllers down the line. This however needs to be done in a way that doesn't invalidate the original standard.
    The past discussions showed that most users want new features, more pins, more xyz.. all that would'nt be possible .
    More pins is exactly what this new foot print provides from what I can see. All I'm saying is don't be changing pin functionality down the road after releasing this new design. Rather make sure it is right from the start. If new features are to be offered down the road, add a header for,users to plug into, or do something else that doesn't trash third party boards. If needed define an exclusion zone for third party makers that future Teensy's can grow into. In the end what I'm concerned about is all of those third party boards that hopefully will find their way to these new Teensy's.

    By the way there is an additional reason to get away from the Teensy 3.x family naming. It makes it easier for third party board makers to indicate compatibility and reduce confusion. Teensy Bigfoot implies something physically different than Teensy 3.x for example.

  16. #66
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,652
    Sorry, but I am personally trying to understand what the argument is here?

    There has been lots of discussions on the thread Any-Chance-of-a-Teensy-3-1

    I am pretty sure Paul understands the idea of trying to keep things compatible, which is why he has mentioned that the pinout for this board will be as close to compatible with the Teensy 3.2. The chip will be something like an inch longer and the new functionality with new pins and new functionality.

    Personally I like the idea behind the two different boards. If I want +5v compatibility I will use that one. Note: I earlier shied away from Teensy 3.0 as it did not have this, but as things change and more boards and sensors are 3.3v, there are now many times when 5v may not be necessary.

    My assumption is that the pinouts will be the same for the two chips, however some of the pins may have additional functionality, example USB host.

    As for adding in Level shifters on board, personally I am not sure that would be a great idea, other than potentially adding 1 or 2 output level shifters to +5v for Neopixel and/or Dotstar, like the LC.

    But again this is a trade off, if you only have N pins exposed from the chip how many do you want to sacrifice for this? Also there are now many cases where I want 3.3v IO pins, for example when I talk to an XBee or maybe connect the IO pin to RPI.

    In many cases I have seen general purpose level shifters being problematic. There have been many threads about problems with level shifters, like some don't work well with I2C, or some don't work well with Pull up resistors, or they are too slow. Also I have seen some other boards like Edison Arduino board, where you need to configure the level shifter from input to output (trying to remember if I2C or SPI), and to do this was so slow, that you could not reliably use a ping sensor...

    At this point I am assuming that the board designs are complete and only if issues are found in the first rounds of testing will there be any modifications made.

    Once some of this testing is done, I will probably play around with building my own adapter board(s).

    Should be fun!

    Kurt

  17. #67
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,785

    Cool

    To quote from page 21 of the thread about a then possible K66 (https://forum.pjrc.com/threads/24633...nsy-3-1/page21):

    Quote Originally Posted by PaulStoffregen View Post
    I'd like to ask everyone following this thread to refrain from creating illustrations or mock-up images. Please keep the conversation here on this forum thread, and please do not repost this info on social networking sites. Teensy is still nowhere near the scale and need for new product secrecy of Arduino. But we are at the point where new products are newsworthy for sites like Makezine & Hackaday, which is the main reason I've asked everyone to refrain from photos during beta tests.

    Yes, that's still the plan, for a total PCB size of 2.4 by 0.7 inches.

    The 28 pins on the left side will retain close compatibility with Teensy 3.2. The 20 new pins will add 3.3V (next to pin 12) and GND (next to pin 13), and digital pins 24 to 39 with analog on 31-39, and two analog-only pins for DAC0/A19 & DAC1/A20.

    Most of the new left-side area will be occupied by a SD socket, with fast 4-bit SDIO bus, which is not shared with SPI or any other normally used pins.

    A location solder a 5 pin through-hole header is planned, for the 2nd USB port (with 480 Mbit/sec speed & USB host mode). The pinout will be the same as 5 pin USB headers on PC motherboards, so you can add a header and plug in a commonly available USB front-panel cable. This is likely to be located close to pins 2-6.

    Double rows or other changes in form factor are not planned. Best possible pinout compatibility with Teensy 3.x & LC is a major goal.
    Given DAC0 will be moved out to the outer rows, and given a new pin # (A19 instead of A14/A12), I would suspect the back row (DAC, Program, Ground, 3.3v, Vbat) will disappear. This would mean for the prop shield, you would need to solder a wire to connect to the shield DAC pin. Some of onehorse's shields that use the back ground/3.3v pins would have to be similarly connected with wires.

  18. #68
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,317
    Quote Originally Posted by KurtE View Post
    At this point I am assuming that the board designs are complete and only if issues are found in the first rounds of testing will there be any modifications made.
    Yes, exactly. While I do not wish to censor any conversation, the hardware design is pretty much fixed at this point and not really up for discussion. Indeed those conversations have already occurred many, many times. Especially to achieve Teensy's small form factor (2.4 by 0.7 inch for this one), quite a few compromises had to be made.

    This beta test is really about software. Plenty of things are still in need of porting. New peripherals like the SDIO are not yet supported at all, and my hope is to work on those over the coming weeks, with your help beta testing.

  19. #69
    Senior Member Ben's Avatar
    Join Date
    Jul 2013
    Location
    Germany
    Posts
    401
    Quote Originally Posted by PaulStoffregen View Post
    New peripherals like the SDIO are not yet supported at all,[...].
    Your post made me realize that the K66 features an SD host controller. Will accessing an SD card through this controller speed up the access times and read/write speeds to a level where SPI flash will be obsolete for audio effects (delay)?

  20. #70
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,317
    SDIO will speed up the portion of SD card access where a block of data is transferred. Today that part occurs at nearly 3 Mbyte/sec speed (SPI clocked at 24 MHz). In theory, the raw data transfer might increase to 24 MByte/sec, using 4 bit mode clocked at 48 MHz.

    But with many SD cards, the raw data transfer is only about half of the time spent. The other half involves some overhead and mostly just waiting for the card. So today we get about 1.5 Mbyte/sec overall speed. If all the 50% overhead stays the same and data movement becomes 8X faster, you can expect about 2.7 Mbyte/sec overall speed. With a fairly "simple" replacement of the SPI code with SDIO in 4 bit, this is the likely speedup.

    Perhaps some cards will respond faster in SDIO mode. I've heard people argue this from time to time, but so far I've never seen anyone back that up with actual measurements. I'm a bit skeptical.

    Of course, much more might be possible with a massive redesign of the Arduino SD library. Perhaps some (most) cards respond with very little extra delay when multi-sector reads are used. Again, I've heard this said, and based on when I know of the cards and protocol, I believe this is very likely true. But to make use of it, quite a lot of memory will be needed for caching.

    Likewise, with speculative read-ahead and delayed writing (even more memory for caching) and DMA to perform transfers while other code runs, perhaps even more speedup could be achieved in practical usage scenarios. But that's even more dramatic changes to the code.

    I do want to eventually try all this... but I'm doubtful we'll ever get close to the theoretical speed of sustained 24 MByte/sec transfer for real applications which actually do something with the files they're reading or writing.

  21. #71
    Senior Member
    Join Date
    Mar 2013
    Posts
    643
    Ok, now that im done screaming like a little girl.....
    I thank you for including me in the beta, but at this time I am not sure what assistance I could offer. I would like to be placed at the end of the line so that those with better coding/library abilities can get these first.

    Im not sure I could warrant the cost of the board + shipping without a clear goal for the testing(I am however a RL test tech). I have zero skills when it comes to digging into the Kinetis datasheets. I have failed on many occasions to de-crypt them. I am mainly a HW guy who when a gun is placed against his head can do C coding (could not write a library to save my life).

    On a lighter note, you mention needing memory for caching for high speed Sd Cards. Could the Flexbus/SDRAM controller in the K66 help in that regard ? (think i recall you saying they could not be brought out or they did not work as advertised)

    Have the ADC's improved any or do we still have a 16Bit ADC that cant do more then 12-13bit? I have a CC Dummy Load project that may start using 13Bit if I can get enough clean values from it.

    PS, the more I look the more ideas for future/current projects pop into my head. Who needs a life anyway lol.

  22. #72
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,831
    Paul: Is it correct that SD reader is attached on unique SPI that will work on Beta_K66 and can evolve to SDIO pins already selected and wired?

    Maybe the SDIO will keep the SD from boredom and faster not parsing out single bits and the 50% overhead will drop, as well as the bonus 4X bit throughput with less traffic and we'll be surprised.

    Excited for next week and K66 to get here to see what the 9 sq in beast looks like to hook it up!

    Donziboy2 - I think the RAM was buffer space - hard to carve out of 64KB - RAM not so critical with ~4X on hand?

  23. #73
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    SDIO in 1 bit mode is faster than SPI. But SDIO shines when you implement the 4 bit mode and of course DMA on all this.
    Most all SDIO uses 4 bit mode. So it's wise to wire up those bits and not try to use those pins off-board.
    The protocol and the data are on different serial data paths to eliminate overhead in addition to the parallel transfers.
    I'm using SDIO on the Cortex M4 from ST, plus FAT FS. The DMA/SDIO driver and FATFS for this were from ST - plug and play. Maybe same from NXP?
    Last edited by stevech; 06-12-2016 at 04:36 AM.

  24. #74
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,792
    Hi, have time to beta test against the assorted break out boards and parts around the place but not deep enough in the software world to usefully contribute libraries for this so prioritise accordingly. Also the wrong part of the world for sensible speedy shipping.

  25. #75
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,584
    Here are some library .cpp files that have conditional for MK20DX256 but not yet for MK66FX1M0 (nor K64)

    Code:
         TFT_ILI9163C.cpp
         Adafruit_ST7735/Adafruit_ST7735.cpp
         FastCRCsw.cpp FastCRChw.cpp
         RH_NRF905.cpp
         RA8875.cpp
         OSCTiming.cpp
         XBee.cpp
         UTFT.cpp
         OctoWS2811.cpp
         i2c_t3.cpp

Posting Permissions

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