K66 Beta Test

Status
Not open for further replies.
Sumotoy mine should work same way with pins you mentioned. The other stuff was a way to get something running when we required more than one CS pin. I just have not tested the other configurations yet
 
sumotoy - thanks I'll give that a try. That speed drop doesn't look significant - two independent buses could be better than sharing one for two displays.
I left the twin i2c Wire1/Wire2 code running at 240 MHz with FBUS at 120 MHz - that compiled fine - the last 4 hours.

F_BUS 120000000 == 6,349,959 versus F_BUS 60000000 == 6,398,008 as above - with a delay(10) so the red LED display is readable.
F_BUS 120000000 == 349,947 versus F_BUS 60000000 == 397,957 as above - No delay(10) the red LED last digit isn't readable - shows a 13% speedup with faster FBUS.

My K66 CPU is (barely) warm to touch - measures 94.6°F - at 240 MHz and F_BUS 120, no delays and constant dual i2c updates. <edit> 7 hours later temp stable - max seen 98°F - rest of the surface is lower.
 
Last edited:
Sumotoy mine should work same way with pins you mentioned
Cannot get work, setting same pin as mine doesn't do nothing, no activity on PIN 6 or 10 but MOSI and SCLK are fine, also the function pinIsChipSelect(_cs, _dc) cannot get true in SPI1 since only one pin is available (6).
Accordly this table, in SPI1 only pin 6 (or 31) should be usable and the SPI.cpp return always false for pinIsChipSelect(pin1,pin2), also setCS can handle only pin 6 or 31.
At this point a question is inevitable, where is pin 0xE4 and pin 0xE5 located on K66 board and how they can be legally usable in SPI1?
 
That's our Open Sound Control Library

I have successfully compiled the examples. I will push those changes out soon. I have to do a round of tests against the latest changes people have been contributing.


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
 
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

Ok, so what issue are you having with openGLCD?
I'm doing some updates to make it better, but the latest openGLCD release without these updates works "as is" for me.
--- bill
 
defragster, I got SPI1 working on a test version ... , 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.

I got an updated PM from sumotoy to github 9163C lib for K66 on SPI1 and it works, tried at 240 MHZ with F_BUS 60 and the faster 120:

Code:
//TFT_ILI9163C::TFT_ILI9163C(cspin,dcpin,rstpin,mosi,sclk)
TFT_ILI9163C tft = TFT_ILI9163C(10,6,255,0,32);//Teensy K66 SPI1!!!

Benchmark[rot=0]         Time(F_BUS=60) Time (F_BUS=120) (microseconds)
Screen fill              9563           9016
Text                     2262           2129
Text2                    6735           6314
Lines                    12844          11964
Horiz/Vert Lines         4124           3882
Rectangles (outline)     3344           3146
Rectangles (filled)      72931          68756
Circles (filled)         12176          11422
Circles (outline)        11583          10776
Triangles (outline)      4024           3751
Triangles (filled)       25046          23576
Rounded rects (outline)  6643           6209
Rounded rects (filled)   79837          75247

<edit>: Interlaced 12 steps of 'BenchMarkSPI1' into the other two displays: running SPI1 (TFT_ILI9163C) with Wire1 (HT16K33) and Wire2 (Adafruit_SSD1306)
Max K66 Temp 96°F
>sumotoy - the 9163C #define of WHITE&BLACK redefine/conflict with adafruit_ssd1306 (opened an issue)
 
Last edited:
Cannot get work, setting same pin as mine doesn't do nothing, no activity on PIN 6 or 10 but MOSI and SCLK are fine, also the function pinIsChipSelect(_cs, _dc) cannot get true in SPI1 since only one pin is available (6).
Accordly this table, in SPI1 only pin 6 (or 31) should be usable and the SPI.cpp return always false for pinIsChipSelect(pin1,pin2), also setCS can handle only pin 6 or 31.
At this point a question is inevitable, where is pin 0xE4 and pin 0xE5 located on K66 board and how they can be legally usable in SPI1?
You are right that the pinIsChipselect(cs1,cs2) always returns false, as only one true CS on Spi1. Yes you can use pins 6 or 31, but they are both CS0, so they will both incode the same in the spi commands. I.e. They are simply alternate pins for each other in same way as there are alternates for MOSI.

There are 8pins that go into the Sdcard connector, +5v, Gnd, and 6 IO pins which are on signal pin names E0-E5. I access these pins using Sparkfun sniffer adapter, I simply hacked up Spi and core to add those values to hard code if you ask for 0xe0 I use the hard coded E0 pin....

Note Sdcard pins mentioned in Paul's posting#93
https://forum.pjrc.com/threads/34808-K66-Beta-Test/page4

So my last zip file, I first ask if both io pins are CS pins, if so great, else it checks if DC is a CS pin, if so it manipulates CS manually, and let's spi manage DC pin.
 
Last edited:
FS USB-OTG test results, Teensy 3.5.
256MB generic USB thumb drive.

Code:
240Mhz
1MB write timing test  2048 writes, (0), (0),  2477 ms (2 sec)
1MB read timing test 2048 reads, (20),  1478 ms (1 sec)
1MB write timing test  2048 writes, (0), (0),  2258 ms (2 sec)
1MB read timing test 2048 reads, (20),  1476 ms (1 sec)
1MB write timing test  2048 writes, (0), (0),  2477 ms (2 sec)
1MB read timing test 2048 reads, (20),  1477 ms (1 sec)

192Mhz
1MB write timing test  2048 writes, (0), (0),  2280 ms (2 sec)
1MB read timing test 2048 reads, (20),  1487 ms (1 sec)
1MB write timing test  2048 writes, (0), (0),  2508 ms (3 sec)
1MB read timing test 2048 reads, (20),  1489 ms (1 sec)
1MB write timing test  2048 writes, (0), (0),  2279 ms (2 sec)
1MB read timing test 2048 reads, (20),  1490 ms (1 sec)

168Mhz
1MB write timing test  2048 writes, (0), (0),  2521 ms (3 sec)
1MB read timing test 2048 reads, (20),  1492 ms (1 sec)
1MB write timing test  2048 writes, (0), (0),  2290 ms (2 sec)
1MB read timing test 2048 reads, (20),  1491 ms (1 sec)
1MB write timing test  2048 writes, (0), (0),  2516 ms (3 sec)
1MB read timing test 2048 reads, (20),  1495 ms (1 sec)

144Mhz
1MB write timing test  2048 writes, (0), (0),  2300 ms (2 sec)
1MB read timing test 2048 reads, (20),  1518 ms (2 sec)
1MB write timing test  2048 writes, (0), (0),  2542 ms (3 sec)
1MB read timing test 2048 reads, (20),  1514 ms (2 sec)
1MB write timing test  2048 writes, (0), (0),  2289 ms (2 sec)
1MB read timing test 2048 reads, (20),  1514 ms (2 sec)

120Mhz
1MB write timing test  2048 writes, (0), (0),  2549 ms (3 sec)
1MB read timing test 2048 reads, (20),  1608 ms (2 sec)
1MB write timing test  2048 writes, (0), (0),  2302 ms (2 sec)
1MB read timing test 2048 reads, (20),  1560 ms (2 sec)
1MB write timing test  2048 writes, (0), (0),  2544 ms (3 sec)
1MB read timing test 2048 reads, (20),  1668 ms (2 sec)

96Mhz
1MB write timing test  2048 writes, (0), (0),  2549 ms (3 sec)
1MB read timing test 2048 reads, (20),  1560 ms (2 sec)
1MB write timing test  2048 writes, (0), (0),  2306 ms (2 sec)
1MB read timing test 2048 reads, (20),  1561 ms (2 sec)
1MB write timing test  2048 writes, (0), (0),  2553 ms (3 sec)
1MB read timing test 2048 reads, (20),  1560 ms (2 sec)
 
Thanks Kurt, reached the same conclusions, without your work on SPI cannot be possible.
Ive used this library for testing stuff with SPI_FIFO, maybe can be useful to someone.
thanks defragster, I've upgraded all libraries with a k64/66 additional fork. I'm sure is possible increase speed by direct manipulating cs pin in SPI1.
Just need to add some more stuff on RA8875 to handle SPI1 (and SPI2), otherwise it's compatible already with SPI0
I'll add code for SPI2 later so it's ready for the future....
 
Last edited:
Thanks,

Suggestion for pin summary and cards, wish it would give more CS info, like CS-1 and CS2-0, as if your program uses more than 1 CS you need to make sure the ones you choose are not duplicates of each other.
 
I wonder if SPIFIFO.h in teensy core needs a upgrade, for sure pin 26 is missed....
I never used it, someone knows anything that use it?
 
Last edited:
Paul Quick questions and suggestion. Is there a plan to make time_t 64bit? Perhaps we should, since I can forsee some devices in the wild that will actually still be using these devices. I've been seeing devices put out into the wild that are going to be monitoring things like air, water, soil, etc for an indefinite period. It is very possible such systems will be still in use. Right now it isn't if the system headers say time_t is 32bit, which is what I believe newlib uses. A patch is needed urgently, and is basically a mandate by 2018. Since this is an easy fix, why not fix it early, and never have to be concerned about it again.

I'm also concerned with your choice of epoch. I know others have expressed concerns/griped about it. Sure it does extend the date range, but it also causes confusion since it isn't using either of the standard epoch times. Luckily I am smart enough to work around this to present the time functions with an adjusted epoch, thus resolving the entire problem for me and uses of my libraries. I still need to update my RTClib to 64bits for every choice.

FAT uses even less bits and is also a concern, but is beyond the scope of the topic, but worth mentioning. I wonder what will happen in this case...
 
Paul Quick questions and suggestion. Is there a plan to make time_t 64bit? Perhaps we should, since I can forsee some devices in the wild that will actually still be using these devices. I've been seeing devices put out into the wild that are going to be monitoring things like air, water, soil, etc for an indefinite period. It is very possible such systems will be still in use. Right now it isn't if the system headers say time_t is 32bit, which is what I believe newlib uses. A patch is needed urgently, and is basically a mandate by 2018. Since this is an easy fix, why not fix it early, and never have to be concerned about it again.

While I agree that the systems capable of running 64bit native integers should be using 64 bit time_t values,
using 32 bit time_t values (the 2038 problem) isn't always as big of a deal as you might think
While the 2038 problem is a much bigger deal than the Y2K issue that scared so many people,
Many applications only need dates after 1970, this is particularly common in embedded systems.
So as long as time_t is a 32 bit unsigned value datetimes up to the year 2106 can be handled.
Not great but probably eliminates the issue for all practical purposes until a full cuttover to 64 bit can be achieved.

I think a bigger concern is that in the Time library time_t is defined as an "unsigned long".
This gives you an unsigned 32 bit value on AVR, and I'm assuming that this already creates a 64 bit or larger value on 64 bit architectures; however, different 64 bit architecture implementations use different sizes for longs. 32, 64, 128....
I think that this value should be defined much more explicitly i.e. uint32_t vs uint64_t depending on the architecture and desired result rather than leaving its size up to the compiler implementation.
For sure I think it shouldn't be allowed to create 128 bit time_t values.


--- bill
 
Last edited:
Yes, 32 bit rollover of time_t in 2038 is a problem that needs to be addressed. This issue is coupled to newlib, since we're inheriting time_t from newlib's headers. The actual RTC hardware in Teensy implements a 32 bit unsigned integer, so when time_t becomes 64 bits we'll need a way to define a 64 bit offset.

Right now, in the middle of bringing up new hardware, is not the moment to make this software change.

Next time we update the ARM toolchain would be the right time to look at this, at least the newlib component. I believe the newlib part really must happen first. Changes in the Time library and Teensyduino's core library for the RTC support will follow.

I do intend to update the toolchain "soon". My hope is to get K66 fully released using our old but well established toolchain.

I also want to coordinate with the Arduino folks on the toolchain. I don't intend to wait for them to upgrade or even make a final decision. In fact, I'm pretty sure they'll be happy to see Teensy go first on an update to gcc 5.x. But this is on my list of stuff to talk with them, probably in September. Hopefully later this year the lawsuit between Arduino LLC & Arduino SRL will move forward and hopefully lead to some sort of settlement. Again, I'm not going to wait for their legal battle to fully play out, but I do want to work with them so we're all on the same path for a future where all 32 bit Arduino compatible boards handle time compatibly.

Realistically, I see this time_t change happening somewhere in 2017. That's still more than 20 years from the rollover. In the long term, I believe we'll all be better served if we get the newlib part right and there's agreement with Arduino, so they'll likely follow the same path as 2038 comes onto their horizon.
 
Paul's posting - hopefully that means the PCB routing of his lifetime is going well?

I still just have the three displays on my K66 - Running well and good since my last post. I need to hook up a touch ILI9341 on SPI0 I suppose.

I did add - to that cycling single sketch with 3 displays - sets of KurtE's Float/Double loop and manitou's RNG generation with RTC operation tracking the time each minute. In activating that circuitry temp staying stable - may have gone up a degree - but I'm not tracking my ambient temp. Max temp with IR thermometer is 98°F at 240 MHz w/F_BUS at 120.

As Koromix has time I'm testing his TYQT updates for K66 (which I really miss). For USB Serial number ID and K66_BETA reporting '0', I made this change to usb_desc.c in usb_init_serialnumber():
if ( 0 == num ) num = 10203040L; // HIDE K66_BETA LACK of USB_Serial # in FLASH
It doesn't help what is reported outside USB during boot - but harmless fun.

Still trying to refine the manitou RTC clock sketch sync testing against the 1_sec interrupt from RTC hardware - just discovered my volatile's are not being treated properly! The isr() sets it on each entry, but it stays at the first set value, I can set it to 0, then it stays zero - On both T_3.5 and T_3.1. I added one each of an elapsedMicros and Millis and some other code - not sure what is causing it? Need to make a simple sample to confirm and demo.

Paul - I didn't see a response to creating a LINK only index thread to K66 - I'm taking that as out of scope of post1/3 rules. Post #3 still aging. Perhaps I could commandeer my page#1, post #8 as a thread link list and invite PM's to link to summary posts on devices and topic areas such as : i2c, SPI, Ethernet, USB, SDHC, AUDIO, BUS speed, etc. that folks have worked through and made a definitive contribution?

That came to mind having to scan back through 4 pages to find this post: ethernet shield fits with the PCB. It looks like I need to move my wire2 device as those start shipping this week. You mention the length - hopefully they are just ~7 pins wide - then the 12 wide headers on the Adafruit ProtoBoard shield adapter shield I made can still work to get to all the other pins without soldering the K66 board.

<Combo update>:
ILI9341 working on K66 on SPI0 - by itself different pins than first tested - and in parallel with one each SPI1::ILI9163C, Wire2::SSD1306, Wire1::eek:nehorse HT16K33 bubble display.
Code:
ILI9341_t3 tft9341 = ILI9341_t3(TFT_CS, 20, 255, 11, 14, 12);
// ILI9341_t3::ILI9341_t3(cs, dc, rst, mosi, sclk, miso)

Single sketch, five files now and 155K of code - took some 'refactoring'
> noted BLACK&WHITE compile warn resolved by moving the 9163C to a .cpp
> Link Problem with ILI9341_t3 : Stopped using 'Adafruit_GFX' code - but kept the class name, conflicts with Adafruit_SSD1306 usage until refactored to "Adafruit_GFX_Button_t3" - only 5 instances.
> graphicstest code tft became tft9341, plus all the common subtest to 9163C to satisfy linker

Nothing much exciting here - it works, no temp change.

One note the 9341 has 5 times the pixels of the smaller 9163C - but similar test suite takes 6.4 times as long to run, even on lesser SPI1 hardware wiring - sumotoy did some good work.
 
Last edited:
Paul's posting - hopefully that means the PCB routing of his lifetime is going well?

Yes, the PCB is going well. Everything is routed using 5 mil traces (ugly in some places but passes all design rule checks), and I've cleaned up and routed some of the power with wide 15 mil traces. Much cleanup remains to be done. We're going to send out the files for a first prototype run probably on Wednesday. Turn time is 1-2 weeks, and probably another week for assembly, since we can't hand solder the BGA. We're going to switch to a stronger Micro-B connector with the 4 tabs, which is also adding a new unknown on the assembly side.

Perhaps I could commandeer my page#1, post #8.

Yes, please do. Then I'll edit the original post with a link to #8, and I'll edit #3 with a notice it's out of date and a link to #8.

I know this thread is getting ridiculously long, but please bear with it. Things will change shortly after we get the first prototypes and start round #3. I'm still debating whether to use Kickstarter or just put up a pre-order page. Either way, when we have a first working prototype board and a way to pre-order, we'll change how we're doing things, including photos.

If we use Kickstarter, which is a pretty big "if", boards will ship first to beta testers (everyone on the #1 post list), then to Kickstarter backers, and then to the distributors, and then to orders placed via the PJRC site.

In the meantime, if you could take over the list Ben started, that's really help.
 
Hello Beta testers round 1 and 2 ... . If you have - or saw any - any definitive posts - now or that you can clean up for a device or library or other unique finding please PM me - I just dumped my PM inbox. I'll watch there for updates or edits. They will be placed on this post #8 Awesome - I sent email to Robin ... Also looking forward to the K66


I'm thinking as noted - like the WIKI thread - Maybe like these just one line to announce the link with the link (Ctrl+L embededed)?

A Kickstarter would be cool - they could use the publicity and funds from a huge project done well!

If anyone can send me an updated version of the pinouts (text,doc,xl,csv) like post 3 with bottom added and alternate pin usage I'd like to have that available as well.


Here is Version 0.0 of that post:
Commandeering this post to provide LINKS into what now is almost 800 posts to the current state of T_3.5 Beta hardware notes and library and usage developments.

See post one and perhaps post three above for added info on working with the T_3.5 Beta K66 board.

Essentials - you need TeensyDuino 1.29 installed and this updated Boards.Txt:
K66 BETA Boards.txt HERE

Device libraries:
<pending>


Software Samples and Features:
manitou RTC clock sketch sync

KurtE's Float/Double loop

manitou's RNG generation

Notes on additional Hardware:
PJRC Beta ethernet shield fits with the PCB
<audio board>
<prop shield>
<tft ili9341>


*** Relevant posts on this thread not linked - or have edits to suggest - PM me the details for adds or changes. ***

* have an evolving library - make a post and keep it updated in one place - send a 'static' link. *
 
Last edited:
Paul : First pass in place for WikiLinks, if my effort looks ready you can edit post 1(3) and I'll try to keep after it based on updates.

Feedback?:: PJRC, FrankB, Theremingenieur, KurtE, dgarcia42, manitou, sumotoy, el_supremo, pictographer, WMXZ, duff, bperrybap, nox771, Pedvide, xxxajk, macaba, mxxx, dgarcia42, JBeale, ...

SPI Question: I assume this 'white display' is because I'm wiring direct with no SPI PullUps on CS and D/C?
I added the extra header space to my Proto Shield shield for 9341/Touch shared pins - connecting T_CLK/SCK for Touch takes 9341 display to all white after a few test sections, also discovered when I touch the free T_CLK pin (or screen?) [Relief - I thought earlier I had a bad display when I saw this].
[I don't have TOUCH library loaded yet- just pulled all common pins and it is worse now going white on its own, not better with those lines floating?]
Smaller non-touch 9341 doesn't seem to be showing this.

ALSO:: Just went to the 'graphicstest' with pin edits for K66 as wired and with:
Code:
  tft.begin();
  tft.setRotation(1);

And running the two rectangle tests::
Code:
for ( int ii=0; ii<8; ii++) {

  Serial.print(F("Rectangles (filled)      "));
  Serial.println(testFilledRects(ILI9341_YELLOW, ILI9341_MAGENTA));
  delay(500);

  Serial.print(F("Rounded rects (filled)   "));
  Serial.println(testFilledRoundRects());
  delay(500);
}

Looks like a displaced/wrapped line on the long edge. One GREEN or MAGENTA edge 'bar' appears on the opposite edge. Should this run in all rotated orientations?
 
Last edited:
Guys I'm sorry I let you down with Post #3. It was just too big of a time-consumer to go through the rapidly growing thread daily. If you want to help defragster with his post #8, I suggest dropping him a PM when you post something you want to see linked in or adding a bold font line in your post with a sort of "TL;DR" so he can easily identify if/when he needs to take action.
@defragster, I can update post#3 to contain a link to #8 at the very top if you wish, and either remove the rest or keep it with an "outdated" note. PM me if you like.
 
@defragster, I can update post#3 to contain a link to #8 at the very top if you wish, and either remove the rest or keep it with an "outdated" note. PM me if you like.

Hi Ben - assembled the 'sent' list above and saw your name wasn't on it -not having one in hand would make working with it and tracking it really tough.

I saw the WiKiLinks post as a complement to a general source of info like post 3 - I was hoping anyone who did 'work' or something novel would have a summary post somewhere for the nitty gritty details on USB/SPI/i2C/RNG/... where they linked to the GitHub for code. All I hope to do it organize and update links to those posts - much easier task than post 3 details, but really important to have any feel for what is where among 800 posts - where to look and what is current. Also make it more like the specific device threads where the first post is always the go to spot - except it's all in one thread for now.

So feel free to mod post 3 to prune anything that might get out of date - or end up shadowed by the list of links index. If you'd rather pass it on - it could be moved to another post - and linked in post #8 - where ever it ends up. Please do link to the post 8 links.
 
Status
Not open for further replies.
Back
Top