Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 26 to 50 of 76

Thread: Teensyduino 1.53 Beta #2

  1. #26
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,297
    I ordered the 5 inch 480x272 display.

    Here's the wiring I used between Teensy 4.0 and the 7 inch display.

    Click image for larger version. 

Name:	ra8755wires.jpg 
Views:	11 
Size:	91.9 KB 
ID:	20677

  2. #27
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,297
    Well, maybe I have a flaky Buydisplay? I'm running the mangGauges_800x480 example on Adafruit's RA8875 (which measures about 5 inches) . It works fine with Teensy 4.0 at 600 MHz or even overclocked to 720 MHz.

    Click image for larger version. 

Name:	ra8875adafruit.jpg 
Views:	13 
Size:	127.1 KB 
ID:	20678

  3. #28
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,297
    Quote Originally Posted by KurtE View Post
    And it looks like I maybe missed removing a warning from digitalToggle()
    unused variable (pinMode)...
    Fixed.
    https://github.com/PaulStoffregen/co...65f341a674a494

  4. #29
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,162
    @Paul - Thanks

    @mjs513 - GFX fonts appear to be screwed!
    I have Warnings fixed in example... Have not setup to do PR yet, just need to convert the wt ht variables to be uint8_t instead of int8_t...

    Next up, see if how Adafruit may have updated their GFX fonts...

  5. #30
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,162
    @Paul and @mjs513 - Yes Adafruit changed the GFX Font format last month.

    They changed the top level first/last frim uint8_t to 16 bits... So all of our drivers that attempt to display the GFX font characters are at pot luck on if it will work or not.
    If you have not updated your GFX it works, if you are up to date ... It don't...

    Looks like we need to hack up code for ILI9483_t3n (not part of build) st7735_t3(89), RA8875...

    Not sure if we can deduce the format, by looking at something, I can probably do a quick and dirty hack that if last==0 probably new format or some such thing...

    Note: I issued an issue on GFX to see if they have any suggestions

  6. #31
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,474
    Sorry had to run out to the store. Needed to let the car run awhile - battery died yesterday today ok.

    Just tested probably the same board you have @Paul just to see if it works and no problems either. Just as a note my Adafruit display seems to run with or without the GPIOX(true) ?

    May not be a flaky display - will have to get another one hooked up as a sanity check.

    @KurtE - yeah see what you mean with the GFX fonts. It doesn't look like they changed the glyph structs or glcdfont.c. Just did a copy and paste of that. Have to dig deeper.

    EDIT = oops cross post

  7. #32
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,474
    Ok fixed issue with GFX fonts - real easy:
    1. substitute new font structure in glcdfont.h for what we have in RA8875.h
    Code:
    /// Font data stored PER GLYPH
    typedef struct {
      uint16_t bitmapOffset; ///< Pointer into GFXfont->bitmap
      uint8_t width;         ///< Bitmap dimensions in pixels
      uint8_t height;        ///< Bitmap dimensions in pixels
      uint8_t xAdvance;      ///< Distance to advance cursor (x axis)
      int8_t xOffset;        ///< X dist from cursor pos to UL corner
      int8_t yOffset;        ///< Y dist from cursor pos to UL corner
    } GFXglyph;
    
    /// Data stored for FONT AS A WHOLE
    typedef struct {
      uint8_t *bitmap;  ///< Glyph bitmaps, concatenated
      GFXglyph *glyph;  ///< Glyph array
      uint16_t first;   ///< ASCII extents (first char)
      uint16_t last;    ///< ASCII extents (last char)
      uint8_t yAdvance; ///< Newline distance (y axis)
    } GFXfont;
    2. I did copy over the latest glcdfont.c into the RA8875 directory

  8. #33
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,474
    Just posted a response on Github

  9. #34
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,162
    @mjs513 and @paul - I did a PR for RA8875, that looks like it worked for me..

    If not LadyAda replied to Issue I raised that we could request that change undone as the person who did it, decided to fork the library and do their support of UTF fonts differently...

    But if the above works for you, we need to also do for the other displays as well.
    Ili9341_t3n updated

  10. #35
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,474
    @KurtE and @PaulStoffregen

    Went ahead and did the merge of the PR and added the GPIOX(true) for Adafruit displays in the "begin" function.

  11. #36
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,162
    @mjs513 - I also did a PR on the ST7735_t3 code for same issue: https://github.com/PaulStoffregen/ST7735_t3/pull/17

    and as mentioned already did for ili9341_t3n... Have not done yet for RA8876, nor ILI9488_t3...

    Will try to do 9488 soon unless someone beats me... But getting ready for another round of Sushi

  12. #37
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,474
    Quote Originally Posted by KurtE View Post
    @mjs513 - I also did a PR on the ST7735_t3 code for same issue: https://github.com/PaulStoffregen/ST7735_t3/pull/17

    and as mentioned already did for ili9341_t3n... Have not done yet for RA8876, nor ILI9488_t3...

    Will try to do 9488 soon unless someone beats me... But getting ready for another round of Sushi
    Updated ILI9488, HX8357 and RA8876 with the GFX font changes.

  13. #38
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,162
    Thanks

    I started doing ILI9488, but was having issues with the display running the fonts4 test on T4.x and wanted to get back to it, but then

    it was time to eat...

    So will pick up your changes and try again Probably just wiring issues.

  14. #39
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,162
    @Paul - You should probably pickup the updated libraries that are part of the build, that have these changes to isolate our drivers somewhat from GFX changes.

  15. #40
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,297
    Quote Originally Posted by KurtE View Post
    @Paul - You should probably pickup the updated libraries
    Done. I've pulled in the latest for RA8875, ST7735_t3 and ILI9488_t3.

    I'm still looking though a long list of compiler warnings & errors. Seems ILI9488_t3 examples UpdateAsyncCont_Test and Kurts_ILI9488_t3n_FB_and_clip_tests may still be using extRAM_t4.h.

  16. #41
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,474
    Quote Originally Posted by PaulStoffregen View Post
    Done. I've pulled in the latest for RA8875, ST7735_t3 and ILI9488_t3.

    I'm still looking though a long list of compiler warnings & errors. Seems ILI9488_t3 examples UpdateAsyncCont_Test and Kurts_ILI9488_t3n_FB_and_clip_tests may still be using extRAM_t4.h.
    Yes they do from what I remember. Not sure if you want to pull that stuff in yet.

  17. #42
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,700

    PID for MTP-Disk/Serial

    Paul,
    could you please assign a own PID for an experimental MTP Serial that is recognized by Teensy loader, Teensy monitor and would allow automatic reprogramming?
    It would also allow simpler SW development and pull requests.

  18. #43
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,981
    Quote Originally Posted by mjs513 View Post
    Yes they do from what I remember. Not sure if you want to pull that stuff in yet.
    Is that just used for PSRAM access? That is built in now with TD 1.52. Only problem is lack of a uniform malloc() scheme for that to avoid conflicts with a user manual alloc.

  19. #44
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,297
    Quote Originally Posted by WMXZ View Post
    ...that is recognized by Teensy loader, Teensy monitor and would allow automatic reprogramming?
    We're only a matter of days away from a non-beta release. The last thing I'm going to do right now is make changes in that critically important code, no matter how trivial they may seem.
    Last edited by PaulStoffregen; 06-23-2020 at 11:11 AM.

  20. #45
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,474
    Quote Originally Posted by defragster View Post
    Is that just used for PSRAM access? That is built in now with TD 1.52. Only problem is lack of a uniform malloc() scheme for that to avoid conflicts with a user manual alloc.
    Simple answer is yes. More complicated answer is that with one PSRAM chip extram_t4 reserves the lower 4 MBs for user to use for EXTRAM, etc and the upper 4MBs for other purposes. Also addresses if you have no PSRAM chips or 2 PSRAM chips. But would be a lot easier if there was a malloc scheme for extram. Dont know if this makes sense.

  21. #46
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,297
    Looking at the "Kurts_ILI9488_t3n_FB_and_clip_tests" example, I don't understand why it's including extRAM_t4.h. It creates an "ext_mem" object which seems to be only used once for "ext_mem.begin();". Since 1.52 initializes the hardware, that shouldn't be needed, right?

    But just commenting those lines doesn't make it compile. The next issue that comes up is an elapsedMicros variable which is defined for one #ifdef case but not the other. Fixing that still doesn't get it to build. I didn't investigate any further.

    Could I talk you into committing at least some comments at the beginning of this file, stating it's experimental code that probably doesn't work? Likewise for other examples which are experimental stuff, please add some comments at the top of those files for users who click File > Examples > ILI9488_t3 and unwittingly choose one that doesn't actually work.

    Fine to leave this broken stuff in... but please think of end users who are experiencing the library for the first time, perhaps having just connected the wires and not 100% sure their hardware is connected properly. Known-good examples are essential to help people bring up their freshly-wired hardware.

  22. #47
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,297
    I made a little PCB to connect Teensy to these RA8875 displays from BuyDisplay.

    Click image for larger version. 

Name:	ra8875oshpark.jpg 
Views:	13 
Size:	62.0 KB 
ID:	20685
    Last edited by PaulStoffregen; 06-23-2020 at 12:39 PM.

  23. #48
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,474
    Quote Originally Posted by PaulStoffregen View Post
    Looking at the "Kurts_ILI9488_t3n_FB_and_clip_tests" example, I don't understand why it's including extRAM_t4.h. It creates an "ext_mem" object which seems to be only used once for "ext_mem.begin();". Since 1.52 initializes the hardware, that shouldn't be needed, right?

    But just commenting those lines doesn't make it compile. The next issue that comes up is an elapsedMicros variable which is defined for one #ifdef case but not the other. Fixing that still doesn't get it to build. I didn't investigate any further.

    Could I talk you into committing at least some comments at the beginning of this file, stating it's experimental code that probably doesn't work? Likewise for other examples which are experimental stuff, please add some comments at the top of those files for users who click File > Examples > ILI9488_t3 and unwittingly choose one that doesn't actually work.

    Fine to leave this broken stuff in... but please think of end users who are experiencing the library for the first time, perhaps having just connected the wires and not 100% sure their hardware is connected properly. Known-good examples are essential to help people bring up their freshly-wired hardware.
    Not a problem will do as soon as I get another cup of coffee

  24. #49
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,474
    Quote Originally Posted by PaulStoffregen View Post
    I made a little PCB to connect Teensy to these RA8875 displays from BuyDisplay.
    Nice Paul. Mine is a bit more complicated since I set it up to be multi-purpose for all the displays we play with: But sometimes simple is better, i tend to get carried away
    Click image for larger version. 

Name:	Capture3.PNG 
Views:	5 
Size:	384.3 KB 
ID:	20686

    I liked your little wired boards that you posted. Have to try doing that one of these days

    EDIT: What are those other components and how did are they wired - may have to add them to mine
    Last edited by mjs513; 06-23-2020 at 12:54 PM. Reason: Added EDIT

  25. #50
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,162
    Good Morning Paul - and mjs513 - Right now what I downloaded (ILI9488_t3) is not properly building and linking for T4.x...

    Probably my issue or earlier merge issue... In particular when not using the PSRAM version, the defines for:
    Code:
    #elif defined(__IMXRT1052__) || defined(__IMXRT1062__)  // Teensy 4.x
    ...
    //DMASetting 	ILI9488_t3::_dmasettings[2];
    //DMAChannel 	ILI9488_t3::_dmatx;
    #else
    In the header file we have:
    Code:
    #elif defined(__IMXRT1052__) || defined(__IMXRT1062__)  // Teensy 4.x
    	// Going to try it similar to T4.
    	#if defined(ENABLE_EXT_DMA_UPDATES)
    	#define SCREEN_DMA_NUM_SETTINGS 5 // see if making it a constant value makes difference...
    	DMASetting   		_dmasettings[6];
    	DMAChannel  		_dmatx;
    	#else
    	static DMASetting 	_dmasettings[2];
    	static DMAChannel  	_dmatx;
    Where we can either remove the static from the defines or we can conditionally define the settings in the CPP file... Right now I am going to remove static as in theory even if the user does not define the stuff to enable 32 bit pixels, with T4.1 and external memory they could have two of these displays!.

    WIll soon do PR back to @mjs513... WIll also change example to remove the old PSRAM library stuff..

Posting Permissions

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