Teensyduino 1.58 Beta #2

This seems an incorrect test, surely the LC isn't in the T4 family?
Code:
  teensyLC  FreqCount/examples/Serial_Output_T4/Serial_Output_T4.ino
FreqCount documentation says FreqCount.begin() takes a parameter in milliseconds, but looking at the code it's in microseconds for IMXRT1062 ... not gonna touch this one.
 
Today the Arduino prefs for compiler warnings aren't used. I'm not a fan of the "None" setting, which is the default, so when Arduino added this (years ago) I didn't bother to adopt it for Teensy. I haven't looked recently at how IDE 2.0.0 is handling this.

I am not a fan of None either - But might be interesting if it maybe looked and maybe None->Default and ...

Today the situation is much better. (except of course for semiconductor shortages & wild changes in delivery schedules, which have again come up over the last few days...)

Hopefully not more bad news!

These last couple days I've sort of run out of enthusiams for fixing the remaining compiler warnings. But there aren't many left. Here's a list of what's left from the perl script finding.

Don't blame you! I would not want to fix a bunch of these either...

Code:
  teensy31  ssd1351/examples/banding/banding.ino
  teensy31  ssd1351/examples/fonts/fonts.ino
  teensy31  ssd1351/examples/indexedcolors/indexedcolors.ino
  teensy31  ssd1351/examples/simpletest/simpletest.ino
  teensy35  Adafruit_nRF8001/examples/callbackEcho/callbackEcho.ino
  teensy35  Adafruit_nRF8001/examples/echoDemo/echoDemo.ino
  teensy35  ssd1351/examples/banding/banding.ino
  teensy35  ssd1351/examples/fonts/fonts.ino
  teensy35  ssd1351/examples/indexedcolors/indexedcolors.ino
  teensy35  ssd1351/examples/simpletest/simpletest.ino
  teensy36  ssd1351/examples/banding/banding.ino
  teensy36  ssd1351/examples/fonts/fonts.ino
  teensy36  ssd1351/examples/indexedcolors/indexedcolors.ino
  teensy36  ssd1351/examples/simpletest/simpletest.ino
  teensy40  ssd1351/examples/banding/banding.ino
  teensy40  ssd1351/examples/fonts/fonts.ino
  teensy40  ssd1351/examples/indexedcolors/indexedcolors.ino
  teensy40  ssd1351/examples/simpletest/simpletest.ino

I am taking a quick look at these. But then again wonder:
What the differences are between teensy_ssd1351 and Adafruit_ssd1351...
 
Code:
  teensy31  ssd1351/examples/banding/banding.ino
  teensy31  ssd1351/examples/fonts/fonts.ino
  teensy31  ssd1351/examples/indexedcolors/indexedcolors.ino
  teensy31  ssd1351/examples/simpletest/simpletest.ino
  teensy35  Adafruit_nRF8001/examples/callbackEcho/callbackEcho.ino
  teensy35  Adafruit_nRF8001/examples/echoDemo/echoDemo.ino
  teensy35  ssd1351/examples/banding/banding.ino
  teensy35  ssd1351/examples/fonts/fonts.ino
  teensy35  ssd1351/examples/indexedcolors/indexedcolors.ino
  teensy35  ssd1351/examples/simpletest/simpletest.ino
  teensy36  ssd1351/examples/banding/banding.ino
  teensy36  ssd1351/examples/fonts/fonts.ino
  teensy36  ssd1351/examples/indexedcolors/indexedcolors.ino
  teensy36  ssd1351/examples/simpletest/simpletest.ino
  teensy40  ssd1351/examples/banding/banding.ino
  teensy40  ssd1351/examples/fonts/fonts.ino
  teensy40  ssd1351/examples/indexedcolors/indexedcolors.ino
  teensy40  ssd1351/examples/simpletest/simpletest.ino

I am taking a quick look at these. But then again wonder:
What the differences are between teensy_ssd1351 and Adafruit_ssd1351...
I’ve done those and put PRs in for them … just fixing the ones in Paul’s repos, though a lot are way behind the upstream ones.
 
OK, I've done most of what Paul mentioned in #64, and put PRs in, except for:

  • XBee - not in the repo
  • FNET - not in the repo
  • FlexCAN - repo doesn't have these examples in
  • FreqCount - doesn't seem to apply to Teensy LC
  • SdFat - can't see how to fix this (yet)
 
I’ve done those and put PRs in for them … just fixing the ones in Paul’s repos, though a lot are way behind the upstream ones.

Sounds good, I had done the exact editing of the ssd1351 did, EXCEPT, was unsure about glcdfont.c

That is: it is defined like:

static const unsigned char font[] PROGMEM = {

And that is the only thing in the file! Since static defined, it won't be used by other files. Unless I am missing something.

My guess was at one point, maybe another source file included this file. But I don't see any signs of that.

So was going to suggest either delete the file.
Or simply leave an empty place holder file
 
I do believe you're right! I was just blindly making minimal changes to remove warnings and totally missed the static keyword... May be best if an issue is raised* in the repo for now, just in case some code out in user-land makes use of it; I expect it won't have any real impact, as the linker will presumably discard it.

* EDIT: for some reason I can't raise issues for that repo... probably some weird GitHub thing
 
Last edited:
This seems an incorrect test, surely the LC isn't in the T4 family?
Code:
  teensyLC  FreqCount/examples/Serial_Output_T4/Serial_Output_T4.ino
FreqCount documentation says FreqCount.begin() takes a parameter in milliseconds, but looking at the code it's in microseconds for IMXRT1062 ... not gonna touch this one.

On this one the documentation should probably be updated to reflect that for the T4.x FreqCount.begin() uses microseconds instead of milliseconds.
 
On this one the documentation should probably be updated to reflect that for the T4.x FreqCount.begin() uses microseconds instead of milliseconds.
Yes, but as the LC isn't T4.x this example shouldn't be used with it at all. The compile warning is because the sketch is trying to set the time in microseconds (unsigned long), but the library is expecting a time in milliseconds (unsigned short), so the value is overflowing.

An excellent example of why you should always see what is causing a compiler warning, rather than blithely saying "it's only a warning, nothing will go wrong".
 
Yes, but as the LC isn't T4.x this example shouldn't be used with it at all. The compile warning is because the sketch is trying to set the time in microseconds (unsigned long), but the library is expecting a time in milliseconds (unsigned short), so the value is overflowing.

An excellent example of why you should always see what is causing a compiler warning, rather than blithely saying "it's only a warning, nothing will go wrong".

Agree with you on the compiler warnings. With the new compiler fairly clear on what the warning is and how to fix it. When updating a recent library it found errors in the code that the old compiler didn't pick up and I was able to fix it. However, with that said there are a limited number of cases that warning about initialization or variable not used may be appropriate - but as @luni and @KurtE showed there are ways that can be fixed.

As for the example, the example is clearly marked for use with the T4. There are ways to get around it but the documentation should be updated to reflect the correct usage for all boards.
 
As for the example, the example is clearly marked for use with the T4. There are ways to get around it but the documentation should be updated to reflect the correct usage for all boards.

I think many new users run into this. Rather than having separate examples for T4 and others, there could be one example program that uses the correct pin and argument type according to board type. I'll post one here for review, and maybe it can be included in TD 1.58.
 
I think many new users run into this. Rather than having separate examples for T4 and others, there could be one example program that uses the correct pin and argument type according to board type. I'll post one here for review, and maybe it can be included in TD 1.58.

Should be easy enough to do just by using a if defined(__IMXRT1062__)
 
As for the example, the example is clearly marked for use with the T4. There are ways to get around it but the documentation should be updated to reflect the correct usage for all boards.
True, but there are a large number of libraries that were developed for the t3.x or t35/t36 which are labelled just that but are also intended NOW to be used for t4.x as well.
By the same argument these libraries should not be used for t4.x or the names should be updated.
 
True, but there are a large number of libraries that were developed for the t3.x or t35/t36 which are labelled just that but are also intended NOW to be used for t4.x as well.
By the same argument these libraries should not be used for t4.x or the names should be updated.

True. While I haven't checked all the libraries, at least some of them have things like:
Code:
#if defined(__AVR__)
#error "Sorry, ILI9488_t3 does not work with Teensy 2.0 or Teensy++ 2.0.  Use Adafruit_ILI9488."
#endif

or

Code:
#if !defined(__MK66FX1M0__) && !defined(__IMXRT1052__) && !defined(__IMXRT1062__)
#error "USBHost_t36 only works with Teensy 3.6 or Teensy 4.x.  Please select it in Tools > Boards"
#endif

On the other hand during T4 testing I believe all the libraries were tested and were updated to a work with either the T3s or T4's.

But with all that said, this goes back to what @KurtE mentioned in one of his posts somewhere about using the library.properties architectures -field to define what processors (not sure this is possible to use board types or processor types).
 
So according to their naming NONE of these should be used on T4.x USBHost_t36, ST7735_t3, ILI9488_t3, ILI9341_t3?
 
So according to their naming NONE of these should be used on T4.x USBHost_t36, ST7735_t3, ILI9488_t3, ILI9341_t3?

Unfortunately no - naming convention didn't change but was taken care of with ifdefs. The libs you mentioned all were updated to support the T4's as well.
 
Early morning all (at least in my time zone),

As we see, library naming conventions like this are flawed. But these libraries exist with these names.

And with anything like this, when a new board comes along, that has a different processor, what should you do?

Example: USBHost_t36. When it was originally developed it was only supported on T3.6, but along comes T4 which also has the USB Host support. We have/had several possible solutions:
a) Put the support in the existing library, such that code could hopefully run on either, without source code changes - current solution.
b) Create a duplicate library for T4 and hopefully try to keep them in sync with each other - i.e., along the lines of the cores teensy3 versus teensy4
c) Make 3 libraries - USBHost_common, USBHost_t36, USBHost_t4x - might be cleaner in some ways, but then most all sketches would have #ifdef <t36> - include the t3.6 version else...

d) Jetson this naming convention and create a new one, like: Teensy_USBHost or PJRC_USBHost, along the line of Adafruit or Sparkfun or ..
This is probably a cleaner solution, but a lot of work.

e) go whole hog and change everything. That is currently all Teensy things are installed as one big composit package. And we sort of Lie to Arduino and say everything is built with the architecture of: avr
To be specific, every teensy is considered the same as the Arduino AVR8 based boards like: uno, mega, leonardo. Which works well for Teensy 2.x stuff. And in the beginning of the Arduino ARM stuff, like when Teensy 3.0 came out made sense to continue.

But maybe now that there are many others ARM type boards out there and now with Arduino 2.0 released where we have Teensy Board Manager support, it might make sense, to split this up into at least 2 maybe 3 different board architecture types, in the same way for example: Arduino has: avr, SAM, SAMD, ... Likewise for Adafruit, Sparkfun...
So for example, if this was split into 3, like: avr, kinetis, imxrt1062 (or other names, like, teensy3, teensy4), then, some of the other solutions, could be resolved by the Arduino builder.

For example, today: Teensy build, we install our own version of the libraries: SD and SDFat. Now if I install another SDFat for some other boards, it breaks building for Teensy, likewise if I put the Teensy one in my <sketches>/libraries folder, it breaks building other boards... But if we have specific architectures, like mentioned, we could instead do like what Adafruit does, with their fork of SDFat.
They install as some name like: SdFat_-Adafruit_Fork They still have the main header file SdFat.h as we do, but since they have defined in their library.properties file: architectures=rp2040,nrf52,samd,esp32,*
If you are building for some of their boards, the library builder will probably choose this one over ones that are simply marked: * or avr.

But the main question would be, would the gain of doing something like this be worth the pain? Or would this just be opening up Pandora's box? This probably something that only Paul could answer. But my guess is that this would not be a simple, few hours to convert type thing! And when there is probably so little spare time right now, one would have to weigh this versus that many other things that need attention.

Sorry, hopefully I had enough coffee, that some of this might make some sense. :D
 
In terms of examples, it would be nice if the examples were updated to use the correct pins via #ifdef's for different processors. For example the audio examples:

  • WavFilePlayer
  • WavFilePlayerPause
  • Part_1_03_Playing_Music
  • Part_1_04_Blink_While_Playing
  • Part_1_05_Do_More_While_Playing
  • Part_2_01_First_Design_Tool_Use
  • Part_3_03_TFT_Display
  • Part_2_07_Mixers
  • Part_2_07_Filters
  • Part_3_01_Peak_Detection
  • Part_3_02_Fourier_Transform
  • Part_3_03_TFT_Display
  • TestTutorialKit
  • WaterfallSpectrum
  • Bitcrusher
  • Freeverb
  • Freeverb_Stereo
  • Granular

All use SPI.setMOSI to set the default MOSI to be 7, which works of course for the revision A-C audio adapter on the Teensy 3.2, 3.5, and 3.6 microprocessors, but it doesn't work for the revision D audio adapter on the Teensy 4.0 and Teensy 4.1 microprocessors. In addition in comments for which SD card to use, the comment should add the Teensy 4.1 to the list of boards where you can select the built-in micro SD card reader.
 
Having some problems which I've traced to _newlib_version.h. My copy (from a fresh portable install) looks like:
Code:
/* _newlib_version.h.  Generated from _newlib_version.hin by configure.  */
/* Version macros for internal and downstream use. */
#ifndef _NEWLIB_VERSION_H__
#define _NEWLIB_VERSION_H__ 1

/* The newlib version in string format. */
#define _NEWLIB_VERSION "@NEWLIB_VERSION@"

/* The newlib major version number. */
#define __NEWLIB__ @NEWLIB_MAJOR_VERSION@

/* The newlib minor version number. */
#define __NEWLIB_MINOR__ @NEWLIB_MINOR_VERSION@

/* The newlib patch level. */
#define __NEWLIB_PATCHLEVEL__ @NEWLIB_PATCHLEVEL_VERSION@

#endif /* !_NEWLIB_VERSION_H__ */
which looks as if it's failed to be run through some sort of pre-processor to fill in the values. TD1.57 had version 2.4.0 here.
 
But maybe now that there are many others ARM type boards out there and now with Arduino 2.0 released where we have Teensy Board Manager support, it might make sense, to split this up into at least 2 maybe 3 different board architecture types, in the same way for example: Arduino has: avr, SAM, SAMD, ... Likewise for Adafruit, Sparkfun...
So for example, if this was split into 3, like: avr, kinetis, imxrt1062 (or other names, like, teensy3, teensy4), then, some of the other solutions, could be resolved by the Arduino builder.

I strongly support to split up according to board architecture types.
 
Hi,

I have a big problem with the SDfat library and USBHost.
I have a project that needs to use the USB host port for a keyboard and mouse and write to the SD port to integrate the Teensy micormod card.

With version 1.55 everything was fine, but since version 1.57 or 1.58B2 I have a strange bug.
If I only use the SDfat library, everything is fine, but if I add the USBHost library (without even using its functions), I can no longer write to the card, but I can read it well.

Before I used the standard adruino SDFat library, and it worked, but with the new version of the USBHost library I can no longer use it, I must absolutely use the provided version of PJRC.

And the other problem is that the previous versions of teensyduino are no longer available for download, especially version 1.55.

Can you help me? Due to a small update I'm blocked and I can't go back :/ .
 
Back
Top