Teensyduino 1.53 Beta #2

Status
Not open for further replies.
I ordered the 5 inch 480x272 display.

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

ra8755wires.jpg
 
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.

ra8875adafruit.jpg
 
@Paul - Thanks :eek:

@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...
 
@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
 
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 :)
 
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
 
@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
 
@KurtE and @PaulStoffregen

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

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 :D Probably just wiring issues.
 
@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.
 
KurtE said:
@Paul - You should probably pickup the updated libraries
Click to expand...

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.
 
PaulStoffregen said:
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.
Click to expand...

Yes they do from what I remember. Not sure if you want to pull that stuff in yet.
 
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.
 
mjs513 said:
Yes they do from what I remember. Not sure if you want to pull that stuff in yet.
Click to expand...

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.
 
WMXZ said:
...that is recognized by Teensy loader, Teensy monitor and would allow automatic reprogramming?
Click to expand...

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:
defragster said:
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.
Click to expand...

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.
 
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.
 
PaulStoffregen said:
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.
Click to expand...

Not a problem will do as soon as I get another cup of coffee :)
 
PaulStoffregen said:
I made a little PCB to connect Teensy to these RA8875 displays from BuyDisplay.
Click to expand...

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
Capture3.PNG

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:
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..
 
Status
Not open for further replies.
Back
Top