Teensyduino 1.54 Beta #5

Status
Not open for further replies.
... 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=^([COLOR=#ff0000]?:\.text|\.text\.progmem|\.text\.itcm|\.data)[/COLOR]\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:
@Paul, please edit platform.text and use this:
recipe.size.regex=^(?:\.text|\.text\.progmem|\.text\.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:
Frank B said:
@Paul, please edit platform.text and use this:
recipe.size.regex=^(?:\.text|\.text\.progmem|\.text\.itcm|\.data|\.text.csf)\s+([0-9]+).*
Click to expand...

Ok, added. It'll be in 1.54-beta6.


...whatever csf is...
Click to expand...

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.
 
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.
 
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?
 
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.
 
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:
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:
..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?
 
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)? .
 
daj59 said:
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?
Click to expand...

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 :
screenshot.jpg

Edit: Teensy loader can also be launched without problems from PlatformIO, still in Big Sur 11.1 beta :
screenshot2.png
 
Last edited:
TFTLCDCyg said:
Now with the Teensy Loader 1.54-beta5 only errors jump like rabbits!
Click to expand...

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/commit/947085342ff7ce15d9e725fecc40572d10ff368b
 
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!
 
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_download.html#mac_documents_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.
 
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.
 
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.

15sesk1z2bvqi6kzg.jpg

Teensy 4 + ILI9488 3.5" + SD + JPEGDEC

Thanks for the prompt response.
 
PaulStoffregen said:
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. ;)
Click to expand...
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.

PaulStoffregen said:
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.
Click to expand...
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.
 
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?
 
KurtE said:
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?
Click to expand...

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
 
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.
 
Frank B said:
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.
Click to expand...

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..
 
Status
Not open for further replies.
Back
Top