Forum Rule: Always post complete source code & details to reproduce any issue!
Page 16 of 175 FirstFirst ... 6 14 15 16 17 18 26 66 116 ... LastLast
Results 376 to 400 of 4368

Thread: Teensy 4.0 First Beta Test

  1. #376
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,949
    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.

  2. #377
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,910
    Ah, ok - somebody wrote that it has no spi-fifo... or i've misread something...

  3. #378
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,365
    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);
    }

  4. #379
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,534
    Quote Originally Posted by mjs513 View Post
    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/co...ensy4/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 by manitou; 01-03-2019 at 09:33 PM.

  5. #380
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,826
    Kurt >> Works - pinning 20 to 21 and in code :: #define SERIALX Serial5


    Quote Originally Posted by KurtE View Post
    Hardware Serial testing -
    Loop back test:
    ...

  6. #381
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,826
    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

  7. #382
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,365
    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!!!!

  8. #383
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,365
    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 by mjs513; 01-03-2019 at 10:41 PM.

  9. #384
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,365
    @Frank B

    Just gave your loop back test a go and it worked for me no problem - test serial1 and 3.

  10. #385
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,826
    Quote Originally Posted by mjs513 View Post
    @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?

  11. #386
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,365
    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.

  12. #387
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,826
    Quote Originally Posted by mjs513 View Post
    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.
    Thanks for confirming it isn't just my machine. If there is any Serial output without SerMon active the T4 BLOCKS - The other Teensy units do not do that.

    I'll go add to Msg #6 … already there - updated text and a newer link

  13. #388
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,115
    Quote Originally Posted by manitou View Post
    I think the core copies flash to RAM before starting ... so need SLOWRUN
    You have it. It's spelled "PROGMEM".

  14. #389
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,949
    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.

  15. #390
    Senior Member
    Join Date
    Jan 2014
    Posts
    160
    I work with fastled and smartmatrix. I can help with these two if beta is provided. Richard Ferraro.

  16. #391
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,826
    PROGMEM was my assumption Nov 20th:
    Quote Originally Posted by PaulStoffregen View Post
    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...
    ...
    Quote Originally Posted by defragster View Post
    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.

  17. #392
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,826
    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 by defragster; 01-04-2019 at 06:59 AM.

  18. #393
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,910
    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.

  19. #394
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,115
    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.

  20. #395
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,910
    Okay.

    Is there a way to disable the cache for the buffer? Caching it makes no sense.

  21. #396
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,115
    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!

  22. #397
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,910
    - 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 by Frank B; 01-04-2019 at 11:42 AM.

  23. #398
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,910
    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.

  24. #399
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,365
    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?

  25. #400
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,949
    Quote Originally Posted by PaulStoffregen View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •