Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 3 1 2 3 LastLast
Results 1 to 25 of 52

Thread: Teensyduino 1.38 Beta #2

  1. #1
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    261

    Teensyduino 1.38 Beta #2

    Here is a second beta test for Teensyduino 1.38.

    Linux 32 bit:
    https://www.pjrc.com/teensy/td_138-b...nstall.linux32

    Linux 64 bit:
    https://www.pjrc.com/teensy/td_138-b...nstall.linux64

    Linux ARM:
    https://www.pjrc.com/teensy/td_138-b...stall.linuxarm

    Mac OS-X:
    https://www.pjrc.com/teensy/td_138-b...inoInstall.dmg

    Windows:
    https://www.pjrc.com/teensy/td_138-b...inoInstall.exe


    Changes since Teensyduino 1.38-beta1:

    Fix C++14 delete and link with -lstdc++
    Add pure code choices in Tools > Optimization
    Fix Wire lib with fastest optimize and >120 MHz CPU speed
    Wire emulate AVR twi_writeTo - for Adafruit compatibility
    Wire1 support for pins on SD socket (if not using SD card)
    Fix install problem on Arduino 1.0.6
    Fix analogReadAveraging with ADC1
    Allow more memory for audio library on Teensy 3.5 & 3.6
    Fix audio library delay effect on Teensy 3.5 & 3.6
    Audio I2S uses 64 bit frame, improve compatibility with I2S mics
    Fix OctoWS2811 seldom-used color conversion options
    USBHost_t36 improved handling of error & pipe stall

  2. #2
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    408
    Downloaded and installed no issues. Ran it through several of the same sketches as for beta1 and everything compiled. Ran a modified Onehorse's PropShield sensor sketch with fastest-mpure the "sketch uses 58260 bytes (11%) of program storage space" with fastest only the "Sketch uses 53220 bytes (10%) of program storage space". Not much of a difference. Haven't tested speed but will give it a try later and update.

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,135
    Thanks for testing! It's a huge help.

  4. #4
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    408
    My pleasure. If there is anything else I can do I will. With all that you do its the least that I can do. Been using the c14 version now non-stop since you released it and haven't had any issue.

  5. #5
    I just tested on windows 10 installed on top of the arduino ide 1.8.2.
    Compiled and uploaded blink ( on a teesy3.1 ) from arduino IDE and Sloeber.
    All went as smooth as can be.
    Jantje

  6. #6
    A test run in sloeber just finished compiling all arduino examples on all teensy boards. That makes 560 compiles.
    No problems whatsoever so the toolchain is fine.
    Top quality as usual.
    Best regards
    Jantje

  7. #7
    Senior Member Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    827
    That's why I use Teensyduino with Sloeber

  8. #8
    Junior Member
    Join Date
    Jul 2017
    Posts
    1
    latest Mac OS and AIDE 1.8.3, compiles for Teensy2.0++ various flavors of Marlin that run correctly w/o issue.

  9. #9
    Senior Member
    Join Date
    Oct 2016
    Posts
    160
    Quote Originally Posted by Paul View Post
    Audio I2S uses 64 bit frame
    What's this?

  10. #10
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,379
    Quote Originally Posted by danixdj View Post
    What's this?
    one stereo frame (left/right word) of a I2S sample consists of 64 bits (2 x 32 bit)
    this was changed by Paul from 32 bit (2 x 16 bit)
    The driver has also been modified to allow proper 16 bit access for audio library

  11. #11
    Senior Member
    Join Date
    Oct 2016
    Posts
    160
    Quote Originally Posted by WMXZ View Post
    one stereo frame (left/right word) of a I2S sample consists of 64 bits (2 x 32 bit)
    this was changed by Paul from 32 bit (2 x 16 bit)
    The driver has also been modified to allow proper 16 bit access for audio library
    So the sample is more accurate?

    This feature need a sketch modification?

  12. #12
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,379
    Quote Originally Posted by danixdj View Post
    So the sample is more accurate?

    This feature need a sketch modification?
    No, if the ADC has only 16 bit resolution the I2S interface will not increase resolution,
    The Audio library is also fixed a 16 bit resolution.
    Standard sketches do not need to be modified, only recompiled.

    The modification was only introduced to allow the use of 24 or 32 bit I2S-ADC's to be used with Audio library.
    For this to work, all data are stored MSB first by the I2S interface and the upper 16 bit are extracted.

    The Audio library still will work with 16 bit resolution.
    To use the Audio library with 32 bit resolution, ALL routines may need rewriting, as they are hard coded to 44100 Hz AND 16 bit resolution.

  13. #13
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    408
    Been playing around with the Prop Shield IMU code and the only different warning I have been getting that I have not seen before is:
    Code:
    warning: argument to 'sizeof' in 'void* memset(void*, int, size_t)' call is the same 
    expression as the destination; did you mean to dereference it? [-Wsizeof-pointer-memaccess]
    
      memset(_ar, 0.0, sizeof(_ar));
    Haven't gone back to give it a try in 1.37 though.

  14. #14
    Senior Member
    Join Date
    Jan 2013
    Posts
    843
    Quote Originally Posted by mjs513 View Post
    Been playing around with the Prop Shield IMU code and the only different warning I have been getting that I have not seen before is:
    Code:
    warning: argument to 'sizeof' in 'void* memset(void*, int, size_t)' call is the same 
    expression as the destination; did you mean to dereference it? [-Wsizeof-pointer-memaccess]
    
      memset(_ar, 0.0, sizeof(_ar));
    Chances are 99% that it's a valid warning and the code in question buggy (wherever it may be from).

  15. #15
    Senior Member MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,382

    Cool

    Quote Originally Posted by mjs513 View Post
    Been playing around with the Prop Shield IMU code and the only different warning I have been getting that I have not seen before is:
    Code:
    warning: argument to 'sizeof' in 'void* memset(void*, int, size_t)' call is the same 
    expression as the destination; did you mean to dereference it? [-Wsizeof-pointer-memaccess]
    
      memset(_ar, 0.0, sizeof(_ar));
    Haven't gone back to give it a try in 1.37 though.
    Note, you do not want to use 0.0 as an argument to memset, instead:

    Code:
      memset(_ar, 0, sizeof(_ar));
    However, what it is likely warning you about is the variable _ar is likely a pointer, and not an array. Note, in C/C++, arrays are second class objects. If you pass an array to a function, the compiler converts the declaration within the function to be a pointer to the element, and it passes the pointer, instead of copying the entire array to a temporary on the stack.

    So for example:

    Code:
    void clear (char foo[])
    {
      memset (foo, 0, sizeof (foo));
    }
    
    void bar (void)
    {
      char foo[100];
      clear (foo);
      // ...
    }
    is actually implemented as:

    Code:
    void clear (char *foo)
    {
      memset (foo, 0, sizeof (foo));   // sizeof char * is 4
    }
    
    void bar (void)
    {
      char foo[100];
      clear (&foo[0]);
      // only the first 4 bytes are cleared
      // ...
    }
    What you should do is pass the length as a separate argument:

    Code:
    void clear (char *foo, size_t len)
    {
      memset (foo, 0, len);
    }
    
    void bar (void)
    {
      char foo[100];
      clear (foo, sizeof (foo));
      // ...
    }
    Last edited by MichaelMeissner; 07-18-2017 at 02:53 AM.

  16. #16
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    408
    Thanks Michael for the explanation. I was wondering what the warning really meant, never saw that one before. Saw one piece but didn't dive into the library that is calling it yet.

    Appreciate it.
    Mike

  17. #17
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,135
    Quote Originally Posted by mjs513 View Post
    Been playing around with the Prop Shield IMU code and the only different warning I have been getting that I have not seen before is:
    Is this from code in one of the libraries or any of the examples?

    I tried compiling all 5 of the Arduino examples with the NXPMotionSense library. None give this warning. The MadgwickAHRS and MahonyAHRS do give a couple [-Wstrict-aliasing] warnings, but I couldn't find any example that gives the [-Wsizeof-pointer-memaccess] warning you reported.

    If this problem is in any of the libraries or published examples, please point me to the right code so I can fix it.

  18. #18
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    408
    Hi Paul. Not in any of the Teensy libraries or examples. It came from a modified version of an APM library that contained several types of filters that can be used. I added a couple more and the issue is with the RunningAverage. Here is the offending code for reference:
    Code:
    //
    //    FILE: RunningAverage.cpp
    //  AUTHOR: Rob Tillaart
    // VERSION: 0.2.04
    // PURPOSE: RunningAverage library for Arduino
    //
    // The library stores the last N individual values in a circular buffer,
    // to calculate the running average.
    //
    // HISTORY:
    // 0.1.00 - 2011-01-30 initial version
    // 0.1.01 - 2011-02-28 fixed missing destructor in .h
    // 0.2.00 - 2012-??-?? Yuval Naveh added trimValue (found on web)
    //          http://stromputer.googlecode.com/svn-history/r74/trunk/Arduino/Libraries/RunningAverage/RunningAverage.cpp
    // 0.2.01 - 2012-11-21 refactored
    // 0.2.02 - 2012-12-30 refactored trimValue -> fillValue
    // 0.2.03 - 2013-11-31 getElement
    // 0.2.04 - 2014-07-03 added memory protection
    //
    // Released to the public domain
    //
    
    #include "RunningAverage.h"
    #include <stdlib.h>
    
    RunningAverage::RunningAverage(int n)
    {
        _size = n;
        _ar = (float*) malloc(_size * sizeof(float));
        if (_ar == NULL) _size = 0;
        clear();
    }
    
    RunningAverage::~RunningAverage()
    {
        if (_ar != NULL) free(_ar);
    }
    
    // resets all counters
    void RunningAverage::clear()
    {
        _cnt = 0;
        _idx = 0;
        _sum = 0.0;
        //for (int i = 0; i< _size; i++) _ar[i] = 0.0;  // needed to keep addValue simple
    	memset(_ar, 0.0, sizeof(_ar));
    	}
    
    // adds a new value to the data-set
    void RunningAverage::addValue(float f)
    {
        if (_ar == NULL) return;
        _sum -= _ar[_idx];
        _ar[_idx] = f;
        _sum += _ar[_idx];
        _idx++;
        if (_idx == _size) _idx = 0;  // faster than %
        if (_cnt < _size) _cnt++;
    }
    
    // returns the average of the data-set added sofar
    float RunningAverage::getAverage()
    {
        if (_cnt == 0) return NAN;
        return _sum / _cnt;
    }
    
    // returns the value of an element if exist, 0 otherwise
    float RunningAverage::getElement(uint8_t idx)
    {
        if (idx >=_cnt ) return NAN;
        return _ar[idx];
    }
    
    // fill the average with a value
    // the param number determines how often value is added (weight)
    // number should preferably be between 1 and size
    void RunningAverage::fillValue(float value, int number)
    {
        clear();
        for (int i = 0; i < number; i++)
        {
            addValue(value);
        }
    }
    // END OF FILE
    Last edited by mjs513; 07-18-2017 at 01:40 AM.

  19. #19
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,135
    That's definitely a bug in the RunningAverage library.

    It should have been:

    memset(_ar, 0, _size * sizeof(float));

    This is a common occurrence, where newer versions of the toolchain are able to detect more problems. Long established bugs become more apparent.

  20. #20
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    408
    Thank you for the solution. Seems so obvious . Thought that what was happening, with the new toolchain I was seeing things that I didn't see before. Think its good for newbies to toolchains to understand that.

  21. #21
    Per this post, I think you need to update the AudioControlSGTL5000::enable() method to select BCLK = 64 * Fs. I say "think" because I've only looked at the code, haven't actually tested it.

  22. #22
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    408
    @Paul. Is this a good time to start talking about additional libraries to be included with the Teenys loader?

  23. #23
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,135
    Yes, or sometime next week. I'm actually taking this weekend off... but will try to catch up to forum messages when I get back Monday.

  24. #24
    Senior Member Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    4,071
    The ADC Library misses the documentation doxygen-folder

  25. #25
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    408
    Good for you Paul. Enjoy they weekend.

Posting Permissions

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