PDA

View Full Version : Teensyduino 1.31 Beta #1 Available



Paul
09-21-2016, 03:51 PM
Here is a first beta test for Teensyduino 1.31.


Edit: old beta test linkes removed. Full non-beta release is here:
http://www.pjrc.com/teensy/td_download.html



The only change since 1.30 is support for Arduino 1.6.12.

Arduino 1.6.12 has a faster build process (caches include dependencies) and supports Mac OS-X Sierra.

oqibidipo
09-21-2016, 08:25 PM
supports Mac OS-X Sierra.
*ahem* macOS Sierra ;)

el_supremo
09-21-2016, 08:33 PM
So far I've only tested the vocoder with about 600kB of flash. It uploaded and works.

Pete

defragster
09-22-2016, 06:08 AM
I went to IDE 1.6.12 and TD 1.31 no problem on my Win10, so far just FASTLEDS on the T_3.6

Wozzy
09-22-2016, 09:41 AM
I compiled encoder lib, bounce and ili9341-t3. I still had to apply KurtEs hacks to ILI9341_t3.cpp and avr_emulation.h to be able to use pin 27 as alternate SCLK(0). Otherwise all compiled fine on WIN10-64.

v01den
09-22-2016, 10:06 PM
Hi, I tried to upload the code to a teensy 3.1 and it builds but teensy loader doesn't detect the teensy, I tried to push the teensy program button. I have used dmesg in terminal and it says:

AMFI: allowing exception handler for 'Arduino' (7295) because the process is not restricted.

Also, in the port selection menu, the teensy doesn't appear. I'm using Arduino 1.6.12 with teensyduino 1.31-beta 1 in macOs Sierra. :(

Edit: I have tried "system_profiler SPUSBDataType" on terminal and the output doesn't change when I plug the teensy.

KurtE
09-22-2016, 11:29 PM
I compiled encoder lib, bounce and ili9341-t3. I still had to apply KurtEs hacks to ILI9341_t3.cpp and avr_emulation.h to be able to use pin 27 as alternate SCLK(0). Otherwise all compiled fine on WIN10-64.
I would not necessarily call them hacks, they are simply changes to add those pins as valid options. In some cases it made the code slightly more complicated in that, before there were only two options for MOSI or MISO or SCLK, now there are three. So the code that encoded this can no longer use 1 bit to say which one you are using, now it requires 2 bits per each...

There are still outstanding Pull requests to fix this which include:
Cores: https://github.com/PaulStoffregen/cores/pull/173
ILI9341_t3: https://github.com/PaulStoffregen/ILI9341_t3/pull/31
SPI: https://github.com/PaulStoffregen/SPI/pull/20 (actually not sure if Wozzy used this one, added another valid CS pin)

I have now downloaded 1.6.12 and installed this beta and used winmerge to verify that the only things different in my two trees is the above changes, which I then reapplied.

Note: One change that I see made this beta was the fix to core_pins.h which fixed the problems with the count of Analog pins and PWM pins.

Kurt

Wozzy
09-22-2016, 11:32 PM
I would not necessarily call them hacks, they are simply changes to add those pins as valid options.
Kurt
KurtE,
I agree... Sorry, poor choice of words on my part.

KurtE
09-22-2016, 11:41 PM
KurtE,
I agree... Sorry, poor choice of words on my part.
No problem, I was just pulling your leg ;)

PaulStoffregen
09-23-2016, 12:02 AM
Also, in the port selection menu, the teensy doesn't appear.

Can you look at Arduino > About to double check the version of Arduino and Teensyduino?

If no Teensyduino version is shown, seems likely Teensyduino didn't actually get installed to this copy of Arduino. Maybe try running the installer again? Perhaps double check the location of Arduino before installing. During install, the "?" button can show you how the installer is detecting Arduino. Maybe check that it's really seeing 1.6.12?

PaulStoffregen
09-23-2016, 12:06 AM
Does anyone notice a speed difference when building the audio lib, or other stuff?

defragster
09-23-2016, 12:20 AM
Odd - my 1.6.11 won't complete a build of audio memoryandpu test. I must have munged a file - it is dying in SD . . . building for T_3.6. Will clean up and try again later for T_3.2.

Don't have time to look - I wonder if one is building with a local sketchbook/lib and the other is not?

I did see the error 5 seconds faster on my SSD copy during Verify build at 26 versus 31 seconds.

On my SSD 1.6.12 it completed in 33 seconds.

defragster
09-23-2016, 05:32 AM
There is a difference in the INCLUDE indications? IDE 1.6.11 is picking up SDFAT from sketchbook\libraries and 1.6.12 is not using that at all? And 1.6.11 is giving me this batch of errors. Same machine - same sketch - Windows 10.

Notes:
SKETCH - unchanged :: C:\arduino-1.6.12\hardware\teensy\avr\libraries\Audio\example s\MemoryAndCpuUsage
That SDFAT I think is the BETA_T_3.6 thread version.

IDE 1.6.11::

C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:25:57: error: 'void (* SdFile::dateTime_)(uint16_t*, uint16_t*)' is not a static member of 'class SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:33:28: error: no 'uint8_t SdFile::addCluster()' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:46:35: error: no 'uint8_t SdFile::addDirCluster()' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:61:44: error: no 'dir_t* SdFile::cacheDirEntry(uint8_t)' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:74:27: error: no 'uint8_t SdFile::close()' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:91:71: error: no 'uint8_t SdFile::contiguousRange(uint32_t*, uint32_t*)' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:130:44: error: no 'uint8_t SdFile::createContiguous(SdFile*, const char*, uint32_t)' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:158:36: error: no 'uint8_t SdFile::dirEntry(dir_t*)' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:178:50: error: no 'void SdFile::dirName(const dir_t&, char*)' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:201:46: error: no 'void SdFile::ls(uint8_t, uint8_t)' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:245:58: error: no 'uint8_t SdFile::make83Name(const char*, uint8_t*)' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:284:57: error: no 'uint8_t SdFile::makeDir(SdFile*, const char*)' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:384:74: error: no 'uint8_t SdFile::open(SdFile*, const char*, uint8_t)' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:476:68: error: no 'uint8_t SdFile::open(SdFile*, uint16_t, uint8_t)' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:502:64: error: no 'uint8_t SdFile::openCachedEntry(uint8_t, uint8_t)' member function declared in class 'SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:550:26: error: 'uint8_t SdFile::openRoot' is not a static member of 'class SdFile'
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:550:26: error: 'SdVolume' was not declared in this scope
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:550:36: error: 'vol' was not declared in this scope
C:\arduino_16_11\hardware\teensy\avr\libraries\SD\ utility\SdFile.cpp:550:41: error: expected ',' or ';' before '{' token
Multiple libraries were found for "SD.h"
Used: C:\arduino_16_11\hardware\teensy\avr\libraries\SD
Not used: C:\arduino_16_11\libraries\SD
Using library Audio at version 1.3 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\Aud io
Using library SPI at version 1.0 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\SPI
Using library SD at version 1.0.8 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\SD
Using library SerialFlash at version 0.4 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\Ser ialFlash
Using library Wire at version 1.0 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\Wir e
Using library SdFat at version 2016.7.24 in folder: i:\tcode\libraries\SdFat
Error compiling for board Teensy 3.6.

IDE 1.6.12::

Multiple libraries were found for "SD.h"
Used: C:\arduino-1.6.12\hardware\teensy\avr\libraries\SD
Not used: C:\arduino-1.6.12\libraries\SD
Using library Audio at version 1.3 in folder: C:\arduino-1.6.12\hardware\teensy\avr\libraries\Audio
Using library SPI at version 1.0 in folder: C:\arduino-1.6.12\hardware\teensy\avr\libraries\SPI
Using library SD at version 1.0.8 in folder: C:\arduino-1.6.12\hardware\teensy\avr\libraries\SD
Using library SerialFlash at version 0.4 in folder: C:\arduino-1.6.12\hardware\teensy\avr\libraries\SerialFlash
Using library Wire at version 1.0 in folder: C:\arduino-1.6.12\hardware\teensy\avr\libraries\Wire

defragster
09-23-2016, 05:37 AM
As far as TIMING - I removed the i:\tcode\libraries\SdFat - BOTH take 33 seconds to compile!
IDE 1.6.12 :: 33 seconds
IDE 1.6.11 :: 33 seconds

IDE 1.6.12 :: 33 seconds ::

Multiple libraries were found for "SD.h"
Used: C:\arduino_16_11\hardware\teensy\avr\libraries\SD
Not used: C:\arduino_16_11\libraries\SD
Using library Audio at version 1.3 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\Aud io
Using library SPI at version 1.0 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\SPI
Using library SD at version 1.0.8 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\SD
Using library SerialFlash at version 0.4 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\Ser ialFlash
Using library Wire at version 1.0 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\Wir e

IDE 1.6.11 :: 33 seconds ::

Multiple libraries were found for "SD.h"
Used: C:\arduino_16_11\hardware\teensy\avr\libraries\SD
Not used: C:\arduino_16_11\libraries\SD
Using library Audio at version 1.3 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\Aud io
Using library SPI at version 1.0 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\SPI
Using library SD at version 1.0.8 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\SD
Using library SerialFlash at version 0.4 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\Ser ialFlash
Using library Wire at version 1.0 in folder: C:\arduino_16_11\hardware\teensy\avr\libraries\Wir e

Epyon
09-23-2016, 10:11 AM
I haven't noticed any speed increases when compiling. I mostly use libraries like SDfat, Ethernet, ...

I did see a lot of improvement when upgrading from 1.6.8 to 1.6.11 though.

KurtE
09-23-2016, 01:58 PM
I did not notice much (any?) change in speed. Are we expecting it on the first compiles of the program or more on subsequent compiles?

v01den
09-23-2016, 06:50 PM
Can you look at Arduino > About to double check the version of Arduino and Teensyduino?

If no Teensyduino version is shown, seems likely Teensyduino didn't actually get installed to this copy of Arduino. Maybe try running the installer again? Perhaps double check the location of Arduino before installing. During install, the "?" button can show you how the installer is detecting Arduino. Maybe check that it's really seeing 1.6.12?

OK, problem solved. It was a faulty teensy 3.1. I have tested with other new teensy 3.2 and it works perfect. Thank you for your help :).

defragster
09-23-2016, 07:31 PM
FASTER 1.6.12 :: RECOMPILE TIMES - no code change :: MemoryAndCpuUsage
// #include <Audio.h> #include <Wire.h> #include <SPI.h> #include <SD.h> #include <SerialFlash.h>

4-5 seconds on 1.6.12 [ Win 10 pro - i7 from SSD - TD_1.31b1 ] - tested 3 times. :: Versus first compile 33 seconds noted above.

12-13 seconds on 1.6.11 [ Win 10 pro - i7 from SSD - TD_1.30 ] - tested 3 times (and repeated).

On a T_3.6 default compile with

Sketch uses 108,080 bytes (10%) of program storage space. Maximum is 1,048,576 bytes.
Global variables use 14,676 bytes (5%) of dynamic memory, leaving 247,468 bytes for local variables. Maximum is 262,144 bytes.


I did not notice much (any?) change in speed. Are we expecting it on the first compiles of the program or more on subsequent compiles?

opps - I didn't do that - the first compile would being exhaustive isn't a surprise - speed up would be on subsequent rebuilds.

PaulStoffregen
09-23-2016, 11:49 PM
subsequent compiles?

Subsequent compiles are supposed to be faster.

It's also supposed to do this for multiple windows. When you open another window, the first compile of that code might redo everything. But as long as you don't change the board, usb type, cpu speed or keyboard layout, each window is supposed to reuse compile work from its previous builds.

Arduino 1.6.12 appears to be the first version of Arduino to ever really get this fully working as it should. Maybe?

el_supremo
09-24-2016, 12:13 AM
I tried compiling the vocoder which has a fair bit of data and, of course, a fair bit of the audio library. I deleted one blank line in the .ino file so that it would force a recompile of that particular module. It is a wee bit faster the second time around.
First time compile 52 seconds
Second time 7 seconds.
In previous versions of the IDE, the second and subsequent compiles seemed to take almost as long as the first time.

Pete

bicycleguy
09-25-2016, 12:25 AM
On Mac OSX 10.9.5 (Mavericks) with Teensy 3.2

updated
from: Arduino from 1.6.6 Teensduino 1.12
to: 1.6.12 and 1.31-beta1

No problems at all, very clear on Teensy side.

Recompiles of 'Audio/Tutorial/Part_1_03Playing-Music' after changing only volume went from over 30 seconds to less than 1. Yaaaah

Opening second window with 'Audio/Tutorial/Part_1_04_Blink_while_playing', 1st compile about 11secs (because same library's ?), then switch between windows with same Teensy and recompile again less than 1 second !

GSR_proj
09-25-2016, 09:37 AM
Beta 1.31 works perfectly with arduino 1.6.12
I use

#include <SPI.h>
#include <ILI9341_t3.h>
#include <EEPROM.h>
#include <I2Cdev.h>
#include <i2c_t3.h>
#include <ADS1115.h>
#include <TimeLib.h>
#include <ADC.h>
#include <CapacitiveSensor.h>
#include <FreqCount.h>
#include <PID_v1.h>
#include <medianFilter.h>
in my project. To be noted I2Cdev lib support perfectly i2c_t3 lib and offers a large choice of devices/sensors libraries.

yasuski
09-26-2016, 04:34 AM
Please check the direct pin accessing is not accepted.

/*
Blink
*/

#define LED 13

#define LED_ON (PORTC |= (1<<5))
#define LED_OFF (PORTC &= ~(1<<5))

void setup() {
pinMode(LED, OUTPUT);
}

void loop() {
LED_ON; // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
LED_OFF; // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}

darioconcilio
09-26-2016, 11:33 AM
I'm using 1.6.12 with T 1.31 it works! (macOs Sierra)
it compiled correctly:
#include <ADXL345.h>
#include <L3G4200D.h>
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

this evening I'll try to use this complied....

Teensy 3.2

el_supremo
09-26-2016, 04:37 PM
@ yasuski
Which Teensy board are you using?

Pete

yasuski
09-26-2016, 05:17 PM
Hi Pete,

I tested the code with Teensy 3.2 with Arduino 1.6.12.

I found GPIOC_PSOR and GPIOC_PCOR works collect, but GPIOD_PDIR does not works .

el_supremo
09-26-2016, 07:11 PM
It's been a while since I played around with the pins at the hardware level. I can't remember if Paul had a macro which mapped what you are doing onto the Teensy's 3.2 hardware but the ARM chips have a different way of setting/clearing the port pins than the AVR chips do.
Changing your two macros to this will work:

#define LED_ON (CORE_PIN13_PORTSET = (1<<5))
#define LED_OFF (CORE_PIN13_PORTCLEAR = (1<<5))

Pete

yasuski
09-26-2016, 11:50 PM
Thank you, Pete.

The mocros works fine.

darioconcilio
09-28-2016, 04:16 AM
I corrected my post, T3.2

lbattraw
10-01-2016, 08:26 AM
Hi Paul, I've run into issues with Arduino 1.6.12 and TD 1.31-beta1 on Linux x64 when uploading code to a Teensy 3.6. It brings up the TD loader but the IDE errors out after a couple seconds with this (From the terminal the IDE was launched from):

Opening Teensy Loader...

Sketch uses 20,648 bytes (1%) of program storage space. Maximum is 1,048,576 bytes.
Global variables use 3,964 bytes (1%) of dynamic memory, leaving 258,180 bytes for local variables. Maximum is 262,144 bytes.
Opening Teensy Loader...
Unable find Teensy Loader. Is the Teensy Loader application running?
An error occurred while uploading the sketch
Opening Teensy Loader...
Error compiling for board Teensy 3.6.

The loader does appear but it doesn't actually do anything as far as programming the Teensy. If I click the button on the Teensy the loader will correctly program the Teensy with the updated code, it just seems to be a problem communicating between the IDE and loader. Any suggestions?

Thanks-
Larry

defragster
10-01-2016, 08:31 AM
Do you have any external serial monitor program on USB to the Teensy? If so that needs to be dropped when you compile to upload or the needed communications to the Teensy is blocked from the TeensyLoader and then a button press is required to drop to the bootloader.

The IDE Serial Monitor does this when it is used.

lbattraw
10-01-2016, 09:48 AM
Do you have any external serial monitor program on USB to the Teensy? If so that needs to be dropped when you compile to upload or the needed communications to the Teensy is blocked from the TeensyLoader and then a button press is required to drop to the bootloader.

The IDE Serial Monitor does this when it is used.


I assume you mean another program that opens the USB device like minicom; I am not running any other apps that open the serial port and I haven't modified the bootloader, this is just a copy of the Blink sketch I'm using to test with. Is there a particular programmer I should have selected? I just left it as the default: "AVRISP mkII", since there was no Teensy-specific option.

Ok. I've done a little more homework on this and it's a little different than what I was expecting. I should also add that I've moved from running the Arduino IDE remotely over the net (Using X11 remote display) to running it on a local system to avoid any weirdness that might cause.
From what I can tell a fresh, untouched Teensy 3.6 shows up as a raw HID device like /dev/usb/hiddev2 and I have made sure the udev rules were installed from the TD download page. The permissions are correct so opening the device as my user ID is ok. One issue seems to be that there's no way to tell the IDE what port to use (It's grayed out, I expect because there is no /dev/ttyACMx device available). There also seems to be some odd TCP behavior which triggers some messages about syn flooding from the kernel:

Oct 1 05:38:20 acebrix kernel: [27618.756793] TCP: request_sock_TCP: Possible SYN flooding on port 3149. Sending cookies. Check SNMP counters.


The IDE prints these messages:

Opening Teensy Loader...

Sketch uses 16,812 bytes (1%) of program storage space. Maximum is 1,048,576 bytes.
Global variables use 2,496 bytes (0%) of dynamic memory, leaving 259,648 bytes for local variables. Maximum is 262,144 bytes.
An error occurred while uploading the sketch
Error reading Teensy Loader status! (tpc)This error should never happen (when using Arduino). Please report this to paul@pjrc.com, hopefully with enough information to reproduce the problem so it can be understood and fixed!

I'm not clear on whether the kernel messages are also associated with some throttling/blocking behavior and I'll have to look into it further. At any rate it isn't quite a clear-cut as I had hoped. For reference these are the options in the IDE under Tools I have selected:

Board: Teensy 3.6
USB Type: No USB
Port <---- (disabled/grayed out)
CPU Speed: 180 MHz
Programmer: AVRISP mkII


My OS info:

Ubuntu 16.04.1 LTS
Linux acebrix 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

|Update|
I did some research on what causes the kernel messages and adjusted the kernel values:

net.core.somaxconn (to 2048)
net.ipv4.tcp_max_syn_backlog (to 2048)

This eliminates the messages about syn flooding from the kernel, however the error from TD about TCP problems remains and it doesn't have any effect on the core issue.
|/end update|


Thanks-
Larry

WMXZ
10-01-2016, 10:18 AM
I assume you mean another program that opens the USB device like minicom; I am not running any other apps that open the serial port and I haven't modified the bootloader, this is just a copy of the Blink sketch I'm using to test with. Is there a particular programmer I should have selected? I just left it as the default: "AVRISP mkII", since there was no Teensy-specific option.



I never worried about programmer, so I just ckecked my Arduino/TD setup and the programmer is set to ArduinoISP.
You could try this one

defragster
10-01-2016, 10:31 AM
AFAIK :: The programmer selection is ignored on Teensy as TeensyLoader (teensy.exe) is hardcoded during install.

Indeed 'another program that opens the USB device like minicom' is what I meant. Perhaps you should try that - supposing the Teensy is running a sketch that prints USB output and make sure you have "Tools /USB Type / Serial" selected - like this sketch here :: Can-t-communicate-with-Teensy-3-2-through-Teensyduino? (https://forum.pjrc.com/threads/31518-Can-t-communicate-with-Teensy-3-2-through-Teensyduino?p=88073&viewfull=1#post88073)

I'm on Windows - there may be something else in that post that might help you.

lbattraw
10-01-2016, 10:35 AM
I never worried about programmer, so I just ckecked my Arduino/TD setup and the programmer is set to ArduinoISP.
You could try this one

Thanks for the suggestion, unfortunately it looks like it ignores which programmer you're using and behaves the same way regardless.

defragster
10-01-2016, 10:37 AM
Larry: This is your problem. It takes USB coded into the Teensy sketch to respond to the Program request, with No USB the button is required to get its attention:



Board: Teensy 3.6
USB Type: No USB

lbattraw
10-01-2016, 10:45 AM
Larry: This is your problem. It takes USB coded into the Teensy sketch to respond to the Program request, with No USB the button is required to get its attention:

Ok, thanks for the info! Is there a particular value I should choose? I thought that was only for sketches that did specific things as a USB device.

defragster
10-01-2016, 10:51 AM
I typically use the "Serial" - it allows information/debugging spew to come out. That is the default. Unless you run out of room - not that it is large (though it does create some RAM buffers)- it is always safe to just have resident. If you don't send or receive anything it will sit idle, and if you do send or receive it is DMA controlled and faster than most any other interface on the Teensy with low overhead thanks to the DMA- except the new SDIO 4 bit parallel hardware to read/write from a fast enough card.

lbattraw
10-01-2016, 10:56 AM
I typically use the "Serial" - it allows information/debugging spew to come out. That is the default. Unless you run out of room - not that it is large - it is always safe to just have resident. If you don't send or receive anything it will sit idle, and if you do send or receive it is DMA controlled and faster than most any other interface on the Teensy with low overhead thanks to the DMA- except the new SDIO 4 bit parallel hardware to read/write from a fast enough card.


Ok, I went ahead and chose Serial and this allows it to present the ACM device /dev/ttyACM0 after programming, which allows me to select that as the port to talk to the Teensy with. Unfortunately it still doesn't help to get it to program the Teensy automatically, I get the "report this error message" every time I restart the IDE and try uploading the blink sketch:

Opening Teensy Loader...

Sketch uses 20,648 bytes (1%) of program storage space. Maximum is 1,048,576 bytes.
Global variables use 3,964 bytes (1%) of dynamic memory, leaving 258,180 bytes for local variables. Maximum is 262,144 bytes.
An error occurred while uploading the sketch
Error reading Teensy Loader status! (tpc)This error should never happen (when using Arduino). Please report this to paul@pjrc.com, hopefully with enough information to reproduce the problem so it can be understood and fixed!

KurtE
10-01-2016, 01:01 PM
Sorry you may have mentioned it, but did you install the udev rules as mentioned in the installing teensyduino page? http://www.pjrc.com/teensy/td_download.html

PaulStoffregen
10-01-2016, 01:24 PM
Which Linux distro is this?

Localhost networking is used between the utilities Arduino runs and the Teensy Loader program. This is the first time I've ever heard of it failing on Linux. We get this sometimes with zonealarm on Windows, where it prevents local host communication.

Teensy Losder has a Verbose Info window under its help menu. Try looking at that. It should print info about the requests coming from Arduino.

Maybe try on Ubuntu (the only Linux which I actually test and support), or use Mac or Windows for comparison. If you can see a working setup, you'll get a good idea of what that verbose info is supposed to be when things work.

I'm really curious what's wrong on this Linux system. Usually Linux problems are things like missing libs and udev rules.

lbattraw
10-02-2016, 09:38 AM
Hi Paul, I'm actually running Ubuntu 16.04.1 LTS (x86-64), so that shouldn't be an issue. The Teensy loader freezes up when it's started from the Arduino IDE; if I click the button on the Teensy it will go through the steps of programming it, but it doesn't respond to keyboard/mouse input. I was just playing around with it and it seems to buffer the keys/clicks until it programs the Teensy, where it will then process them before going back into that frozen, unresponsive state. After using the Teensy button to force it to reprogram the same file over and over I managed to get the logs saved to a file, which I have attached, hope that may help.

I've used other Teensy 3.1 boards before so it isn't so much a new environment, it just doesn't work currently. I've previously installed your udev rules and don't see anything that would tend to point towards missing libraries/dependencies.

|Update|
I've tried launching the loader without the Arduino IDE and it seems to be acting the same way-- by default when launched it freezes and doesn't respond to keys/clicks. Clicking the button on the Teensy "wakes" it up and it becomes responsive until an action is selected. I've included a second log from the console output that I've annotated to show what happens at what point.

I've also noticed a rather odd behavior that occurs while the loader is running: it will suddenly grab focus and acts like I'm trying to move it (a 4-way arrow mouse pointer appears). This happens every couple minutes but I'm not sure what's going on since no messages are logged-- very strange. I'm using KDE as my desktop by the way; I tried it with MATE and the behavior is identical.



Thanks-
Larry

PaulStoffregen
10-02-2016, 02:40 PM
Any chance you could try it with the default unity desktop? Or with gnome.

Honestly, I have never tested it (or any software I've written) with KDE.

jimmayhugh
10-02-2016, 05:01 PM
Just FYI, I'm running Debian 8 x64 with the MATE (Gnome 2) desktop with no issues.

PaulStoffregen
10-03-2016, 12:53 PM
When you say the software is unresponsive to clicks, can you be more specific about exactly what you're clicking?

Most of the time, the toolbar icons are disabled, so only a coulpe places are supposed to be responsive under most normal conditions. The new file icon (a document icon with purple hue) is always supposed to be enabled. When you click it, a file open dialog is supposed to appear, to let you open a different hex file. Normally with Arduino this is never needed, since Arduino automatically tells it to open the most recently compiled file.

Anyway, the point is to establish if the gui really is frozen, or if it merely appears that way because most of the controls are not enabled when no Teensy is connected *and* in programming mode.

yasuski
10-03-2016, 06:15 PM
I am learning about how to use the FTM. Unfortunately, I could not find the way to capturing
the counter value from FTM0_CH0/CH1. The counter itself works correct, but the value of
FTM0_C0V/C1V are always zero.

Is there anybody konw how to use the ALT4 pins in the correct way?


/* FTM Capture Test */

#define LED 13 // LED on D13
#define LED_ON (CORE_PIN13_PORTSET = (1<<5))
#define LED_OFF (CORE_PIN13_PORTCLEAR = (1<<5))

#define buttonPin01 5 // Button Pin on D5
#define buttonState (CORE_PIN5_PINREG & (1<<7))
#define buttonMask (CORE_PIN5_BITMASK = (1<<7))

#define statePin01 22 //
#define statePin02 23 //
#define PC_STATE1 (CORE_PIN22_PINREG & (1<<1))
#define PC_STATE2 (CORE_PIN23_PINREG & (1<<2))

uint8_t state1 = 0;
volatile int state = LOW;
uint16_t readCount1 = 0;
uint16_t readCount2 = 0;

void setup() {
FTM0_FILTER = 0x07;
FTM0_MODE = 0x05;

FTM0_SC = 0x00; // Set zero
FTM0_CNT = 0x0000; // Reset the count to zero
FTM0_MOD = 0xFFFF; // max modulus = 65535
FTM0_SC = 0x0A; // TOF=0 TOIE=0 CPWMS=0 CLKS=01 PS=010 (divide by 4)
FTM0_CNTIN = 0;

FTM0_C0SC = 0x48; // CHF=0 CHIE=1 MSB=0 MSA=0 ELSB=1 (input capture) ELSA=0 DMA=0
FTM0_C1SC = 0x48; // CHF=0 CHIE=0 MSB=0 MSA=0 ELSB=1 (input capture) ELSA=0 DMA=0

NVIC_ENABLE_IRQ(IRQ_FTM0);

CORE_PIN22_CONFIG = PORT_PCR_MUX(4);
CORE_PIN23_CONFIG = PORT_PCR_MUX(4);

Serial.begin(115200);

pinMode(LED, OUTPUT);
pinMode(buttonPin01, INPUT_PULLDOWN);
pinMode(statePin01, INPUT_PULLDOWN);

attachInterrupt(buttonPin01, blink, HIGH);
attachInterrupt(statePin01, count, RISING);
}

void loop() {
state1 = buttonState;
if(state1 == LOW) {LED_OFF;}
else {LED_ON;};
}

void blink() {
LED_ON ; // turn the LED on (HIGH is the voltage level)
delay(100); // wait for a second
LED_OFF ; // turn the LED off by making the voltage LOW
delay(100); // wait for a second

readCount2 = FTM0_C1V;
Serial.println(readCount2);
}

void count(){
LED_ON ; // turn the LED on (HIGH is the voltage level)
delay(100); // wait for a second
LED_OFF ; // turn the LED off by making the voltage LOW
delay(100); // wait for a second
readCount1 = FTM0_CNT;
Serial.println(readCount1);
}

Frank B
10-03-2016, 06:41 PM
Maybe this helps ?: https://github.com/FrankBoesing/FastIR

defragster
10-03-2016, 06:57 PM
Cool - does it work on K66 and K64?

#if (!defined(FastIR_h)) && (defined(__MK20DX128__) || defined(__MK20DX256__))

Frank B
10-03-2016, 06:58 PM
Ooops.. it's so old.. did not think of it :)

yasuski
10-03-2016, 07:02 PM
Thanks Frank,

but addressing 0x410 does not works.

Frank B
10-03-2016, 07:15 PM
hm, looks like i have to review the code .. :-) but the 0x410 has nothing to do with your timer ?!? that's for the interrupt..which reads the timer-value.
Anyway, it's better to start a new thread instead of hijacking this one.

Edit:
Uhh.. really.. that needs to be repaired.. NEVER read your own code after two years.. I wonder why it works .)

tni
10-03-2016, 07:28 PM
I am learning about how to use the FTM. Unfortunately, I could not find the way to capturing the counter value from FTM0_CH0/CH1. The counter itself works correct, but the value of
FTM0_C0V/C1V are always zero.
Your pin numbers and ALT are messed up. E.g, FTM0_CH0 is Teensy pin 20, Kinetis D5 package pin 25; ALT3 (not 4). There are settings macros that you should use (kinetis.h). E.g. FTM_SC_CLKS() for clock source and FTM_SC_PS() for prescale factor; flag values: FTM_CSC_CHIE for Channel Interrupt Enable.

Edit:
BTW, The ALT configuration is in the datasheet: "8.1 K20 Signal Multiplexing and Pin Assignments".

Edit2:
Never mind, I forgot that FTM0 has multiple pin configs.

Frank B
10-03-2016, 08:05 PM
Never mind: Me too.. I've lost count on the bits :) Everything is ok with my old code :)
Yasuki: Sorry, the 0x410 was not for the interrupts .)


@Defragster: I've updated it (https://github.com/FrankBoesing/FastIR)

tni
10-03-2016, 08:52 PM
@yasuski:
doing things like this:


CORE_PIN22_CONFIG = PORT_PCR_MUX(4);
...
pinMode(statePin01, INPUT_PULLDOWN);

doesn't work. pinMode overwrites the MUX setting. The rest of your config works for me with FTM0_CH0 (pin 13 connected to pin 22).

Experimentalist
10-04-2016, 10:07 AM
Just recompiled one of my largest projects against this and all is working. Has amongst others the following.

#include <SPI.h>
#include <RA8875.h>
#include <SdFat.h>
#include <Wire.h>
#include <FT5x06.h>
#include <EEPROM.h>
#include <AES.h>

yasuski
10-04-2016, 03:14 PM
Thanks for the replys.

I feel selecting the attatchInterrupt might be the easier way for getting the result. (I cannot get the data from FTM0_C0V still)

Anyway, I am trying to relocate the Arduino sketch "open.theremin" to Teensy3.2.
The original sketch is here (http://www.gaudi.ch/OpenTheremin/index.php?option=com_content&view=article&id=109&Itemid=99):

The led blink cord is the research work for getting the knowledge about the hardware.

tni
10-04-2016, 03:53 PM
Thanks for the replys.

I feel selecting the attatchInterrupt might be the easier way for getting the result. (I cannot get the data from FTM0_C0V still)
Here is a bare bones sketch that's working for FTM0_CH0. Pin 13 is connected to pin 22.


#define LED 13 // LED on D13

void setup() {
FTM0_FILTER = 0x07;
FTM0_MODE = 0x05;

FTM0_SC = 0x00; // Set zero
FTM0_CNT = 0x0000; // Reset the count to zero
FTM0_MOD = 0xFFFF; // max modulus = 65535
FTM0_SC = 0x0A; // TOF=0 TOIE=0 CPWMS=0 CLKS=01 PS=010 (divide by 4)
FTM0_CNTIN = 0;
FTM0_C0SC = 0x48; // CHF=0 CHIE=1 MSB=0 MSA=0 ELSB=1 (input capture) ELSA=0 DMA=0
CORE_PIN22_CONFIG = PORT_PCR_MUX(4);

Serial.begin(115200);
pinMode(LED, OUTPUT);
delay(2000);
}

void loop() {
digitalWriteFast(LED, HIGH);
delay(100);
digitalWriteFast(LED, LOW);
delay(100);
Serial.println(FTM0_C0V);
}

The only issue with using interrupts is that they may be disabled for a while, so you can potentially get inaccurate results. You may have variable latency from the pin change to your interrupt getting executed. If your code is the only thing running, that's not a big issue, but if you have some library doing things in background...

yasuski
10-04-2016, 06:45 PM
Thank you very much for your help, tni.

I found the input pin need the full swing voltage for sensing the signal edge.
This is a reason why the pin needs the pull down. On the other hand,
it means the data acquisitions from attatchInturrupt would be the incorrect.

tni
10-04-2016, 08:28 PM
Thank you very much for your help, tni.

I found the input pin need the full swing voltage for sensing the signal edge.
This is a reason why the pin needs the pull down. On the other hand,
it means the data acquisitions from attatchInturrupt would be the incorrect.
Teensy has a very fast analog comparator built in, "Chapter 32 Comparator" in the K20 manual. That can be used as FTM input, there is some code here (https://forum.pjrc.com/threads/30822-Teensy-3-1-and-Flextimer(s)-Counting-external-pulses-accurately?p=116512&viewfull=1#post116512) or it can trigger interrupts as well.

yasuski
10-05-2016, 06:14 AM
I will read the Chapter 32.

Anyway, The reason why I use attatchInterrupt is that Teensyduino 1.31 does not accept ISR vector interrupts like this.

ISR( PC_STATE1_vect) {
FTM0Count01 = FTM0_C0V;
}

IDE show me the alert "expected constructor, destructor, or type conversion before '(' token "

randomvibe
10-05-2016, 07:57 AM
Tested my IMU project with a DDS signal to drive a stepper motor using a Teensy 3.2 on Arduino-IDE 1.6.12 with Teensy Loader 1.31-beta1. All is working normally with the following headers. So far my transition from the Arduino Due has been a positive experience.



#include <math.h>
#include "C:\Programs\arduino-1.6.12\libraries\Eigen329\Eigen329.h"
using namespace Eigen;

#include <SPI.h>
#include "ILI9341_t3.h"


The program also uses two IntervalTimer objects: one for the overall control system sampled at 100hz, and another for the DDS function sampled at 65,536hz.

The Eigen library is used for my Extended Kalman filter. The #include needs the full path, otherwise it does not work. This was not an issue on the 1.6.8 Arduino-IDE (although 1.6.8 had other problems with Eigen).

Now I need to check the Encoder library as soon as I put in the hardware. Then I'll swap in my newly arrived Teensy 3.6.

KurtE
10-05-2016, 01:29 PM
Looks interesting...

Full path? My guess is you have another version of Eigen329 library, probably some place like: <sketch folder>/libraries. The way it chooses which one when there are duplicate libraries has changed with recent copies of Arduino. However in addition, the compiler now will often tell you there are two copies and which one it chose.

madmattd
10-07-2016, 12:46 PM
I'm having an issue getting this version (and v.1.30 final in fact) installed fully. My 3.5 and 3.6 boards arrived this week and last night I went to update Teensyduino so I could at least get them running in my system so they are ready when I have time to play at some point. I've had older versions of Teensyduino installed just fine, I think 1.28 or 1.29 was what was there. Ran the v1.30 install off http://pjrc.com/teensy/td_download.html. The install goes fine from all appearances, but there is no option for the 3.5 or 3.6 in Tools->Board. Same result for this 1.31beta. I looked around in the teensy cores folder and I see some header files for the K64 and K66, but the boards.txt file makes no mention of the new boards. I'm sure it is something stupid, it's been a little while since I did some playing with my Arduino toys? OS is Win10, with Arduino 1.6.5r5 (maybe the time has come to update finally?). I just got the same behavior on another computer with the same OS and Arduino IDE so I'm betting its just me.

PaulStoffregen
10-07-2016, 01:11 PM
The install goes fine from all appearances, but there is no option for the 3.5 or 3.6 in Tools->Board.

Any chance you might have more than one copy of Arduino on your computer?

madmattd
10-07-2016, 01:33 PM
Any chance you might have more than one copy of Arduino on your computer?

I shouldn't, I use the installer and not a zip/standalone setup, and any updates go to the same location (plus I've updated Teensyduino a couple times on both these installs without an IDE change). A drive-wide search for arduino.exe only turned up the expected one location, so I'd say not.

The installer auto-selected to writing to the correct folder (C:\Program Files(x86)\Arduino), and in C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3, I see .ld files for both the mk64 and mk66, which suggests to me things are going to the right spot?

The boards.txt file 2 levels up (hardware\teensy\avr) does not have the 3.5, 3.6 listed, it looks like a pre-3.5/3.6 file though I haven't done a full compare. I've attached this file in case it helps (I'm guessing not though), it did get a new modified date based on when I ran the installation of the new Teensyduino.

PaulStoffregen
10-07-2016, 01:47 PM
If you use Help > About in Arduino, what versions does it say?

madmattd
10-07-2016, 02:00 PM
If you use Help > About in Arduino, what versions does it say?

I have 2 machines I've been trying this on, I only have access to one at the moment, and I've only tried the "final" 1.30 off the main PJRC site on it. It reports Arduino 1.6.5, Teensyduino 1.30. I had also tried the 1.31beta1 on my machine at home last night (after the 1.30 had this same issue), and that was showing Teensyduino 1.31beta1 as expected. Both exhibit the same behavior. I'm happy to ignore one of them completely for debugging this.

randomvibe
10-08-2016, 07:46 AM
My guess is you have another version of Eigen329 library, probably some place like: <sketch folder>/libraries.

That's impossible. I started with a clean slate: Arduino-1.6.12, Teenyduino 1.31 Beta, and a fresh download from the Eigen website.

The problem is that Eigen's "Array" file clashes with gcc-4.8.4's "array" file. Here's the compile error without the full path:


C:\Programs\arduino-1.6.12\libraries\Eigen329/array:8:4: error: #error The Eigen/Array header does no longer exist in Eigen3. All that functionality has moved to Eigen/Core.

#error The Eigen/Array header does no longer exist in Eigen3. All that functionality has moved to Eigen/Core.
^
Error compiling for board Teensy 3.2 / 3.1.


This error happens whether I compile for the Teensy 3.2 or Arduino Due, so it's an IDE problem. It works in Arduino-1.6.8, but not 1.6.10 and above.

defragster
10-08-2016, 08:02 AM
Not sure of the OS and actual folder structure? Is that your sketchbook/libraries folder inside the Arduino folder directory? Or a private library in the Arduino tree?

If so it should be caught - but I gave Paul a day of grief once doing that, so now I have I:\sketchbook\libraries where I put all my private libraries there.

May be reading my history into your problem - but the path looks funny as shown "without the full path"?

madmattd
10-12-2016, 01:30 AM
Well, after being away for the last few days, I was able to get back to my installation issue. I still could not get my existing installs to get an out-of-the-box install of Teensyduino working for the 3.5/3.6, but I blew out my full install on one computer, installed 1.6.12, TD1.31b1, and everything is working fine out of the gate. I'm going to try putting the boards.txt file from this working install into the broken install and see if everything seems to work there too with just that one file before just doing the same clean-up on that one.

defragster
10-12-2016, 01:38 AM
Installing Teensyduino 1.31b1 is the best way to have the correct boards.txt in place. You should never have to copy it manually. It may somehow be corrupted and result in a fix - but I'm not sure how. The problem is likely larger and a fresh copy of the IDE first may be needed.

madmattd
10-12-2016, 01:46 AM
Installing Teensyduino 1.31b1 is the best way to have the correct boards.txt in place. You should never have to copy it manually. It may somehow be corrupted and result in a fix - but I'm not sure how. The problem is likely larger and a fresh copy of the IDE first may be needed.

If you skim through my prior posts on this (perhaps you already did), I did just that (installed Teensyduino on top of the existing install of Arduino and Teensydunio) and seemed to have everything BUT the correct boards.txt in place afterwards. On 3 different computers in fact (all with the same OS and IDE version mind you). So I did the fresh copy thing and migrated to the latest version while I was at it, as things seem to have settled down after the 1.6.6-1.6.8 launch issues I recall reading about. I've not noticed issues updating Teensyduino on these computers before, though I only noticed this one by the absence of the 3.5/3.6 listings. I think my first install was right around when the LC came out, so I may have been having trouble all along and not known it.

defragster
10-12-2016, 02:07 AM
I got some idea you had redone TD - that's why I added reinstall IDE. I only ever unzip the IDE to a fresh directory anymore - When I started Feb 2015 the IDE jumps with early 1.6x gave me fits otherwise. I picked up 1.6.12 after giving it a couple days ( having skipped 1.6.11 ) - and it is working well for me.

The other thing I didn't write was making sure NOTHING is active IDE or Teensy.exe - maybe a restart of the computer before installs. Orphaned things usually abort the install - but you may have an odd case. And nothing changed while the IDE is active will be seen by the IDE until it restarts..

I've not seen your issue in my 1.5 years with the IDE going 1.6.0 to 1.6.12 and all the Teensyduino updates that went with them - including getting the K66 and K64 beta boards back to June.

The only thing I've seen documented hitting others oddly was ANTIVIRUS - not sure how that would hit boards.txt alone though.

dkryder
10-12-2016, 06:53 AM
can the version info please be added to the filename? so that instead of teenysduinoinstall.exe it becomes teensyduino1.31beta.exe or something similar? it would be great going forward to be able to identify the various versions of file by the filename. so if you have a archive listing it would look like [for example]
teensyduino1.28.exe
teensyduino1.29.exe
teensyduino1.30.exe
teensyduino1.31beta.exe

instead of,

teensyduinoinstall.exe
teensyduinoinstall.exe
teensyduinoinstall.exe
teensyduinoinstall.exe
teensyduinoinstall.exe
teensyduinoinstall.exe

alexandros
10-12-2016, 12:35 PM
This might be a bit obvious, but on my Debian Jessie machine, I'm asked which application do I want to open the TeensyduinoInstaller with... So, what should I choose? Double clicking on the icon won't do..

MichaelMeissner
10-12-2016, 12:50 PM
The Teensydunio installer is an executable ELF image. After you download it, from a shell prompt, change the permissions to include execution and execute it (the $ is the standard bash prompt if you haven't set the PS1 environment variable):



$ chmod +x <file>
$ ./<file>

madmattd
10-12-2016, 12:52 PM
I got some idea you had redone TD - that's why I added reinstall IDE. I only ever unzip the IDE to a fresh directory anymore - When I started Feb 2015 the IDE jumps with early 1.6x gave me fits otherwise. I picked up 1.6.12 after giving it a couple days ( having skipped 1.6.11 ) - and it is working well for me.

The other thing I didn't write was making sure NOTHING is active IDE or Teensy.exe - maybe a restart of the computer before installs. Orphaned things usually abort the install - but you may have an odd case. And nothing changed while the IDE is active will be seen by the IDE until it restarts..

I've not seen your issue in my 1.5 years with the IDE going 1.6.0 to 1.6.12 and all the Teensyduino updates that went with them - including getting the K66 and K64 beta boards back to June.

The only thing I've seen documented hitting others oddly was ANTIVIRUS - not sure how that would hit boards.txt alone though.

Yea, I remember the constant streams of posts about issues with early 1.6.x installations... I waited those out until things seemed to calm down and jumped from 1.0.6->1.6.5 and had no noticed issues (other than needing to update libraries), until now. And yes, I was doing the Teensyduino update without anything Arduino or Teensy running (double-checked processes even), did some reboots in there, forcing run as admin, etc etc. I never saw anything other than a success message, but nothing got it to work on the existing install. Ultimately, like you said, something must have needed cleaning up and a clean install of the IDE did that. It's not like it is even that much work, uninstall Arduino which takes Teensyduino with it, and for added measure I deleted everything but preferences.txt from the user/roaming/arduino15 folder. Install Arduino, install Teensyduino, and back in business.

I did try copying over the boards.txt file and I also did the same with the platform.txt as a document compare revealed some changes in paths (I did not check the core files). That of course got the newer Teensy options to appear in Arduino but I was unable to compile for a 3.6 board. I was going to rebuild this install anyway given that if 2 files didn't copy right, who knows what else didn't, but it was a curiosity check more than anything that perhaps could have given Paul a datapoint. The same uninstall/reinstall procedure worked fine. So obviously something is odd with my setup as it persisted across 3 computers, but I don't have anything set up strangely that I know of. I'll chalk this one up to Windows 10 being stupid, the fix was easy enough, so back to playing (and trying out the serialPlotter, which has been on the todo list)!

alexandros
10-12-2016, 01:45 PM
The Teensydunio installer is an executable ELF image. After you download it, from a shell prompt, change the permissions to include execution and execute it (the $ is the standard bash prompt if you haven't set the PS1 environment variable):



$ chmod +x <file>
$ ./<file>

Thanks! That did it..

KurtE
10-12-2016, 01:58 PM
This might be a bit obvious, but on my Debian Jessie machine, I'm asked which application do I want to open the TeensyduinoInstaller with... So, what should I choose? Double clicking on the icon won't do..

After downloading the app, you need to mark it as an executable.
I typically do this in a command line prompt using the chmod command (chmod +x Teensyduino...)

I believe you can probably also do it in the GUI using properties.

glasspusher
10-12-2016, 09:35 PM
Hi,

Just chiming in to say this works fine for me on macOS Sierra, Arduino 1.6.1. Thanks as always!

Oh- yes- Teensy 3.2

rjp
10-14-2016, 10:33 AM
just received 3.5 & 3.6 (yay) - installed the 1.31 beta on arduino 1.6.11, did some quick tests on existing project code and discovered the Snooze library has errors, so mentioning it here incase its not known.

the builtin examples will trigger it, eg: pushbutton_pullup_sleep.ino.

the tailend of the error message is


C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Snooze/utility/llwu.h:170:50: error: 'LLWU_F3' was not declared in this scope

uint32_t flag = ( LLWU_F1 | LLWU_F2<<8 | LLWU_F3<<16 );

^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Snooze/utility/llwu.h: In function 'void llwu_reset_enable()':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Snooze/utility/llwu.h:260:9: error: 'LLWU_RST' was not declared in this scope

LLWU_RST = 0x02;//LLWU_RST_LLRSTE_MASK;

manitou
10-14-2016, 11:30 AM
just received 3.5 & 3.6 (yay) - installed the 1.31 beta on arduino 1.6.11, did some quick tests on existing project code and discovered the Snooze library has errors, so mentioning it here incase its not known.


For T3.5/3.6 you need to use this version of Snooze
https://github.com/duff2013/Snooze_V6_Beta
and make sure the IDE is using that version of the library

rjp
10-14-2016, 11:34 AM
For T3.5/3.6 you need to use this version of Snooze
https://github.com/duff2013/Snooze_V6_Beta
and make sure the IDE is using that version of the library


brilliant, thank you very much - installing now.

Ray.E
10-16-2016, 11:04 PM
I am having an issue with the standard PassThroughStereo sketch using my new Teensy 3.6, Arduino 1.6.12 and Teensyduino 1.31-beta1 (and Audio Shield). No audio is passed through either to the headphones or Line-out.
On the other hand a sketch I wrote a while back that passes through the same audio via the record and output queue functions in the Audio library works fine, so the hardware path seems good.
The standard PassThroughUSB sketch also works.

Connected to the original Teensy 3.2/Audioshield and recompiled for the 3.2, the standard PassThroughStereo sketch works fine.

Anybody else seeing this?

System is Mac OSX 10.11.6

el_supremo
10-16-2016, 11:25 PM
I reported about having a problem with the microphone in the K66 beta thread quite a while back and then forgot about it. The first message was #936 on page 38 - last message was #957 on the next page.
I'll try to check it out again in the next day or so.
Pete

Ray.E
10-17-2016, 03:23 AM
Thanks Pete. It's not that the Line-in doesn't work at all, it just seems to be not connecting through to outputs when the connection is only made through the patchcord system as a continuous stream, without involving the sktech itself in the transfer. It feeds a queue object in a sketch just fine.
Thanks again.

Paraglider
10-19-2016, 12:45 PM
There is an error message when compiling the example eeprom_put for Teensy 3.2, compiled using Arduino 1.6.12 and Teensyduino 1.31 Beta #1 on Windos 7 x64:


C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\EEPROM/EEPROM.h: In instantiation of 'const T& EEPROMClass::put(int, const T&) [with T = float]':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\EEPROM \examples\eeprom_put\eeprom_put.ino:37:28: required from here

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\EEPROM/EEPROM.h:144:15: warning: variable 'e' set but not used [-Wunused-but-set-variable]

EEPtr e = idx;

^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\EEPROM/EEPROM.h: In instantiation of 'const T& EEPROMClass::put(int, const T&) [with T = MyObject]':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\EEPROM \examples\eeprom_put\eeprom_put.ino:52:36: required from here

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\EEPROM/EEPROM.h:144:15: warning: variable 'e' set but not used [-Wunused-but-set-variable]