Teensyduino 1.62 Beta #2

Collecting a quick list of all the minor edits so far since beta2. Mostly cleaning up a huge pile of compiler warnings.

SPI compile time init on Teensy 3

Wire consistent internal port address name for compile time init testing

boards.txt change -flto to -flto=auto - multithreaded LTO and avoid warning

SdFat warnings fix (msg #18)

FS.h compiler warning

Teensy 4.1 memory section types (msg #15)

MTP Storage warning

Silly warning on Teensy 2.0

Adafruit_STMPE610 compiler warning

Update to latest FlexCAN_T4

IRremote compiler warning

VirtualWire compiler warning
 
Last edited:
Can we take it you're determined to go it alone on all these fixes? Or is it worth trying to delegate at least a first pass to willing forum members?
 
I've already fixed the majority of the warnings with beta2. I should probably package up beta3 soon, so we don't risk duplicating effort.

But yes, could use help with some stuff. NativeEthernet still needs attention. Still some small warnings in ST7735 and ILI9341_t3n.

Fixed warnings in ST7735_t3, and updated Adafruit_nRF8001 and fixed warnings. Could really use help with testing to make sure I didn't break these libraries!

The ST7735_t3_multiple.ino example needs some attention, possible conflicts with SPI_INTERFACES_COUNT defined by core library.
 
I've done a very quick test on the ST7735_t3_multiple.ino example with a Teensy 4.1. Compiles OK with no warnings, and runs one screen on SPI with pins changed to suit my hardware. I'll add a second screen and check they both work together OK.
 
PaulStoffregen said:
It's in ILI9488_t3.h at line 561
Click to expand...
pushed up.

PaulStoffregen said:
Still some small warnings in ILI9341_t3n.
Click to expand...
Which sketch, which board?

EDIT: I tried t3.2 looked like similar uninitialized, which was half way correct. That is the first time that function is called, they are
but called again right after that when the next call in the init sets those and then recalls...

Pushed up.
 
Last edited:
Thanks @KurtE and @h4yn0nnym0u5e - I've pulled in these changes.

Kurt, could I talk you into one more look at ILI9341_t3n doubleBuffer.ino example? Compiling for Teensy 4.1 with default settings gives a couple compiler warnings about addresses never NULL.

Yeah, this new gcc 15.2 is quite picky!
 
PaulStoffregen said:
Kurt, could I talk you into one more look at ILI9341_t3n doubleBuffer.ino example? Compiling for Teensy 4.1 with default settings gives a couple compiler warnings about addresses never NULL.
Click to expand...

Code: 
D:\temp\.arduinoIDE-unsaved202653-12208-3mqc01.sa1k4\doubleBuffer\doubleBuffer.ino:48:22: warning: the address of 'fb1' will never be NULL [-Waddress]
   48 |   tft.useFrameBuffer(fb1);
      |                      ^~~
D:\temp\.arduinoIDE-unsaved202653-12208-3mqc01.sa1k4\doubleBuffer\doubleBuffer.ino:11:17: note: 'fb1' declared here
   11 | DMAMEM uint16_t fb1[320 * 240];

Sorry, I may be behind the times, but why is that a problem?
The header file has:
Code: 
void setFrameBuffer(uint16_t *frame_buffer);
 
Because
C++: 
uint8_t useFrameBuffer(boolean b);  // use the frame buffer?  First call will allocate
vs
C++: 
void setFrameBuffer(uint16_t *frame_buffer);

Line 48 looks as if it's expecting a bool, and you've handed it a pointer, moreover a pointer which the compiler knows is never nullptr; it can therefore tell you've made an error...
 
h4yn0nnym0u5e said:
Line 48 looks as if it's expecting a bool, and you've handed it a pointer, moreover a pointer which the compiler knows is never nullptr; it can therefore tell you've made an error...
Click to expand...
😲 :oops:

Sorry my eyes glazed over and the it was setFrameBuffer... A bug, not the error message was not overly helpful, but...
Anyway pushed up changes
 
KurtE said:
Anyway pushed up changes
Click to expand...

Thanks! Looks like you pushed this fix just a moment before I started running my verify_all script again, which automatically pulled the latest. Happy to say it hasn't complained about ILI9431_t3n on this round.

Here's what I'm still seeing. Seems like a long list, but this is a huge improvement over beta2, and on-par or maybe even better than we've ever had with the gcc 11.3 toolchain.

Code: 
Libraries shipped with Teensyduino
----------------------------------
ssd1351   Fastest LTO  -Wnarrowing
XBee  Series1_Tx.ino   -Wuninitialized
Adafruit_nRF8001  echoDemo.ino  Smallest LTO  -Wsign-compare
NativeEthernet  -Wint-in-bool-context  -Warray-parameter  -Wstringop-overflow
SdFat  TeensyDmaAdcLogger.ino  T4.0 Smallest

Libraries primarily used with Teensy
------------------------------------
QNEthernet  T4.1 Fastest  SNTPClient.ino  -Wstringop-truncation

External libraries not focused on Teensy
----------------------------------------
Adafruit_NeoPixel  T4.0 Smallest LTO  RGBWstrandtest.ino  -Wsign-compare
Adafruit_BusIO   T4.1 Fastest LTO   genericdevice_uarttest.ino  -Wsign-compare
Adafruit_VS1053  -Wsign-compare
Adafruit_ILI9341  -Wmaybe-uninitialized
Adafruit_STMPE610  T3.6  -Wmaybe-uninitialized
Madgwick   -Wstrict-aliasing
ArduinoUnit  -Wsign-compare  advanced.ino

Libraries to add to testing  (maybe??)
---------------------------
SmartMatrix
Luni's TeensyStep for Teensy 4?
Frank's MP3 ?
Audio with floats?
others???

Looking for feedback on libraries I should add. Especially libraries meant only or primarily for Teensy but not bundled with the Teensyduino install should probably go onto my verify_all script.

I'm going to package up beta3 this evening, so anyone who wants to join in the fun doesn't have the suffer the huge number of compiler warnings fixed so far this week.
 
The only library I can think of to add to the non-Teensyduino pool is TeensyTimerTool, and then only because I happen to be using it on a current project.
 
h4yn0nnym0u5e said:
The only library I can think of to add to the non-Teensyduino pool is TeensyTimerTool
Click to expand...

I added TeensyTimerTool. Also dove into NativeEthernet and cleaned up several warnings.

The script is finding a minor issue inside TeensyTimerTool with 2 slightly different setPrescaler() functions.
 
Opps: Picked '...TeensyTimerTool\examples\03_Applications\DoubleExposure' and it doesn't have T_4.x suppport:
PulseGenerator.h:60: error: 'FTM0' is not a member of 'TeensyTimerTool'

Code: 
"T:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++17 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -Wno-psabi -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=160 -DARDUINO=10819 -DARDUINO_TEENSY41 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IT:\\TEMP\\arduino_build_45789/pch" "-IT:\\T_Drive\\arduino-1.8.19\\hardware\\teensy\\avr\\cores\\teensy4" "-IT:\\T_Drive\\tCode\\libraries\\TeensyTimerTool\\src" "T:\\TEMP\\arduino_build_45789\\sketch\\DoubleExposure.ino.cpp" -o "T:\\TEMP\\arduino_build_45789\\sketch\\DoubleExposure.ino.cpp.o"
In file included from T:\T_Drive\tCode\libraries\TeensyTimerTool\examples\03_Applications\DoubleExposure\LaserController.h:2,
                 from T:\T_Drive\tCode\libraries\TeensyTimerTool\examples\03_Applications\DoubleExposure\SystemController.h:2,
                 from T:\T_Drive\tCode\libraries\TeensyTimerTool\examples\03_Applications\DoubleExposure\DoubleExposure.ino:1:
T:\T_Drive\tCode\libraries\TeensyTimerTool\examples\03_Applications\DoubleExposure\PulseGenerator.h: In constructor 'PulseGenerator::PulseGenerator()':
PulseGenerator.h:60: error: 'FTM0' is not a member of 'TeensyTimerTool'
   60 |     : pulseTimer(TeensyTimerTool::FTM0)         // use one of the 8 FTM0 channels
      |                                   ^~~~
Using library TeensyTimerTool at version 1.4.0 in folder: T:\T_Drive\tCode\libraries\TeensyTimerTool
'FTM0' is not a member of 'TeensyTimerTool'
 
kd5rxt-mark said:
@PaulStoffregen: E-mail sent. Glad to help !!
Click to expand...

I looked at this today. The unfortunate news is the new gcc 15.2 compiler produces slightly larger code than gcc 11.3.

Previously your code in RAM1 was 324104 bytes, which fit nicely into 10 blocks of 32K. But with gcc 15.2, the code in RAM1 grew to 328712.

That's a 1.4% increase in compiled code size.

The main problem is 328712 pushes slight beyond 327680 bytes of 10 blocks, meaning an 11th RAM1 block of 32K needs to be taken from the memory available for variables. That leaves not enough RAM1 for all your variables, so compiling fails due to not enough memory.

The easy answer is to compile with Tools > Optimize set to Smallest Code.

The not so easy answer is to convert more functions to FLASHMEM. I see you already have many of them. If you can convert more to trim just 1023 bytes, you'll get back to the 10 block threshold that makes gives you 192K RAM for your variables.
 
@shawn - did you have a suggestion some time ago about overriding some C++ standard library stuff that needlessly takes up code space? I seem to remember seeing it, but can't find on my list of stuff to investigate.
 
PaulStoffregen said:
@shawn - did you have a suggestion some time ago about overriding some C++ standard library stuff that needlessly takes up code space? I seem to remember seeing it, but can't find on my list of stuff to investigate.
Click to expand...
Let me look around and get back to you likely tomorrow.
 
PaulStoffregen said:
I looked at this today. The unfortunate news is the new gcc 15.2 compiler produces slightly larger code than gcc 11.3.

Previously your code in RAM1 was 324104 bytes, which fit nicely into 10 blocks of 32K. But with gcc 15.2, the code in RAM1 grew to 328712.

That's a 1.4% increase in compiled code size.

The main problem is 328712 pushes slight beyond 327680 bytes of 10 blocks, meaning an 11th RAM1 block of 32K needs to be taken from the memory available for variables. That leaves not enough RAM1 for all your variables, so compiling fails due to not enough memory.

The easy answer is to compile with Tools > Optimize set to Smallest Code.

The not so easy answer is to convert more functions to FLASHMEM. I see you already have many of them. If you can convert more to trim just 1023 bytes, you'll get back to the 10 block threshold that makes gives you 192K RAM for your variables.
Click to expand...
@PaulStoffregen: thanks for your investigation & for the detailed follow-up description. I'll have to take a look to see if there's a candidate function to join the others in FLASHMEM, but in the meantime, using Smallest Code is no problem at all. I already use that optimization selection for the T4.0 managing the Audio portion of the TMPS, and it serves its purpose very well.

Thanks again,

Mark J Culross
KD5RXT
 
PaulStoffregen said:
@shawn - did you have a suggestion some time ago about overriding some C++ standard library stuff that needlessly takes up code space? I seem to remember seeing it, but can't find on my list of stuff to investigate.
Click to expand...
This thread, maybe? Or possibly this one?

I’ve recently experienced the linking in of odd stuff I wasn’t using, as referred to in this post. Unfortunately it’s in an application which uses quite a few heavily modified libraries, and a modified cores, so it‘s hard to “post a simple example”. But do let me know if it becomes necessary to email a complex example, with instructions…
 
You must log in or register to reply here.
Back
Top