paulstoffregen/cores

Teensy Core Libraries for Arduino

Teensy 2.0, LC, 3.x, 4.x core libraries for Arduino.

The latest stable version of Teensy's core library is always available in the Teensyduino installer, at this page:

http://www.pjrc.com/teensy/td_download.html

cores's Issues

SPI struct naming

Instead of having KINETISK_SPI_t and KINETISL_SPI_t with only one of these ever defined in functional Teensy code, I suggest to just use KINETIS_SPI_t or to typedef it from one of the K and L variants.

teensy 3.1 elapsedMicros seems to have issues

Hi,

I am trying a very simple program with elapsedMicros(sending data at fixed intervals). However, I found it to be not working for short time intervals. I documented the problem(with code and screenshots) at here:
http://forum.pjrc.com/threads/26107-teensy-3-1-elapsedMicros-seems-to-have-bugs

I am wondering if you can take a look and provide some pointers.

Thanks,
Keith

teensy_post_compile and teensy_reboot ?

Hi,

The Makefile in directory teensy3 refers to teensy_post_compile and teensy_reboot
Where are they found ?
I'm on a platform (FreeBSD) that is not supported by teensyduino and have been trying to find the two files in some of your repositories - but no luck

Kind regards Uffe

Large increase in program memory for Teensy LC when using floats

teensy LC uses much more program space when using floats with respect to Teensy 3.x

See this post: https://forum.pjrc.com/threads/28684-Program-storage-space-in-Teensy-LC?p=73866&viewfull=1#post73866

USB Raw HID - NUM_ENDPOINTS

Apologies for the excessive upper casing in the issue title.

I'm in the process of trying to define a new USB Raw HID type with no SEREMU interface and I noticed the number of endpoints for USB_RAWHID is set to 6 where only 4 appear to be used. Is this an issue?

cores/teensy3/usb_desc.h

Line 255 in d1a6e77

#define NUM_ENDPOINTS 6

Porting advancetouchsensing to teensy3.x

https://github.com/shirish47/AdvancedTouchSensing
this can be an awesome idea to port this library to Teensy 3.1 with part of comparision being done in teensy3.x and not on processing.. I think this is possible as T3.x is fast and 32bit .. also it has a good sinwave generator using DAC. can someone suggest on this?

Overclock 120MHz

How do you want to handle F_BUS = 40MHz, in respect to SPIFIFO clock rates and the ADC resolution?
SPIFIFO: nice divisible freq's or get them close as possible to 24 and 48MHz bus speeds?

#elif  F_BUS == 40000000

#define HAS_SPIFIFO
#define SPI_CLOCK_20MHz   (SPI_CTAR_PBR(0) | SPI_CTAR_BR(0) | SPI_CTAR_DBR) //(40 / 2) * ((1+1)/2)  20 MHz
#define SPI_CLOCK_10MHz   (SPI_CTAR_PBR(1) | SPI_CTAR_BR(0)) //(40 / 2) * ((1+0)/2) 10 MHz
#define SPI_CLOCK_8MHz    (SPI_CTAR_PBR(2) | SPI_CTAR_BR(0)) //(40 / 5) * ((1+1)/2)
#define SPI_CLOCK_4MHz    (SPI_CTAR_PBR(2) | SPI_CTAR_BR(0)) //(40 / 5) * ((1+0)/2)

ADC: A little more complex, would this work from FrankBoesing port? They would be close 20, 10 and 5MHz

#if F_BUS == 48000000 | F_BUS == 40000000
  #define ADC_CFG1_6MHZ   ADC_CFG1_ADIV(2) + ADC_CFG1_ADICLK(1)
  #define ADC_CFG1_12MHZ  ADC_CFG1_ADIV(1) + ADC_CFG1_ADICLK(1)
  #define ADC_CFG1_24MHZ  ADC_CFG1_ADIV(0) + ADC_CFG1_ADICLK(1)

Non Teensy board recognized as Teensy USB Serial with USB-Hub

I noticed a very weird problem.

When I try to connect my HoodLoader via USB to an USB Hub it is recognized as Teensy Serial and the uploading via Arduino IDE doesnt work anymore (the veryfication fails but the sketch is uploaded correct). On a direct USB Port its recognized correct as 16u2.

Sometimes the CDC reset occurs and then the board isnt recognized at all anymore. If you replug it its still dead. Switching to a different usb hub port works well and then the 1st port works again.

What I tried:
I am using 1.6 rc1. I redownloaded a clean installation, maybe the teensy install on my other Arduino IDE messed something up, but the problem is still there.
I tried different Arduino boards and a HL2 firmware that worked on usb hubs. (16u2 and 32u2, leonardo hasnt this problem)
I tried different PIDs
This problem only occured after i installed the teensyduino with its drivers. And i have no clue how to uninstall them.
I havent tried a different usb hub, since I dont have another one here.

http://i.minus.com/iZH17ATOmfTg2.PNG

Teensy 3 usb_serial: Transmission ceases completely when receive buffer fills up.

It appears that while the receive buffer is full, the usb_serial driver will cease any transmission. Test case:

usb_init();
uint32_t count = 0;
while (1) {
    char buf[20];
    sprintf(buf, "%" PRIu32 "\n", count);
    usb_serial_write(buf, strlen(buf));
    count++;
}

This seemingly innocent program can be brought to a halt, as follows:

stty -F /dev/ttyACM0 raw -echo
cat /dev/ttyACM0
# In another terminal:
cat /dev/zero > /dev/ttyACM0

At this point, the stream of numbers stops, and there's no way to get the transmission to continue other than power cycling the board.

Empty interrupt.h in cores/teensy3/avr/interrupt.h

The inertrupt.h file in Teensy Core Libraries for Arduino in cores/teensy3/avr/interrupt.h is empty

Invalid assembly generated in delayMicroseconds for teensy lc

The instruction sub %0, #1 is not legal on armv6 unless the register is SP

subs has to be used instead it seems: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0432c/CHDCICDF.html

Distorted audio when using USB audio input

When using the teensy as a USB audio device I get distorted audio from both the DAC and using the audio shield after around 2 minutes of playing a song. Once the distortion starts it gets progressively worse until no audio can be heard.

Steps to reproduce

• Set up a Teensy so it can ouput audio, either by connecting a speaker/buzzer to the DAC pin or using the Audio Shield and headphones
• In the Arduino IDE set the Teensy to USB type Audio
• Load the PassThroughUSB example
• From your computer choose 'Teensy Audio' as the audio interface
• Play a song on your computer. Personally I use "DJs take control" by SL2.
• Listen to the track

Expected results

• The track plays with no distortion

Actual results

• After a few minutes distortion occurs and gets progressively worse until only glitches are heard

Test environment/equipment

• Teensy 3.1
• Audio Shield Rev B with headphones
• Mac OSX 10.11.5
• Teensy Audio library: latest from github
• Teensy core library: latest from github

My suspicion is that this issue is caused by some kind of clock drift or synchronisation problem. Perhaps there's a bug in usb_audio.cpp. I tried uncommenting various serial print statements in that file to debug further but have been unable to see any of those statements in the serial output - would welcome some advice on how to switch that on.

I originally thought this was an issue with the audio shield so a duplicate bug can be found here: PaulStoffregen/Audio#185

DMAChannel.h LC transferCount

in the following thread
https://forum.pjrc.com/threads/28439-Teensy-LC-Trying-to-Link-DMA-Channels
it suggests that shift to get byte-count in LC's transferCount() should be
CFG->DSR_BCR = len << n;

HardwareSerial always linked, even when Serial1, Serial2 & Serial3 never used

Compiling File > Examples > 01.Basics > Blink results in 4996 bytes of unnecessary code. Detailed analysis here:

https://groups.google.com/a/arduino.cc/d/msg/developers/1Lk5aCOEQ-M/Nm3noUD6D64J

Related issues Arduino has faced are here:

arduino/Arduino#1711

teensy 3.x sendRealTime() incorrect

The current sendRealTime() function does not work, easy to test with a very simple sketch and MIDI-OX.

See this thread for the fix, fully tested using MIDI-OX.

https://forum.pjrc.com/threads/28969-Audio-adapter-and-library-noob-frustration?p=98871&viewfull=1#post98871

need more weak symbols

pins_teensy.c
port[abcde]_isr should be prefixed with __attribute__((weak))
so that it can be overridden with other libraries/code in order to do groups of pins on an ISR together.
As an example, if I want to monitor port D bits 0, 1, 2, and 3 for a pin change, but don't care WHICH one changed, I can write code to do that, and output the entire nybble. This allows for the ability to do parallel signal analysis, much like a logic analyzer... which is exactly what I need to do.
There are possibly other use cases as well, such as monitoring a bit stream inputs for a bit-banged slave-mode SPI implementation.
I can think of many other uses as well, too numerous to list here.

[HELP] How to run program

Hi,

I'm using Teensy 2.0 / Teensy++ How to run program( exe, pdf etc.) from internal disk storage?
Are there examples?

Thanks..

Error using sscanf function

Using sccanf generates the following error:

/Applications/Arduino-1.0.6.app/Contents/Resources/Java/hardware/tools/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/4.7.2/../../../../arm-none-eabi/lib/thumb2/libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text+0x16): undefined reference to `_write'
collect2: error: ld returned 1 exit status

Open HalfKay Bootloader source

I'd like to kindly ask and discuss for opening the Teensy 2.0 USB HID HalfKay Bootloader source.
Since Teensy2.0 does not get much more updates and Teensy 3.x (and LC) is now the most up to date and fancy Teensy, you might consider to open the source for the halfkay bootloader for the avr product.

Pro

• People could recover their broken Teensy Bootloader (if they've overwritten it).
• The Bootloader can be used a reference to code a very small USB HID bootloader, similar to optiboot, but for HID. That's what open source is all about.

Con

• Chinese people can copy it without caring on copyrights

Any thoughts from Paul and the Community about that?

Compilation error using gcc-arm-embedded-4.9.3 in teensy3 using provided makefile without arduino

I'm trying to use my teensy 3.1 without Arduino on Linux. But I'm getting a compile error using gcc-arm-embedded-4.9.3. I'm running make inside the cores/teensy3 directory without arduino. Here's the compiler error output:

arm-none-eabi-g++ -std=gnu++0x -felide-constructors -fno-exceptions -fno-rtti -Wall -g -Os -mcpu=cortex-m4 -mthumb -MMD -DF_CPU=48000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH -DUSING_MAKEFILE -D__MK20DX256__ -DARDUINO=10600 -DTEENSYDUINO=121 -I.  -c -o Stream.o Stream.cpp
In file included from WProgram.h:14:0,
                 from Arduino.h:1,
                 from Stream.cpp:23:
avr_functions.h:97:104: error: 'char* utoa(unsigned int, char*, int)' was declared 'extern' and later 'static' [-fpermissive]
 static inline char * utoa(unsigned int val, char *buf, int radix) __attribute__((always_inline, unused));
                                                                                                        ^
In file included from /nix/store/a10h1v4iyw1m4kcxzqb0dgjzzkw42fm2-gcc-arm-embedded-4.9-2015q1-20150306/arm-none-eabi/include/stdlib.h:11:0,
                 from WProgram.h:4,
                 from Arduino.h:1,
                 from Stream.cpp:23:
/nix/store/a10h1v4iyw1m4kcxzqb0dgjzzkw42fm2-gcc-arm-embedded-4.9-2015q1-20150306/arm-none-eabi/include/stdlib.h:184:8: note: previous declaration of 'char* utoa(unsigned int, char*, int)'
 char * _EXFUN(utoa,(unsigned, char *, int));
        ^
In file included from WProgram.h:14:0,
                 from Arduino.h:1,
                 from Stream.cpp:23:
avr_functions.h:99:95: error: 'char* itoa(int, char*, int)' was declared 'extern' and later 'static' [-fpermissive]
 static inline char * itoa(int val, char *buf, int radix) __attribute__((always_inline, unused));
                                                                                               ^
In file included from /nix/store/a10h1v4iyw1m4kcxzqb0dgjzzkw42fm2-gcc-arm-embedded-4.9-2015q1-20150306/arm-none-eabi/include/stdlib.h:11:0,
                 from WProgram.h:4,
                 from Arduino.h:1,
                 from Stream.cpp:23:
/nix/store/a10h1v4iyw1m4kcxzqb0dgjzzkw42fm2-gcc-arm-embedded-4.9-2015q1-20150306/arm-none-eabi/include/stdlib.h:183:8: note: previous declaration of 'char* itoa(int, char*, int)'
 char * _EXFUN(itoa,(int, char *, int));
        ^
<builtin>: recipe for target 'Stream.o' failed
make: *** [Stream.o] Error 1

If I add -fpermissive to CPPFLAGS I get a linker error instead:

arm-none-eabi-gcc -Os -Wl,--gc-sections,--defsym=__rtc_localtime=0 --specs=nano.specs -mcpu=cortex-m4 -mthumb -Tmk20dx256.ld -o main.elf usb_m
erial3.o usb_dev.o usb_keyboard.o keylayouts.o usb_midi.o usb_joystick.o ser_print.o pins_teensy.o usb_rawhid.o nonstd.o eeprom.o usb_mem.o us
usb_desc.o serial1.o mk20dx128.o serial2.o analog.o math_helper.o touch.o usb_seremu.o usb_serial.o new.o HardwareSerial1.o DMAChannel.o Print
nst.o Stream.o IPAddress.o Tone.o AudioStream.o yield.o main.o usb_flightsim.o HardwareSerial3.o WString.o HardwareSerial2.o avr_emulation.o W
ntervalTimer.o -lm
Print.o: In function `utoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: multiple definition of `utoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: first defined here
Print.o: In function `itoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: multiple definition of `itoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: first defined here
usb_inst.o: In function `utoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: multiple definition of `utoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: first defined here
usb_inst.o: In function `itoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: multiple definition of `itoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: first defined here
Stream.o: In function `utoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: multiple definition of `utoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: first defined here
Stream.o: In function `itoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: multiple definition of `itoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: first defined here
IPAddress.o: In function `utoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: multiple definition of `utoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: first defined here
IPAddress.o: In function `itoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: multiple definition of `itoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: first defined here
Tone.o: In function `utoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: multiple definition of `utoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: first defined here
Tone.o: In function `itoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: multiple definition of `itoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: first defined here
AudioStream.o: In function `utoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: multiple definition of `utoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: first defined here
AudioStream.o: In function `itoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: multiple definition of `itoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: first defined here
yield.o: In function `utoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: multiple definition of `utoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: first defined here
yield.o: In function `itoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: multiple definition of `itoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: first defined here
main.o: In function `utoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: multiple definition of `utoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: first defined here
main.o: In function `itoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: multiple definition of `itoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: first defined here
HardwareSerial3.o: In function `utoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/HardwareSerial.h:174: multiple definition of `utoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: first defined here
HardwareSerial3.o: In function `itoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/HardwareSerial.h:175: multiple definition of `itoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: first defined here
WString.o: In function `utoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: multiple definition of `utoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: first defined here
WString.o: In function `itoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: multiple definition of `itoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: first defined here
HardwareSerial2.o: In function `utoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/HardwareSerial.h:174: multiple definition of `utoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:98: first defined here
HardwareSerial2.o: In function `itoa':
/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/HardwareSerial.h:175: multiple definition of `itoa'
HardwareSerial1.o:/home/zed/development/embedded_c/teensy3_test/tmp/teensy-template/cores/teensy3/avr_functions.h:100: first defined here
collect2: error: ld returned 1 exit status
Makefile:92: recipe for target 'main.elf' failed
make: *** [main.elf] Error 1

I can supply more information if needed!

usb_init() does not set initial endpoint configuration

Refering to this line, in multiple atmega files:
https://github.com/PaulStoffregen/cores/blob/master/usb_rawhid/usb.c#L279

I found that LUFA (and also other cores, and the datasheet as well!) say, that you should initialize the endpoint first (and not only inside the reset interrupt).

Lufa patched this here (only have a look at the endpoint init function, not the rest)
abcminiuser/lufa@d66a925

However I do not know if a host would not reset the device, how rare this is. The datsheet sais to do it like this though. @PaulStoffregen what do you think?

Another question:
Wouldnt it make sense to enable the EORSTE reset before attaching the device? This way you would not miss any interrupt, even though the time between the setting is very little. (Lufa does this, made sense to me)

Also applies to @limpkin s MooltiPass firmware.

kinetis.h TMPx_SC DMA flag not defined

There is a DMA bit in the LC TPMx_SC that is not in the teensy 3 FTMx_SC and no corresponding symbol in kinetis.h
need FTM_SC_DMA as 0x100

discussed in https://forum.pjrc.com/threads/28439-Teensy-LC-Trying-to-Link-DMA-Channels
and https://forum.pjrc.com/threads/27689-Teensy-LC-Beta-Testing?p=69176&viewfull=1#post69176

Bad 1.21+ file structure?

While trying to make Arduino-Makefile work with the latest Arduino.app + Teensyduino 1.21, I've encountered a few issues and shared my progress on this issue.

One of the contributors pointed out that the new directory layout used by teensyduino was odd:

teensyduino 1.21 (for 1.6.1) seems to use some very odd directory structure and boards.txt, doesn't even seem to match other 1.5+ implementations, and so doesn't work with the makefile.

Not sure what is the reference/"good" file layout/structure but was interested by your input on this issue.

Float-version of Print::printFloat is missing

We should add it to take advantage of the T3.6 FPU

SERIAL_PORT_MONITOR incorrect when no USB

teensy/cores/teensy3/pins_arduino.h...

#define SERIAL_PORT_MONITOR             Serial

This is all fine, but, should default to Serial1 when USB is disabled, and the other defines should change as well...

invalid assembly generated in nvic_execution_priority

This may be a false positive, I'm not sure if this code is ever executed.

The Teensy LC uses armv6-m, however the operands faultmask and basepri seen in nvic_execution_priority are only present in armv7-m see here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472l/chr1359125006491.html

LICENSE file

The licensing for this project is hard to read. Different files have different license headers and many files don't have a licensing header at all. That makes it hard to understand how to treat this code. (Also, some people have IP assignment agreements with their employers and need a clearer license before we can offer contributions) Could you put a LICENSE file at the top of the tree?

GCC 5.3 random()

Just installed GCC 5.3 and got the following error:

C:\Arduino\hardware\teensy\avr\cores\teensy3/WProgram.h:51:21: error: ambiguating new declaration of 'uint32_t random()'

uint32_t random(void);

                 ^

In file included from c:\arduino\hardware\tools\arm5\arm-none-eabi\include\stdlib.h:11:0,

             from C:\Arduino\hardware\teensy\avr\cores\teensy3/WProgram.h:4,

             from C:\Arduino\hardware\teensy\avr\cores\teensy3/Arduino.h:1,

             from f:\build4def553c7c5cc6638db6fb6a30be3b17.tmp\sketch\coremark.h:27,

             from f:\build4def553c7c5cc6638db6fb6a30be3b17.tmp\sketch\core_list_join.cpp:20:

c:\arduino\hardware\tools\arm5\arm-none-eabi\include\stdlib.h:231:6: note: old declaration 'long int random()'

long _EXFUN(random,(_VOID));

  ^

in analog.c enable VREF output channel for K64/K66

In analog_init() in analog.c, VREF_SC is set for teensy 3*, it needs to be set for K66 and K64 (use KINETISK?)

some discussion https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107457&viewfull=1#post107457

Possibility for non-blocking HardwareSerial?

I am looking at microcontroller options for a complex robotics project. From my understanding of the Teensy 3.1 core library, the serial read and write functions calls yield() to wait for transmission when the buffer is full, which subsequently busy-waits and does nothing. Is it possible to extend the function to return control to the user and potentially notify them via callback? Or even better, can the library be integrated with the FreeRTOS Teensy port and properly "yields" as in the RTOS sense? Thanks!

Teensy 3 usb_serial: Arduino dependency should be optional.

If usb_serial.h is included from C++ source, that file will attempt to define the Arduino Stream interface. This is not desirable in a non-Arduino C++ program. I suggest changing he __cplusplus condition there to ARDUINO (but I'm not sure that's what Arduino defines). It can be hacked around but it's a very dirty hack.

Be careful, only the ifdef for the C++ class should be changed, the ifdef for the extern C should stay as is.

Source for teensyduino utilitues "teensy_post_compile" and "teensy_reboot" ?

I'm sorry to bother you with yet another issue about this subject - but you closed the old issue (#29) before I could ask another question - hence this new issue

JFTR: old issue #29 (#29)

Source for teensyduino utilitues "teensy_post_compile" and "teensy_reboot" ?
Where can I find the source for the teensyduino utilitues "teensy_post_compile" and "teensy_reboot" ?

I've looked through the source repositories without any luck - what did I miss ?

Or are they closed source ?

Thanks in advance

/Uffe

Teensy 3 startup: Don't write watchdog configuration if the user provides an early hook.

Watchdog configuration can only be updated once in the unlock window, so if WDOG_STCTRLH is unconditionally written in the startup code, it's hard for the user to enable the watchdog. Therefore, only the default early hook should disable the watchdog. The user can then easily do his own watchdog configuration within his early hook, where the watchdog has been unlocked, but not had any of its configuration changed.

Additionally, add some nop's to satisfy the timing requirements demanded by the datasheet.

K66 I2C2 Kinetis.h pin def missing :: SIM_SCGC4_I2C2

For I2C2 support :: I can't easily pull as my tested source is the 1.29b3. This line needs value validation and when correct inserted at line 1169:

define SIM_SCGC4_I2C2 ((uint32_t)0x00000040) // I2C2 Clock Gate Control

cache setting

This gives a bit better performace:
FMC_PFB0CR &= ~( 0x10 | 0x4 );

It disables the Data-prefetch and Data Cache. This leaves more room for instructions in the cache (doubles it!).
Tried with a number of benchmarks and -O1

micros() can't be called from within an ISR

The micros function (and all functions that use it) will enable IRQs if used from within an ISR.

Teensy installer breaks Stino

Cross post from Stino issue. Not sure where the problem is:
Robot-Will/Stino#252

Uninstalling Teensy libs for the time being.

USB Serial.flush() doesn't truly wait for all buffered packets to complete transmission

Details here.

http://forum.pjrc.com/threads/26999-Serial-flush

Teensy 3 usb_serial: Please provide a non-blocking write function.

The current usb_serial_write has the sometimes undesirable behavior of waiting for the tx buffer to free up if needed. While it does have a maximum wait time, it can still be problematic. Please provide another function which is completely non-blocking or an argument that makes it non-blocking.

Second thing, usb_serial_write currently does not give any indication of how many bytes have been successfully transmitted. If there's a problem, in particular it times out waiting for tx buffer, it just returns -1.

These two behaviors make it impossible to implement a second send buffer in user code that feeds data into the usb_serial driver.

Wrong SET_ADDRESS implementation

Referring to:

cores/usb_serial/usb.c

Lines 441 to 446 in d5a1b97

	if (bRequest == SET_ADDRESS) {
	usb_send_in();
	usb_wait_in_ready();
	UDADDR = wValue | (1<<ADDEN);
	return;
	}

This also applies to all other files with this implementation.
You first have to set the address and then enable it and not all at once. It is clearly stated that this mechanism (like in the teensy code) is wrong.

The 32u4 Datasheet says (section 22.7, page 269)

The USB device address is set up according to the USB protocol:
• the USB device, after power-up, responds at address 0
• the host sends a SETUP command (SET_ADDRESS(addr)),
• the firmware handles this request, and records that address in UADD, but keep ADDEN
cleared,
• the USB device firmware sends an IN command of 0 bytes (IN 0 Zero Length Packet),
• then, the firmware can enable the USB device address by setting ADDEN. The only accepted
address by the controller is the one stored in UADD.
ADDEN and UADD shall not be written at the same time.
UADD contains the default address 00h after a power-up or USB reset.

A possible implementation (modified from LUFA) could look like this:

// 32u4 datasheet section 22.7
static void USB_Device_SetAddress(void)
{
  // Get address value
    uint8_t DeviceAddress = (USB_ControlRequest.wValue & 0x7F);

  // Record Address, keep ADDEN cleared
    //USB_Device_SetDeviceAddress(DeviceAddress);
  UDADDR = (UDADDR & (1 << ADDEN)) | (DeviceAddress & 0x7F);

  // TODO move upwards?
    Endpoint_ClearSETUP();

  // Send IN ZLP
    Endpoint_ClearStatusStage();

  // Wait for IN endpoint to get ready
    while (!(Endpoint_IsINReady()));

  // Enable USB device address
    //USB_Device_EnableDeviceAddress(DeviceAddress);
  UDADDR |= (1 << ADDEN);
}

Correct me if I am wrong

cc @limpkin (also applies to Mooltipass)

License missing on crc16.h

The file util/crc16.h in the teensy3 core is missing a license and copyright header. Looking at the repository-wide README, I didn't find any default license, it only refers to the comments in individual files.

I'd like to include this code into a library of mine, but cannot really do so without a proper license.

usb_rawhid_send() on teensy 3.x (multiple issues)

1: Even if the other end is alive, and ready to receive the data, packets are dropped.

2: If the host has not enumerated yet, the function still thinks the packet was sent.

Is there any way to ensure a packet is sent even if it means waiting forever?

teensy3/Makefile TOOLSPATH

on my ubuntu 14.04, using make, i get a permission denied because the definition of TOOLSPATH (line 44) has a comment at the end, and that introduces blanks after the path ? Removing the trailing comment fixed it for me

the Makefile could be extended to support K66/64

DMAChannel destinationCircular bug

I think there's a bug in the destinationCircular/sourceCircular functions for the Teensy 3.x.
The DMOD (or SMOD) is set to (31 - __builtin_clz(len)), but it should be (32 - __builtin_clz(len)). Otherwise it only fills half of the buffer before going back to the 1st element.
I've only tested it with destinationCircular, it works correctly if I call the function with 2*len instead.

PDB channel 1 for ADC1

The definitions for the registers for the PDB channel 1 that controls the ADC1 are missing kinetis.h
They are given in this old forum post (https://forum.pjrc.com/threads/25153-PDB0CH1-register-definitions) and I have checked that at least PDB0_CH1C1 is correct.

Provide a method to get the size of internal eeprom

The title says all :)

The Arduino-like define E2END does not tell the real size.

touch.c for K66

touchRead() hangs on K66. The K66 TSI logic/registers is different from teensy 3, additional logic is required in touch.c

LC pin mask problem in pulseIn() in pins_teensy.c

Like digitalRead(), pulseIn() needs to use a pin-mask for LC. discussions in
https://forum.pjrc.com/threads/24627-Read-RC-Reciever-with-Teensy-3

Use defined number of DMA channels in DMAChannel::init()

The number of available DMA channels is defined for each chip in kinetis.h as DMA_NUM_CHANNELS. This define should be used in DMAChannel.cpp::init(), line 20.

kinetis.h K66 RNG registers are wrong

problem and fix described at
https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107134&viewfull=1#post107134