Teensyduino 1.38 Beta #2

Paul · Jul 3, 2017

Here is a second beta test for Teensyduino 1.38.

Old beta download links removed. Please use the latest version:
https://www.pjrc.com/teensy/td_download.html

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

mjs513 · Jul 3, 2017

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.

PaulStoffregen · Jul 4, 2017

Thanks for testing! It's a huge help.

mjs513 · Jul 4, 2017

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.

Jantje · Jul 7, 2017

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

Jantje · Jul 8, 2017

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

Theremingenieur · Jul 8, 2017

That's why I use Teensyduino with Sloeber

fiveangle · Jul 12, 2017

latest Mac OS and AIDE 1.8.3, compiles for Teensy2.0++ various flavors of Marlin that run correctly w/o issue.

danixdj · Jul 15, 2017

Paul said:
Audio I2S uses 64 bit frame

What's this?

WMXZ · Jul 15, 2017

danixdj said:
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

danixdj · Jul 15, 2017

WMXZ said:
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?

WMXZ · Jul 15, 2017

danixdj said:
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.

mjs513 · Jul 16, 2017

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.

tni · Jul 16, 2017

mjs513 said:
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).

MichaelMeissner · Jul 17, 2017

mjs513 said:
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));
  // ...
}

mjs513 · Jul 17, 2017

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

PaulStoffregen · Jul 17, 2017

mjs513 said:
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.

mjs513 · Jul 17, 2017

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

PaulStoffregen · Jul 17, 2017

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.

mjs513 · Jul 18, 2017

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.

gfvalvo · Jul 20, 2017

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.

mjs513 · Jul 20, 2017

@Paul. Is this a good time to start talking about additional libraries to be included with the Teenys loader?

PaulStoffregen · Jul 20, 2017

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.

Frank B · Jul 20, 2017

The ADC Library misses the documentation doxygen-folder

mjs513 · Jul 20, 2017

Good for you Paul.

Enjoy they weekend.

Teensyduino 1.38 Beta #2

Administrator

Senior Member+

Well-known member

Senior Member+

Well-known member

Well-known member

Senior Member+

New member

Well-known member

Well-known member

Well-known member

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member

Senior Member+