Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 9 FirstFirst 1 2 3 4 ... LastLast
Results 26 to 50 of 207

Thread: Teensyduino 1.54 Beta #5

  1. #26
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    8,229
    ... i'd remove the adding from platform.txt, and do the adds for all models "Teensy 4- like" in the linkerfiles.
    Otherwise it will be difficult to get that right for all models.
    Code:
    recipe.size.pattern="{compiler.path}{build.toolchain}{build.command.size}" -A "{build.path}/{build.project_name}.elf"
    recipe.size.regex=^(?:\.text|\.text\.progmem|\.text\.itcm|\.data)\s+([0-9]+).*
    recipe.size.regex.data=^(?:\.usbdescriptortable|\.dmabuffers|\.usbbuffers|\.data|\.bss|\.noinit|\.text\.itcm|\.text\.itcm\.padding)\s+([0-9]+).*
    recipe.size.regex.eeprom=^(?:\.eeprom)\s+([0-9]+).*
    I.e. for Teensy 4, for flash-size it would just be _flashimagelen (which is "internally" correct, but is not displayed?!?)
    Similar for RAM.
    Or, best, don't use the size-tool. It is not useful for Teensy 4, anyway.

    Edit: For ESP 8266, it looks like this:
    Code:
    Executable segment sizes:
    IROM   : 228656          - code in flash         (default or ICACHE_FLASH_ATTR) 
    IRAM   : 26756   / 32768 - code in IRAM          (ICACHE_RAM_ATTR, ISRs...) 
    DATA   : 1252  )         - initialized variables (global, static) in RAM/HEAP 
    RODATA : 688   ) / 81920 - constants             (global, static) in RAM/HEAP 
    BSS    : 24880 )         - zeroed variables      (global, static) in RAM/HEAP
    Last edited by Frank B; 11-29-2020 at 08:41 PM.

  2. #27
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    8,229
    @Paul, please edit platform.text and use this:
    recipe.size.regex=^(?:\.text|\.text\.progmem|\.tex t\.itcm|\.data|\.text\.csf)\s+([0-9]+).*
    This fixes the used flash (almost, 4 Bytes are still missing) (...whatever csf is...) for T4.x, at least (T3 still wrong)
    Last edited by Frank B; 11-29-2020 at 09:21 PM.

  3. #28
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,977
    Quote Originally Posted by Frank B View Post
    @Paul, please edit platform.text and use this:
    recipe.size.regex=^(?:\.text|\.text\.progmem|\.tex t\.itcm|\.data|\.text.csf)\s+([0-9]+).*
    Ok, added. It'll be in 1.54-beta6.


    ...whatever csf is...
    CSF is a digital signature format defined by NXP which can be appended to your program. Currently Teensy is configured to ignore it, and that configuration is locked so you can't make any Teensy actually enforce the signature. Well, except for 5 special boards I created a while back which have that setting unlocked.

    The way CSF is supposed to work involves burning a SHA256 hash of your public key into the fuse memory. While NXP's "high assurance boot" is complicated, the essential idea is the contents of flash memory are checked against the CSF signature, and the CSF signature compared against the SHA256 hash. If you've turned on the security requirement (which can't be turned on for any Teensy, except those 5 test boards), the chip won't run your program unless both of those checks match. In other words, once you write that SHA256 hash and set the secure mode, the chip can only run code you have signed. Nobody else can create programs to run on a chip with the security set (and you can't either if you lose your private key). Setting the security is a permanent, utterly irreversible one-time operation. Once locked, there is no erase and no way to alter the private key hash.

    The CSF data is meant to be appended after the compiler has produced the final binary output. Typical size for CSF (at least the relatively simple way that makes sense for Teensy) is about 3K to 4K.

  4. #29
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    8,229
    That sounds like a very nice feature, for the future!

    If missed a "\" backslash before ".csf" and inserterted it with a later edit. Don't know wether it is important - at least with windows it works without.

  5. #30
    Junior Member
    Join Date
    Jul 2019
    Posts
    9
    The latest big sur 11.1 update doesn't load the teensyloader, it's also still crashing when opening arduino, but works on reload..it was doing this before but now as i said won't lode the loader?

  6. #31
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,977
    Quote Originally Posted by daj59 View Post
    The latest big sur 11.1 update doesn't load the teensyloader
    Which Mac are you using? It is an Intel model or the new ARM M1?

  7. #32
    Junior Member
    Join Date
    Jul 2019
    Posts
    9
    Quote Originally Posted by PaulStoffregen View Post
    Which Mac are you using? It is an Intel model or the new ARM M1?
    Intel macbook pro 2018

  8. #33
    Deleted User
    Guest
    What is that? Always that Apple Extra! Catalina solved, Big Sur on. Would it be rude to drop Mac support altogether to keep the development going? There need to be many and strong signals towards Cupertino!

    ed: btw, i've recycled my Mac, because it was getting on my nerves with Catalina already.

  9. #34
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,600
    I strongly oppose against dropping Mac support. It looks like the new Apple Silicon based hardware will rather boost their market share:
    https://appleinsider.com/articles/20...ktop-pc-market

    Seen how the "little" M1 outperforms already most Intel CPUs, I'd rather consider dropping the Wintel platform...

  10. #35
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,772
    Quote Originally Posted by Theremingenieur View Post
    .........

    Seen how the "little" M1 outperforms already most Intel CPUs, I'd rather consider dropping the Wintel platform...
    Funny person

  11. #36
    Deleted User
    Guest
    Apple users can still use one of the existent Windows or Linux VM solutions.
    You can not burden a similar requirement onto people using a functional OS!
    This completely arrogant Apple-tude needs to be grounded once, and hopefully forever.

    At the End it is good, Apple reverts to console chips, showing their true colours.

    There is no reason why a hold on Mac support has to be eternal. Once the Costermongers change their strategy from sucking and bullying users to making a working functional system, Mac support might be considered again.
    Last edited by Deleted User; 12-01-2020 at 02:04 PM. Reason: typos

  12. #37
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    8,229
    platform.txt:

    Is it possible to specify the teensy-mode for this line?
    recipe.size.regex.data=

    For T4, it would be just
    recipe.size.regex.data=^(?:\.data|\.bss)\s+([0-9]+).*
    Last edited by Frank B; 12-01-2020 at 07:27 PM.

  13. #38
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    8,229
    ..if you add something like

    teensy40.build.flags.size=^(?:\.data|\.bss)\s+([0-9]+).*
    to boards.txt and use it as {build.flags.size} in platform.txt it ends corrupted
    as "^(?:\\.data|\\.bss)\\s+([0-9]+).*"

    Is there a flag that can prevent this? Or a kind of escape-character?

  14. #39
    Thanks for your constant work on improving the working environment for teensy boards. Great effort.

    I am getting familiar with the ILI9488_t3 library and the settings to SdFat. Today I was reviewing the JPEGDEC library; To migrate the old projects to the new screen, I was compiling some examples that worked well in the IDE 1.8.13 with the Teensy Loader 1.54-beta3.

    Now with the Teensy Loader 1.54-beta5 only errors jump like rabbits!

    Code:
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\SD\src/SD.h:159:49: error: 'FILE_READ' was not declared in this scope
      File open(const char *filepath, uint8_t mode = FILE_READ) {
                                                     ^
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\SD\src/SD.h: In member function 'virtual File SDClass::open(const char*, uint8_t)':
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\SD\src/SD.h:161:15: error: 'FILE_WRITE' was not declared in this scope
       if (mode == FILE_WRITE) flags = O_RDWR | O_CREAT | O_AT_END;
                   ^
    JPG_decoder: In function 'void* myOpen(const char*, int32_t*)':
    JPG_decoder:5: error: call to 'virtual File SDClass::open(const char*, uint8_t)' uses the default argument for parameter 2, which is not yet defined
       myfile = SD.open(filename);
                                ^
    SliderJPG: In function 'void loop1()':
    SliderJPG:5: error: call to 'virtual File SDClass::open(const char*, uint8_t)' uses the default argument for parameter 2, which is not yet defined
       File dir = SD.open("/");
    Is the JPEGDEC library still compatible with the settings made to SdFat (formerly SdFat beta)? .

  15. #40
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,600
    Quote Originally Posted by daj59 View Post
    The latest big sur 11.1 update doesn't load the teensyloader, it's also still crashing when opening arduino, but works on reload..it was doing this before but now as i said won't lode the loader?
    Can't confirm. Had Teensyduino crashing once on opening, but that problem disappeared after a reboot. Now opens consistently and launches the teensy loader as expected :
    Click image for larger version. 

Name:	screenshot.jpg 
Views:	30 
Size:	166.1 KB 
ID:	22713

    Edit: Teensy loader can also be launched without problems from PlatformIO, still in Big Sur 11.1 beta :
    Click image for larger version. 

Name:	screenshot2.png 
Views:	29 
Size:	431.9 KB 
ID:	22714
    Last edited by Theremingenieur; 12-02-2020 at 09:42 AM. Reason: More details

  16. #41
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,977
    Quote Originally Posted by TFTLCDCyg View Post
    Now with the Teensy Loader 1.54-beta5 only errors jump like rabbits!
    I was able to reproduce this problem. It's a bug in the new SD.h, where it's a bit too aggressive about undefining the incompatible FILE_READ and FILE_WRITE from SdFat.h. When headers are included in an unexpected order, as the JPEGDEC example does, SD.h was undefining the correct values, and then FS.h was not redefining them because it had already been included. That causes code elsewhere in SD.h to not compile because we undefined them, expecting FS.h to define them properly.

    I've committed a fix on github.

    https://github.com/PaulStoffregen/SD...40572d10ff368b

  17. #42
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,977
    I'm absolutely not going to drop Macintosh support. Anyone who's worried by the talk on this thread can consider can this message to be official word from PJRC. Mac support will continue. No need to worry - stand down from Red Alert.

    But seriously, I'm usually only able to fix problems I can reproduce one 1 of my 5 Macs (an old 11 inch Macbook Air, a 13 inch Macbook Air, a "trashcan" Mac Pro, and a really slow Mac Mini, and a very old 17 inch Macbook Pro). Currently those 5 machines have 10.7, 10.12, 10.13, 10.14 and 10.15 installed. I'm currently running a Time Machine backup on the 13 inch Macbook Air, which is the one with 10.15 Catalina installed. It's also the newest of my machines, from 2015. Later today I'll update it to Big Sur. This means I won't be able to test Catalina, unless I update one of the other machines or find a way to revert this machine.

    FWIW, even though I haven't bought a Mac for 5 years, I do have 5 of them sitting around. I'm planning to get a 6th Mac with the new M1 chip, but hoping to wait until Apple releases a faster version with more RAM.

    I'm guessing my Big Sur experience will be similar to what Theremingenieur showed, partly because Big Sur has been out for a while and this is only the first report of it not working. If it does work when I test, of course I'll give you a screenshot, and you can take that to mean I probably won't be able to resolve the problem unless you give my a *lot* of info that's often hard to find with Macs (and even then, odds are slim I'll figure it out from only tech info). If I can reproduce the problem, of course I'll work on a fix!

  18. #43
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,977
    On the Big Sur issue, please check the System Preferences > Security & Privacy settings. First look at "Files and Folders" to check whether you've (perhaps unintentionally) disallowed the software to access files it needs.

    This is a known issue on Catalina, where disallowing access to Documents causes the software to be unable to start up.

    https://www.pjrc.com/teensy/td_downl...cuments_folder

    Maybe also look through the many other types of access on the left side column and check whether Teensyduino or Arduino or Teensy Loader are listed in any of them. Apple may have added more types of privacy restrictions in Big Sur, where disallowing access has (so far) unknown effects on the software. We do know 100% for sure that disallowing Documents causes Teensyduino to quit before it can fully start up, so these sorts of privacy restrictions can be a real problem if something the software needs is restricted.

  19. #44
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    8,229
    Paul i'm not sure if I use the newest version of the Serial Monitor.
    I'm using Windows. The problem with empty lines is gone. Good!

    BUT:


    With STRG+A, STRG+C it copies only a small part of the text in the monitor.
    In my current example, 19 lines only . But there are many more.

  20. #45
    THX Paul.

    I put these lines at the beginning of the SD.h file:

    Code:
    // Use FILE_READ & FILE_WRITE as defined by FS.h
    //#ifdef FILE_READ
    #if defined(FILE_READ) && !defined(FS_H)
    #undef FILE_READ
    #endif
    //#ifdef FILE_WRITE
    #if defined(FILE_WRITE) && !defined(FS_H)
    #undef FILE_WRITE
    #endif
    #include <FS.h>
    Now both libraries: SD and JPEGDEC can coexist without problems.


    Teensy 4 + ILI9488 3.5" + SD + JPEGDEC

    Thanks for the prompt response.

  21. #46
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,600
    Quote Originally Posted by PaulStoffregen View Post
    I'm absolutely not going to drop Macintosh support. Anyone who's worried by the talk on this thread can consider can this message to be official word from PJRC. Mac support will continue. No need to worry - stand down from Red Alert.
    Thank you! It's not because just I am a Mac user, but as I wrote above, odds are good that parts of the PC market will be overtaken by M1 based hardware in 2021/22.

    Quote Originally Posted by PaulStoffregen View Post
    But seriously, I'm usually only able to fix problems I can reproduce one 1 of my 5 Macs (an old 11 inch Macbook Air, a 13 inch Macbook Air, a "trashcan" Mac Pro, and a really slow Mac Mini, and a very old 17 inch Macbook Pro). Currently those 5 machines have 10.7, 10.12, 10.13, 10.14 and 10.15 installed. I'm currently running a Time Machine backup on the 13 inch Macbook Air, which is the one with 10.15 Catalina installed. It's also the newest of my machines, from 2015. Later today I'll update it to Big Sur. This means I won't be able to test Catalina, unless I update one of the other machines or find a way to revert this machine.
    From my experience, at least on Intel based Macs, you can at 99.99% be sure that if something runs in Big Sur, it will also run in the latest Catalina. I'm running the latest Catalina on a 2012 Mac mini (it can't be updated further) and always the newest beta on my MacBook Pro. There are things which (temporarily, until fixed by the devs) don't run in Big Sur, but everything I use (including some weird USB over network redirection stuff) works well in Catalina. Never had the case that something which ran in Big Sur wouldn't run in Catalina.

  22. #47
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,871
    Quick wondering... Usually I try to remove all warning from my programs and libraries...

    But now when using the SD library I keep getting warning messages about including Time.h that should be replaced by TimeLib.h...

    Problem is, the include of Time.h is in run time of the compiler...
    Code:
    "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_CSI_41_OV7670_ILI.ino\\sketch\\CSI_41_OV7670_ILI.ino.cpp.o"
    In file included from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\sys\stat.h:9:0,
                     from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\sys\_default_fcntl.h:188,
                     from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\sys\fcntl.h:4,
                     from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\fcntl.h:1,
                     from c:\arduino-1.8.13\hardware\teensy\avr\libraries\sdfat\src\common\fsapiconstants.h:30,
                     from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/ExFatLib/ExFatFile.h:36,
                     from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/ExFatLib/ExFatVolume.h:28,
                     from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/ExFatLib/ExFatLib.h:27,
                     from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/SdFat.h:33,
                     from C:\Users\kurte\Documents\Arduino\libraries\SD\src/SD.h:27,
                     from C:\Users\kurte\Documents\Arduino\Teensy Tests\CSI_41_OV7670_ILI\CSI_41_OV7670_ILI.ino:24:
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\Time/time.h:1:2: warning: #warning "Please include TimeLib.h, not Time.h.  Future versions will remove Time.h" [-Wcpp]
    And in programs that for example include SD.h in several source files, this gets repeated over and over again.

    Wonder best way to suppress this? Change from #warning to #message or some such thing?

  23. #48
    Senior Member
    Join Date
    Jul 2014
    Posts
    3,120
    Quote Originally Posted by KurtE View Post
    Quick wondering... Usually I try to remove all warning from my programs and libraries...

    But now when using the SD library I keep getting warning messages about including Time.h that should be replaced by TimeLib.h...

    Problem is, the include of Time.h is in run time of the compiler...
    Code:
    "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_CSI_41_OV7670_ILI.ino\\sketch\\CSI_41_OV7670_ILI.ino.cpp.o"
    In file included from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\sys\stat.h:9:0,
                     from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\sys\_default_fcntl.h:188,
                     from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\sys\fcntl.h:4,
                     from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\fcntl.h:1,
                     from c:\arduino-1.8.13\hardware\teensy\avr\libraries\sdfat\src\common\fsapiconstants.h:30,
                     from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/ExFatLib/ExFatFile.h:36,
                     from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/ExFatLib/ExFatVolume.h:28,
                     from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/ExFatLib/ExFatLib.h:27,
                     from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/SdFat.h:33,
                     from C:\Users\kurte\Documents\Arduino\libraries\SD\src/SD.h:27,
                     from C:\Users\kurte\Documents\Arduino\Teensy Tests\CSI_41_OV7670_ILI\CSI_41_OV7670_ILI.ino:24:
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\Time/time.h:1:2: warning: #warning "Please include TimeLib.h, not Time.h.  Future versions will remove Time.h" [-Wcpp]
    And in programs that for example include SD.h in several source files, this gets repeated over and over again.

    Wonder best way to suppress this? Change from #warning to #message or some such thing?
    I simply delete the Time.h file in Time library and use only TimeLib.h for the specific Arduino stuff (i.e. I anticipate the threatened action)
    Sure in some cases there will be a missing functionality, but then edit the library to correct

  24. #49
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    8,229
    Time.h / time.h: The problem is, Windows ignores the case of filenames (by default). There is a switch that can be set to switch that off for certain directories, but this is not the solution here, as it is complicated and needs Admin-rights.

    Yes, best would be to delete this file. It is long enough marked as "deprecated" now. And the worst what could happen would be that most users DON'T get the wrong warning anymore, and a few users will see a correct errormessage.

  25. #50
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,871
    Quote Originally Posted by Frank B View Post
    Time.h / time.h: The problem is, Windows ignores the case of filenames (by default). There is a switch that can be set to switch that off for certain directories, but this is not the solution here, as it is complicated and needs Admin-rights.

    Yes, best would be to delete this file. It is long enough marked as "deprecated" now. And the worst what could happen would be that most users DON'T get the wrong warning anymore, and a few users will see a correct errormessage.
    I agree that might be the best approach here...
    I did a quick search within sublimetext for all files under <Arduino install>/hardware/teensy/avr directory and found:
    Code:
    Searching 6638 files for ""Time.h""
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\Time\TimeLib.h:
       25  // This ugly hack allows us to define C++ overloaded functions, when included
       26  // from within an extern "C", as newlib's sys/stat.h does.  Actually it is
       27: // intended to include "time.h" from the C library (on ARM, but AVR does not
       28  // have that file at all).  On Mac and Windows, the compiler will find this
       29: // "Time.h" instead of the C library "time.h", so we may cause other weird
       30: // and unpredictable effects by conflicting with the C library header "time.h",
       31  // but at least this hack lets us define C++ functions as intended.  Hopefully
       32  // nothing too terrible will result from overriding the C library header?!
    
    4 matches in 1 file
    
    
    Searching 6638 files for "<Time.h>"
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\Audio\extras\miditones\miditones.c:
      193  #include <ctype.h>
      194  #include <stdbool.h>
      195: #include <time.h>
      196  #include <inttypes.h>
      197  
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\stack\fnet_stack_config.h:
      635  /**************************************************************************/ /*!
      636   * @def      FNET_CFG_TIME
      637:  * @brief    FNET time() implementation, defined by <time.h>:
      638   *               - @c 1 = is enabled.
      639   *               - @c 0 = is disabled.
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\stack\fnet_timer.h:
      113  
      114  #if FNET_CFG_TIME || defined(__DOXYGEN__)
      115: #include <time.h>
      116  
      117: #define fnet_time   time  /* Compliance with <time.h> */
      118  
      119  /***************************************************************************/ /*!
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\third_party\mbedtls-2.12.0\src\net_sockets.c:
      106  #include <stdio.h>
      107  
      108: #include <time.h>
      109  
      110  #include <stdint.h>
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\third_party\mbedtls-2.12.0\src\timing.c:
       65  #include <sys/time.h>
       66  #include <signal.h>
       67: #include <time.h>
       68  
       69  struct _hr_time
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\third_party\mbedtls-2.12.0\src\x509.c:
       68  #endif
       69  #if defined(MBEDTLS_HAVE_TIME_DATE)
       70: #include <time.h>
       71  #endif
       72  
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\third_party\mbedtls-2.12.0\src\x509_crl.c:
       61  #include <windows.h>
       62  #else
       63: #include <time.h>
       64  #endif
       65  
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\third_party\mbedtls-2.12.0\src\x509_crt.c:
       67  #include <windows.h>
       68  #else
       69: #include <time.h>
       70  #endif
       71  
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\third_party\mbedtls-2.12.0\src\mbedtls\platform.h:
       59  #include <stdio.h>
       60  #include <stdlib.h>
       61: #include <time.h>
       62  #if !defined(MBEDTLS_PLATFORM_STD_SNPRINTF)
       63  #if defined(_WIN32)
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\third_party\mbedtls-2.12.0\src\mbedtls\platform_time.h:
       50  #else
       51  /* For time_t */
       52: #include <time.h>
       53  typedef time_t mbedtls_time_t;
       54  #endif /* MBEDTLS_PLATFORM_TIME_TYPE_MACRO */
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\RadioHead\RHutil\RasPi.cpp:
       11  #if (RH_PLATFORM == RH_PLATFORM_RASPI)
       12  #include <sys/time.h>
       13: #include <time.h>
       14  #include "RasPi.h"
       15  
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\RadioHead\RHutil_pigpio\RasPi.cpp:
       15  #if (RH_PLATFORM == RH_PLATFORM_RASPI)
       16  #include <sys/time.h>
       17: #include <time.h>
       18  #include "RasPi.h"
       19  #include <stdio.h>
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\RadioHead\tools\simMain.cpp:
       11  #include <sys/time.h>
       12  #include <unistd.h>
       13: #include <time.h>
       14  
       15  SerialSimulator Serial;
    
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\TimeAlarms\readme.txt:
       49  A weekly alarm is triggered every Sunday at 8:30:30
       50  
       51: #include <Time.h>
       52  #include <TimeAlarms.h>
       53  
    
    15 matches across 14 files
    Looks like many of them would be easy to get awy from. Looks like many/most of them are under some form of #if to either RASPI or windows..

Posting Permissions

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