Teensyduino support for Teensy LC?

G

gatheround

Well-known member
Just wondering -

Are the latest versions of Teensyduino still 100% backwards compatible with Teensy LC?

Just wondering if there's any updates that might break compatibility and if maybe the best bet is to only use the teensyduino version last written when the LC was still in production.

Thoughts?
 
Start with the latest and report back if you have trouble. Probably not much change to Teensy3 core, but you’ll have the latest tools, etc.
 
Yeah I actually found a problem!

In 1.59 something breaks that works fine in 1.57.3

I cannot print any String values from my custom struct calib[].name

In my declarations I have a struct and two arrays of said structure, config[] and calib[]. I have no problem printing any config[].name, but in 1.59 and 1.58.2, all calib[].name Strings show up blank.


Code: 
typedef struct
{
    uint8_t *pnt;
    String name;
} pointnname;

pointnname config[] = {
    {&serialmode, "serialmode - (0=off 1=debug 2=raw adc 3=osc pitch 4=osc pitch slow)"},
    ... 23 other declarations
};

pointnname calib[] = {
    {&daccorrectionoffsetval, "daccorrectionoffsetval (64 is null)"},
    ... 7 other delcarations
};

in my code I have:

Code: 
Serial.print(calib[a].name);

this outputs the expected String in 1.57.3 but displays nothing in 1.59

From what I can see everything else works, although it's hard to tell at this point since it's a very large program written years ago.

It seems like it's a memory allocation problem or something, if I reverse the order of the delcarations so calib[] is declared before config[], all of calib[].name work but ony the first 20 declared config[].name Strings display correctly.
 
Last edited:
One of the C++ gurus can probably tell you what’s wrong. It may be something to do with the way you’re initializing your String variables.
 
gatheround said:
In 1.59 something breaks that works fine in 1.57.3
Click to expand...

Just a guess, maybe it's related to the gcc toolchain from 5.4 to 11.3.

Long ago we used constexpr constructors in the main Arduino API classes like Print, String, Wire, SPI. With the old gcc 5.4, this caused those static classes to be fully initialized at compile time. But apparently that behavior wasn't fully guaranteed by the C++ spec. It's has been added as constinit by C++20, but we're so far only using C++17. Quite a bit of work went into experimenting with different syntax to get the constinit behavior back. I believe 1.59 has that work, but since it's easy to try you might as well try 1.60-beta5 to see if it makes this problem magically disappear.

This constinit stuff only matters if you use Print or String or other stuff not part of your custom class in its constructor(s). Of course there is general C++ guidance that you really shouldn't do such things in any class with static instances. But the reality of classes like String, Print, Wire, SPI is people expect code from ordinary functions to be work if copied into C++ constructors. If you've done that, it definitely would have worked with the old version before the toolchain update. It should also work with the latest. Or maybe "should" isn't quite the right word. From a pure C++ language specification perspective, before C++20 constinit didn't even exist so it was never officially possible. But unofficially, it worked great with gcc 5.4. Also unofficially, we found a syntax that seems to always work with 11.3. So this is getting into multiple levels of guesswork... maybe your struct is somehow similar to custom classes? Maybe it's somehow being used early as static constructors are being run?


gatheround said:
I cannot print any String values from my custom struct calib[].name
Click to expand...

To really help, I need you to craft a (hopefully small) sample program which reproduces the problem. I still have a few old Teensy LCs here for testing, so if you give a complete program, I can give it a try here.
 
PaulStoffregen said:
Just a guess, maybe it's related to the gcc toolchain from 5.4 to 11.3.

Long ago we used constexpr constructors in the main Arduino API classes like Print, String, Wire, SPI. With the old gcc 5.4, this caused those static classes to be fully initialized at compile time. But apparently that behavior wasn't fully guaranteed by the C++ spec. It's has been added as constinit by C++20, but we're so far only using C++17. Quite a bit of work went into experimenting with different syntax to get the constinit behavior back. I believe 1.59 has that work, but since it's easy to try you might as well try 1.60-beta5 to see if it makes this problem magically disappear.

This constinit stuff only matters if you use Print or String or other stuff not part of your custom class in its constructor(s). Of course there is general C++ guidance that you really shouldn't do such things in any class with static instances. But the reality of classes like String, Print, Wire, SPI is people expect code from ordinary functions to be work if copied into C++ constructors. If you've done that, it definitely would have worked with the old version before the toolchain update. It should also work with the latest. Or maybe "should" isn't quite the right word. From a pure C++ language specification perspective, before C++20 constinit didn't even exist so it was never officially possible. But unofficially, it worked great with gcc 5.4. Also unofficially, we found a syntax that seems to always work with 11.3. So this is getting into multiple levels of guesswork... maybe your struct is somehow similar to custom classes? Maybe it's somehow being used early as static constructors are being run?




To really help, I need you to craft a (hopefully small) sample program which reproduces the problem. I still have a few old Teensy LCs here for testing, so if you give a complete program, I can give it a try here.
Click to expand...

Thanks Paul, I'm unable to create a small sample program that reproduces the problem because when I do, the problem goes away.

I can remove some large blocks and the problem remains. But I can remove something as simple as:

Code: 
    while (usbMIDI.read()) // catches any incoming midi messages so buffer doesn't overrun
    {
    }

from the main loop and the problem goes away! even when printing the struct Strings from the setup loop. It's like once the program gets simple enough, the problem goes away. So it's almost like a processing overhead thing or a memory use thing.

I'll try 1.60-beta5 soon and report back.
 
You must log in or register to reply here.
Back
Top