Teensy 4.0 First Beta Test

Status
Not open for further replies.
The main issue about porting ili9341_t3 is not that there is not a FIFO, but that the fifo does not include information about the desired state of up to 4 Chip select pins, which we use to encode both the CS, but more importantly the DC state. Without this, you typically have to wait until the queue is empty, before changing the state of these pins, which adds in delays.

Without this, not sure how much higher performance you will get then using SPI library support, especially if we get the DMA support into the library.
 
Been trying to test analogReadResolution, analogReadAveraging and analogReference using the sharp IR sensor as input on pin A0. To be honest don't see much difference between resoultions Using the following sketch to test: Is there a better way?
Code:
void setup() {
  // open a serial connection
  Serial.begin(9600);
}

void loop() {
  // read the input on A0 resolution (10 bits)
  // and send it out the serial connection
  //analogWriteResolution(10);
  analogReadResolution(10);
  //analogReadAveraging(200);
  Serial.print("ADC 10-bit: ");
  Serial.print(analogRead(A0));

  // change the resolution to 12 bits and read A0
  analogReadResolution(12);
  //analogWriteResolution(12);
  analogReadAveraging(5);
  Serial.print(", 12-bit : ");
  Serial.print(analogRead(A0));

  // change the resolution to 8 bits and read A0
  analogReadResolution(8);
  //analogWriteResolution(8);
  analogReadAveraging(5);
  Serial.print(", 8-bit : ");
  Serial.println(analogRead(A0));

  // a little delay to not hog Serial Monitor
  delay(100);
}
 
Been trying to test analogReadResolution, analogReadAveraging and analogReference using the sharp IR sensor as input on pin A0. To be honest don't see much difference between resoultions Using the following sketch to test: Is there a better way?
Code:
void setup() {
  // open a serial connection
  Serial.begin(9600);
}

void loop() {
  // read the input on A0 resolution (10 bits)
  // and send it out the serial connection
  //analogWriteResolution(10);
  analogReadResolution(10);
  //analogReadAveraging(200);
  Serial.print("ADC 10-bit: ");
  Serial.print(analogRead(A0));

  // change the resolution to 12 bits and read A0
  analogReadResolution(12);
  //analogWriteResolution(12);
  analogReadAveraging(5);
  Serial.print(", 12-bit : ");
  Serial.print(analogRead(A0));

  // change the resolution to 8 bits and read A0
  analogReadResolution(8);
  //analogWriteResolution(8);
  analogReadAveraging(5);
  Serial.print(", 8-bit : ");
  Serial.println(analogRead(A0));

  // a little delay to not hog Serial Monitor
  delay(100);
}

You have a new project, ReadResolution and ReadAveraging and analogReference (not needed? REEFSEL has only one option) have not been implemented!
https://github.com/PaulStoffregen/cores/blob/master/teensy4/analog.c

Also To Be Done:
1) SPI lib, SPI CLK only runs at one speed (12.5 mhz)
2) I2C lib, I2C SCL only runs at one speed (100 khz)
 
Last edited:
Kurt - do me a favor - next time running that Serial Loop back - after starting it up - Close the SerMon. I just did and the LED #13 stops ON - and re-open of SerMon picks up where loop_counter left off.

And if started with No SerMon - I get the 5 LED #13 blinks - then it stays ON. Then on SerMon open it prints "Loop 1" and runs.

This is in ref to this post
 
You have a new project, ReadResolution and ReadAveraging and analogReference (not needed? REEFSEL has only one option) have not been implemented!
What an idiot I am - saw it on the list and thought it was ready for test. Think I need to step away from this for awhile ARGH!!!!
 
TinyGPS Library

Just tested and works fine. No changes. Running on Serial1 at 57600

EDIT: ADDED GPS LIBRARIES TESTED
BOLDERFLIGHT UBLOX LIBRARY
Works - no problem

Chris O's UBLOX LIBRARY
Works - no problem.
 
Last edited:
@Frank B

Just gave your loop back test a go and it worked for me no problem - test serial1 and 3.
 
Was that with KurtE's Serial? What do you see if you close SerMon while running?
Oops sorry Kurt - got confused. Yes, the LED stays on bright when the serial monitor is closed. Looks like for any sketch to run the SerMon has to be opened otherwise the sketch stops.
 
Yep - Sorry I thought I responded earlier, but I guess I never hit the post button..

I have found that my apps that use the USB Serial object does not run without the Serial monitor running.

Including things like: while (!Serial && millis() < 3000)) ;
I am not sure if it hangs there or when the Serial.begin() is called, but...

I meant to mention it earlier, but as Paul is going to rewrite a bunch of it next week, thought I would wait to see if still did that then.
 
PROGMEM was my assumption Nov 20th:
Yes, there will be a way to cause a function to go into slow flash, pretty much the opposite of FASTRUN we have now. It will have a familiar name... ;)
...

PROGMEM ?

Yes Kurt - Serial writes Block with no SerMon - that was my request looking for confirmation in post #381

I noticed that Last Year :) Dec 31st in post #182 and it got logged … That came with Beta #4 in post #180 - it worked non-blocking in the prior beta - at the same time startup entry and Serial online came 100 [or more ] ms later than prior beta 3.

No doubt it will get fixed - but like the dead cycle counter it can mess with testing - I was doing the 1.5 MB SPEW testing and then killing SerMon to save the USB overload - and was testing for 'if ( Serial )' that came online in Beta 3 - then it went blocking … thought it was my machine as nobody else noticed.
 
KurtE - Good work on the Serial! I have a sketch loopback (to self not crossed) on Serial #1 and #5 running in parallel at 1 Mbaud. Only odd thing is an occasional extra line break showing in TyComm window (below)? <Odd extra line not in T_sermon>

Here you can see the two are in sync - does one and then the other in code the same the fashion you had one with unique loop_counter# variables - except I remove the pin #2 signaling. Been running some time with two delay(100) in loop. Odd they alternate in code but often pair up in prints?

> Loop1 33038
<Loop5 33037
<Loop5 33038
> Loop1 33039

> Loop1 33040
<Loop5 33039
<Loop5 33040
> Loop1 33041
> Loop1 33042
<Loop5 33041
<Loop5 33042
> Loop1 33043
> Loop1 33044
<Loop5 33043
<Loop5 33044
> Loop1 33045
> Loop1 33046
<Loop5 33045

<Loop5 33046
> Loop1 33047
> Loop1 33048
<Loop5 33047
<Loop5 33048

It is Working Crossing #1Tx>#5Rx and #5Tx>#1Rx at 2Mbaud and looks good. Are the FIFO's not in use yet? Also dropped the pair of delays to delay ( 10 ); with a pause every 100 counts and show millis run time. That shows a spare blank line every few hundred as well, no other loss or corruption.
<EDIT: BAD NOTE removed > - button push not required - false alarm - I was using TyComm that was holding Serial USB preventing AUTO
<Note 2>: Back to T_sermon and I don't see those spare blank lines that TyComm oddly showed - so that can be ignored as well.

<Note 3>: Also went to 3Mbaud and turned on IntervalTimer at 2 us - with delay(500) once per second to read screen it is triggering 750K per ~1.5 sec interval. And cut down to delay(6) between crossed send receives - No Issues.

Looks good like this:
> Loop1 31097
<Loop5 31097
> Loop1 31098
<Loop5 31098
> Loop1 31099
<Loop5 31099
> Loop1 31100millis = 1459629
 
Last edited:
I'll try to get the ili9341_t3 running this weekend.
This will test SPI, too.
And if I have time I'll try to port my ili9341_dma variant too, which involves some testing of dma.
 
For ILI9341, I believe the Teensy 4 optimized library should look something like your DMA version, where all drawing is done to a big frame buffer in RAM.
 
The MPU can define up to 16 regions with different access rights and caching settings. We're currently using 6 of them, and I'm planning to add 3 more eventually. See configure_cache() in startup.c for details. Not mentioned in the comments is a long-term idea I have for the bootloader which might involve a 4th region, so assume no more than 6 are available.

But why would you wish to disable caching for a TFT display frame buffer? That makes no sense to me. It saves very little every ~33 ms when you refresh the display, but it costs a lot when you're rendering fonts, drawing lines, or doing pretty much any graphics other than copying large groups of pixels. Even for block copy, write-back cache is likely to help. Your code can more fully utilize the bus to read whatever pixels you're using and let the writes happen later. The writes will be grouped into highly optimized 8 word bursts on the 64 bit AXI bus, rather than 1 word at a time utilizing only 32 of the 64 bit path to the memory. If the source is in fast DTCM, caching lets the slower OCRAM writing happen later when the user's code isn't waiting.

Especially for fonts, icons or images with masks, lines, special shapes, and alpha blending, rendering to the frame buffer involves read-modify-write operations. Usually that sort of code has strong locality of reference (you're highly likely to do another operation within the same 32 byte area). That's where the cache *really* helps!
 
- Currently, the library has nothing like that. There is a getpixel and a function to read memory, that's all. Getpixel is not used by the library itself, if I remember correctly. All other functions are write-only.
- The only case where caching writes makes sense, currently, is when drawing a horizontal line (and even then only for neighbour-pixels in half of the cases (16-bit per pixel) ) or accesses to a small region very near a pixel short before.
- The cache is much smaller than the buffer..isn't it 32kb? if you do a fillscreen, it means to overwrite the whole cache several times, and it gets filled with pretty useless data (edit: and most likely throws away more useful cached data)

For *future* extension like alphablending, smoothing and other things it can make sense, yes. *if* it has strong locality.
A compromise would be to to configure that region to cache reads only, so the neighbour-pixels on the same line can fill a cache-line. Edit: I don't know if this is possible.
 
Last edited:
Let's do benchmarks :)
If i'm wrong and the enabled cache helps I'll buy some T4 more :) But it must be a real-world benchmark, with a real, useful, app.
 
ANALOGREADAVERAGING

think I got the analogreadaveraging function working. If someone besides me wants to give it a try here is a standalone copy before I propose the change:
Code:
void setup() {
  // open a serial connection
  Serial.begin(9600);
  delay(4000);
  aRAveraging(5);
}

void loop() {
  // change the resolution to 12 bits and read A0
  Serial.println(analogRead(14));

  // a little delay to not hog Serial Monitor
  delay(100);
}

void aRAveraging(unsigned int num)
{
  uint32_t tmp32, mode, avg=0;
  
  //disable averaging
  tmp32 = ADC1_GC;
  //Serial.println("ADC1_GC :"); Serial.println(ADC1_GC, BIN);

  ADC1_GC &= ~0x20;
  //Serial.print("Turn off ADC1_GC :"); Serial.println(ADC1_GC, BIN);
  //Serial.print("Initial ADC1_CFG :"); Serial.println(ADC1_CFG, BIN);

  mode = ADC1_CFG & ~0xC000;
  //Serial.print("Clear bits ADC1_CFG :"); Serial.println(mode, BIN);

    if (num >= 32) {
      mode |= ADC_CFG_AVGS(3);
      //Serial.println(ADC_CFG_AVGS(3), BIN);
    } else if (num >= 16) {
      mode |= ADC_CFG_AVGS(2);
    } else if (num >= 8) {
      mode |= ADC_CFG_AVGS(1);
    } else {
      mode |= ADC_CFG_AVGS(0);
    }

  ADC1_CFG = mode;
  //Serial.print("After avg set :"); Serial.println(ADC1_CFG, BIN);

  
  //enable averaging
  //ADC1_GC &= ~(ADC_GC_AVGE & 0x20);
  ADC1_GC = tmp32;
  //Serial.print("Turn on ADC_GC :"); Serial.println(ADC1_GC, BIN);
}

I think if I am reading the manual correctly if I try to change resolution I need to essentially re-init the ADC module (turn module off and re-cal), is this correct or can I just change the resolution with the restart on the module?
 
For ILI9341, I believe the Teensy 4 optimized library should look something like your DMA version, where all drawing is done to a big frame buffer in RAM.
You might want to take a look at my ili9341_t3n version which supports the DMA buffering mode as well. Although I have used mine more in a different way then you had done with your _dma version in that I did not typically run it in continuous update mode. As I wanted more control on when things update as to not have probable flashing or partial updates...

Also I have not looked at the _dma version for awhile, but at least back then, my version may have been more complete, like supporting all 4 directions, all of the primitives were updated to work either buffered or not buffered, clipping, offsets...

Depending on who gets there first, I will try converting as well...

But right now probably higher priority to finish some of the SerialX support. I have more features on my machine to test out... Also not sure yet if SPI has the DMA (Async transfer) support yet? If not, would be a nice thing to add in... (At one point I had a 16 bit version transfer buffer async, which I was playing with and at that time I was playing with version of display library that used it... So all of the DMA support was taken care of by the SPI library... But that was awhile ago, before we then converted to SPI to use event responder.
 
Status
Not open for further replies.
Back
Top