Teensyduino 1.59 Beta #2

[PaulStoffregen]

Pretty sure it's an issue in teensy_serialmon.exe for 1.8.19 and also in teensy_monitor.exe for IDE 2, and (probably) also the same thing in TyCommander. Will look into it today (teensy_serialmon and teensy_monitor that is...)

[KurtE]

Pretty sure it's an issue in teensy_serialmon.exe for 1.8.19 and also in teensy_monitor.exe for IDE 2, and (probably) also the same thing in TyCommander. Will look into it today (teensy_serialmon and teensy_monitor that is...)

TyCommander apppears to work. I just ran the simple sketch:

void setup() {
  while(!Serial);
}
void loop() {
  delay(1000);
  Serial.println(Serial.baud(), DEC);
}

And it was printing 115200, I then went to the options page and change to 23400 and the output changed:

...
115200
115200
115200
230400
230400
230400
...

[tonton81]

that is a cool trick, but extra latency you wouldn't physically notice in the loop() 🙂

[KurtE]

that is a cool trick, but extra latency you wouldn't physically notice in the loop() ��

In majority of sketches yes the Serial.baud() does not matter. As it does nothing to the USB transfer stuff.
However in a small set of sketches, like the example Teensy->USB Serial -> USBtoSerial
or the case that I doing now like it for USBtoUSBHostSerial


Which here is a stripped down version of it, minus most comments and options and the like:
Not sure if it will build - the actual sketch part of a PR...

#include <USBHost_t36.h>
#define USBBAUD 1000000 //115200
uint32_t baud = USBBAUD;
uint32_t format = USBHOST_SERIAL_8N1;
USBHost myusb;

USBSerial userial(myusb);  // works only for those Serial devices who transfer <=64 bytes (like T3.x, FTDI...)
char buffer[512];
uint32_t led_on_time=0;

void setup() {
  myusb.begin();
  userial.begin(USBBAUD); 
  Serial.begin(USBBAUD);

  pinMode(LED_BUILTIN, OUTPUT);

}

//=============================================================================
// loop: continuously called.
//=============================================================================
void loop() {
  myusb.Task(); 

  uint16_t rd, wr, n;

  // check if any data has arrived on the USB virtual serial port
  rd = Serial.available();
  if (rd > 0) {
    // check if the USB Host serial port is ready to transmit
    wr = userial.availableForWrite();
    if (wr > 0) {
      // compute how much data to move, the smallest
      // of rd, wr and the buffer size
      if (rd > wr) rd = wr;
      if (rd > sizeof(buffer)) rd = sizeof(buffer);
      // read data from the USB port
      n = Serial.readBytes((char *)buffer, rd);
      // write it to the USB Host serial port
//      DBGPrintf("S-U(%u %u)\n", rd, n);
      userial.write(buffer, n);
      // turn on the LED to indicate activity
      digitalWrite(LED_BUILTIN, HIGH);
      led_on_time = millis();
    }
  }

  // check if any data has arrived on the USBHost serial port
  rd = userial.available();
  if (rd > 0) {
    // check if the USB virtual serial port is ready to transmit
    wr = Serial.availableForWrite();
    if (wr > 0) {
      // compute how much data to move, the smallest
      // of rd, wr and the buffer size
      if (rd > wr) rd = wr;
      if (rd > 80) rd = 80;
      // read data from the USB host serial port
      n = userial.readBytes((char *)buffer, rd);
      // write it to the USB port
 //     DBGPrintf("U-S(%u %u):", rd, n);
      Serial.write(buffer, n);
      // turn on the LED to indicate activity
      digitalWrite(LED_BUILTIN, HIGH);
      led_on_time = millis();
    }
  }

  // if the LED has been left on without more activity, turn it off
  if (led_on_time && (millis() - led_on_time > 3)) {
    digitalWrite(LED_BUILTIN, LOW);
    led_on_time = 0; 
  }

  // check if the USB virtual serial wants a new baud rate
  // ignore if 0 as current Serial monitor of Arduino sets to 0..
  uint32_t cur_usb_baud = Serial.baud();
  if (cur_usb_baud && (cur_usb_baud != baud)) {
    baud = cur_usb_baud;
    DBGPrintf("DEBUG: baud change: %u\n", baud);
    if (baud == 57600) {
      // This ugly hack is necessary for talking
      // to the arduino bootloader, which actually
      // communicates at 58824 baud (+2.1% error).
      // Teensyduino will configure the UART for
      // the closest baud rate, which is 57143
      // baud (-0.8% error).  Serial communication
      // can tolerate about 2.5% error, so the
      // combined error is too large.  Simply
      // setting the baud rate to the same as
      // arduino's actual baud rate works.
      userial.begin(58824);
    } else {
      userial.begin(baud);
    }
  }

}

Before I changed the line if (cur_usb_baud != baud) {
to: if (cur_usb_baud && (cur_usb_baud != baud)) {

It was telling the USB to Serial adapter that I had plugged in to set it's baud rate to 0... Not sure how slow it was able to set it. But you could visually see one character at a time being returned by the adapter...

P.S. - This is similar if not the same as the sketch we played with where you could have one Teensy program another Teensy (or other board).

[mjs513]

Just ran across something interesting with the new toolchain and and updating to c17

Found that cout now works (no cin does not) and the c++ function setprecission works. Came across this when I was looking at @brtaylor's update EKF 15 state model and was wondering if it worked so tried a test case from the web:

#include <iomanip>
#include <iostream>

using namespace std;

void setup() {
  while (!Serial && millis() < 5000) ; //wait up to 5 seconds

#ifdef __IMXRT1062__
  if (CrashReport) {
    Serial.print(CrashReport);
  }
#endif

    double num1 = 3.12345678;
    cout <<"Test of cout and setprecission" << endl;
    cout << fixed << showpoint;
    cout << setprecision(12);
    cout << num1 << endl;
    cout << setprecision(2);
    cout << num1 << endl;
}

void loop() {
  // put your main code here, to run repeatedly:

}

which prints:

Test of cout and setprecission
3.123456780000
3.12

Fun stuff

[luni]

Yes, but did you look at the memory consumption? Last time I tried it was some 300kB :-(

[mjs513]

Yes, but did you look at the memory consumption? Last time I tried it was some 300kB :-(

Well you made me look and sure enough the sketch as written uses 309k. Looks like most of that is coming from using IOSTREAM. If I change the sketch to:

#include <iomanip>
//#include <iostream>

using namespace std;

void setup() {
  while (!Serial && millis() < 5000) ; //wait up to 5 seconds

#ifdef __IMXRT1062__
  if (CrashReport) {
    Serial.print(CrashReport);
  }
#endif

    double num1 = 3.12345678;
    //cout <<"Test of cout and setprecission" << endl;
    //cout << fixed << showpoint;
    //cout << setprecision(12);
    //cout << num1 << endl;
    setprecision(2);
    Serial.println( num1 );
}

void loop() {
  // put your main code here, to run repeatedly:

}

its goes down to about 12K

Memory Usage on Teensy MicroMod:
  FLASH: code:11748, data:5068, headers:8780   free for files:16489476
   RAM1: variables:5504, code:7952, padding:24816   free for local variables:486016
   RAM2: variables:12416  free for malloc/new:511872

Also did a check that if you include the Streaming library to get the use of cout it stays at about 12k:

Memory Usage on Teensy MicroMod:
   RAM1: variables:5504, code:7968, padding:24800   free for local variables:486016
   RAM2: variables:12416  free for malloc/new:511872

So probably not a good idea to use iostream but was interesting to see that it works.

[ted]

I would have the following problem. I'm using PlatformIO and teensy 4.1 lockable and tried LTO. Both with 1.58 and 1.59 (I changed the teensy library to a new version, so I can test it).

There are two options:
TEENSY_OPT_SMALLEST_CODE
CCFLAGS=["-Os", "--specs=nano.specs"],
LINKFLAGS=["-Os", "--specs=nano.specs"]
TEENSY_OPT_SMALLEST_CODE_LTO
CCFLAGS=["-Os", "--specs=nano.specs", "-flto", "-fno-fat-lto-objects"],
LINKFLAGS=["-Os", "--specs=nano.specs", "-flto", "-fno-fat-lto-objects", "-fuse-linker-plugin"]

when I complied it with TEENSY_OPT_SMALLEST_CODE under 1.58, the code did not start. This is fine, I think, the 1.59 was made to fix this problem, because under 1.59 it works fine, it starts.

However, with TEENSY_OPT_SMALLEST_CODE_LTO, starts with 1.58 and 1.59.
However, once I upload the code, I cannot update it again via serial. Teensy reboots and that's it. Serial says, press the flasher button (it also throws errors when looking at the flash program log).
When I press it, it works. Upload the new code to it.



Could this be some kind of abnormal behavior? Could I ask for help with this? I saw that there were bugs related to the LTO code, and I found in another forum topic that it should be reported here if there is anything like that. I know, PlatformIO, not Arduino IDE, but that's why I looked up the compilation options. Maybe someone can help me with my question.

Thanks!

[defragster]

...
However, with TEENSY_OPT_SMALLEST_CODE_LTO, starts with 1.58 and 1.59.
However, once I upload the code, I cannot update it again via serial. Teensy reboots and that's it. Serial says, press the flasher button (it also throws errors when looking at the flash program log).
When I press it, it works. Upload the new code to it.
...

Not clear if the issue is 1.58 or 1.59 as noted?

IDE 2 does not show LTO as an option for 1.58 so it was not corrected and incorporated. PIO may trigger it as an option - but not valid.

If this is just PIO and 1.59 beta it may be an issue - or not given "changed the teensy library to a new version, so I can test it" - the changes may not be 100%?

Here IDE 1.8.19 has TD 1.59 b2 and just built Coremark 'smallest w/LTO' and it uploads and runs and the computer can AUTO upload code for another sketch.

[ted]

Not clear if the issue is 1.58 or 1.59 as noted?

IDE 2 does not show LTO as an option for 1.58 so it was not corrected and incorporated. PIO may trigger it as an option - but not valid.

If this is just PIO and 1.59 beta it may be an issue - or not given "changed the teensy library to a new version, so I can test it" - the changes may not be 100%?

Here IDE 1.8.19 has TD 1.59 b2 and just built Coremark 'smallest w/LTO' and it uploads and runs and the computer can AUTO upload code for another sketch.

Thank you very much for the information. Now, just to be sure, I downloaded the TeensyDuino 1.59 beta2 code installer for Arduino IDE 1.8.x. I installed it.
I set the "Smalles Code with LTO" option. I chose a simple blink code from the example library.
I uploaded it after compile. That worked. After that, I change the delay from 1000ms to 100ms to see if the update was working or not.
After pressing upload, Teensy started again and I got a timeout while uploading.

Got this error:
Teensy did not respond to a USB-based request to enter program mode.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.

Please note thtat there was no problem with platformio, not with the normal case.
I have a problem when I try Lockable verision. Or Teensy is locked with the key. I admit, it could have been a problem if I copied/updated something wrong under PlatformIO. That's why I made it, a simpler, reproducible code, and tried with Arduino as well.

I attached some photos.

Should I attach anything else to this information? Please let me know and I'll try to help to better show the problem/error I'm experiencing.

Regards,