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

Thread: Teensyduino 1.58 Beta #2

  1. #76
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    11,165
    @Paul - if there is going to be a B3 soon, you may want to pick up. https://github.com/PaulStoffregen/USBHost_t36/pull/98
    The Keyboard HID code was too aggressive in claiming usages... It was hurting Mouse and Joystick

  2. #77
    Senior Member h4yn0nnym0u5e's Avatar
    Join Date
    Apr 2021
    Location
    Cambridgeshire, UK
    Posts
    520
    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.

  3. #78
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    11,165
    Quote Originally Posted by PaulStoffregen View Post
    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 ...

    Quote Originally Posted by PaulStoffregen View Post
    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!

    Quote Originally Posted by PaulStoffregen View Post
    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...

  4. #79
    Senior Member h4yn0nnym0u5e's Avatar
    Join Date
    Apr 2021
    Location
    Cambridgeshire, UK
    Posts
    520
    Quote Originally Posted by KurtE View Post
    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.

  5. #80
    Senior Member h4yn0nnym0u5e's Avatar
    Join Date
    Apr 2021
    Location
    Cambridgeshire, UK
    Posts
    520
    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)

  6. #81
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    11,165
    Quote Originally Posted by h4yn0nnym0u5e View Post
    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

  7. #82
    Senior Member h4yn0nnym0u5e's Avatar
    Join Date
    Apr 2021
    Location
    Cambridgeshire, UK
    Posts
    520
    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 by h4yn0nnym0u5e; 09-21-2022 at 06:05 PM.

  8. #83
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,481
    Quote Originally Posted by h4yn0nnym0u5e View Post
    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.

  9. #84
    Senior Member h4yn0nnym0u5e's Avatar
    Join Date
    Apr 2021
    Location
    Cambridgeshire, UK
    Posts
    520
    Quote Originally Posted by mjs513 View Post
    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".

  10. #85
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,481
    Quote Originally Posted by h4yn0nnym0u5e View Post
    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.

  11. #86
    Quote Originally Posted by mjs513 View Post
    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.

  12. #87
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,481
    Quote Originally Posted by joepasquariello View Post
    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__)

  13. #88
    Senior Member BriComp's Avatar
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    953
    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.

  14. #89
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,481
    Quote Originally Posted by BriComp View Post
    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).

  15. #90
    Senior Member BriComp's Avatar
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    953
    So according to their naming NONE of these should be used on T4.x USBHost_t36, ST7735_t3, ILI9488_t3, ILI9341_t3?

  16. #91
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,481
    Quote Originally Posted by BriComp View Post
    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.

  17. #92
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    11,165
    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.

  18. #93
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,481
    @ PaulStoffregen,

    Not sure you have seen this thread:
    https://forum.pjrc.com/threads/71128...?highlight=dsp

    But I managed to get DSP updated to the latest version using uVision5. Ran some simple tests if anyone has any other interesting tests please post and I will give them a try.

  19. #94
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    4,328

    Cool

    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.

  20. #95
    Quote Originally Posted by mjs513 View Post
    Should be easy enough to do just by using a if defined(__IMXRT1062__)
    Here's the FreqCount Serial_Output example updated to run on LC/T3/T4/MM. Pins are chosen as a function of processor and there are comments on specifying the counting period in microseconds for T4/MM and in milliseconds for T3/LC.

    Serial_Output_LC_T3_T4_MM.ino

  21. #96
    Senior Member h4yn0nnym0u5e's Avatar
    Join Date
    Apr 2021
    Location
    Cambridgeshire, UK
    Posts
    520
    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.

  22. #97
    Senior Member
    Join Date
    Jul 2014
    Posts
    3,466
    Quote Originally Posted by KurtE View Post
    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.

  23. #98
    Member
    Join Date
    Dec 2017
    Location
    France, Paris
    Posts
    80
    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 :/ .

  24. #99
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,519
    Prior versions of TD like 1.55 are still online as: pjrc.com/teensy/td_155/

  25. #100
    Member
    Join Date
    Dec 2017
    Location
    France, Paris
    Posts
    80
    Ok, cool ! Thank you
    So the links present in the forum of the previous versions are no longer good :/ .

Posting Permissions

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