Teensyduino 1.31 Beta #1 Available

Status
Not open for further replies.
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 .)
 
Last edited:
yasuski said:
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.
Click to expand...
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.
 
Last edited:
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
 
Last edited:
@yasuski:
doing things like this:
Code: 
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).
 
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>
 
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:

The led blink cord is the research work for getting the knowledge about the hardware.
 
yasuski said:
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)
Click to expand...
Here is a bare bones sketch that's working for FTM0_CH0. Pin 13 is connected to pin 22.
Code: 
#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...
 
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.
 
yasuski said:
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.
Click to expand...
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 or it can trigger interrupts as well.
 
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 "
 
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.

Code: 
#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.
 
Last edited:
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.
 
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 said:
Any chance you might have more than one copy of Arduino on your computer?
Click to expand...

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.
 

Attachments

  • boards.txt
    26.7 KB · Views: 309
PaulStoffregen said:
If you use Help > About in Arduino, what versions does it say?
Click to expand...

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.
 
KurtE said:
My guess is you have another version of Eigen329 library, probably some place like: <sketch folder>/libraries.
Click to expand...

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:

Code: 
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.
 
Last edited:
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"?
 
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.
 
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.
 
defragster said:
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.
Click to expand...

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.
 
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.
 
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
 
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..
 
Last edited:
Status
Not open for further replies.
Back
Top