K66 Beta Test

Status
Not open for further replies.
A true wiki still on the list for scheduling . . . "Wiki-Coming-Please-link-worthy-posts" but a bit much for now. I suggested a "Semi-Wiki"/Thread as one where Beta users could make/edit one post on a (2nd K66 Beta) thread exclusively for that - so the posts might get long - but would be a dedicated summary of open and closed issues without banter or the real answer 'x' posts away. Non-Beta user posts would get spammed away - (OP could be a maintained index of general subject area links to posts) - not a real wiki but would allow whatever portion of the ~80 folks getting boards to get/stay up to speed in one place.

I totally agree, it is getting out of hand. :)
Hopefully this will be resolved soon, because I am wondering if the UHS3 posts are getting lost in the sauce.
FWIW, all the boards should be able to support the USB HOST feature on the "normally uploading" port.
I have not tried it yet, and this may need a few adjustments.
Paul asked me a while ago for the K66 EHCI support, and I am working on that in my spare time now.
 
<SNIP>
Have you given my improved fat filesystem a try? Although it is "geared" for USB, it should be able to drive an SD card driver front end. All you would need to do ins provide a few hooks, and present it to it, and it will work with it. This is better than having to use the included SDcard stuff, since it ends up as an abstraction layer. It also has some major bug fixes. For example, the old code doesn't update the other copies of the FAT tables, mine does, and eliminates a lot of the corruption problems people have seen when writing.
I have not done so, I was mainly doing the SD test to help see if the problems being seen were specific to one board/SD-card or if mine would have the same issue.

But I can run tests on new FS driver. It is probably posted somewhere in this thread, but are there instructions on where to get drivers and tests to be run?

Thanks
 
SUB speed on the K66 variant

USB on the K66,

I see the data sheet says K66 can do High Speed ( 480 Mb/s ) USB 2.
which I think is the first Arduino that can, certainly the first Teensey,

Is the Teensey K66 going to be able to work at the USB 2, HS mode ?
 
I totally agree, there is about 10 concurrent conversations going on in this thread... Thread? Wiki? One option might be to convert the thread into a forum. i.e. create a new top level forum called something like Beta test... Maybe have one or a few threads which are summary threads, and then maybe try to breakout several threads by major sub-systems... SDCard, Net, Serial, ... Maybe add a few trusted people as Moderators, who can edit postings.

Potentially make the forum private. Only people who are added by Administrator can actually see the forum. A few years ago we had a few of these forums up on Lynxmotion. Then you could post pictures and the like.

As for my yesterdays posting about using the SDCard IO pins... I have edited the SPI code including the library and the avr_emulation, as to allow you to use the SPI1 pins that are on the SDcard pins... I also did a quick hack to ILI9341_t3, to allow me to use the SPI1 object and the right set of SPI registers (KINETISK_SPI0 vs KINETISK_SPI1). I have tried hooking up an Adafruit ILI9341 display to these pins. Not working yet. I am pretty sure I know why.
Looking again at SPI specs, like section 57.1.4 you see SPI0 has fifo of 4 entries. SPI1 and SPI2 have fifo of 1 entry. And the ILI9341 code has stuff like:
Code:
	//void waitFifoNotFull(void) __attribute__((always_inline)) {
	void waitFifoNotFull(void) {
		uint32_t sr;
		uint32_t tmp __attribute__((unused));
		do {
			sr = ILI9341_KINETISK_SPI.SR;
			if (sr & 0xF0) tmp = ILI9341_KINETISK_SPI.POPR;  // drain RX FIFO
		} while ((sr & (15 << 12)) > (3 << 12));
	}
Which won't work here... as we are looping while we have more than three items here (i.e. 4 entries), I will try to parameterize these tests as well, but may find may need other tests instead... Also may find performance may not be much better than just using Adafruit driver...

May try the Adafruit driver, but will need to also hack up pinMode and digitalWrite to handle pin numbers: 0xe0-0xe5...
 
I have not done so, I was mainly doing the SD test to help see if the problems being seen were specific to one board/SD-card or if mine would have the same issue.

But I can run tests on new FS driver. It is probably posted somewhere in this thread, but are there instructions on where to get drivers and tests to be run?

Thanks

https://github.com/felis/UHS30
For SD card, "some code needed", however I will point you to exactly what you need to do.

First, note there is a recursive structure
https://github.com/felis/UHS30/blob/master/libraries/UHS_FS/UHS_FS.h#L38-L50
and that you can use a C hook to C++ code like so:
https://github.com/felis/UHS30/blob/master/libraries/UHS_FS/UHS_FS.h#L38-L50
This is where you would implement SDcard, simply model it after what is above the comment:
https://github.com/felis/UHS30/blob/master/libraries/UHS_FS/UHS_FS_INLINE.h#L234

I hope that provides enough clues for you. Let me know if you run into any problems and I will try to help.
You may need to poll manually, unless the SD card stuff can provide you with an IRQ. If it does, use the DYN_SWI.
You will also want to use the ISR safe malloc hooks.

As is it will work on the native programming port on all teensy 3.x, even the LC.
 
Last edited:
I see the data sheet says K66 can do High Speed ( 480 Mb/s ) USB 2.
which I think is the first Arduino that can, certainly the first Teensey,

Yes, the first Teensy with 480 Mbit/sec USB. Arduino Due's native port uses 480 Mbit/sec, but the software Arduino has published isn't capable of achieving this speed in practice. Whether Teensy will really be able to keep up with 480 Mbit/sec speed is also a good question...

Is the Teensey K66 going to be able to work at the USB 2, HS mode ?

There's actually 2 USB ports on the K66. The USB connector on the PCB will be the same 12 Mbit/sec port as Teensy 3.2. A second port will be meant for USB host at 480 Mbit/sec. On the round 1+2 betas, it actually a type A host port. On the final boards, it will be 5 pads meant for soldering a header to plug in a standard PC internal USB2 cable.


Paul asked me a while ago for the K66 EHCI support, and I am working on that in my spare time now.

I did some initial experiments, but so far only managed to get the ports to reset and enable. So far, no actual USB packets, but I had to put it aside for ethernet and lots of other more urgent stuff. Wish I could help more on the EHCI stuff. I'll do more later, if nobody else gets to it first.
 
https://github.com/felis/UHS30
For SD card, "some code needed", however I will point you to exactly what you need to do.
...
Thanks, will try to take a look tomorrow


As I mentioned, I have been playing with SPI1 and being able to use the IO pins on the SDCARD adapter. Today I have had some luck now being able to run the ili9341_t3 code on SPI1 using these pins.
Took a little work as there were lots of places assuming SPI0 and fifo of 4...
I don't expect it to be as much of a speed demon as on SPI0 as FIFO of 1, but visually looks like it is still working reasonably...
Code:
ILI9341 Test!
CS: E5
CS: E4
Display Power Mode: 0xDA
MADCTL Mode: 0x24
Pixel Format: 0x2
Image Format: 0x0
Self Diagnostic: 0xE0
Benchmark                Time (microseconds)
Screen fill              224746
Text                     11305
Lines                    58697
Horiz/Vert Lines         18378
Rectangles (outline)     11678
Rectangles (filled)      467331
Circles (filled)         68990
Circles (outline)        53572
Triangles (outline)      14100
Triangles (filled)       153631
Rounded rects (outline)  24509
Rounded rects (filled)   509561
Done!
If anyone is interested, I pushed up the current changes up to github in a new branch (T35_USE_SDCARD_PINS) for the projects: core, spi and ili9341_t3. Warning, I left the ili... in this branch setup for SPI1. Wish there was an easy way to configure SPI vs SPI1... In a program and not be editing library header file... Might also be nice to be able to run two of these displays on same board...

I also hacked up the graphic test program to allow me to use these pins:
Code:
// For the Adafruit shield, these are the default.
#define TFT_DC  0xe4
#define TFT_CS 0xe5

// Use hardware SPI (on Uno, #13, #12, #11) and the above for CS/DC
// 
// Tell system to use default pins
ILI9341_t3 tft = ILI9341_t3(TFT_CS, TFT_DC, 11, 255, 255, 255);

void setup() {
  Serial.begin(9600);
  while (!Serial) ; // wait for Arduino Serial Monitor
  Serial.println("ILI9341 Test!"); 

  SPI1.setSCK(0xe2);
  SPI1.setMISO(0xe3);
  SPI1.setMOSI(0xe1);
  tft.begin();
  tft.fillScreen(ILI9341_BLACK);
...
Note, in this case I moved the Serial print stuff to start, so I could print out debug stuff in the tft.begin() code.
Also in the ILI library, I changed the code that if 255 was passed in for SCK/MISO/MOSI - It used whatever they are current defined on... Maybe should be default.

Anyway having some fun!
 
Yes, the first Teensy with 480 Mbit/sec USB. Arduino Due's native port uses 480 Mbit/sec, but the software Arduino has published isn't capable of achieving this speed in practice. Whether Teensy will really be able to keep up with 480 Mbit/sec speed is also a good question...
Considering I had to slow down host mode when going over a hub (because of TT), I think it can, especially since the packet size grows to 1024. For storage, that means 1 microframe per sector... should be able to get some really good speeds.

I did some initial experiments, but so far only managed to get the ports to reset and enable. So far, no actual USB packets, but I had to put it aside for ethernet and lots of other more urgent stuff. Wish I could help more on the EHCI stuff. I'll do more later, if nobody else gets to it first.

I'm going to have time to do quite a lot tonite. I'm done for the day, after 16 hours of work I need a nap first. I'll put in a couple hours into it and we'll see what I come up with.
 
I've been wondering if the Teensy can be used to a vocoder effect. About a week after I received the K66 I came across this diagram of a channel vocoder and thought that it could be done on the K66. Since then I've been working away at implementing a channel vocoder based on that diagram and I think I have finally squashed the last of the bugs.

The sketch has 16 channels, which requires so many objects and connections that even a small change can require a lot of editing. To make life easier, I wrote a TCL script which generates the objects, connections and some supporting functions from a template text file.
At the moment, the "carrier" signal is one of a few brief samples built-in to an array in the sketch but the "modulator" signal can be:
- a WAV file on the uSD card.
- input from a microphone (not tested very much)
- input from the line in (not tested at all)
The output can go to
- the headphone (and line out)
OR
- the flash chip on pin 6 (using SerialFlash), and from there to a WAV file on the uSD card. In this case the input must be a WAV file on the uSD.

Example:
See this page for an example carrier file and modulator file. The output of his vocoder produces this. I edited the carrier file down to a clip of about 0.2 seconds and the vocoding procedure of the two programs is entirely different but I think the output produced by my vocoder sketch is pretty good.

For something completely different have a listen to this file which is the result of vocoding a carrier clip of a pipe organ with a recording of me saying a few important words.

I hope to have the code hammered into shape for distribution in a day or two.

Pete
 
... Currently SPI1 only has one CS pin available ...

KurtE - I wanted to move a single TFT_ILI9163C to SPI1 - is that possible? Or do D/C and CS both need to come from the approved list where only one pin exists? Perhaps there was a better post somewhere - but this seemed close enough to perhaps explain why it isn't working?

Paul: about a second K66 discussion Semi-Wiki thread. Would it be okay to create a non-discussion thread ( same caveats as per the OP ) that was only a list of links to this thread as maintained by the Beta Poster on this K66 thread. Looking like the 'Wiki Coming - Please link worthy posts' thread

Though in writing this - such a summary info presentation may be what you foresaw as a double edged sword ahead of its time ... dang the bad guys, you just can't have nice things.
 
KurtE - I wanted to move a single TFT_ILI9163C to SPI1 - is that possible? Or do D/C and CS both need to come from the approved list where only one pin exists? Perhaps there was a better post somewhere - but this seemed close enough to perhaps explain why it isn't working?

Defragster, it should work!
This library uses the same SPI FIFO of t3_ILI9341.
Thanks Kurt for the overall work on SPI, I was working last week and followed every update, tested as well between all Teensy's to be sure nothing broken and I have to say, all is apparently working till now.
 
Hi defragster and sumotoy,

TFT_ILI9163C on SPI1: You probably have a couple of choices on how to make it work. Without using the extra pins of the SDPort, you only have one CS pin, so you can pick off this case and go the slower route, like you have for Teensy LC and use SPI1.transfer(x) and manage the CS/DC pins directly.

Or if you wish to use the extra pins, you now have 3 valid distinct CS pins on SPI1, so then you can use some of the faster access. However you then run into assumptions in the code that the SPI queue is 4 entries long, which it is for SPI0, but not for SPI1 or SPI2, which only have a queue of 1.

So you run into issues like in the function:
Code:
//Here's Paul Stoffregen magic in action...
		void waitFifoNotFull(void) {
			uint32_t sr;
			uint32_t tmp __attribute__((unused));
			do {
				sr = KINETISK_SPI0.SR;
				if (sr & 0xF0) tmp = KINETISK_SPI0.POPR;  // drain RX FIFO
			} while ((sr & (15 << 12)) > (3 << 12));
		}
Where the 3 << 12 is checking for more than 3 entries... So I changed all of these to use a #define for QUEUE size - 1. Also you need to update the code that checks valid pin numbers
My quick check through the code, I did not notice any read like functions, but if there are, you may need to check those to make sure you are not depending on more than 1 return item begin queued up...

Likewise in that function, you need to setup for SPI1 vs SPI0. I defined a #define for which KINETISK_SPI I was using. Which in the above function, you needed to use to get the SR as well as the POPR... And in some other functions you will see things like: SPI0_MCR = mcr;
And you need to change those as well to something like above: KINETISK_SPI0.MCR where you again change which KINETISK_SPIn you are using.

As I mentioned, all of my changes for the ILI9341 are up on github if you wish to take a look.

What I would also like to be able to try out is to make a version of the SPI library, where we make a base class like: SPIClass which is probably mostly pure virtual and then we create sub-classes for SPI0 (SPI) and SPI1 and maybe SPI2 (if the optional bottom pins are actually making it on the board? Paul?). Then in some of these libraries, I would hold onto a Pointer to the appropriate SPI object as well as a pointer to the KINETISK_SPIx object and can compile for multiple instances. It will be interesting to see how much of a perf hit this would be to add call indirects for many of these functions that are now static inline functions. I can probably hack up a version that uses my quick and dirty SPIN object which tests a variable and then either does the SPI or the SPI1 code. Not sure if it would be faster or slower than doing indirect calls, but pretty sure more bloated...
 
Ethernet UDP NTP query

Here is a UDP example using sendto/recvfrom to do an NTP time query with active polling of the Ethernet DMA ring. Raw ethernet (no lwIP), more info on post #686

Code:
void udp_ntp(int reps, int ms) {
  int i, sport, t;
  uint32_t  secs;
  IPAddress sender;
  uint8_t buff[48] __attribute__ ((aligned(4)));

  UDP_lth=0;
  for (i=0;i<reps; i++) {
    buff[0] = 0x1b;   // ntp query
    sendto(buff,sizeof(buff),4444,manitou,123);
    while(UDP_lth==0) check_rx();  // poll ether ring
    recvfrom(buff,sizeof(buff), 4444, &sender, &sport);
    secs = *(uint32_t *) (buff+40);
    Serial.print("ntp "); Serial.println(swap4(secs));
    t=millis();
    while(millis() -t < ms) check_rx();   // active delay
  }
}
 
Last edited:
Hi all, just wanted to let people know I have a new Version(6) of Snooze that supports Teensy 3.5 and I just fixed a bunch Teensy LC issues also. It has a few api changes but very similar to the old version 5. All the examples show this and should not be to much to change existing code. There are also a bunch of upgrades that I hope make it conflict less with other libraries or user code. One such upgrade it that it saves pin state before going to sleep and restores it back after waking up. So for an example if you want to use Serial1 RX pin as a wakeup pin and still have Hardware Serial1 work after sleeping it should work without having to configure anything. This is still beta but I want to put it out now so I can get some fresh eyes on it to see what other bugs or short comings there are before merging it to Version 5.
 
Here's an update on the likely extra bottom-side pins.

There will probably be a total of 18 bottom side pins, similar to the 14 we have now on the bottom of Teensy 3.2. They will be in 2 groups of 8 and 10 pins. This is the expected pinout for the bottom side:

Code:
Pin  ADC  Ser  PWM  SPI     I2C   CAN  Touch  I2S   Eth   Native
---  ---  ---  ---  ---     ---   ---  -----  ---   ---   ------

GND
DBGEN
SWCLK
SWDAT
40                                                        D15
41                                                        D11
42                          SDA3              txd0        E10
43                          SCL3              lrclk       E11

44                  CS2                                   B20
45                  MOSI2                                 B22
46                  MISO2                                 B23
47                  SCK2                                  B21
GND
3.3V
48        RX6               scl0                          D8
49        TX6               sca0                          D9
50   A23                                            TIMER B4
51   A24                                            TIMER B5
 
Last edited:
Thanks Kurt, was really easy to do something, at list it compile. I'll try in a min.
I have modded another library, really similar to t3_ILI9341, at list can drive the same display so it's possible to do some comparison:
Library is here, it's nice to compare speeds since it can handle any SPI pin combination (If I coded correctly without stupid things). There's the code for SPI2 as well but actually not defined so there is a preprocessor trigger to enable it.
A quick question, if I remember well the SPI1 & 2 has just a 1 byte FIFO buffer and not 4 right? Later I need to mod another function for reading SPI using FIFO, I was trashing 3 bytes currently but with SPI1 this is not necessary, maybe faster?!
 
Hi defragster and sumotoy,

TFT_ILI9163C on SPI1: You probably have a couple of choices on how to make it work. Without using the extra pins of the SDPort, you only have one CS pin, so you can pick off this case and go the slower route, like you have for Teensy LC and use SPI1.transfer(x) and manage the CS/DC pins directly.

Thanks KurtE - indeed then it was not having an SPI1 pin for DC that got me stuck. I'll leave the gory details to sumotoy to match the ILI9341 work.

As far as TFT_ILI9163C it does not have a MISO pin so no reads from that device. But that pin won't work for DC it seems?

I have Talkie doing the 24KB DINER song from RAM with the TFT_ILI9163C on SPI0 using the canned FFT data I saved. I may resample the FFT to 800KB to try to fill some flash.

sumotoy - reading your same time post - KurtE above wrote :: SPI1 or SPI2, which only have a queue of 1. Let me know if you get something to test - then I can put an ILI9341 on SPI0.
 
Last edited:
Since DC is used only during data strem it can be done, I will try later, will be not as fast.
For sure I have to avoid pinIsChipSelect(uint8_t pin1, uint8_t pin2) an use pinIsChipSelect(uint8_t pin1), but how this impact on FIFO routines?
es: pcs_command = pcs_data | SPI1.setCS(_dc);
 
Here's an update on the likely extra bottom-side pins.

There will probably be a total of 18 bottom side pins, similar to the 14 we have now on the bottom of Teensy 3.2. They will be in 2 groups of 8 and 10 pins. This is the expected pinout for the bottom side:

Code:
Pin  ADC  Ser  PWM  SPI     I2C   CAN  Touch  I2S   Eth   Native
---  ---  ---  ---  ---     ---   ---  -----  ---   ---   ------

GND
DBGEN
SWCLK
SWDAT
40                                                        D15
41                                                        D11
42                          SDA3              txd0        E10
43                          SCL3              lrclk       E11

44                  CS2                                   B20
45                  MOSI2                                 B22
46                  MISO2                                 B23
47                  SCK2                                  B21
GND
3.3V
48        RX6               scl0                          D8
49        TX6               sca0                          D9
50   A23                                            TIMER B4
51   A24                                            TIMER B5
Thanks Paul,
Looks like of the 12 pins above, looks like 5 of them were in your earlier list and 7 new ones.
For example looks like SPI2 will be nice and usable from these pins (SIN/SOUT/SCK, CS2-0, CS2-1). Does it look promising enough to maybe start playing with Uart6 (LPUART) and the like?
 
Since DC is used only during data strem it can be done, I will try later, will be not as fast.
For sure I have to avoid pinIsChipSelect(uint8_t pin1, uint8_t pin2) an use pinIsChipSelect(uint8_t pin1), but how this impact on FIFO routines?
es: pcs_command = pcs_data | SPI1.setCS(_dc);
Wonder if it would make sense to handle this on our own thread? As this may apply to T3.2 as well?

I actually don't know which would be quicker. If you only have one CS pin, if you should use it for CS or DC.
That is if you use it for DC, You manually set CS at start of command and after the end of the command which we probably wait for anyway, you clear CS. You would set the Change CS on the Instruction byte, which would automatically turn off when it sends the additional data bytes.

If you use the one CS pin for CS, then have to wait to start of instruction, then set the DC state, issue the istruction byte, wait till it completes, clear DC state and then issue the remaining data bytes for the command.
Which implies that we would probably wait twice...

Could be wrong.
 
I think I've got it working, I don't use at all pcs_command, always pcs_data ( cs pin ) and separate conventional (for now) gpio method for dc so it can be any pin.
Since it's K66 related, maybe we can stop discussion about this, it can be interesting only for understand how to deal with extra SPI channels but for a separate thread the T4/5 should be officially out?!
At this point I really don't know if have sense to use SPI FIFO with 1 byte buffer and conventional SPI.transfer, have to measure speed gaps between the two
 
Last edited:
Status
Not open for further replies.
Back
Top