Teensyduino 1.58 Released

W5ZZO said:
I figured out how I got the compile to happen with the missing semi-colon. I have autosave set to 6 seconds in my preferences.
It's probably an omission or a bug, but you can run "compile" or "upload" with a dirty file... you won't get prompted to save, and the disk image is yet unchanged.

That is masking what is the real problem, and that is that the directory for the project outputs gets deleted prior to teensyduino obtaining the .hex file. This seems to happen mostly after there was a failed compilation, and you fix the issue and try a new compilation.

That said, if none of you can reproduce this, the odds of anyone ever looking at it and fixing it are pretty slim.

- Wes, W5ZZO
Click to expand...

Sorry couldn't find that setting in advanced - more than likely I did but do not know how to set. Probably someone else will
 
ctrl-shift-p in IDE 2.0.4. That is workplace settings, look in the Files portion. I had mine on 10000 (10 seconds).
I changed mine back to the default 1000 (milliseconds) setting... the last thing I want is to make a code change, compile upload the file and then scratch my head about why things appear the same as before.
But that was why my deleted semicolon did not generate an error, as 10 seconds was enough for the compiler to chew through the first file.

- Wes, W5ZZO
 
@W5ZZO
Not sure if related to your issue or not but I have noticed that bugs (or no longer allowed procedures by me) can mess up the aggressive caching of previous compiles in 2.0.4 and the nightlies. Previous 1.8.xx versions of arduino cleared the cache when you quit arduino but 2.0.4+ try to keep all sorts of things cached. I have an unanswered question on GitHub about how to clear the cache.

For example, changes to the board.txt file done in /Users/me/Library/Arduino15/packages/teensy/hardware/avr/1.58.0/boards.txt (on macOS) do not cause the cache to be flushed. This also caused weird problems with upgrading when I had a successful compiled version of the old version still in the cache. I ended up doing:

cd /private/var/folders/q9/pwxvzmz56xvbkcnp3q0gsjkr0000gn/T/arduino

and deleting the directories cores and sketches. I'm sure this is not the recommended procedure but it worked.
 
@W5ZZO
I think KurtE was pointing out the same issue:
#22

Also the main point I forgot to make was that if it's messing up in 2.0.4+ try in 1.89.19
 
W5ZZO said:
ctrl-shift-p in IDE 2.0.4. That is workplace settings, look in the Files portion. I had mine on 10000 (10 seconds).
Click to expand...

with ctrl-shift-p I get list of commands /short-cuts but not workplace settings (2.0.4 Win11)
 
ctrl-shift-p, then find "Preferences: Open User Settings"

I also had issues with "tons of temp files" causing errors... mine was something about mingw making an illegal memory access, I assume it found more files than it had buffers, deleting /Temp fixed that.

As for 1.8.19, it is no longer installed. Too many features in 2.0 to give up. Just want 2.0 to be reliable.

- Wes
 
W5ZZO said:
ctrl-shift-p in IDE 2.0.4. That is workplace settings, look in the Files portion. I had mine on 10000 (10 seconds).
I changed mine back to the default 1000 (milliseconds) setting... the last thing I want is to make a code change, compile upload the file and then scratch my head about why things appear the same as before.
But that was why my deleted semicolon did not generate an error, as 10 seconds was enough for the compiler to chew through the first file.

- Wes, W5ZZO
Click to expand...

Ok with help from @KurtE I changed the autosave delay to 10000 from 1000:
autosaveDely.PNG

I then compiled and uploaded your sketch no issues (just a test). I then removed a semi-colon and tried to reload the sketch and received the error message about missing semi-colon only... NOT what you are seeing:
errormsg.PNG

Tried it a couple of times going back and forth with/without the semi-colon, couldn't duplicate what you are seeing.
 
Working with the USBHost_t36.h, after updating to 1.58 Logitech wireless ERGO M575 started providing following messages constantly couple of times per second, I guess it is really sending those, and previously they just did not come trough ?

Any idea what they mean?

Code: 
When mouse not moved (these are new with 1.58)
UNKNOWN USAGE: 700E0, VALUE: 0
UNKNOWN USAGE: 700E1, VALUE: 0
UNKNOWN USAGE: 700E2, VALUE: 0
UNKNOWN USAGE: 700E3, VALUE: 0
UNKNOWN USAGE: 700E4, VALUE: 0
UNKNOWN USAGE: 700E5, VALUE: 0
UNKNOWN USAGE: 700E6, VALUE: 0
UNKNOWN USAGE: 700E7, VALUE: 0
UNKNOWN USAGE: 70000, VALUE: 1
UNKNOWN USAGE: 70000, VALUE: 1
UNKNOWN USAGE: 70000, VALUE: 1
UNKNOWN USAGE: 70000, VALUE: 1
UNKNOWN USAGE: 70000, VALUE: 1
UNKNOWN USAGE: 70000, VALUE: 1

When mouse is moved (these come also before)
UNKNOWN USAGE: 90004, VALUE: 0
UNKNOWN USAGE: 90005, VALUE: 0
UNKNOWN USAGE: 90006, VALUE: 0
UNKNOWN USAGE: 90007, VALUE: 0
UNKNOWN USAGE: 90008, VALUE: 0
UNKNOWN USAGE: 90009, VALUE: 0
UNKNOWN USAGE: 9000A, VALUE: 0
UNKNOWN USAGE: 9000B, VALUE: 0
UNKNOWN USAGE: 9000C, VALUE: 0
UNKNOWN USAGE: 9000D, VALUE: 0
UNKNOWN USAGE: 9000E, VALUE: 0
UNKNOWN USAGE: 9000F, VALUE: 0
UNKNOWN USAGE: 90010, VALUE: 0
UNKNOWN USAGE: C0238, VALUE: 0

the actual mouse movements are on thise

Code: 
          case 0x010030: { mouse_tmp.MOV[0].x        = value; }  break;
          case 0x010031: { mouse_tmp.MOV[0].y        = value; }  break;
          case 0x010038: { mouse_tmp.sroll.action[0] = value; }  break;
          case 0x090001: { mouse_tmp.b[1].action[0]  = value; }  break;
          case 0x090002: { mouse_tmp.b[2].action[0]  = value; }  break;
          case 0x090003: { mouse_tmp.b[3].action[0]  = value; }  break;

It seems all these are now provided couple of times at second if no movement and seems to provide last update, the mouse x and y may be +-1 at last 1 is 1, so the last movement is sent constantly, is that really the mouse that is doing that? I could use the 700xx messages to set mouse speed to 0...

3Dconnexion wireless provides now couple of seconds after the movement has been stoped this

Code: 
UNKNOWN Usage3: 60020
 UNKNOWN Usage3: FF000027

So maybe some Wireless goes to sleep. that is good.
 
Last edited:
Who else would be sending it? ;)

I am assuming this is a wireless mouse? As I mentioned in a few threads, some of these dongles also support keyboards.
Earlier on some of these dongles it was totally hanging USBHost... And from USBHost side, no way for us to know if these are useful messages or not.

If you look into the HID Usage Table documents, I have hut1_3_0.pdf) open right now. If you don't have this document, you should do a internet search and download...

UNKNOWN USAGE: 700E0, VALUE: 0
The high word in this is the Usage Page: so in this case 7 which is Keyboard/Keypad For what it is worth, in this page E0 is Keyboard Left Control. E1 left shift, Alt, left GUI,
right ... The 70000 - 0 is reserved probably means ignore more.

The other messages: 90004 is page 9 the Button page.
90000 is no button presses, 90001 is logical button one pressed or not. The value tells you if pressed or not.
 
Edit: ignore the below. After looking into my code, it is just the 700xx messages that arrives after mouse movement has stoped. That just triggers my code to reprocess the last received data.

I must look a bit more into it to eliminate that it is on my code, but why would the mouse send constantly the last update of mouse movement. This is problematic as it seems x and/or y are always +-1 based on what direction the last movement was. So I get constantly updates the mouse is moving though it is not. This came with 1.58.
 
Are you sure? That is I don't see anything in your first post that had usage values like: 0x010030 or 0x010031 which are
the X and Y values. Could it simply be that when you receive these other messages you simply left all of the values to the previous time
your processing of messages happens and are left with the old junk?

Maybe when you receive the hid_input_begin your code and maybe in mouse.cpp needs to clear out those values and/or only generate
an event hid_input_end if there was some values in the mouse or button ranges.
 
The actual data comes with these (also above)

Code: 
          case 0x010030: { mouse_tmp.MOV[0].x        = value; }  break;
          case 0x010031: { mouse_tmp.MOV[0].y        = value; }  break;
          case 0x010038: { mouse_tmp.sroll.action[0] = value; }  break;
          case 0x090001: { mouse_tmp.b[1].action[0]  = value; }  break;
          case 0x090002: { mouse_tmp.b[2].action[0]  = value; }  break;
          case 0x090003: { mouse_tmp.b[3].action[0]  = value; }  break;

It is currently just printout that I have on code, and it gets activated when data comes from mouse. Before 1.58 data come only when moving mouse, now also when stopped. So I had the printout trigger mouse1.updated = true; on wrong place, now it is ok.

The nice thing would be if the mouse would send x, y both zeros when movement has stopped, but seems not.

In lack of better I added now this

Code: 
          case 0x0700E0: case 0x0700E1: case 0x0700E2: case 0x0700E3: case 0x0700E4:
          case 0x0700E5: case 0x0700E6: case 0x0700E7: case 0x070000: 
          { mouse_tmp.MOV[0].x = 0; mouse_tmp.MOV[0].y = 0; } break;

there is about 0.5 s delay, but with this I can get the mouse to x, y zero when no movement.

Ps. unlike the Logitech M575, the 3Dconnexion really take care of providing 0 at the end of the movement

Code: 
  x 0 y 92 z 103 pitch -12 roll -263 yaw 82 b1 0 b2 0
 x 0 y 89 z 95 pitch 0 roll -206 yaw 68 b1 0 b2 0
 x -26 y 77 z 62 pitch 0 roll -102 yaw 42 b1 0 b2 0
 x -56 y 23 z 0 pitch 5 roll 13 yaw 14 b1 0 b2 0
 x -20 y 12 z 0 pitch 5 roll 47 yaw 6 b1 0 b2 0
 x 0 y 0 z 0 pitch 0 roll -13 yaw 0 b1 0 b2 0
 x 0 y 0 z 0 pitch 0 roll 0 yaw 0 b1 0 b2 0
 x 0 y 0 z 0 pitch 0 roll 0 yaw 0 b1 0 b2 0
 x 0 y 0 z 0 pitch 0 roll 0 yaw 0 b1 0 b2 0
 x 0 y 0 z 0 pitch 0 roll 0 yaw 0 b1 0 b2 0
 UNKNOWN Usage3: 60020 //comes couple of seconds after movement, maybe wireless sleep?
 UNKNOWN Usage3: FF000027

EDIT: just update, the 700xx messages are useful for setting the mouse x and y zero (for applications that need that) So good thing we get them now.

After a fast movement it takes about 0.5 s to activate.
Code: 
 x -2 y 6 s 0 b1 0 b2 0 b3 0 time 8
 x 0 y 5 s 0 b1 0 b2 0 b3 0 time 8
 x -1 y 6 s 0 b1 0 b2 0 b3 0 time 8
 x -1 y 5 s 0 b1 0 b2 0 b3 0 time 8
 x 0 y 2 s 0 b1 0 b2 0 b3 0 time 8
 x 2 y 1 s 0 b1 0 b2 0 b3 0 time 8
 x 7 y 3 s 0 b1 0 b2 0 b3 0 time 16
 x 5 y 2 s 0 b1 0 b2 0 b3 0 time 8
 x 3 y 1 s 0 b1 0 b2 0 b3 0 time 6
 x 0 y 0 s 0 b1 0 b2 0 b3 0 time 490

With slower movement it activates faster after last mouse update

Code: 
 x -1 y 0 s 0 b1 0 b2 0 b3 0 time 24
 x 0 y 1 s 0 b1 0 b2 0 b3 0 time 242
 x -1 y 0 s 0 b1 0 b2 0 b3 0 time 48
 x 0 y 0 s 0 b1 0 b2 0 b3 0 time 140
 x 0 y 1 s 0 b1 0 b2 0 b3 0 time 14
 x -1 y 0 s 0 b1 0 b2 0 b3 0 time 32
 x 0 y 1 s 0 b1 0 b2 0 b3 0 time 202
 x 0 y 0 s 0 b1 0 b2 0 b3 0 time 248

It would be actually difficult to make better mouse movement stoped indicator, as the update interval depends of the movement speed somewhat. (time ms between the updates)
 
Last edited:
Probably the mouse driver needs to be updated. To do as I mentioned above, of either clear the data out at the start of receiving the next set of HID data.
And/or to detect that the HID data did not contain any mouse information and not inform you that a new message had come in.

It is shame it was not caught during the beta cycle for 1.58. I believe all of these changes were done something like 4 or 6 months ago, which was included in several of the betas.
 
So do you think the mouse actually sends x and y zero at the end of the movement? and it is just missed somehow?

But over all I would rather just get all the data that belongs to the mouse and is relevant for the control movements detection, unfiltered. I mean, just receive and process it on my code like this

Code: 
void HID_Input::hid_input_data(uint32_t Usage, int32_t value)
{   

    //MOUSE
    if(hid_input_dev == 2)
      {  
    switch (Usage) 
         {
          case 0x010030: { mouse_tmp.MOV[0].x        = value; }  break;
          case 0x010031: { mouse_tmp.MOV[0].y        = value; }  break;
          case 0x010038: { mouse_tmp.sroll.action[0] = value; }  break;
          case 0x090001: { mouse_tmp.b[1].action[0]  = value; }  break;
          case 0x090002: { mouse_tmp.b[2].action[0]  = value; }  break;
          case 0x090003: { mouse_tmp.b[3].action[0]  = value; }  break;
          //Logitech M575 for some reason sends these, just to ignore
          case 0x090004: case 0x090005: case 0x090006: case 0x090007: case 0x090008:
          case 0x090009: case 0x09000A: case 0x09000B: case 0x09000C: case 0x09000D:
          case 0x09000E: case 0x09000F: case 0x090010: case 0x0C0238: break;

          case 0x0700E0: case 0x0700E1: case 0x0700E2: case 0x0700E3: case 0x0700E4:
          case 0x0700E5: case 0x0700E6: case 0x0700E7: case 0x070000: 
          { mouse_tmp.MOV[0].x = 0; mouse_tmp.MOV[0].y = 0; } break;

          default:       { Serial.print(" UNKNOWN Usage2: "); Serial.println(Usage, HEX);     }  break;    
        }
      }
 
Garug said:
So do you think the mouse actually sends x and y zero at the end of the movement? and it is just missed somehow?

But over all I would rather just get all the data that belongs to the mouse and is relevant for the control movements detection, unfiltered. I mean, just receive and process it on my code like this
Click to expand...
Sorry little bits and pieces of the code often don't show how all of the things work together.

As I mentioned, we could potentially add code into the mouse code to check as I mentioned.

I have not noticed the issue you are seeing, as most of our code goes something like:
Code: 
  if (mouse1.available()) {
    Serial.print("Mouse: buttons = ");
    Serial.print(mouse1.getButtons());
    Serial.print(",  mouseX = ");
    Serial.print(mouse1.getMouseX());
    Serial.print(",  mouseY = ");
    Serial.print(mouse1.getMouseY());
    Serial.print(",  wheel = ");
    Serial.print(mouse1.getWheel());
    Serial.print(",  wheelH = ");
    Serial.print(mouse1.getWheelH());
    Serial.println();
    mouse1.mouseDataClear();
  }
So we detect that we have a mouse event, and then get the data and then clear out the data.
Code: 
void MouseController::mouseDataClear() {
	mouseEvent = false;
	buttons = 0;
	mouseX  = 0;
	mouseY  = 0;
	wheel   = 0;
	wheelH  = 0;
}
So even if we get a new event with no mouse data in it, the X, Y and the like will be zero.

Note: we potentially should have disabled interrupts to USB and the like when processing the Mouse data and clearing it, as who knows we may have received 8 mouse inputs in between the time the first happened and we decide to try to process it.
 
I rather get just the RAW data updates, and decide then what to do with that.

for a mouse 8 updates on the buffer would not be good, but not terribly bad either for most use, 8 ms update so 64 ms latency.

For some applications it could be good just to get the latest, but most often probably better process them all, each update is increment on x or y or both.

Joystick or 3D mouse would be different as they provide the absolute position/force, so best to get the latest update as fast as possible.

Still a question so I understand it. I am now using

virtual void hid_input_begin(uint32_t topUsage, uint32_t type, int lgmin, int lgmax);
virtual void hid_input_data(uint32_t Usage, int32_t value);
virtual void hid_input_end();

to get the HID data do I get with these all the data from the device, or could some messages be dropped filtered etc.
 
Last edited:
I'm using the lin_bus.h library with Arduino IDE 2.0.4 on a Teensy 4.

https://github.com/MarkusLange/Teensy_3.x_4.x_and_LC_LIN_Master

This is working with v1.57.2 and now I've upgraded to v1.58.0 but the Teensy looks like it crashes on startup.

Code: 
#include "lin_bus.h"

LIN lin(&Serial3, 19200);

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
}


void loop() {

  digitalWrite(LED_BUILTIN, HIGH);
  delay(200);

  digitalWrite(LED_BUILTIN, LOW);
  delay(200);
}

Looks like this library is not compatible with v1.58 but works ok on v1.57.2

Whats in v1.58 that stops it working ?
 
Garug said:
I rather get just the RAW data updates, and decide then what to do with that.

for a mouse 8 updates on the buffer would not be good, but not terribly bad either for most use, 8 ms update so 64 ms latency.

For some applications it could be good just to get the latest, but most often probably better process them all, each update is increment on x or y or both.

Joystick or 3D mouse would be different as they provide the absolute position/force, so best to get the latest update as fast as possible.

Still a question so I understand it. I am now using

virtual void hid_input_begin(uint32_t topUsage, uint32_t type, int lgmin, int lgmax);
virtual void hid_input_data(uint32_t Usage, int32_t value);
virtual void hid_input_end();

to get the HID data do I get with these all the data from the device, or could some messages be dropped filtered etc.
Click to expand...

You get all of the messages as long as your code, has said it wants it. That is for thoe topusage your object code says claim_report when claim_collection is called.
 
KurtE said:
You get all of the messages as long as your code, has said it wants it. That is for thoe topusage your object code says claim_report when claim_collection is called.
Click to expand...

Is there some example how to do this? should it be here, how?

Code: 
class HID_Input : public USBHIDInput {
public:    
  HID_Input(USBHost &host, uint32_t Usage = 0) : fixed_Usage_(Usage) { INIT(); }
  uint32_t Usage(void) {return Usage_;}
  
protected:
  virtual hidclaim_t claim_collection(USBHIDParser *driver, Device_t *dev, uint32_t topUsage);
  virtual bool hid_process_in_data(const Transfer_t *Transfer);
  virtual void hid_input_begin(uint32_t topUsage, uint32_t type, int lgmin, int lgmax);
  virtual void hid_input_data(uint32_t Usage, int32_t value);
  virtual void hid_input_end();
 // virtual bool hid_process_in_data(const Transfer_t *transfer);
  virtual void disconnect_collection(Device_t *dev);

  
private:
  void         INIT();
  USBHIDParser *driver_;
  uint8_t      collections_claimed = 0;
  volatile int hid_input_begin_level_ = 0;
  uint32_t     fixed_Usage_;
  uint32_t     Usage_ = 0;
  Transfer_t mytransfers[4] __attribute__ ((aligned(32)));
};
 
skpang said:
I'm using the lin_bus.h library with Arduino IDE 2.0.4 on a Teensy 4.

https://github.com/MarkusLange/Teensy_3.x_4.x_and_LC_LIN_Master

This is working with v1.57.2 and now I've upgraded to v1.58.0 but the Teensy looks like it crashes on startup.

Code: 
#include "lin_bus.h"

LIN lin(&Serial3, 19200);

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
}


void loop() {

  digitalWrite(LED_BUILTIN, HIGH);
  delay(200);

  digitalWrite(LED_BUILTIN, LOW);
  delay(200);
}

Looks like this library is not compatible with v1.58 but works ok on v1.57.2

Whats in v1.58 that stops it working ?
Click to expand...

It is using a whole new version of GCC toolchain. I have no idea what the LIN code is for... But looks like it takes over the code for a hardware Serial port.

If it were me and could plug in the USB, I would

probably see if you can get a CrashReport.

That is in setup do something like:

Code: 
void setup() {
    if (CrashReport) {
        while (!Serial && millis() < 5000) ; // wait up to 5 seconds for serial port
        Serial.print(CrashReport);
    }
    LIN lin(...
}
And see if it crashes.
You might also put the !Serial stuff before CrashReport so it always waits for some time for you to connect up Serial terminal...

Then maybe put things in like:
Code: 
    Serial.println("Before LIN  object created"); Serial.flush();
   LIN lin(&Serial3, 19200);
    Serial.println("After created"); Serial.flush();

Wondering how this code is supposed to work, as your LIN object is inside of the setup() method. So it will get destroyed when setup() returns.
The destructor should be called, did not see one... So the _stream member variable if something still access is some random place on the stack which
could easily be overwritten...
 
Putting LIN lin(&Serial3, 19200); inside the setup works ok but I can't access it in the main loop.

I have to recompile the code and comment out the LIN lin(&Serial3, 19200) and upload again to get the crash report.

Code: 
CrashReport:
  A problem occurred at (system time) 19:17:32
  Code was executing from address 0x620
  CFSR: 82
	(DACCVIOL) Data Access Violation
	(MMARVALID) Accessed Address: 0x10 (nullptr)
	  Check code at 0x620 - very likely a bug!
	  Run "addr2line -e mysketch.ino.elf 0x620" for filename & line number.
  Temperature inside the chip was 50.69 °C
  Startup CPU clock speed is 600MHz
 
skpang said:
Putting LIN lin(&Serial3, 19200); inside the setup works ok but I can't access it in the main loop.

I have to recompile the code and comment out the LIN lin(&Serial3, 19200) and upload again to get the crash report.

Code: 
CrashReport:
  A problem occurred at (system time) 19:17:32
  Code was executing from address 0x620
  CFSR: 82
	(DACCVIOL) Data Access Violation
	(MMARVALID) Accessed Address: 0x10 (nullptr)
	  Check code at 0x620 - very likely a bug!
	  Run "addr2line -e mysketch.ino.elf 0x620" for filename & line number.
  Temperature inside the chip was 50.69 °C
  Startup CPU clock speed is 600MHz
Click to expand...

I am pretty sure it is dying in the constructor processing.
That is the constructor mucks with the Serial port setup and always unclear how well that might work or not. When do things like the hardware Serial port get init versus order of when C++ constructors called.

I did a quick hack to the library, moved everything in the constructor to a begin() method, added a blank constructor...
The code is in a new fork/branch: https://github.com/KurtE/Teensy_3.x_4.x_and_LC_LIN_Master/tree/two_step_init

This now runs:
Code: 
#include "lin_bus.h"

LIN lin;

void setup() {
  lin.begin(&Serial3, 19200);
  if (CrashReport) {
    while (!Serial && millis() < 5000);
    Serial.print(CrashReport);
    pinMode(LED_BUILTIN, OUTPUT);
  }
}


void loop() {

  digitalWrite(LED_BUILTIN, HIGH);
  delay(200);

  digitalWrite(LED_BUILTIN, LOW);
  delay(200);
}
Let me know what you think. Not sure if you are the library owner or not. Could issue PR if desired.
 
I just replaced my library with your lin_bus.h and lin_bus.cpp files.

Changed to LIN lin and move the lin.begin into setup().

It works!! This is now working as it used to be. Strange v1.58 broke it.

Thank you KurtE for fixing this.

It is not my library.
 
I just installed TD 1.58 on Arduino 2.04 on an M1 Mac Mini running MacOS Ventura (13.3). My program compiled successfully, but I'm getting a lot of warnings concerning snprintf() in MTP_Teensy:

Code: 
/Users/markborgerson/Documents/Arduino/libraries/MTP_Teensy-main/src/MTP_Teensy.cpp:522:42: note: directive argument in the range [0, 255]
/Users/markborgerson/Documents/Arduino/libraries/MTP_Teensy-main/src/MTP_Teensy.cpp:522:13: note: 'snprintf' output between 16 and 21 bytes into a destination of size 16
  522 |     snprintf(ctimebuf, sizeof(ctimebuf), "%04u%02u%02uT%02u%02u%02u",
      |     ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  523 |              dtf.year + 1900, dtf.mon + 1, dtf.mday, dtf.hour, dtf.min,
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  524 |              dtf.sec);
      |              ~~~~~~~~

/Users/markborgerson/Documents/Arduino/libraries/MTP_Teensy-main/src/MTP_Teensy.cpp:530:60: warning: '%02u' directive output may be truncated writing between 2 and 3 bytes into a region of size between 2 and 5 [-Wformat-truncation=]
  530 |     snprintf(mtimebuf, sizeof(mtimebuf), "%04u%02u%02uT%02u%02u%02u",
      |                                                            ^~~~
/Users/markborgerson/Documents/Arduino/libraries/MTP_Teensy-main/src/MTP_Teensy.cpp:530:42: note: directive argument in the range [0, 255]
  530 |     snprintf(mtimebuf, sizeof(mtimebuf), "%04u%02u%02uT%02u%02u%02u",
      |                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~

I like to get my programs to the warning-free state, but I'm reluctant to start editing the MTP_Teensy library. I can't believe I'm the first to see these warnings. Are they discussed elsewhere?
 
mborgerson said:
I just installed TD 1.58 on Arduino 2.04 on an M1 Mac Mini running MacOS Ventura (13.3). My program compiled successfully, but I'm getting a lot of warnings concerning snprintf() in MTP_Teensy:

Code: 
/Users/markborgerson/Documents/Arduino/libraries/MTP_Teensy-main/src/MTP_Teensy.cpp:522:42: note: directive argument in the range [0, 255]
/Users/markborgerson/Documents/Arduino/libraries/MTP_Teensy-main/src/MTP_Teensy.cpp:522:13: note: 'snprintf' output between 16 and 21 bytes into a destination of size 16
  522 |     snprintf(ctimebuf, sizeof(ctimebuf), "%04u%02u%02uT%02u%02u%02u",
      |     ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  523 |              dtf.year + 1900, dtf.mon + 1, dtf.mday, dtf.hour, dtf.min,
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  524 |              dtf.sec);
      |              ~~~~~~~~

/Users/markborgerson/Documents/Arduino/libraries/MTP_Teensy-main/src/MTP_Teensy.cpp:530:60: warning: '%02u' directive output may be truncated writing between 2 and 3 bytes into a region of size between 2 and 5 [-Wformat-truncation=]
  530 |     snprintf(mtimebuf, sizeof(mtimebuf), "%04u%02u%02uT%02u%02u%02u",
      |                                                            ^~~~
/Users/markborgerson/Documents/Arduino/libraries/MTP_Teensy-main/src/MTP_Teensy.cpp:530:42: note: directive argument in the range [0, 255]
  530 |     snprintf(mtimebuf, sizeof(mtimebuf), "%04u%02u%02uT%02u%02u%02u",
      |                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~

I like to get my programs to the warning-free state, but I'm reluctant to start editing the MTP_Teensy library. I can't believe I'm the first to see these warnings. Are they discussed elsewhere?
Click to expand...

Ok you made me look. Not sure why its giving a warning but maybe has to do with the pragma's used
Code: 
  [COLOR="#FF0000"]#pragma GCC diagnostic push
  #pragma GCC diagnostic ignored "-Wformat-truncation" /* Or "-Wformat-truncation" */[/COLOR]
  if (storage_.getCreateTime(handle, dt)) {
    breakTime(dt, dtf);
    snprintf(ctimebuf, sizeof(ctimebuf), "%04u%02u%02uT%02u%02u%02u",
             dtf.year + 1900, dtf.mon + 1, dtf.mday, dtf.hour, dtf.min,
             dtf.sec);
  } else {
    ctimebuf[0] = 0;
  }
  if (storage_.getModifyTime(handle, dt)) {
    breakTime(dt, dtf);
    snprintf(mtimebuf, sizeof(mtimebuf), "%04u%02u%02uT%02u%02u%02u",
             dtf.year + 1900, dtf.mon + 1, dtf.mday, dtf.hour, dtf.min,
             dtf.sec);
  } else {
    mtimebuf[0] = 0;
  }
[COLOR="#FF0000"]#pragma GCC diagnostic pop[/COLOR]

Sorry not smart enough to sort it out. Have used this before though, not sure it would be applicable here
#pragma GCC diagnostic ignored "-Warray-bounds"
 
You must log in or register to reply here.
Back
Top