K64 Beta Test :: Teensy 3.5

Status
Not open for further replies.
KurtE said:
Also I2C3 does not exist on T3.5 on T3.6 it is on pins 56 I2C3_SDA and 57 I2C3_SCL
Click to expand...
Paul, I should point this out for Kickstarter as well.

Again unless I am missing something:
Teensy 3.5 has 3 I2C ports
Teensy 3.6 has 4 I2C ports.
 
Oh, opps... I knew that but totally missed it when writing up the Kickstarter page. Will post an update and correct it today.
 
Frank B said:
@Defragster, the links (post #1) to the datasheets do not work for me.
Click to expand...

Should work now (cut and paste from K66 thread wasn't tested)- does PJRC have a local linked copy?

Indeed - one card per Teensy right? Not enough room for all pin defs already without trying to spilt the difference. Also the 3.3V versus 5V will need clear notice!

A shame it isn't easy to make the PCB's difference mask colors - and no room for silkscreen label. A sticker or INK stamp on the SD (USB?) socket to differentiate at a glance would be cool.
 
Last edited:
FYI - Right now playing with SPI and testing out my SPIN/ILI9341_t3n library on the 3.5 board.

Graphic Test worked on SPI1 with the defines:
Code: 
#define TFT_DC 6 // 0xe4
#define TFT_CS 7 // 0xe5
#define TFT_SCK 32 //0xe2
#define TFT_MISO 1 // 0xe3
#define TFT_MOSI 0 // 0xe1
#define TFT_RESET 8
ILI9341_t3n tft = ILI9341_t3n(TFT_CS, TFT_DC, TFT_RESET, TFT_MOSI, TFT_SCK, TFT_MISO, &SPIN1);
Again my version of ILI9341 works with just one hardware SPI CS pin when used as DC pin... not too much of a perf hit.

Now trying on SPI2, with the defines:
Code: 
#define TFT_DC 43 // 55 // 0xe4
#define TFT_CS 42 //57 // 0xe5
#define TFT_SCK 46 //53 //0xe2
#define TFT_MISO 44 //51 // 0xe3
#define TFT_MOSI 45 // 52 // 0xe1
#define TFT_RESET 8
ILI9341_t3n tft = ILI9341_t3n(TFT_CS, TFT_DC, TFT_RESET, TFT_MOSI, TFT_SCK, TFT_MISO, &SPIN2);
Right now it is not working properly so starting to debug. Actually this is the first time I have tried SPI2 code for these pins (tried for the others commented out on Beta1 3.6 board. Could not test on that board as several of these pins were not on Beta 1 board.

Hopefully after I get this working will test on Beta3 board, but was hoping to not have to solder pins on until I get one of my expansion boards...

User Error:
TFT_MOSI 44
TFT_MISO 45

So graphic Test on SPI2 with only using one CS pin also queue is only 1 item deep on SPI1 and SP2.

Code: 
isplay Power Mode: 0xCE
MADCTL Mode: 0x24
Pixel Format: 0x2
Image Format: 0x0
Self Diagnostic: 0xE0
Benchmark                Time (microseconds)
Screen fill              226382
Text                     15832
Lines                    64506
Horiz/Vert Lines         18580
Rectangles (outline)     11760
Rectangles (filled)      472090
Circles (filled)         78391
Circles (outline)        71962
Triangles (outline)      15797
Triangles (filled)       158977
Rounded rects (outline)  30722
Rounded rects (filled)   517308
Done!
Should mention the code I am running for the ILI9341_t3 display that works on the different SPI ports, with 1 or 2 hardware CS pins I have up on github:
https://github.com/KurtE/ILI9341_t3n it also relies on my quick and dirty SPI code converts the different SPI objects into a base class with instances for each is up at:
https://github.com/KurtE/SPIN

Warning should mention there may be debug prints in some of the code and it is mostly for testing...
 
Last edited:
I was looking at having updated TYQT work - not quite seeing the T_3.5 right yet - spamming Koromix with log files and findings - hoping to get updated code to lose the distraction. Using IDE with TeensyLoader very sad with multiple devices - having to GUESS the COM# and restart the SerMon between compiles when it gets lost. Having to Verify only, then Button push (which won't work with top headers when I plug in a board). For some reason my long trusted hub from laptop was going away on the desktop?

Teensy is so much better with TYQT! TYQT keys on the serial#. Somehow last night my T_3.5 was reporting serial# 2020 - but went right and hasn't recurred. T_3.6 hack I did for HSRUN is working on beta 3 board, having the PROTO board with no serial# messes up the works too.

KurtE - did you look at my simpler 'caching only' change to see the serial number from HSRUN on T_3.6? I would have done a PULL but my forked CORES needs a MERGE and I can't find that button on web or desktop.
 
defragster said:
Using IDE with TeensyLoader very sad with multiple devices - having to GUESS the COM# and restart the SerMon between compiles when it gets lost.
Click to expand...
You are using Windows, right?

With powershell:
Get-WMIObject Win32_SerialPort | Select-Object Description,DeviceID,PNPDeviceID | format-list

Description : Teensy USB Serial
DeviceID : COM20
PNPDeviceID : USB\VID_16C0&PID_0483\<<<Serial Number is here>>>
 
Sorry, I have not taken a look yet at your simpler caching yet. I could if you want.

Merging is fun ;)
I typically do one of two approaches (make that 3)
a) Punt
b) start over - That is, I put my changed files somewhere, then I kill my changed branch, I sync up to latest changes in Master. I have a batch script that does this with sledgehammer.
Code: 
cd \Users\Kurt\Documents\GitHub\Cores
git fetch upstream
git checkout master
git reset --hard upstream/master
git push origin master --force
But warning, this destroys anything you have in your current code including things that have changed and you have not saved...
Then I create a new branch again, and then I use something like winmerge to merge in my changes back into the new fork.... Then push/publish the changes...

c) I use the git merge stuff. Each time I do it I end up doing searches on net and look at pages like: http://stackoverflow.com/questions/7244321/how-do-i-update-a-github-forked-repository

FYI - I played around some this afternoon and hand merged in the pull requests for making the SDCard act like IO pins and then tested out my above ILI9341 SPIN version with these pins using one of the adapters I had made at Seeedstudio. As you can see it works :D

T3.5-with-display-on-SDCard.jpg
Actually would be sort of nice to be able to take the display from one machine to another...
 
tni: Yes, I am on Windows.

Kurt: simple step makes it work - but I don't know if where it is cached is static or if some other subsequent read might wipe it? Also does it need interrupt off/on around it like Frank's did?

Pluggable display is cool! if I had your pinout and software I could wire one up an ILI9341 on my adapter.

I wiped my web fork and re-forked - actually I didn't really look at desktop as the code is on my other computer.
 
defragster said:
Pluggable display is cool! if I had your pinout and software I could wire one up an ILI9341 on my adapter.
Click to expand...
Again this sort-of requires the two pull requests I mentioned earlier today (SPI and cores)
I am using the libraries I am using in #33 above.

The defines I am using in this case is:
Code: 
#ifdef SPI1_SDCARD
#define TFT_DC 62 // 0xe4
#define TFT_CS 63 // 0xe5
#define TFT_SCK 60 //0xe2
#define TFT_MISO 61 // 0xe3
#define TFT_MOSI 59 // 0xe1
#define TFT_RESET 58 // 0xe0
ILI9341_t3n tft = ILI9341_t3n(TFT_CS, TFT_DC, TFT_RESET, TFT_MOSI, TFT_SCK, TFT_MISO, &SPIN1);
#endif
And the Adapter boards I had made (sent a few to Paul ;) , which I believe you made some as well..
SDCard-Adapters.jpg
Have my pin numbers on the bottom.

Note: In this case I am using the Adafruit one as it is easier to wire in. Don't need the resister and like for the back light, but could be easily done. I defined the Reset pin o this, but have thought about using that pin for CS pin to sdcard...
 
Something odd with ILI9341 on my T_3.5 - Odd in that it won't work to run example/graphicstest?

Compile for T_3.6 using some private ILI9341_t3.h and it works, recompile for T-3.5 and it uploads and the USB out shows, but the display is white.

Compile for T_3.6 using KurtE ILI9341_t3n.h (with SPIN) and it works, recompile for T-3.5 and it uploads and the USB out shows, but the display is white.

This is true on T_3.6 PROTO and beta3 board using the proper version of this line for SPI0 ::

ILI9341_t3 tft = ILI9341_t3(10, 20, 255, 11, 14, 12);

ILI9341_t3n tft = ILI9341_t3n(10, 20, 255, 11, 14, 12);

Is there some subtle difference I don't know about with SPI0 and T_3.5 .vs. T_3.6?

All three units are like the PROTO with top side female headers. I have an ADAFRUIT PermaProto with bottom pins and top sockets that I can wire into and then as a unit plug to each of these devices.

I'm using a 2.4" TOUCH ILI9341 but actually started this to test a new 2.2" ILI9341 that worked on the T_3.6's. Neither sketch is anything but white on the T_3.5?

I just moved SCK from 14 to 13 and recompiled on T_3.5, I do see the LED blinking as expected, but still a white display? The T_3.6 is running the 2.2" ILI9341 now on the same SCK=13 sketch.

After soldering this is the first of anything plugged into the T_3.5, and I'm using the same uncoated wood pencil to press the program button on both of the KS Beta boards. I just scanned the solder on the bottom of the T_3.5 - nice clean and shiny, unlike the hazy ick on the T_3.6. There are wires in the headers for the Serial Loop Through, but they are the same on both with no serial pin conflicts.

Once I see this work I'll wire the SD CARD SPI on the 2.2" ILI9341.
 
In my post #11 I have some tests with K66 and K64 both running @120mhz, and the K66 is a little faster. This is probably due to the 8KB cache on the K66 (another difference between the two), maybe other reasons? @120mhz flash bus speed is 24mhz for both. I still haven't figured out why K64 is consuming a bit more power than K66 on simple loop/delay() test.

Re: SPI0. I have only run SerialFlash tests with propshield that uses SPI0. That seemed to work. Unconncected SPI0 performance was 27.3 mbs on both K66 and K64.
 
I tried the latest DmaSpi from github (worked for SPI0 on K66), but it hung on K64 (first test ok, non-DMA transfer). library does have conditionals for k64.
 
Hi Defragster, I will verify your pins in excel document to make sure no subtle difference.

First thing I would try is connecting up the Reset pin (not use 255) and see if that helps. I have had some of displays not work unless they are reset...

Update: I connected my Adafruit display up to the pins you mentioned. I did use pin 8 as a reset.

And the display appears to be working fine using my SPIN version.

I pushed up a delta to my test program that has this as a new case and currently as the default one...
 
Last edited:
manitou said:
I tried the latest DmaSpi from github (worked for SPI0 on K66), but it hung on K64 (first test ok, non-DMA transfer). library does have conditionals for k64.
Click to expand...
I also just updated to latest on github and confirmed it hangs.

I turned on debug support and added a few extra debug prints, which currently shows:
Code: 
Hi!
Buffers are prepared
Time for non-DMA transfer: 234us
src and dest match

Press a key to continue

DmaSpi::begin() : DmaSpi::start() : state_ = eStopped
DmaSpi::beginNextTransfer: no pending transfer
Transfer @ 0x2001fee8
Testing src -> dest, single transfer
--------------------------------------------------
Transfer @ 0x2001ff20
After Transfer
DmaSpi::registerTransfer(0x2001fee8)
  DmaSpi::addTransferToQueue() : queueing transfer
  starting transfer
DmaSpi::beginNextTransfer: starting transfer @ 0x2001fee8
  this was the last in the queue
  real sink
  real source
After register Transfer
The After register Transfer is just before loop:
Code: 
Serial.println("After register Transfer");
  while(trx.busy())
  {
  }
  Serial.println("Finished DMA transfer");
And you already had a serial print after so it is hung still in busy...
Will see if I see anything obvious. Note: I don't believe any specific #ifdef here as all of the casing for T3.5/3.6 was to add support for SPI1 and SPI2
 
Paul: (and maybe others)

Wondering about the capabilities of SPI1 and SPI2 on K64 and wondering if different than K66? In particular.

If you look at THe K66 document sections 57.1.4 (and 5), it is clear that SPI1/SPI2 only have fifo of one entry. But looking at the K64 manual, don't see any such distinction. Section 50.1.2 simply says:
• Buffered transmit operation using the transmit first in first out (TX FIFO) with depth
of 4 entries
• Buffered receive operation using the receive FIFO (RX FIFO) with depth of 4 entries
Click to expand...

Sounds like something to test in my SPIN stuff, where for T3.6 on SPI1/SPI2 you look at how many items are in queue before returning from the not full condition...
 
KurtE said:
Paul: (and maybe others)

Wondering about the capabilities of SPI1 and SPI2 on K64 and wondering if different than K66? In particular.

If you look at THe K66 document sections 57.1.4 (and 5), it is clear that SPI1/SPI2 only have fifo of one entry. But looking at the K64 manual, don't see any such distinction. Section 50.1.2 simply says:


Sounds like something to test in my SPIN stuff, where for T3.6 on SPI1/SPI2 you look at how many items are in queue before returning from the not full condition...
Click to expand...

K64 ref manual 3.9.4.4, table shows SPI1 and SPI2 with depth of 1 FIFO
 
Thanks for looking/confirming it should work - I'll check that my wires are solid - there is 'one(?)' wire I can touch and the K66 can go white, but a repower brings it back. Maybe the K64 is more sensitive? Problem is finding which of the 9 is the trouble on which end given the overlapping wires and close proximity. It seems something is floating as even pushing my finger near the wires was taking the K66 to white the other week. It wasn't that sensitive last night - but something was 'position sensitive'. The K66 ran fine overnight 8.5 hours.

Koromix just updated me on a new TYQT that should recognize the T_3.5! But I have to wait a couple hours to get to it and the display.
Current newest is TyQt-0.7.5-189-gfdbe8aa...
 
Last edited:
Status
Not open for further replies.
Back
Top