Teensy 4.0 First Beta Test

Status
Not open for further replies.
I reverted the local interval timer change last made to no attributes and it compiles :: static void (*funct_table[4])(void) = {dummy_funct, dummy_funct, dummy_funct, dummy_funct};

I had to rewrite my micros test since only the new micros is there - and after pulling my changes and looking for micros() delta by 10 us instead of 1 us it is working - but in both cases with and without my code - or the otherwise unchanged cores - millis and elapsedMillis are broken?

<edit> did a fresh folder install of IDE 1.88 and TD 1.45b7
It looks like I was using Serial.printf wrong all of a sudden - .print works ...
 
Last edited:
If I use 32BIT transfers, it looks like this:
View attachment 15613
o...even then gaps between BYTES..(32BIt!!) that effectivly halfes the transferrate.. What the hell i'm doing wrong? (24MHz here)
This is exactly what I saw on the Allwinner A20 (Dual-Core ARM Cortex-A7 using linux-sunxi driver). So solution seems tricky. Need to understand KurtE's suggestion better.
 
I've tried filling the fifo, setting LPSPI_CCR_DBT(0) - did not help. Then I've tried 32 Bit transfers - does not help ( I rewrote the blocktransfer function to use 32BIT if possible ) This is the most confusing issue for me, on my logic analyzer 32Bit look like 4x 8 bit with these gaps inbetween. Before that i've tried to use the CONT Bit - this stopped all transfers completely - I found no mention in the manual that this can happen.

I'll try the CONT bit again, tonight. Might be that I have used it wrong, last time. Or it is something with the receiver fifo - it might block, too - I had issues with this when I used DMA.
Apart from that, I have the impression that the internal clock of the LPSPI device (not SPI Clock - its internal bus clock) might be too slow.. so i'll try very slow transfers to see if that is the reason. It's just an idea.

edit: the manual calls it "Low Speed Periphal". well. ok....
 
Last edited:
yes.. just remove it :) copy&paste error.

Good to know - I did that in the end when I thought I was ready to merge and saw the pull change.

My refined and well tested though not very big change for micros() that was working to have the old and new micros the same when side by side is now oddly off by a huge round number [about 2^32/600000000] since I merged which is why I had the _isr_sync … it keeps time but shifted … maybe tomorrow ...
 
@KurtE
Downloaded the lastest (as of tues 07:30 EST) and ran problems. But first - to get the rest of the tests delete you wait for input code then the rest of the code works. Ok. Nothing gets displayed but looks like its trying and getting strange startup errors:
Code:
ILI9341 Test!
SPI MISO: 12 MOSI: 11, SCK: 13
ILI9341_t3n: Error not DC is not valid hardware CS pin
After TFT Begin
15
Display Power Mode: 0x88
MADCTL Mode: 0x88
Pixel Format: 0x88
Image Format: 0x88
Self Diagnostic: 0x88
Benchmark                Time (microseconds)
Screen fill              244740
Text                     10900
I did verify that the connections are correct using the Adafruit lib. Figure I am missing something

Mike

EDIT: Think I am lost with what you are doing with the CS and DC pin connections? I have CS as pin 10, and DC as 9, tried it the other way as well.
 
Last edited:
Question

USING ALTERNATE DEFINITIONS OF PINS - HOW TO?

Getting myself really confused on this one, trying to read the manual and testing. Looking at PINs 0 and 1 for instance the default is Serial1 (LPUART6). Now if I want to reassign it to XBARA or FLEXCAN. I was looking at the quadrature encoder module and it use the xbara pins for input. Anyway this is the process I think:

1. Turn LPUART6 clock off (CCGR3)
2. Disable the LPUART6 IRQ
3. didn't see a way to update the vtable so guess that stays
4. Update pin configurations, i.e.,
Code:
000 ALT0 — Select mux mode: ALT0 mux port: FLEXCAN2_RX of instance: flexcan2
001 ALT1 — Select mux mode: ALT1 mux port: XBAR1_INOUT17 of instance: xbar1
010 ALT2 — Select mux mode: ALT2 mux port: LPUART6_RX of instance: lpuart6
and sion bit to enable
5. Select input - output modes for pins, i.e.
Code:
IOMUXC_FLEXCAN2_RX_SELECT_INPUT for Flexcan
xbar_connect  (saw this in pwm.c)
6. Configure Flexcan2 or Xbar clocks
7. Enable clocks with CCM_CCGR0 or CCM_CCGR2
8. Almost forgot enable IRQs for XBAR or FLEXCAN2

Still need to work some of the details but just want to see if this makes sense and I am on the right track.

No takers on this question or did it get lost with all the other messages :)
 
@mjs513 -

On my test code - I have CS=9, DC=10, reset=8 and then the normal 11-13 for other SPI stuff... Currently It is on wireless breadboard as the breakout board does not have all of the signals...

As mentioned probably still some other issues. Which causes some of the display commands not to work and as you mentioned it hangs waiting for input on Serial, which is not working.

Using Alternate of pins - Yes probably lost in the other messages... Actually wish there was a Beta forum, so it would be easier to follow all of the sub-threads...

But For defining the different like pins 0 and 1... They default to probably GPIO. Or maybe just in some random start up state...

But if it were me, the things I would probably do is ignore thinking about LPUART6 here... If the user was previously using Serial1... Maybe they should call Serial1.end()...

I have not looked at Flexcan2 or XBar so not sure what the exact settings are.. But for example if you look at SPI...
Example SPI::begin() for T4 about line 1270...

For some reason it first turned off it's clock... (was there before I did some stuff). It setup some of the actual clocks... CCM_CBCMBR_

It updates port Control registers to setup things like speeds drive strength... With code that does something like:
*(portControlRegister(13)) = IOMUXC_PAD_SRE | IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3);

It then re-enabled the SPI clock... Again not sure the unsetting it before was needed...

Then the important lines to enable the pins for the mode you want translatest to something like:
*(portConfigRegister(13)) = 3 | 0x10;

This set the pin into mode 3 - SPI and sets the SION (Software Input On Field)... again for the SCK pin this is described at about page 500 in PDF..

Other complication that I ran into on one of the UARTS is that if a same logical function can be on more than one physical IO pin and you are not on the sort of default one you may have to set its select input daisy register... This hit me on the RX pin for Serial1 (UART6), it was not the default (0) value and as such I was not receiving any data from the RX, until I set the register LPUART6_RX_SELECT_INPUT register to 1.. Page 861

Maybe other stuff, but that is what I have found so far...
 
yeah the daisy register is a mux that the peripheral talks through, and that mux has the path to one of the X pins of the actual pin the hardware is attached to. when changing pins for peripherals its a good idea to point the daisy register at the correct path for sanity check, especially if other user code changed it before hand. Seeing as serial is part of the core no need to do that, however in the case of FlexCAN on pins 1 and 2, the default path is not set to that pin, so the daisy chain register needs to follow the same path. Although currently flexcan_t4 is having no issues changing the registers and attempting to transmit, not getting any data in or out through the pins, thought it may be a conflict with serial but ive disabled serial in the core and still no dice.

EDIT, forgot to mention the MCR is able to goto normal CAN operation mode and the transmit buffers just fill up because no in/out data, have t3.2 and t3.5 and t4 on the bus, the t3’s are talking to each other and t4 is just sitting playing dead. my mailboxStatus code verified that all the transmit buffers are full, even the vector is set, daisy set, clocks enabled, etc
 
I've tried filling the fifo, setting LPSPI_CCR_DBT(0) - did not help. Then I've tried 32 Bit transfers - does not help ( I rewrote the blocktransfer function to use 32BIT if possible ) This is the most confusing issue for me, on my logic analyzer 32Bit look like 4x 8 bit with these gaps inbetween. Before that i've tried to use the CONT Bit - this stopped all transfers completely - I found no mention in the manual that this can happen.

I'll try the CONT bit again, tonight. Might be that I have used it wrong, last time. Or it is something with the receiver fifo - it might block, too - I had issues with this when I used DMA.
Apart from that, I have the impression that the internal clock of the LPSPI device (not SPI Clock - its internal bus clock) might be too slow.. so i'll try very slow transfers to see if that is the reason. It's just an idea.

edit: the manual calls it "Low Speed Periphal". well. ok....
HI Frank might help to see what you are doing? Do you have some example code showing what you are doing? Are you trying to do standard polled input and output or are you trying to do use DMA?

Again I am still debugging my code for the ili9341_t3n, in particular I think how to know when to clear/set the CS pin (i.e. when exactly all of the data has been output)... But I am having some luck now with DC pin on the one hardware CS pin...

And current stuff, which sometimes gets what looks right on the screen, shows reasonable performance:
screenshot.jpg
Note: What I accidentally cut off here at start of screen shot was where it was outputting the 0x2c (memory write) for the start of a fill screen. And then it switches DC off (which appears to add a little delay) of it taking the TCR register off stack... Actually maybe because I only put TCR on when it is empty, which I put in earlier when I read an errata for an issue which may not apply...

Now back to debugging...
 
Morning Kurt
On my test code - I have CS=9, DC=10, reset=8 and then the normal 11-13 for other SPI stuff... Currently It is on wireless breadboard as the breakout board does not have all of the signals...

As mentioned probably still some other issues. Which causes some of the display commands not to work and as you mentioned it hangs waiting for input on Serial, which is not working.
Tried that pin configuration as well - will put it back just as a double check. Funny thing is when I used the adafruit version the follow construct would work:
Code:
Adafruit_ILI9341 tft = Adafruit_ILI9341(10, 9, 11, 13, 8, 12);
but this would not
Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC);
wonder if I have to do the same.

Using Alternate of pins - You gave me a couple of more things that I didn't think about, a few I had like the daisy chain - which took a while to comprehend and Scion bit. Enabling the pins didn't think about. But will definitely look at what you did for SPI begin. Thanks this really helped.

Mike
 
Since we are talking about the daisy register one of the perfect uses is when sharing the SPI interface. Let’s say the MISO pin of one device cannot tristate (damn them!), you can share the SCK and MOSI pins, have separate MISO outputs, both muxes enabled (0x13). Then you’d only need to change the daisy path to the device’s MISO you want to talk to. You could do the same with setMISO I guess, but perhaps this may allow faster switches if the pins are already active
 
Good Morning Mike,

Yep - it is still a bit flaky... I think it still has to do with my CS pin handling. What I saw the hardware CS pin used for DC looked pretty solid.

I think I am going to try another hack for CS pin between these two of my own libraries. Sort of what I did to try to make the library also work with TLC...

That is I will count how many things pushed (increment) on TX queue and then decrement everytime I pull something off RX queue and when zero I know I should be done... See how that works out... Again sort of a kludge.

Alternate pins: This one bit me for maybe a day on HardwareSerial. I had output working great, thought everything was setup for Input but was not seeing anything... Of course I was doing all of my testing on Serial1... Which turned out to be the one with this issue...
 
Question

No takers on this question or did it get lost with all the other messages :)
The EVKB SDK had an encoder example (which I believe you tested on the EVKB) that used the XBAR to map GPIO pins to the Encoder A, B, and Index inputs. In fact, i don't think the T4 encoder peripheral has any defined GPIO pins of its own.
 
Last edited:
This vtable error is some sort of C++ thingee above my old C skills. Here is the simplest program that gets compile errors on T4, works on T3.2. (I believe i have copied in stream.cpp and WString.cpp into my T4 core folder)
Code:
#include <IPAddress.h>
IPAddress ip(192, 168, 1, 15);
void setup() {
  Serial.begin(9600);
  while(!Serial);
  delay(1000);
  Serial.println(ip);
}

void loop() {
}

The FIX: copy teensy3/IPAddress.cpp to teensy4/
 
Good Morning Mike,

Yep - it is still a bit flaky... I think it still has to do with my CS pin handling. What I saw the hardware CS pin used for DC looked pretty solid.

I think I am going to try another hack for CS pin between these two of my own libraries. Sort of what I did to try to make the library also work with TLC...

That is I will count how many things pushed (increment) on TX queue and then decrement everytime I pull something off RX queue and when zero I know I should be done... See how that works out... Again sort of a kludge.

I just put this hack into both libraries and I think things are working pretty well now... I also enabled some of the Frame buffer code in this library, where you can turn on frame buffer, do all writes to it and then say update now... This part appears to be maybe working :D Still need to work on the DMA part of it, All of that code is disabled currently...

But if you (Or anyone else) wish to give it a try, Both SPIN and ILI9341_t3n github projects were updated...

Also I have a test program that I used for working on Frame buffer, plus offsets/clips, Font's stuff, that I hacked up to work, and it is currently setup to use Serial4 for Inputs and Outputs as Inputs work :D and so far does not work on Serial.

Here is screen shot showing start of a full frame update:
screenshot.jpg

And the end of it:
screenshot.jpg
 

Attachments

  • Kurts_ILI9341_t3n_FB_and_clip_tests-190116a.zip
    93 KB · Views: 81
The EVKB SDK had an encoder example (which I believe you tested on the EVKB) that used the XBAR to map GPIO pins to the Encoder A, B, and Index inputs. In fact, i don't think the T4 encoder peripheral has any defined GPIO pins of its own.

@manitou
Nope. You are right the Quadrature encoder in the SDK uses the XBAR pins so the I pins have to be redefined, XBAR is an alternate pin configure. That's why I was asking about reconfiguring the pins.
 
Last edited:
I just put this hack into both libraries and I think things are working pretty well now... I also enabled some of the Frame buffer code in this library, where you can turn on frame buffer, do all writes to it and then say update now... This part appears to be maybe working :D Still need to work on the DMA part of it, All of that code is disabled currently...

But if you (Or anyone else) wish to give it a try, Both SPIN and ILI9341_t3n github projects were updated...

Also I have a test program that I used for working on Frame buffer, plus offsets/clips, Font's stuff, that I hacked up to work, and it is currently setup to use Serial4 for Inputs and Outputs as Inputs work :D and so far does not work on Serial.

Here is screen shot showing start of a full frame update:
….

And the end of it:
…..

@KurtE
Ok just downloaded latest updates to SPIN and ILI9341 WIP libraries as well as redownloading your SPI fork just in case. I am still getting that pin 10 is not a valid CS pin and I changed to your pin configurations:
Code:
#define TFT_DC  10  // only CS pin 
#define TFT_CS 9    // using standard pin
#define TFT_RST 8
ILI9341_t3n tft = ILI9341_t3n(TFT_CS, TFT_DC, TFT_RST);
Not sure what I am missing here that its not working for me? Getting the diagnostics error of 0x88.
 
@KurtE
Ok just downloaded latest updates to SPIN and ILI9341 WIP libraries as well as redownloading your SPI fork just in case. I am still getting that pin 10 is not a valid CS pin and I changed to your pin configurations:
Code:
#define TFT_DC  10  // only CS pin 
#define TFT_CS 9    // using standard pin
#define TFT_RST 8
ILI9341_t3n tft = ILI9341_t3n(TFT_CS, TFT_DC, TFT_RST);
Not sure what I am missing here that its not working for me? Getting the diagnostics error of 0x88.
Which SPI fork did you sync up to? It should be: https://github.com/KurtE/SPI/tree/T4-SerialFlash-fix

And if anyone else wishes to try it out:
https://github.com/KurtE/SPIN/tree/T4_WIP

and
https://github.com/KurtE/ILI9341_t3n/tree/T4_WIP
 
Ok, consider my SPI problem as solved/not existent.. All the time I was testing (+ LA on clk) with a SD-Benchmark. Was too lazy to write my own short test.
I wrote a minimal example now, that uses SPI.transfer with buffer - and this works(?). So whatever the problem is, it does not seem to be SPI. Sorry.

I continue to re-write my ILI-lib tonight (that part that I wanted to do last weekend.) I'll use more transactions, and interrupts and split the refresh in four parts, so that it is more nice to other SPI-devices, and commands like rotate work any time.
 
@KurtE

Ok that got it - used wrong branch the ding bat that i am. Anyway now it works like a charm. Just for comparisons at this point i updated the benchmark table that i generated earlier, post #827. Big difference in most cases.

Code:
                         T3.5(120)                   T4
Benchmark                             Time (microseconds)
                                                           PODF(2)       PODF(6)      _t3n
Screen fill              993332           885880           888130        993390       245580
Text                     59506            43820            44620         48940        11680
Lines                    551647           416280           424020        464270       68780
Horiz/Vert Lines         81940            72440            72680         81230        20110
Rectangles (outline)     52453            46120            46300         51700        12810
Rectangles (filled)      2061753          1838640          1843310       2061770      504870
Circles (filled)         252396           208710           211020        233870       77500
Circles (outline)        240152           182130           184900        203190       63140
Triangles (outline)      124360           94820            96410         105790       16500
Triangles (filled)       683284           597780           600630        670140       168510      
Rounded rects (outline)  109180           86970            87990         97200        27860
Rounded rects (filled)   2055773          1828310          1833510       2050110      551660
Rectangles (filled) FB                                                                51800
Rounded rects (filled) FB                                                             55210
Looks like your trickery worked !
 
Last edited:
@mjs513 - Glad you got it working! I should have done like the last posting and put in links to each of the github projects/forks...

Hopefully @Paul will pick up the SPI PR as well as the CORES PR for SPI soon...

When that happens I will probably pull my T4 branches of SPIN/ILI... into my master branches...

@Paul/@Frank - Not sure if I should pull some of this back into the main ili9341_t3 library? How much?
Note: earlier on I did have a PR to the main library where I merged in lots of the stuff from my ili9341_t3n library, like the ability to work with only one hardware CS pin, which is the case here. Also support for other SPI objects other than just the main SPI object...

Actually looking at the PR... https://github.com/PaulStoffregen/ILI9341_t3/pull/41 it was two years ago 8)

Doing a quick test here to see how hard it is to get the DMA update working as well in here (ili9341_t3n) as I had it working for T3.6 and T3.5...

But still may break off and play with FLEX IO pins.

Kurt
 
hardware dma is pretty easy.. i have 32bit dma now. can send you some code, then you can use it in your lib.. better when all is in one place :)
is it possible to use the "autorefresh" with your library? (and if it works without setting #defines, that would be great and my lib not needed)

edit: and a way to select a *fast* spi clock (without a #define.. makes it easier for users) - tried with 66MHz - works good and would be perfect :)
 
Last edited:
Status
Not open for further replies.
Back
Top