Teensyduino 1.59 Beta #5

I have a modified version of Chris' Uncanny Eyes which compiles without errors on IDE 2 and 1.58.1 and gives this error on 0.59.5:

Code: 
In file included from /Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/config.h:30,
                 from /Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/TeensyEyes.ino:62:
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/src/EyeController.h: In instantiation of 'std::pair<float, float> EyeController<numEyes, Disp>::computeEyelids(Eye<Disp>&) const [with unsigned int numEyes = 2; Disp = GC9A01A_Display]':
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/src/EyeController.h:685:43:   required from 'bool EyeController<numEyes, Disp>::renderFrame() [with unsigned int numEyes = 2; Disp = GC9A01A_Display]'
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/TeensyEyes.ino:205:20:   required from here
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/src/EyeController.h:255:27: note: parameter passing for argument of type 'std::pair<float, float>' when C++17 is enabled changed to match C++14 in GCC 10.1
  255 |   std::pair<float, float> computeEyelids(Eye<Disp> &eye) const {
      |                           ^~~~~~~~~~~~~~

the program is huge. I suspect the error would occur with other attempts to use Chris' codebase. ( I've mostly moved things around and added some audio stuff.) I saw this in 59.4 and reverted to 1.58.1 without saying anything. It showed up subsequent lines when I deleted the offending line with 0.59.4. Is there something different about the way 'array' is handled in the new version?
 
The program runs as expected with 1.58.1--the eyes move and sounds play for 12+hours. If I use just Serial.print statements those seem to print for at least hours. If I include Serial.printf, however, those quit working within 30 minutes; I'm guessing there's a memory leak, although I do not have anything like proof of that. I can live with 1.58.1

With some difficulty I suppose I can figure out a way to send you the source but I think when I zipped it, it was over 3 megabytes. I would never use 'array'. I'm sure it's got correctness/convenience advantages over my old fangled way of doing things but I'm also sure the old fangled way is closer to my mental model of how things work.
 
Most of what I did to make Chris' codebase work on Arduino 2 IDE was to move a huge number of files into src/
 
I tried 'save a copy' then compiling that (somehow I have to recreate the src folder and move everything that I'd put into it back in place). It compiles pretty quickly but I'd guess that means it is not re-using anything from before. Once again I get just the error without the usual list of lengths of various types of memory used.
 
If there's any suspicion that you are not getting a full recompile of everything, a simple/quick way to force a full recompile is to change the Board type to something else, then change it right back to the desired setting (don't even need to initiate a build on the other Board type, but you can if you want to be 200% certain :) ).

Mark J Culross
KD5RXT
 
I tried changing board type and back to teensy 4.1. It does compile, load and start running. It does not show the usual list of memory used in each section, just the error/warning messages -- the same ones, I think.

Code: 
In file included from /Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/config.h:30,
                 from /Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/TeensyEyes.ino:62:
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/src/EyeController.h: In instantiation of 'std::pair<float, float> EyeController<numEyes, Disp>::computeEyelids(Eye<Disp>&) const [with unsigned int numEyes = 2; Disp = GC9A01A_Display]':
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/src/EyeController.h:685:43:   required from 'bool EyeController<numEyes, Disp>::renderFrame() [with unsigned int numEyes = 2; Disp = GC9A01A_Display]'
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/TeensyEyes.ino:205:20:   required from here
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/src/EyeController.h:255:27: note: parameter passing for argument of type 'std::pair<float, float>' when C++17 is enabled changed to match C++14 in GCC 10.1
  255 |   std::pair<float, float> computeEyelids(Eye<Disp> &eye) const {
      |                           ^~~~~~~~~~~~~~


From my perspective, the easiest way to get the 3.7 MB of code to you is probably to put it on an (older) SD card and mail it. I have no real interest in posting stuff on Github, etc. Or struggling with changing the syntax so that old fangled c arrays rather than the new C++ 'array' that Chris' used. I know you'd rather have a short code snippet to pin down the error but at this time I'm not motivated. That's part of why I didn't say anything when I saw this on 59.4.
 
jrraines said:
Does 59.5 use a different compiler version?
Click to expand...

Yes, the compiler is different. In version 1.58.1 compiles with C++14 dialect. In 0.59.5 uses C++17 dialect.

Technically is the same gcc 11.3 software, but because it's run with different dialect options it's effectively a different compiler.

Looks like this may have uncovered a bug in Arduino IDE (or CLI) where files which should be recompiled are instead being reused.
 
I tried to write a small and simple program to reproduce this problem. I only partially succeeded.

main .ino tab
Code: 
#include <utility>
std::pair<float, float> computeTwoThings(int a);

void setup() {
  Serial.begin(9600);
}

void loop() {
  if (Serial.available()) {
    int n = Serial.read();
    std::pair<float, float> things;
    Serial.println(n);
    things = computeTwoThings(n);
    Serial.println(things.first);
    Serial.println(things.second);
    Serial.println();
  }
}

another .cpp tab
Code: 
#include <utility>

std::pair<float, float> computeTwoThings(int a) {
  std::pair<float, float> r;
  r.first = a * 1.234;
  r.second = a * 0.678;
  return r;
}

This does give the parameter passing for argument of type 'std::pair<float, float>' when C++17 is enabled changed to match C++14 in GCC 10.1 message. It always gives this message, even on the first compile. But it compiles and runs fine, despite the message.
 
I will try to put it in the post today. I don't know if it will help, but it's easy to do. I found an ancient 1 gb usb stick.
 
I can reproduce that with @PaulStoffregen s code. I also saw that the warning/note is generated by the compiler, not the linker. So, opposed to what was written in the StackOverflow link it doesn't help doing a clean recompile. Anyway, you can get rid of the note with the compiler flag -Wno-psabi. Maybe there is also a #pragma to disable it localy but, unfortunately, the obvious #pragma GCC diagnostic ignored "-Wpsabi" does not work.
 
Last edited:
Note: when I get strange results, I end up using a sledgehammer and delete their caches:
On Windows: if you look at where: %temp%\arduino is, in my case: on Windows 11
C:\Users\kurte\AppData\Local\Temp\arduino
There are two sub-directories: Cores and Sketches.

I simply delete the directory, which will force everything to have to recompile...
 
Note: when I get strange results, I end up using a sledgehammer and delete their caches:
Click to expand...
Yes, I'll never understand why the Arduino IDE doesn't have a simple "clean all". Anyway, the note is issued during compiling, not linking. So, in this case forcing a rebuild doesn't help.
 
I think the warning is intended for code that may be used to interact with other code or libraries in the future, or if it is intended to itself become a precompiled library. Since most Arduino (or Teensy) projects are standalone, and since all the sources are compiled from scratch (with the exception of a couple internal libraries, eg. math), I don’t think the warning is relevant. It’s there “just in case,” but it’s definitely noise. Unfortunately, it leads to programs being non-warning-free.

The best link I found to explain this was this one: https://www.downtowndougbrown.com/2...ed-to-safely-disable-this-warning-on-arm-gcc/

This paragraph:
Basically, GCC is alerting me that if this interacts with any libraries that were compiled with GCC versions before 7.1, I could run into issues. Definitely a good thing for GCC to be letting me know about just in case.
Click to expand...
 
Again, what I'm seeing at the bottom tile of the arduino 2.2.1 window where it usually finishes with a list of amounts of memory used in various sections is the warning and then nothing below it. It does otherwise finish compiling and uploading and the code runs, but it seems to me that more is wrong than just a warning. What I do NOT see is this:


Code: 
RAM1: variables:19552, code:109592, padding:21480   free for local variables:373664
   RAM2: variables:15552  free for malloc/new:508736
 EXTRAM: variables:16777216

That seems more broken than just a warning.

On my Mac the folder KurtE refers to is at /private/var/folders/cx/4v3v7px56m1bk84ql52nyx100000gn/T/arduino/sketches I think.

I switched back to 1.58.1, compiled to get the memory output above, deleted files inside the sketches folder, switched back to 0.59.5, got this as the final output in that bottom tile of the arduino window:
Code: 
In file included from /Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/config.h:30,
                 from /Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/TeensyEyes.ino:62:
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/src/EyeController.h: In instantiation of 'std::pair<float, float> EyeController<numEyes, Disp>::computeEyelids(Eye<Disp>&) const [with unsigned int numEyes = 2; Disp = GC9A01A_Display]':
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/src/EyeController.h:685:43:   required from 'bool EyeController<numEyes, Disp>::renderFrame() [with unsigned int numEyes = 2; Disp = GC9A01A_Display]'
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/TeensyEyes.ino:205:20:   required from here
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes/src/EyeController.h:255:27: note: parameter passing for argument of type 'std::pair<float, float>' when C++17 is enabled changed to match C++14 in GCC 10.1
  255 |   std::pair<float, float> computeEyelids(Eye<Disp> &eye) const {
      |                           ^~~~~~~~~~~~~~
and the file does upload and run as expected
 
kd5rxt-mark said:
Not sure if I am seeing the same "attempting to upload to the wrong board" as @defragster, but here's the simple case where I am observing a similar (mis)behavior:
Click to expand...

Indeed different than the recently fixed issue which Defragster reported. Sadly, support for this usage scenario is not coming in 1.59.

Teensy Loader simply is not designed to be used with 2 Arduino IDE instances. :(

It only remembers the directory+filename info for a single Teensy board. When you use Verify or Upload in the 2nd IDE, Teensy Loader forgets everything the 1st IDE said. If you press the pushbutton on the 1st Teensy you meant to use with the 1st IDE, but the 2nd IDE has given Teensy Loader new marching orders for your 2nd Teensy, Teensy Loader has forgotten everything the 1st IDE told it to do and will use the only info it has from the 2nd IDE.

Teensy Loader also does not track USB location. That capability was added in the utilities that sit between Arduino IDE and Teensy Loader, starting with Teensyduino 1.42. The (less than ideal) assumption is the specific board you selected in the Tools > Board menu is the one that will soon appear in bootloader mode. Arduino IDE runs a utility (teensy_post_compile or teensy_reboot) which is aware of location info. That utility sends the request for Teensy to go into programming mode. Just before sending the reboot request, it tells Teensy Loader the filename+directory. When Teensy appears (in bootloader mode) a fraction of a second later, or much later if you manually press the button, Teensy Loader only knows the last directory+filename it was told.

The info about which Teensy you actually selected isn't communicated to Teensy Loader at all. Neither is any info about which Teensy model you intended to program actually communicated directly to Teensy Loader. It gets that model number info from reading a .elf file with the same filename as the .hex file. So at least in the case of 2 IDE instances, you do get an error if trying to program code onto the wrong model... if the 2 boards are different models. But Teensy Loader can't detect the problem early, because it's only receiving the directory+filename. As the system works today, the more detailed info about the USB location and expected Teensy model isn't communicated to Teensy Loader at all. The reboot utility uses that info to tell the intended board to reboot and sets Teensy Loader up to do the rest.

Support for usage of 2 IDE instances will require pretty much a complete rewrite of Teensy Loader.
 
Last edited:
jrraines said:
It does otherwise finish compiling and uploading and the code runs,
Click to expand...

Confirm, for 1.59-beta5 I tried to make the size info not appear as red text. It works if you turn on verbose info during compile in File > Preferences (or might be Arduino IDE > Settings on MacOS). But making it ordinary white text in verbose mode turns out to break printing anything at all in non-verbose mode. I've already reverted that change, so 1.59-beta6 (coming later today) will fix this bug, but leave the size info an unfortunate red color text which has occasionally caused people to believe some sort of error occurred. Sadly, it seems Arduino IDE just doesn't give us a way to show the size info as white text in both modes (and I foolishly forgot to test normal mode after I got it "working" as white text in verbose mode).
 
PaulStoffregen said:
Indeed different than the recently fixed issue which Defragster reported. Sadly, support for this usage scenario is not coming in 1.59.

Teensy Loader simply is not designed to be used with 2 Arduino IDE instances. :(

It only remembers the directory+filename info for a single Teensy board. When you use Verify or Upload in the 2nd IDE, Teensy Loader forgets everything the 1st IDE said. If you press the pushbutton on the 1st Teensy you meant to use with the 1st IDE, but the 2nd IDE has given Teensy Loader new marching orders for your 2nd Teensy, Teensy Loader has forgotten everything the 1st IDE told it to do and will use the only info it has from the 2nd IDE.

Teensy Loader also does not track USB location. That capability was added in the utilities that sit between Arduino IDE and Teensy Loader, starting with Teensyduino 1.42. The (less than ideal) assumption is the specific board you selected in the Tools > Board menu is the one that will soon appear in bootloader mode. Arduino IDE runs a utility (teensy_post_compile or teensy_reboot) which is aware of location info. That utility sends the request for Teensy to go into programming mode. Just before sending the reboot request, it tells Teensy Loader the filename+directory. When Teensy appears (in bootloader mode) a fraction of a second later, or much later if you manually press the button, Teensy Loader only knows the last directory+filename it was told.

The info about which Teensy you actually selected isn't communicated to Teensy Loader at all. Neither is any info about which Teensy model you intended to program actually communicated directly to Teensy Loader. It gets that model number info from reading a .elf file with the same filename as the .hex file. So at least in the case of 2 IDE instances, you do get an error if trying to program code onto the wrong model... if the 2 boards are different models. But Teensy Loader can't detect the problem early, because it's only receiving the directory+filename. As the system works today, the more detailed info about the USB location and expected Teensy model isn't communicated to Teensy Loader at all. The reboot utility uses that info to tell the intended board to reboot and sets Teensy Loader up to do the rest.

Support for usage of 2 IDE instances will require pretty much a complete rewrite of Teensy Loader.
Click to expand...
@PaulStoffregen:

Thanks for the explanation...makes complete sense. No change needed.

Mark J Culross
KD5RXT
 
You must log in or register to reply here.
Back
Top