K66 Beta Test
- Thread starter Paul
- Start date
- Status
manitou
Senior Member+
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.
EDIT: I was wrong. ugly hack does map K66 to teensy 3 internal pins OK.
Last edited:
"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:
defragster
Senior Member+
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)?
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)?
Thanks for posting this!
Me too. Simple is good. Remember that we are going to be typing and speaking the name a lot.
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.
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.
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.
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.
defragster
Senior Member+
Check out the now passé 22 page wishlist: Any-Chance-of-a-Teensy-3-1
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:
stefano.ant
New member
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/onehorse/lipo-battery-charger-add-on-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.
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/onehorse/lipo-battery-charger-add-on-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.
I can see I don't spend enough time on the forums, never saw that.
Yes that is why I mentioned 8 bits of buffered outputs. You can read buffers as level shifters if you want.
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.
defragster
Senior Member+
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
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 .
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 .
Possibly! In my case I'm thinking in terms of hardware to control a wide variety of step and direction stepper drives.
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.
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.
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.
KurtE
Senior Member+
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
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
MichaelMeissner
Senior Member+
To quote from page 21 of the thread about a then possible K66 (https://forum.pjrc.com/threads/24633-Any-Chance-of-a-Teensy-3-1/page21):
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.
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.
PaulStoffregen
Well-known member
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.
Ben
Well-known member
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)?
PaulStoffregen
Well-known member
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.
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.
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.
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.
defragster
Senior Member+
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?
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?
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?
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:
GremlinWrangler
Well-known member
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.
manitou
Senior Member+
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- Status