Forum Rule: Always post complete source code & details to reproduce any issue!
Page 4 of 4 FirstFirst ... 2 3 4
Results 76 to 84 of 84

Thread: Teensyduino 1.58 Beta #1 (updated toolchain trial)

  1. #76
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,818
    Quote Originally Posted by shawn View Post
    Curious, will there be a MacOS version of 1.58-beta2?
    If I package it up later today, then no. Building for MacOS is complicated, and especially a change like this is going to take some fiddling to adapt the way I do the signing and Apple notarization steps.

    But if I wait a week or so, probably.

    At this moment I'm looking at whether to include time.h. Runing the verify_all perl script now...

  2. #77
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,368
    Quote Originally Posted by KurtE View Post
    Sorry, I know that all of this is somewhat off topic, but I keep meaning to also try:

    ...
    Sorry, back to the normal interruptions.
    Beta 1 Thread near EOL so off topic keeps us interested and trying different ways to stay active
    posted ALT link in p#75 - looks like .rst got dropped?

    That solution seems to be non Windows specific which is COOL ... at least for 'those' people The TSET is cool cause I can hack and edit it.

  3. #78
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,818
    Some of the compile errors (not merely warnings) found by the perl script are related to time_t not defined. I'm debating what to do about it....

    Turns out some Arduino boards define time_t by default, but others don't. Some boards also define the time() function by including time.h by default.

    Code:
                    time_t  time()
    
    Teensy 2.0      no      no
    Arduino Uno     no      no
    Nano Every      no      no
    Teensy LC/3/4   yes     no
    Arduino Zero    yes     no
    ESP32           yes     yes
    ESP8266         yes     yes
    Arduino Due     yes     yes, but no _gettimeofday
    Nano RP2042     yes     yes
    RaspPi Pico     yes     yes
    Portenta H7     yes     yes
    Nano 33 BLE     yes     yes
    I'm leaning towards including time.h, since many of the other 32 bit boards are including it. But this change will break certain programs where people have named a global scope variable "time", like this Snooze library example.

    The alternative is to find a way to define only time_t with the new toolchain.

    Here are the 2 test programs.

    Code:
    // Does Arduino.h define time_t
    
    time_t count = 0;
    
    void setup() {
      Serial.begin(9600);
    }
    
    void loop() {
      Serial.println(count++);
      delay(250);
    }
    Code:
    // Does Arduino.h define time(void *)
    
    void setup() {
      Serial.begin(9600);
    }
    
    void loop() {
      Serial.println(time(NULL));
      delay(250);
    }

  4. #79
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,818
    I committed include of time.h, at least for testing with 1.58-beta2.

    https://github.com/PaulStoffregen/co...c4b784adb33984

    If this causes too many programs to break or other problems, it may get removed and replaced with some way to define only time_t as the old toolchain did.

  5. #80
    Senior Member
    Join Date
    Aug 2018
    Location
    Brisbane, Australia
    Posts
    129
    Also be aware that the size of time_t has been changed from int32_t to int64_t in recent gcc releases to cater for the "Year 2038 Problem"

  6. #81
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,818
    Yup, looks like time_t is 64 bits with the new toolchain.

    Code:
    void setup() {
      Serial.begin(9600);
      Serial.print("sizeof(time_t) = ");
      Serial.println(sizeof(time_t));
    }
    
    void loop() {
    }
    So far I haven't seen it cause any problems, but this is certainly a difference to keep in mind.

  7. #82
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,818
    Quote Originally Posted by KurtE View Post
    SO suppose I add this to MTP_teensy.h
    Code:
    #if defined(__has_include) && __has_include(<SD.h>)
    #include <SD.h>
    #endif
    .....as such Arduino does not include the SD library into the search path... ... I earlier raised with Arduino. They informed me that it is a GCC issue...
    I wouldn't call this a gcc issue. It's a consequence of the way Arduino automatically discovers which libraries are used. The library search path list is created on-the-fly based on which files have been included.

    You probably want __has_include to resolve whether SD.h could be included, from the set of all possible libraries Arduino might use. But with the way Arduino runs gcc, it only tells if you whether SD.h could be included from any of the (small) set of libraries it has found are needed based on includes in all files. You can't expect gcc to know about any other locations it wasn't giving when Arduino ran it.

    But this is probably a lot of focusing on trees rather than the forest. I'm pretty sure the real problem is we don't yet have enough functionality in FS.h. Adding this is high on my priority list for 1.58.

  8. #83
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,818
    Quote Originally Posted by KurtE View Post
    Paul (or others) have you looked at the addr2line issue:
    Sadly, no, not yet. Have been going through compile errors.

  9. #84
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    10,976
    Again, I know that this is somewhat off topic, but was curious if the behavior changed with this toolchain

    Quote Originally Posted by PaulStoffregen View Post
    I wouldn't call this a gcc issue. It's a consequence of the way Arduino automatically discovers which libraries are used. The library search path list is created on-the-fly based on which files have been included.

    You probably want __has_include to resolve whether SD.h could be included, from the set of all possible libraries Arduino might use. But with the way Arduino runs gcc, it only tells if you whether SD.h could be included from any of the (small) set of libraries it has found are needed based on includes in all files. You can't expect gcc to know about any other locations it wasn't giving when Arduino ran it.

    But this is probably a lot of focusing on trees rather than the forest. I'm pretty sure the real problem is we don't yet have enough functionality in FS.h. Adding this is high on my priority list for 1.58.
    Note this issue is not just related to the SD files and the like issues.

    But more generic. I ran into this with several different usage patterns. Like, use JPGDEC library if installed, or use my Hex Dump library if installed.

    More information about it up on the Arduino Issue I created a while ago that has been closed.
    https://github.com/arduino/arduino-cli/issues/1782
    which they pointed to the open issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80753

    But as you said, in this specific case, there are probably better solutions, that allows code that is called with a FS pointer or File pointer to be able to understand more about the object passed in. Sort of like when I am running a program on an RPI, that is passed in an object to Serially input or output to, I may need/want to know what type of object it is. For example, to minimize latency, I may want to know that it is an
    FTDI object, in which case I want to call the TCDRAIN function. But if it is not an FTDI object TCDRAIN can be very detrimental.

    Now back to playing.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •