Please remind me of open bugs, hopefully with fixes (but not feature requests)

PaulStoffregen said:
I'm running the script which checks all library examples for compile errors. It's finding several in MTP_Teensy. :(

LFS_Program_MTP_Simple_Datalogger
LFS_SPI_MTP_Simple_Datalogger
SD_Program_MTP-logger
SD_SPI_QSPI_MTP-logger
simple
simple_t4_audio_sd
Click to expand...
Found the issue, fix is actually described in: https://forum.pjrc.com/index.php?th...r-ino-compile-error-on-t4-1.73565/post-331920 and https://forum.pjrc.com/index.php?th...r-ino-compile-error-on-t4-1.73565/post-331921

now to update the examples.
 
The script is also finding a different error with MTP_Teensy example CircuitMicroPython.ino.

Maybe it was written before the USB host library had the HID classes?
 
PaulStoffregen said:
I'm running the script which checks all library examples for compile errors. It's finding several in MTP_Teensy. :(

LFS_Program_MTP_Simple_Datalogger
LFS_SPI_MTP_Simple_Datalogger
SD_Program_MTP-logger
SD_SPI_QSPI_MTP-logger
simple
simple_t4_audio_sd
Click to expand...
We should update some/all of these at some point and maybe remove some of the others.

But maybe not critical at this point as per your first post.

PaulStoffregen said:
I'm fixing issues and merging fixes in prep for 1.60-beta1.

Will merge new features for 1.60-beta2... but before merging new stuff I want to start 1.60 with a first beta focusing on fixes only (or mostly).
Click to expand...

Unless of course you are planning to add the MTP library to the install for Beta 1...
 
PaulStoffregen said:
The script is also finding a different error with MTP_Teensy example CircuitMicroPython.ino.

Maybe it was written before the USB host library had the HID classes?
Click to expand...
Fixed - was before when KBD was a top-level device and not supported as a HID device.
 
KurtE said:
Unless of course you are planning to add the MTP library to the install for Beta 1...
Click to expand...

Not for beta1.

Right now just running the script to look for compile errors, because all too often some subtle change in the core library has broken other stuff.

When any library the script builds has examples with errors, they generate a lot of "noisy" output which obscures the, well, obscure problems.

On MTP_Teensy, the mtp_tft_picture_view.ino example's comments list 3 other libraries it needs. Maybe more are needed, for FT5206.h and RA8876_t3.h ?
 
PaulStoffregen said:
On MTP_Teensy, the mtp_tft_picture_view.ino example's comments list 3 other libraries it needs. Maybe more are needed, for FT5206.h and RA8876_t3.h ?
Click to expand...

This sketch is setup, to allow you display images on a display, and is setup to use MTP, such that you can for example install new image files
to be displayed or removed from the storage using MTP.

It was setup and at one point tested on many different display drivers that several of us work on, including:
ones installed by Teensyduino: ILI9341_t3, ST7735_t3.h (7789 as well), ILI9488_t3 RA8875
As well as several others, that are not part of Teensydino, that some of us play with:
ILI9341_t3n, RA8876_t3.h

The current checked in version was setup for RA8876 as I believe some of us were checking out the
update version of @wwatson library, which is setup now 3 libraries (a GFX, SPI, 8080),

Yes the comments mention a few optional libraries, that allow us to display Jpegs as well as PNG files

Note: Some of the mentioned display libraries actually have their own version of this example, which only has that displays
code in it. And this library has a simplified version which only supports the limited library ili9341_t3.

I updated this sketch to not define the usage of RA8876 so it now will default back to ILI9341_t3 as well.
 
BriComp said:
The UnixTime reported by ut = now() gives a UnixTime which is different to the UnixTime calculated by various Web Sites. I am not necessarily saying you are wrong, but someone is.
The sites I have looked at on the web are here and here.
The code I use to demonstrate the problem is as follows:
Code: 
#include <timeLib.h>

void setup() {
    //https://www.unixtimestamp.com/
    //https://www.nexcess.net/web-tools/unix-timestamp-converter/
    tmElements_t t;
    time_t ut;
    uint8_t h, m, s, d, mo;
    int  y;
    h = 11;
    m = 57;
    s = 5;
    d = 9;
    mo = 9;
    y = 2024;

    Serial.begin(9600);
    while (!Serial and millis() < 5000);

    setTime(h,m,s,d,mo,y);
    ut = now();
    Serial.print("UnixTime from Internet Sites: "); Serial.println(1725879425);
    Serial.print("UnixTime from Teensy = now(): "); Serial.println(ut);
    Serial.print("Difference:                   ");  Serial.println(1725879425 - ut);

    breakTime(ut,t);// 1725448362 + 3600, t);  // break time_t into elements

    Serial.print(t.Hour); Serial.print(":");
    Serial.print(t.Minute); Serial.print(":");
    Serial.print(t.Second); Serial.print("   ");
    Serial.print(t.Wday); Serial.print(" ");
    Serial.print(t.Day); Serial.print("/");
    Serial.print(t.Month); Serial.print("/");
    Serial.println(t.Year - 30);
};

void loop() {
    delay(10);
};
Click to expand...
I'm not seeing a problem in the Time library with this, rather the hardcoded unix timestamp in the sketch (1725879425) is one hour behind the specified timestamp of 11:57:05 9-9-2024. This is confirmed by www.unixtimestamp.com .
 
The website is translating that time from your local (browser) timezone to GMT, then to the unix timestamp.
Try using the website to convert from that timestamp and look at the GMT time it returns.
 
In case anyone's wondering about 1.60-beta1, I lost a couple days because an update broke my Yubikey-based code signing for Windows. Things used to be so much simpler when it was just files and I could build inside a virtual machine. Just now got it working again on another PC... which I'm going to leave as-is, no more updates!

Going to look into Time library later. Might be a bug, or might just be daylight savings time offset.
 
You must log in or register to reply here.
Back
Top