PDA

View Full Version : Teensyduino 1.53 Beta #2



Paul
06-19-2020, 08:08 PM
Here is a second beta test for Teensyduino 1.53.

Please install this into a fresh copy of Arduino. Several old libraries have been removed. If you "install on top" of a previous version, your copy of Arduino will keep those old libs. While not harmful, best to test this version installed into a fresh copy of Arduino.


Linux 32 bit:
https://www.pjrc.com/teensy/td_153-beta2/TeensyduinoInstall.linux32

Linux 64 bit:
https://www.pjrc.com/teensy/td_153-beta2/TeensyduinoInstall.linux64

Linux ARM:
https://www.pjrc.com/teensy/td_153-beta2/TeensyduinoInstall.linuxarm

Linux ARM64:
https://www.pjrc.com/teensy/td_153-beta2/TeensyduinoInstall.linuxaarch64

MacOS 10.10 to 10.15:
https://www.pjrc.com/teensy/td_153-beta2/Teensyduino_MacOS_Catalina.zip

MacOS 10.8 to 10.14:
https://www.pjrc.com/teensy/td_153-beta2/TeensyduinoInstall.dmg

Windows:
https://www.pjrc.com/teensy/td_153-beta2/TeensyduinoInstall.exe


Changes since Teensyduino 1.53-beta1:

Improve C++ STL support
Fix compiler warnings in several library examples
Update libraries: FastLED, MIDI, RA8875, Adafruit_NeoPixel, FlexCAN, FlexCAN_T4, ILI9488_t3
Entropy library support for Teensy 4.x random number hardware
ILI9341_t3 proportional font rendering speedup (Larry Bank)
Audio: add rectifier effect and vocoder example by Bradley Sanders
Fix serialEventUSB1 & serialEventUSB2 on Teensy 4.x (KurtE)
Add MIDIUSB.h compatibility on Teensy 4.x
Check hardware serial FIFO in avalable and peek (KurtE)
Remove libraries: Adafruit_GFX, Adafruit_CC3000, Adafruit_RA8875, openGLCD, ST7565

defragster
06-19-2020, 10:18 PM
Win 10 Fresh install of IDE 1.8.13 then TD 1.53b2 - No install issues

some Sketch Upload to T_4.0 then to T_4.1 worked as expected.

Also working @luni's standard lib sample from : pjrc.com/threads/61388-Teensyduino-1-53-Beta-1 (https://forum.pjrc.com/threads/61388-Teensyduino-1-53-Beta-1?p=243675&viewfull=1#post243675)
Same good results:

Testing std::vector ------------
First string
Second string
Last string

Testing std::map--------------
0
42

Testing std::function----------
The string 'some string' has 11 characters

kd5rxt-mark
06-19-2020, 10:48 PM
Paul:
- running under Windows 10 Pro (version 1909, OS build 18363.900)
- downloaded TD 1.53b2
- uninstalled existing Arduino 1.8.13
- installed Arduino 1.8.13
- installed TD 1.53b2
- opened my TeensyMIDIPolySynth sketch & built for Teensy 4.1, Serial + MIDI, 600MHz, Fastest

Capabilities tested/verified:
- Audio Shield Rev D & libraries
- traditional hardware MIDI (thru DIN jacks)
- USB MIDI (advertises itself as a MIDI hardware device)
- USB host w/ USB MIDI keyboard plugged in

All works as expected.

Thanks !!

Mark J Culross
KD5RXT


P.S. Would you consider including the simple change identified <here (https://forum.pjrc.com/threads/61412-AudioStream-cpp-amp-AudioStream-h-BUGFIX?p=243469&viewfull=1#post243469)> in the next beta ??

defragster
06-21-2020, 08:37 AM
Building T_4.1 example :: T:\arduino-1.8.13\hardware\teensy\avr\libraries\ADC\examples\ adc_dma

<<CORRECTION>> :: ADC in TD 1.53b2 does have the functions and does work when the edits are made to the example below is adc1 here are lines for adco:

adc->adc0->setAveraging(8);
adc->adc0->setResolution(12);



Not sure if this is expected - or perhaps fixed in current github code?


adc_dma: In function 'void setup()':
adc_dma:63: error: 'class ADC' has no member named 'setAveraging'
adc->setAveraging(8); // set number of averages
^
...

Using library ADC at version 8.0 in folder: T:\arduino-1.8.13\hardware\teensy\avr\libraries\ADC
'class ADC' has no member named 'setAveraging'


Doesn't look like it has - but 21 day old edit added :: __attribute__((error("Use adc->adcX->setAveraging instead"))) void setAveraging(uint8_t num, int8_t adc_num = -1);

Pulled the latest from github and it is working with this in the second set of settings:


// adc->setAveraging(8, ADC_1); // set number of averages
// adc->setResolution(12, ADC_1); // set bits of resolution
adc->adc1->setAveraging(8);
adc->adc1->setResolution(12);


Will post issue to correct the example { github.com/pedvide/ADC/issues/62 (https://github.com/pedvide/ADC/issues/62) }- but maybe the new lib if ready could be pulled in?

analog&RFmodels
06-21-2020, 06:55 PM
i saw some syntax changes between TD 1.48 and 1.52 that may relate to 1.53 betas?

needed in 1.48
adc->setAveraging(1,ADC_0);

needed in 1.52
adc->adc0->setAveraging(1);

also - total crash when trying to compile adc for TLC - see post #46 in "Teensyduino 1.52 released"
in addition i posted it as a bug report but cannot find that one now - i did a very hockey edit in one
of the adc lib .cpp files to work around it.

quadrupel
06-22-2020, 03:50 AM
I loaded 153B2 into Platformio and tested a program that requires multiple std::vector arrays. Previously, the program would function correctly with one vector defined, but would not compile with multiple vectors. I'm happy to report that my program now compiles and behaves correctly with multiple std:vector assignments.

Great work Paul and thanks for the STL mods.

Deleted User
06-22-2020, 02:26 PM
The audio tool has a new issue when importing a project:
Some connections are not displayed and not established.
As example see attached screen shot taken from importing the Vocoder19Band example.
20672

PaulStoffregen
06-22-2020, 02:36 PM
I'm testing the RA8875 and Adafruit_RA8875 libraries. I currently have only the Adafruit display on my desk. Somewhere I have a Buydisplay one... need to dig it out.

Looks like the Adafruit display requires "tft.GPIOX(true);" to actually turn on. Adafruit's examples have this, but it's missing in the RA8875 examples. Would adding this impact non-Adafruit RA8875 displays?

The good news is Adafruit seems to have fixed the old timing bugs where large text only worked with slow boards. So there no need to keep a modified copy of Adafruit_RA8875.

mjs513
06-22-2020, 02:54 PM
I'm testing the RA8875 and Adafruit_RA8875 libraries. I currently have only the Adafruit display on my desk. Somewhere I have a Buydisplay one... need to dig it out.

Looks like the Adafruit display requires "tft.GPIOX(true);" to actually turn on. Adafruit's examples have this, but it's missing in the RA8875 examples. Would adding this impact non-Adafruit RA8875 displays?

The good news is Adafruit seems to have fixed the old timing bugs where large text only worked with slow boards. So there no need to keep a modified copy of Adafruit_RA8875.

Don't think it will hurt. Looks like its used for turning on the display using PWM as opposed to just having the BL hooked up to a power pin. With BuyDisplay think the jumpers are set to use BL attached to a power pin

PaulStoffregen
06-22-2020, 03:46 PM
I found a 7 inch Buydisplay RS8875 and wired it up. Looks like "tft.GPIOX(true);" has no effect. It should probably be in all the examples with a comment that it's needed for Adafruit's RA8875.

20673

PaulStoffregen
06-22-2020, 04:01 PM
Looks like we may have timing issues. This mangGauges_800x480 example works with Teensy 4.0 when the CPU speed is set to 528 MHz or slower, but fails if 600 MHz or faster.

mjs513
06-22-2020, 04:27 PM
Looks like we may have timing issues. This mangGauges_800x480 example works with Teensy 4.0 is the CPU speed is set to 528 MHz or slower, but fails if 600 MHz or faster.

Don't have a 800x480 display, think Kurt has one, but i just ran it on a 480x272 display with 4 gauges (does clip the last one) but it looks like its working on a T4.0 without a problem. Can you try just 4 gauges to see if its still a problem?

mjs513
06-22-2020, 04:39 PM
I'm testing the RA8875 and Adafruit_RA8875 libraries. I currently have only the Adafruit display on my desk. Somewhere I have a Buydisplay one... need to dig it out.

Looks like the Adafruit display requires "tft.GPIOX(true);" to actually turn on. Adafruit's examples have this, but it's missing in the RA8875 examples. Would adding this impact non-Adafruit RA8875 displays?

The good news is Adafruit seems to have fixed the old timing bugs where large text only worked with slow boards. So there no need to keep a modified copy of Adafruit_RA8875.

I added this line to the end of "begin" function in the RA8875.cpp file:

if(_displaySize == Adafruit_480x272 || _displaySize == Adafruit_800x480 ) GPIOX(true);

Should work.

PaulStoffregen
06-22-2020, 04:42 PM
I tried the "RoundGauges" example which draws 3 of them. It run for a few seconds at 600 MHz. Looks like it's still transmitting, but the display gets confused out out of sync somehow. It runs find with slower clock speeds.

mjs513
06-22-2020, 05:07 PM
I tried the "RoundGauges" example which draws 3 of them. It run for a few seconds at 600 MHz. Looks like it's still transmitting, but the display gets confused out out of sync somehow. It runs find with slower clock speeds.

Just tried round gauges on the 480x272 and its been running at 600Mhz for the last 6 minutes. Something strange going on. I just ordered a 800x480 7inch display from BuyDisplay should be here end of the week.

EDIT: You could try lowering the SPI Clock. Right now we are at 18Mhz by default.

const static uint32_t MAXSPIREADSPEED = 6000000UL; //Read don't go higher than 22000000!;
#if defined(__MK20DX128__) || defined(__MK20DX256__) || defined(__MK64FX512__) || defined(__MK66FX1M0__) || defined(__IMXRT1062__)
const static uint32_t MAXSPISPEED = 18000000UL; //don't go higher than 22000000!;

This if from usersettings.h file. You can change SPI in the begin statement:

void begin(const enum RA8875sizes s,uint8_t colors=16, uint32_t SPIMaxSpeed = (uint32_t)-1, uint32_t SPIMaxReadSpeed = (uint32_t)-1 ); maybe try


tft.begin(RA8875_800x480, 16, 12000000, 22000000);

PaulStoffregen
06-22-2020, 05:22 PM
Which size 480x272 display are you using? I'll get one on order too.

mjs513
06-22-2020, 05:33 PM
Which size 480x272 display are you using? I'll get one on order too.

Have a 480x272. :)

Have to order it quick - they close for awhile starting June 25th.

PaulStoffregen
06-22-2020, 05:38 PM
I don't think it's the SPI clock speed. I edited the code to increase to 22 MHz, and I used my scope to check it really was 21.8 MHz. At 528 MHz and 21,8 MHz SPI clock, it runs reliably. But with Teensy 4.0 at 600 MHz, even with slower SPI clock, it seems to go awry.

20675

PaulStoffregen
06-22-2020, 05:44 PM
Have a 480x272. :)

I see 480x272 comes in both 5 inch and 4.3 inch sizes.

https://www.buydisplay.com/4-3-tft-lcd-display-module-controller-board-serial-spi-i2c-mcu

https://www.buydisplay.com/5-inch-tft-lcd-display-capacitive-touchscreen-ra8875-controller-480x272

Any suggestion which I should get?

mjs513
06-22-2020, 05:47 PM
I have the 4.3 inch one, https://www.buydisplay.com/4-3-tft-l...al-spi-i2c-mcu, setup for 5v, SPI 4-wire, resistive but capacitive works as well.

mjs513
06-22-2020, 06:04 PM
I don't think it's the SPI clock speed. I edited the code to increase to 22 MHz, and I used my scope to check it really was 21.8 MHz. At 528 MHz and 21,8 MHz SPI clock, it runs reliably. But with Teensy 4.0 at 600 MHz, even with slower SPI clock, it seems to go awry.

20675 Reason I was saying about SPI Clock was because of the warning Sumotoy had in the file:

After som mail exchange with RAiO I solved the dilemma behind SPI speed limit:
The RA8875 has limitation of 12Mhz SPI but this has been set because not all internal macros
can run over that speed, the library automatically deal with this so I was able to go over 20Mhz!
At that speed you need to short cables as much you can, provide clean supply and good decoupling!
DO NOT Exceed 23Mhz for RA8875! It will result in garbage on screen or run very slow. I am going to pull out scope and see what it looks like with my setup out of curiosity.

KurtE
06-22-2020, 06:10 PM
Sorry, been off doing other stuff.

I do have a few different ones:
I believe I have a BuyDisplay: 5" 800x... I may also have one of the 480x272 one here as well
Maybe 2 of the 4.3" 800x480 - I like these better, but again they mostly sit in box
Also Adafruit, I think mine is setup for the lower resolution.


One thing I have found, is there connections are very touchy... Usually need short wires... Also sometimes need to lower SPI speed.

Pulling out one now will try. Any particular setup? I am most likely setup for 4.3" 800x480 using my older jumpered board.... My newer board has the 8876 on it.

KurtE
06-22-2020, 06:27 PM
Hi @Paul - I just copied all of Core over to my Arduino 1.8.13
And it looks like I maybe missed removing a warning from digitalToggle()
unused variable (pinMode)...

Not sure why I missed it when building yesterday.


@mjs513 - The example sketch: ILI_Ada_FontTest4
For RA8875 is giving me some warning as well now:

ILI_Ada_FontTest4: In function 'uint32_t displayStuff1()':
C:\Users\kurte\Documents\Arduino\libraries\RA8875\ Examples\_Teensy3\ILI_Ada_FontTest4\ILI_Ada_FontTe st4.ino:208:65: warning: invalid conversion from 'int16_t* {aka short int*}' to 'uint16_t* {aka short unsigned int*}' [-fpermissive]
tft.getTextBounds(rectText, rect_x, rect_y, &xT, &yT, &wT, &hT);
^
In file included from C:\Users\kurte\Documents\Arduino\libraries\RA8875\ Examples\_Teensy3\ILI_Ada_FontTest4\ILI_Ada_FontTe st4.ino:4:0:
C:\Users\kurte\Documents\Arduino\libraries\RA8875/RA8875.h:382:10: note: initializing argument 6 of 'void RA8875::getTextBounds(const char*, int16_t, int16_t, int16_t*, int16_t*, uint16_t*, uint16_t*)'
void getTextBounds(const char *string, int16_t x, int16_t y,
^
C:\Users\kurte\Documents\Arduino\libraries\RA8875\ Examples\_Teensy3\ILI_Ada_FontTest4\ILI_Ada_FontTe st4.ino:208:65: warning: invalid conversion from 'int16_t* {aka short int*}' to 'uint16_t* {aka short unsigned int*}' [-fpermissive]
tft.getTextBounds(rectText, rect_x, rect_y, &xT, &yT, &wT, &hT);
^
In file included from C:\Users\kurte\Documents\Arduino\libraries\RA8875\ Examples\_Teensy3\ILI_Ada_FontTest4\ILI_Ada_FontTe st4.ino:4:0:
C:\Users\kurte\Documents\Arduino\libraries\RA8875/RA8875.h:382:10: note: initializing argument 7 of 'void RA8875::getTextBounds(const char*, int16_t, int16_t, int16_t*, int16_t*, uint16_t*, uint16_t*)'
void getTextBounds(const char *string, int16_t x, int16_t y,
^
Compiling libraries...
Compiling library "Adafruit_GFX_Library"

Probably because of different GFX library than the one we were shiping with Teensyduino

Also some of the pages are not drawing properly.


I also have running the many gauges example and it so far appears to be running.

Edit: Forgot to mention I will be probably busy outside for awhile.

Will check back in a bit

mjs513
06-22-2020, 06:30 PM
@KurtE
Which display are you using? The 480x272 seems to be working. I will check out the new GFX issue

KurtE
06-22-2020, 06:51 PM
I am using one of the 800x480 4.3" displays in my earlier screwed up adapter board... If needed I can try one of the others as well. But now back to garden

PaulStoffregen
06-22-2020, 07:00 PM
I ordered the 5 inch 480x272 display.

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

20677

PaulStoffregen
06-22-2020, 07:12 PM
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.

20678

PaulStoffregen
06-22-2020, 07:39 PM
And it looks like I maybe missed removing a warning from digitalToggle()
unused variable (pinMode)...

Fixed.
https://github.com/PaulStoffregen/cores/commit/a7d9bac6523526db138251765565f341a674a494

KurtE
06-22-2020, 07:56 PM
@Paul - Thanks :o

@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...

KurtE
06-22-2020, 08:32 PM
@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

mjs513
06-22-2020, 08:37 PM
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 :)

mjs513
06-22-2020, 08:59 PM
Ok fixed issue with GFX fonts - real easy:
1. substitute new font structure in glcdfont.h for what we have in RA8875.h

/// 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
06-22-2020, 09:12 PM
Just posted a response on Github

KurtE
06-22-2020, 09:16 PM
@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

mjs513
06-22-2020, 10:10 PM
@KurtE and @PaulStoffregen

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

KurtE
06-22-2020, 10:29 PM
@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 :D

mjs513
06-23-2020, 12:14 AM
@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 :D

Updated ILI9488, HX8357 and RA8876 with the GFX font changes.

KurtE
06-23-2020, 12:46 AM
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.

KurtE
06-23-2020, 12:47 AM
@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.

PaulStoffregen
06-23-2020, 03:13 AM
@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.

mjs513
06-23-2020, 03:21 AM
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.

WMXZ
06-23-2020, 06:00 AM
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.

defragster
06-23-2020, 06:05 AM
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.

PaulStoffregen
06-23-2020, 12:01 PM
...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.

mjs513
06-23-2020, 12:58 PM
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.

PaulStoffregen
06-23-2020, 01:16 PM
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
06-23-2020, 01:24 PM
I made a little PCB to connect Teensy to these RA8875 displays from BuyDisplay.

20685

mjs513
06-23-2020, 01:45 PM
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 :)

mjs513
06-23-2020, 01:52 PM
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
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:)

KurtE
06-23-2020, 02:00 PM
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:

#elif defined(__IMXRT1052__) || defined(__IMXRT1062__) // Teensy 4.x
...
//DMASetting ILI9488_t3::_dmasettings[2];
//DMAChannel ILI9488_t3::_dmatx;
#else

In the header file we have:

#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..

mjs513
06-23-2020, 02:06 PM
@KurtE - @Paul
Just did the same thing and getting the same errors. Could have sworn we fixed those errors a while ago. Wil wait for the PR

mjs513
06-23-2020, 02:18 PM
@KurtE - @PaulStoffregen
Merge Completed!

No need for warning in the file - @KurtE removed references to extMem_t4 as well.

Thanks Kurt

PaulStoffregen
06-23-2020, 02:28 PM
Thanks. I've pulled in the latest here. I hope to be packing up 1.53-beta3 within the next 24 hours, and a final 1.53 release before the end of this week.

Still on my todo list is bringing in one or both of the native ethernet libraries...

KurtE
06-23-2020, 02:30 PM
Sorry probably should have done that earlier. Actually I keep meaning to get back to ILI9488 library and maybe see if we can rework how the buffers works, that is we have 3 different versions of the Frame buffer code:

a) 8 bit buffers that use color lookup table to map to 18 bit colors - Uses secondary buffers for the converted data to DMA to screen. (Default for T3.5/6)
b) 16 bit buffers that upshift during outputs to 18 bit colors - Uses seondary buffers... Default now for T4.x
c) 32 bit buffers that are stored in 18 bit (24 bit colors) that do direct DMA without having to muck with data

Currently to switch from b) to c) you have to compile the library with that option, either through editing header file, which effects every project that uses the library on T4.1 and won't then work on those that don't have external memory... There is a hack for __has_include that can enable per sketch, but this has to be stored in some place NOT in sketch... like a bogus library

Would like to create some form of sub-class or run time option to choose the frame buffer type.... But that is beyond this scope :D

KurtE
06-23-2020, 02:38 PM
@Paul - Wondering about PR for SPI, that may be needed to make SPI work on T4.x with Snooze... Still other issues.
https://github.com/PaulStoffregen/SPI/pull/59

That is it gives some implementation to SPI.end() for T4.x

void SPIClass::end() {
// only do something if we have begun
if (hardware().clock_gate_register & hardware().clock_gate_mask) {
port().CR = 0; // turn off the enable
pinMode(hardware().miso_pin[miso_pin_index], INPUT_DISABLE);
pinMode(hardware().mosi_pin[mosi_pin_index], INPUT_DISABLE);
pinMode(hardware().sck_pin[sck_pin_index], INPUT_DISABLE);
}
}
Again on T4, not sure best way to leave SPI pins... So punted to use INPUT_DISABLE...

Also still did not fully fix the hibernate issue ...

Side note, which I have not yet put up change for.

The current code does something like:

port().CR = LPSPI_CR_RST;
// Lets initialize the Transmit FIFO watermark to FIFO size - 1...
// BUGBUG:: I assume queue of 16 for now...
port().FCR = LPSPI_FCR_TXWATER(15);

I then print out the FCR register and it did not take the 15... Finally figured out that is because we have the SPI still in RESET mode, so changing those registers does not take.
But if I add in:

port().CR = LPSPI_CR_RST;
delay(1);
port().CR = LPSPI_CR_RRF | LPSPI_CR_RTF;
// Lets initialize the Transmit FIFO watermark to FIFO size - 1...
// BUGBUG:: I assume queue of 16 for now...
port().FCR = LPSPI_FCR_TXWATER(15);

The delay is probably not necessary... But then the values do take as I took it out of Reset mode... Probably late to add something like this for this release?

EDIT: Also with the ::end above not sure if it would a good idea to then turn off the clock gate Mask that was set in begin?

mjs513
06-23-2020, 03:00 PM
Thanks. I've pulled in the latest here. I hope to be packing up 1.53-beta3 within the next 24 hours, and a final 1.53 release before the end of this week.

Still on my todo list is bringing in one or both of the native ethernet libraries...

Ethernet both work. The NativeEthernet library does require an additional library to be installed. Its dependent on the FNET library. Seems relatively easy to work with. Used it for the temperature measurements with the T4.1.

@manitou's lwio library works as well but I keep forgetting you have to hack the boards.txt file:

// lwip perf
// to use IDE hack -I into boards.txt
#include "lwip_t41.h"
#include "lwip/inet.h"
#include "lwip/dhcp.h"
#include "lwip/udp.h"
#include "lwip/tcp.h"
#include "lwip/stats.h" so you would have to do something like this (thanks @defragster)

Added this for this machine to boards.txt: teensy41.build.flags.common=-g -Wall -ffunction-sections -fdata-sections -nostdlib -IT:\tCode\libraries\lwip\src\include

defragster
06-23-2020, 06:12 PM
I made a little PCB to connect Teensy to these RA8875 displays from BuyDisplay.

20685

Paul - can you OSH_Share that board? Connections are the same on the RA8876 correct? Assume those extra parts are pullup resistors for SPI pins?

Looking at your shared I see an alternate Ethernet ( oshpark.com/shared_projects/wUFt1emZ (https://oshpark.com/shared_projects/wUFt1emZ) ) - the parts layout shows the prior board with surface mount parts instead of the single through hole cap.

KurtE
06-23-2020, 06:43 PM
Good morning @Paul and @defragster...

The furn of it is for which version of which displays do you have this setup for?

My boards are a little more funky as I set them up to maybe handle a few different configurations.

One reason I am mentioning this is for example if you purchase the 5" RA8875 The board for this has two different connectors:
Disregarding pin headers versus FFC connectors. But unless the board has changed the SPI connections are on the small connector area.

But instead of if you buy the 4.3" display - Then they use the one connector, like you show.... I also think their 7" use this as well.... Don't know for sure as I don't own one.
But this connector is compatible with at least the RA8876 I ordered and I am using.
Doc for this display: https://www.buydisplay.com/download/manual/ER-TFTM043A2-3_Datasheet.pdf

Also did you do anything special with the MISO pin to tri state it?

Does your breakout setup to also handle the different Touch screen options? Where for example the capacitive touch (I2C connections)? Pins 33-35... I have not played with this part for awhile. Don't remember if this display also have an option for resistive touch instead of capacitive?

But lots of fun!

PaulStoffregen
06-23-2020, 06:58 PM
Paul - can you OSH_Share that board?

Sure, here it is.
https://oshpark.com/shared_projects/GQplc8wy



Connections are the same on the RA8876 correct?

Looks like they've designed most of their displays with the same 40 pin connector pinout. But I haven't specifically checked the RA8876 ones. Best to download the PDF for each and check the pinouts.


Assume those extra parts are pullup resistors for SPI pins?

Those 2 resistors are for the I2C signals. I connected them to the pins for the capacitive touch chip.



Looking at your shared I see an alternate Ethernet ( oshpark.com/shared_projects/wUFt1emZ (https://oshpark.com/shared_projects/wUFt1emZ) ) - the parts layout shows the prior board with surface mount parts instead of the single through hole cap.

I've updated that one with a new photo. I didn't bother with a parts placement diagram, since it has only 3 parts which are very distinct shapes.

PJRC will soon start selling a DIY kit with this newer PCB, the Cetus magjack, capacitor, headers and ribbon cable assembly. I wanted to make the kit all through hole parts and as affordable as possible (the Cetus part is less expensive), which is why we waited until the newer board was ready.

defragster
06-23-2020, 07:15 PM
Yes, it shows now on :: oshpark.com/profiles/PaulStoffregen (https://oshpark.com/profiles/PaulStoffregen) - didn't show as posted.

Got the CAP touch 7" RA8876 so will skip that and look at PDF to wire one up.

Cool on the lower cost through hole ethernet kit! - yes just one obvious cap to solder. I got boards and parts for the prior UDE SMD assembly.

PaulStoffregen
06-23-2020, 07:16 PM
Side note, which I have not yet put up change for.


Let's wait to change the SPI initialization, until after 1.53. Committing a late change to the empty end() function doesn't seem risky, but changing how the hardware it initialized is more risk than I want to commit right now.

KurtE
06-23-2020, 07:24 PM
Let's wait to change the SPI initialization, until after 1.53. Committing a late change to the empty end() function doesn't seem risky, but changing how the hardware it initialized is more risk than I want to commit right now.

Understood, which I sort of figured as well and have not pushed up the change... I did try to remove the clock bit at the end of the end method and did not help the Hibernate code...
So I am out of ideas for helping get snooze work for that test case.

mjs513
06-25-2020, 12:50 AM
@PaulStoffregen - are you playing on pulling in The spiff library. If so be careful which branch. If you want I can pull it into a separate repository.

PaulStoffregen
06-25-2020, 03:29 AM
are you playing on pulling in The spiff library.

Probably not for 1.53. I did bring in NativeEthernet and did some testing with it today.

I have 3 issues remaining on my list, all involving the installer. Was planning to package up 1.53-beta3 soon, which will probably be very close to the final 1.53 release. My hope is to finalize 1.53 by the end of this week. Then I'm going to spend a couple weeks on making a Teensy 4 bootloader chip available. Then back to a combination of documentation and starting 1.54, where I really want to focus on the many filesystem and filesystem-like libraries & features. SPIFFS and which flash chips we'll officially support (hopefully at least one large NAND chip) will probably be part of that filesystem stuff for 1.54.

mjs513
06-25-2020, 12:20 PM
Probably not for 1.53. I did bring in NativeEthernet and did some testing with it today.

I have 3 issues remaining on my list, all involving the installer. Was planning to package up 1.53-beta3 soon, which will probably be very close to the final 1.53 release. My hope is to finalize 1.53 by the end of this week. Then I'm going to spend a couple weeks on making a Teensy 4 bootloader chip available. Then back to a combination of documentation and starting 1.54, where I really want to focus on the many filesystem and filesystem-like libraries & features. SPIFFS and which flash chips we'll officially support (hopefully at least one large NAND chip) will probably be part of that filesystem stuff for 1.54.

Good Morning - sorry i missed this last night. Sounds like a plan.

Know its early but any thoughts on which NAND chips you are looking at or what FLASH Chips yet or should I just be patient. Think i know the answer to that one though. :)

PaulStoffregen
06-25-2020, 12:54 PM
any thoughts on which NAND chips you are looking at or what FLASH Chips yet

Winbond W25N01GVZE1G

https://www.winbond.com/hq/product/code-storage-flash-memory/qspinand-flash/index.html?__locale=en&partNo=W25N01GV

https://www.digikey.com/product-detail/en/winbond-electronics/W25N01GVZEIG-TR/W25N01GVZEIGCT-ND/7393545

I designed the wide SOIC8 footprint on Teensy 4.1 with alternatively mounting this WSON8 part onto those pads.



or should I just be patient.

Probably best to start a new thread if you want to chat about the details. Perfectly fine to discuss on this forum. But please know I will not be working on NAND flash support until we're shipping Teensy 4 bootloader chips, so don't expect me to be active on that thread. After 1.53, getting a bootloader chip released is my top priority. Realistically, I'll probably also spend some time on much-needed website updates and documentation before getting into improved file & filesystem abstraction and other storage media (the main focus planned for 1.54).

mjs513
06-25-2020, 01:17 PM
@PaulStoffregen
Thanks for the info Paul.

Website updates and documentation have to be first as the site does need some updating. That's going to be a job and a half.

When you dangle little tidbits I get curious and sometimes its hard not to resist asking the question :) Never played with NAND chips before so gives me some time to do some research :)

mjs513
06-25-2020, 02:22 PM
@PaulStoffregen

Was just using MTP responder with T4.0 and remembered an issue we were have with using MTP above 450 Mhz. Basically above 450Mhz MTP responder would not work. The fix was relatively easy but took a while to find.

@WMXZ found that if you made the following change to usb.c it would work at the higher speeds:

file: usb.c
function: usb_transfer_status
changed #if 0 to #if 1

See post #277 (https://forum.pjrc.com/threads/43050-MTP-Responder-Contribution?p=240282&viewfull=1#post240282) in the MTP responder thread.

Would it be possible to incorporate this into 1.53? I had made the change in 1.52 and was using it about a month and didn't see any adverse affects to USB.

defragster
06-25-2020, 06:45 PM
Interesting question and answer on 128 MB NAND Paul and mjs513! There was an NXP email the other day - in following the link there was a NAND setup question (https://community.nxp.com/thread/534700) - not sure if it has any info not elsewhere.

RE: "See post #277 in the MTP responder thread." - I made that change and MTP worked - wasn't sure of it was turned off for some reason?

mjs513
06-25-2020, 06:52 PM
Interesting question and answer on 128 MB NAND Paul and mjs513! There was an NXP email the other day - in following the link there was a NAND setup question (https://community.nxp.com/thread/534700) - not sure if it has any info not elsewhere.

RE: "See post #277 in the MTP responder thread." - I made that change and MTP worked - wasn't sure of it was turned off for some reason?

Probably should start a new thread for NAND memory.

as for MTP change = that mode wasn't put into the 1.53 core so we have to edit it each time.

defragster
06-25-2020, 08:52 PM
Probably should start a new thread for NAND memory.

as for MTP change = that mode wasn't put into the 1.53 core so we have to edit it each time.

Aware 'MTP change' was not and may not be in TD 1.53 - but just adding I also made the change - it is gone now. Just adding note in case Paul knows for sure why that was done and should not be undone - or if it does have a path forward.

Indeed - NAND intro deserves a new thread - of course QSPI Flash - other than SPIFFS - never got much notice or simple examples for use that I saw or tested. But with 16MB to manage TD 1.54 filesystem work should cover that - and the NAND as well for 128 MB of storage.

mjs513
06-29-2020, 11:09 PM
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.



Received my 7in RA8875 display and hooked it up. Ran the ManyGauge example sketch with a T4.0 at 600Mhz without issue.
20804
Also ran benchmark.ino and FontTest4 with no problem at default SPI clock for the display.

Just wanted to let you know.

Slabshaft
07-01-2020, 12:30 AM
Entropy won't compile on my 4.0. I'm using PlatformIO in VS Code so I think it's pulling an old library and I don't really know how PlatformIO works with Teensyduino updates. Is there a link to the latest Entropy library so I can just include it locally with my sketch?

PaulStoffregen
07-01-2020, 12:34 AM
I'm wrapping up 1.53 now. Let's wait just a day or two, then ask Ivan to take a look at why it's not compiling on PlatformIO.

PaulStoffregen
07-01-2020, 12:37 AM
Received my 7in RA8875 display and hooked it up. Ran the ManyGauge example sketch with a T4.0 at 600Mhz without issue.

Thanks for testing. My 5 inch RA8875 arrived yesterday. Looks like it has a different pinout, so I'm going to put off testing it for a while. I'm feeling pretty good about RS8875 - certainly good enough to release 1.53.

KurtE
07-01-2020, 12:42 AM
As I mentioned, I tried it on my 4.3" RA8875 and it worked fine. I could probably also hook up the 5" as well, but as you mentioned it does have different wiring.

But as mentioned good enough to release.