K66 Beta Test

[WMXZ]

Hm that looks good. I used FAT32... did you create a new File with > 120MHZ ?
Well..if it works for you.. why does it not work for me ? I'll try FAT16...

Ok, Paul said, he used I2S @ with Teensy @ 240MHz... does not work for me, too.

A problem with my board ?

Found an issue with FATFS
Unicode (needed for Long Filename) on Teensy seems to be 32 bit and not 16 bit as assumed by Chan
(I only tested on K64)
can be tested with printf("%d",sizeof(L'1'))

updated https://github.com/WMXZ-EU/uSDFS

[KurtE]

Another SPI Question/Maybe API change/extend...

Many of our Display drivers and the like have code in them like:

void ILI9341_t3::begin(void)
{
    // verify SPI pins are valid;
    if ((_mosi == 11 || _mosi == 7) && (_miso == 12 || _miso == 8) && (_sclk == 13 || _sclk == 14)) {
        ILI9341_SPI.setMOSI(_mosi);
        ILI9341_SPI.setMISO(_miso);
        ILI9341_SPI.setSCK(_sclk);
	} else {
		// allow user to say use current ones...
		if ((_mosi != 255) || (_miso != 255) || (_sclk != 255))
        	return; // not valid pins...
	}
	ILI9341_SPI.begin();
	if (ILI9341_SPI.pinIsChipSelect(_cs, _dc)) {
		pcs_data = ILI9341_SPI.setCS(_cs);
		pcs_command = pcs_data | ILI9341_SPI.setCS(_dc);
	} else {

Note: This version was hacked up to allow me to not to specify MOSI, MISO, SCK and use whatever the SPI Buss is currently configured for.

However I am wondering as we add more different processors which may have different SPI busses and/or different SPI pins, if we should not extend the SPI interface, like what was done for chip Select pins.

So could add: SPI.pinIsMOSI(pin)... methods, which does the test for the appropriate pins for the processor... And/Or could also change functions like SPI.setMOSI(pin), to return something like a bool, which could be tested.

Actually at times not sure how much these tests help as in most cases if the tests fail and we simply return without a working display, there is nothing returned by void ILI9341_t3::begin, to let you know it failed and if so why... But that is another story...

Thoughts?

[Frank B]

A second -red- LED on a dedicated pin would be great... not only to indicate such error-conditions, but for other problems like the NMIs, too (e.g. bus-faults)

[manitou]

K66 ethernet -- projected TCP performance

Using UDP, I have attempted to project K66 TCP performance, details on post 686 with comparisons to mbed K64.

The K66 hardware checksums for IP are flakey (fail (0) for packets > 198 bytes?). There might be some additional configuration magic that might fix it, or maybe a hardware errata exists. I have reverted to software checksums, using 0 for UDP checksum for max speed.

[Frank B]

The OSC-Library (lol..i don't know what it does ;-) - i just saw it when searching mentions of K20 ) misses a whole bunch of #defines for k64/k66 - even in the examples.

What is this lib ? :-)

Edit: More missing #defines (and perhaps more work) in :

- openGLCD
- RA8875
- UTFT
- XBEE

for freqmeasure, I have done a PR some minutes ago

[KurtE]

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:

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

Hi Paul,

I See last night, you did a delta to add new pins to the build. Actually it looks like you added 17 new IO pins If I looked at your changes it looks like: Pin 41-57

I have not updated my Excel document yet, but it looks like fun.

So it looks like time to start playing?

Edit: I think the pins map like:

#   PIN ALT0    ALT1    ALT2        ALT3    ALT4        ALT5        ALT6            ALT7
--  --- ----    ------  ---------   -----   ---------   ------      --------        --------- 
40  A28         PTA28                       MII0_TXER               FB_A25  
41  A29         PTA29                       MII0_COL                FB_A24  
42  A26         PTA26                       MII0_TXD3               FB_A27  
43  B20         PTB20   SPI2_PCS0                       FB_AD31/SDRAM_D31   CMP0_OUT    
44  B22         PTB22   SPI2_SOUT                       FB_AD29/SDRAM_D29   CMP2_OUT    
45  B23         PTB23   SPI2_SIN    SPI0_PCS5           FB_AD28/SDRAM_D28   CMP3_OUT    
46  B21         PTB21   SPI2_SCK                        FB_AD30/SDRAM_D30   CMP1_OUT    
47  D8          PTD8    I2C0_SCL                        LPUART0_RX  FB_A16  
48  D9          PTD9    I2C0_SDA                        LPUART0_TX  FB_A17  
49  B4  A1_10   PTB4                        ENET0_1588_TMR2 SDRAM_CS1-b FTM1_FLT0   
50  B5  A1_11   PTB5                        ENET0_1588_TMR3     FTM2_FLT0   
51  D14         PTD14   SPI2_SIN            SDHC0_D6        FB_A22  
52  D13         PTD13   SPI2_SOUT           SDHC0_D5        FB_A21  
53  D12         PTD12   SPI2_SCK    FTM3_FLT0   SDHC0_D4        FB_A20  
54  D15         PTD15   SPI2_PCS1           SDHC0_D7    FB_A23      
55  D11         PTD11   SPI2_PCS0           SDHC0_CLKIN LPUART0_CTS_b   FB_A19  
56  E10         PTE10   I2C3_SDA            I2S0_TXD0   LPUART0_CTS_b   FTM3_CH5    USB1_ID
57  E11         PTE11   I2C3_SCL            I2S0_TX_FS  LPUART0_RTS_b   FTM3_CH6

Warning: some of the spacing above is a little off, but hard to fit, Only on ALT7....

[Headroom]

The OSC-Library (lol..i don't know what it does ;-) - i just saw it when searching mentions of K20 ) misses a whole bunch of #defines for k64/k66 - even in the examples.

What is this lib ? :-)

Edit: More missing #defines (and perhaps more work) in :

- openGLCD
- RA8875
- UTFT
- XBEE

for freqmeasure, I have done a PR some minutes ago

https://github.com/CNMAT/OSC

;-)

[KurtE]

Before I start playing with all those new pins, thought I would update my SPI playing around. Also I may be busy with some none Teensy stuff for a few days...

I created a new version of my SPIN (SPIn library). I decided to try a different approach and I created a base class with all the members virtual. I then created subclasses for SPIN0 and SPIN1 and soon SPIN2, which implement these methods to call of to the SPI and SPI objects, which most of their code is always inline. So now I have virtual function equivalents for these.

I then added some more virtual functions for checking SCK/MISO/MOSI pins as I mentioned earlier. I also added a method that returns a pointer to the System level SPI KINETISK object and also another one which returns the SPI queue size for that SPI object.

I then played around with a copy of the ili9341_t3 code base, which I added the constructor takes a pointer to a SPIN object (default SPIN0) and then made all of the changes to call through the virtual functions and to use the pointer to the hardware SPI registers. Then I ended up moving the functions like: waitFifoEmpty out of the ili9341 code and added them to my spin object. That way I don't have to loop knowing queue sizes or the like...

With it was able to get the graphic test to run on SPI1 (using my hacks for using SDCard pins), or to run on SPI with normal CS pin.

Note: I have three displays hooked up: that I have #ifdef for which one to use.
SPI1 ...
SPI with default CS pins (CS 10, DC 9)

The third is SPI with CS pins (CS 23, DC 9)

Funny thing still investigating: if I run the the version with CS 10, only the one display does anything, but if instead I run the one with CS=23, both displays on SPI run in sync...
I even tried doing a pinMode(10, OUTPUT); after the tft.begin call and both display appear to still run (in sync)

Edit: never mind it is because pin 10 was floating low. changing to INPUT_PULLUP causes it to no longer output (still see it flicker as it sees the commands...). Could also probably solve by digitalWrite(10, HIGH);

In case anyone is interested in any of this stuff, I included a zip file, with the SPIN stuff, plus a hacked up ili9341_t3n and the updated graphictest with the different defines for different display.

[slomobile]

A second -red- LED on a dedicated pin would be great... not only to indicate such error-conditions, but for other problems like the NMIs, too (e.g. bus-faults)

What do you think of a bi-color LED? Something like these. I haven't used this specific part, but other red/green LEDs I've used light orange when both elements are lit at the same time. This effectively gives you a 4 status display(3 colors and off) on one part using only 2 controller pins.

[PaulStoffregen]

At this point, the hardware design is pretty much fixed, with the same orange LED as every other Teensy.

[KurtE]

Hi Paul, just wondering if any of the other new pin numbers you defined are available on the test boards.
I have verified I an talk to the 8 of them that are part of the 10 pin connector and they have the pin numbers:

 3.3V  [] ()  GND
   48  () ()  47
   57  () ()  56
   51  () ()  52
   53  () ()  55

Right now playing around defining SPI2, may have to do minor tweaks once I know which MISO and MOSI should be the defaults.
I pushed up changes for SPI2 into my T35_USE_SDCARD_PINS branch of the cores and SPI projects. I have not tested SPI2 yet, but have it compiling and I have a SPIN2 locally

[nox771]

Edit: I think the pins map like:

#   PIN ALT0    ALT1    ALT2        ALT3    ALT4        ALT5        ALT6            ALT7
--  --- ----    ------  ---------   -----   ---------   ------      --------        --------- 
40  A28         PTA28                       MII0_TXER               FB_A25  
41  A29         PTA29                       MII0_COL                FB_A24  
42  A26         PTA26                       MII0_TXD3               FB_A27  
43  B20         PTB20   SPI2_PCS0                       FB_AD31/SDRAM_D31   CMP0_OUT    
44  B22         PTB22   SPI2_SOUT                       FB_AD29/SDRAM_D29   CMP2_OUT    
45  B23         PTB23   SPI2_SIN    SPI0_PCS5           FB_AD28/SDRAM_D28   CMP3_OUT    
46  B21         PTB21   SPI2_SCK                        FB_AD30/SDRAM_D30   CMP1_OUT    
47  D8          PTD8    I2C0_SCL                        LPUART0_RX  FB_A16  
48  D9          PTD9    I2C0_SDA                        LPUART0_TX  FB_A17  
49  B4  A1_10   PTB4                        ENET0_1588_TMR2 SDRAM_CS1-b FTM1_FLT0   
50  B5  A1_11   PTB5                        ENET0_1588_TMR3     FTM2_FLT0   
51  D14         PTD14   SPI2_SIN            SDHC0_D6        FB_A22  
52  D13         PTD13   SPI2_SOUT           SDHC0_D5        FB_A21  
53  D12         PTD12   SPI2_SCK    FTM3_FLT0   SDHC0_D4        FB_A20  
54  D15         PTD15   SPI2_PCS1           SDHC0_D7    FB_A23      
55  D11         PTD11   SPI2_PCS0           SDHC0_CLKIN LPUART0_CTS_b   FB_A19  
56  E10         PTE10   I2C3_SDA            I2S0_TXD0   LPUART0_CTS_b   FTM3_CH5    USB1_ID
57  E11         PTE11   I2C3_SCL            I2S0_TX_FS  LPUART0_RTS_b   FTM3_CH6

Warning: some of the spacing above is a little off, but hard to fit, Only on ALT7....

I don't get it, your pin numbers don't look at all like the ones Paul posted, he goes up to 51 and you have 57. Which one is right?

[KurtE]

Look at the code delta Paul made in core yesterday.

[PaulStoffregen]

The code on github is the most up-to-date with the PCB layout.

I believe we still have a few of the round 2 boards unassembled. If anyone (on the beta testers list) still wants to jump in now, just email Robin. Sometime next week I'm going to order the first prototype run. 2 weeks for the PCB and probably another 1-2 weeks for the BGA soldering. If those work, they will become round 3. If they have any show stopper problems, it'll be another PCB+assembly turn before round 3.

Soon the extra Ethernet boards are due to arrive. Those will be hand soldered by Erin, so quick turnaround. If anyone else wants to play with Ethernet, email Robin to request one of those boards.

For the next several days I will be continuing to focus on PCB layout, which also includes 3 boards to make the bed-of-nails test fixture. After next week all the PCBs should be sent, and I'll be able to participate much more here. Until the, please know my absence is due to what's turning out to be the most challenging PCB design I've ever attempted....

[xxxajk]

Paul: Where is the pad/thruhole for bypassing the protection diode for VBUS <-> VIN?
Sure, I can bypass the diode, that's all well and fine, since my power source is all from the same source.
I could use a powered hub to bypass the "problem" too.
2 host ports could be useful if you do not want to use a hub to hook up 2 devices.


FYI once I bypass the diode, UHS3 works dandy on the native FS OTG. I'll post benchmarks after you answer.

[manitou]

Any chance you could benchmark simultaneous transmit & receive UDP data flow? Maybe with sequence numbers or some other data inside the packets, so you could detect packet loss?

Performance metrics are nice, but I'm really most curious to know if there's any packet loss. I recall reading some conversations, maybe from the Beaglebone devs, about issues with packet loss with RMII (but magically solved by using MII) during fast bidirectional data flows.

Paul, the latest UDP tests I did simulating a TCP flow using a linux "ACK server" has simultaneous flows. I did not observe packet loss in either direction. see post 686. "Absence of proof is not proof of absence."

[KurtE]

SPI/ILI9341 - Quick update,

Before I am busy doing other stuff off of the computer, I thought I would upload an updated version of the SPIN and my updated ILI9341_t3n library. The latest hacks to the display code was to handle case where DC is on a chip select pin but the CS pin is not. Then made inline functions that called the SPIBeginTrns.../End calls and added simple test that if I have a _csport, then clear or set it.... Appears to work fine and I am not noticing any change in speed... When I can get back to playing, I will then test SPI1 and SPI2 with using the only 1 CS pin...

[defragster]

SPI/ILI9341 - Quick update,
Before I am busy doing other stuff off of the computer ...

That's cool KurtE - I'll look to give it a try. Have you ever worked with the TOUCH display? It needs another CS pin, but uses the same data lines. It seems those fixed (IIRC) ~10-15 commands could be issued with manual CS selection easily enough in the case the SPI is not using SPI0? And when set up with INT_pin it would never poll when a Touch wasn't indicated. From what I know the CS would be asserted before the groups of commands and then dropped when done? Perhaps your work would account for that in the calls?

[PaulStoffregen]

Paul: Where is the pad/thruhole for bypassing the protection diode for VBUS <-> VIN?

There isn't any such thing on the round 1 & 2 beta test boards.

[sumotoy]

Kurt, I'm confused about K65/K66 pin you used for SPI1 experiments.
I was supposing use:
MOSI:0
SCLK:32
CS:6
but you are using:
DC = 0xe4
CS = 0xe5
SCK = 0xe2
MISO = 0xe3
MOSI = 0xe1
Probing with oscilloscope I've seen activity only on PIN 20 and 0 (this one should be MOSI)
Can you tell me witch pin are you are using (in DEC) and why 0xE1 should be PIN:0, I'm sure I've missed something...

[KurtE]

It is using hacked version using io pins on sdcard using adapter. Will try later with real easy to get pins

Forgot to mention yesterday that th oxe1-5 are the physical pin names on the adapter, needed that as only place with multiple CS pins, uses my changes in core and spi to make those pins work. Should now be able to make work on one CS so will try on official Sp1 and Sp2 pins. But maybe not until maybe Mon or Tue.

[defragster]

K66 at 240 MHz I finally powered up the onehorse i2c bubble display :: HT16K33_Display_Driver. Swapped in K66 edited : C:\sketchbook\libraries\i2c_t3

//#include "Wire.h"
#include <i2c_t3.h>
#define Wire Wire1
//#define Wire Wire2

Sketch works on Wire and Wire1 as written up to 1,600K, won't run at 2,400K.

us time to run the 4 digit print loop for 200 digits at 240 MHz except as noted::

1,257,759 :: At Default Wire.begin Speed and higher Wire.setClock() as noted after .begin()
387,297 :: Then runs fine at 400K and 3+ times faster
227,966 :: Doubling to 800K runs fine as well
177,820 :: At 1,200K runs fine as well
152,642 :: At 1,600K runs fine as well
184,969 :: At 1,600K runs fine as well dropped speed to 96 MHz
340,007 :: At 1,600K runs fine as well dropped speed to 24 MHz

With setClock(800000UL) a 5ms delay() each loop, to the 200 count test loop still runs faster than default speed at 1,227,956
With setClock(1600000UL) a 5ms delay() completes at 1,152,639

<edit> Merged AdaFruit_SSD1306 sample using Wire2 at 400K with above Wire1 at 1.6M at K66 speeds 120 MHz and 216 MHz. Made their busy loops re-entrant to share CPU and Flakes fall smoothly and the bubble digits run nicely. I'll put Manitou's RTC time checker in to see how that works.
Kris' i2c bubble-display-frontpack interface multiplexor chip is fast and nice running 16 LED 8 segment digits at 1.6M! I don't see a speed in the HT16K33 data sheet - but it's working.

[nox771]

Merged AdaFruit_SSD1306 sample using Wire2 at 400K with above Wire1 at 1.6M at K66 speeds 120 MHz and 216 MHz. Made their busy loops re-entrant to share CPU and Flakes fall smoothly and the bubble digits run nicely. I'll put Manitou's RTC time checker in to see how that works.
Kris' i2c bubble-display-frontpack interface multiplexor chip is fast and nice running 16 LED 8 segment digits at 1.6M! I don't see a speed in the HT16K33 data sheet - but it's working.

Cool results, multibus is awesome when it works. I think this thing having 4 buses has a lot more potential for background operation. If I had time I would write an API that would queue traffic and background it as bus time opened up.

Question - When you run the higher clocks have you ever tried running bus overclock? (IIRC requires editing kinetis.h around line ~760) I wasn't able to get any bus overclock to compile last time I tried.

[defragster]

Cool results, multibus is awesome when it works. I think this thing having 4 buses has a lot more potential for background operation. If I had time I would write an API that would queue traffic and background it as bus time opened up.

Question - When you run the higher clocks have you ever tried running bus overclock? (IIRC requires editing kinetis.h around line ~760) I wasn't able to get any bus overclock to compile last time I tried.

Yes - nice to have parallel shared multibus - I'm not sharing - but the 4::1 speed is nice when you can adjust it per device group! Ran 6+ hours ( I didn't sleep enough!) - everything cool and pretty. Can't read a red blur updating - but shoving out a number doesn't take very long to the bubble display - I'll use it to show RTC time diff per second.

On your pointer - yes - about line 760 in Kinetis.h I made this change at 216MHz and it compiled and is running both displays:

#elif (F_CPU == 216000000)
#define F_PLL 216000000
#ifndef F_BUS
//#define F_BUS 54000000
//#define F_BUS 72000000
#define F_BUS 108000000
#endif

Minor difference in overall runtime in usec for 600 number bursts given the i2c time is fixed:
F_BUS 108000000 == 6,376,109 versus F_BUS 54000000 == 6,417,613

[sumotoy]

Kurt, nevermind, it's too weird to me, finded a better solution. Thanks anyway!
defragster, I got SPI1 working on a test version of TFT_ILI93XX, you don't need to do anything special or change any define.
The SPI1 is used only on K64/k66 and when MOSI=0,SCLK=32 and DC=6, in this case CS can be any pin.
Example:

TFT_ILI93XX tft = TFT_ILI93XX(10,6,255,0,32); //(CS,DC,RST,MOSI,SCLK)

It's pretty fast since libraries has been thinked to use as less CS than possible, of course there's buffer drawback as well (4 vs 1).
It's easy to transfer code to TFT_ILI9163C and all the other libraries, if it works ok I'll do it.
The CS pin is now drived by legacy digitalWriteFast so using direct port method can be much faster! DC it's drived directly by SPI FIFO.
The TFT_ILI93XX can be used to test ILI9341, here's a benchmark (using SPI_FIFO, 4 bytes buffer vs 1 byte buffer)

Benchmark                Time (microseconds) (K66/96Mhz, ILI9341)
test                     SPI0           SPI1
Screen fill              280032         280231
Text                     13061          15532
Lines                    73205          79968
Horiz/Vert Lines         23099          23178
Rectangles (outline)     14629          14673
Rectangles (filled)      581465         581870
Circles (filled)         81090          83012
Circles (outline)        64639          67148
Triangles (outline)      17579          19208
Triangles (filled)       188506         190019
Rounded rects (outline)  27054          28702
Rounded rects (filled)   632272         633550