PDA

View Full Version : Teensyduino 1.19 Release Candidate #1 Available



Paul
05-28-2014, 11:58 PM
Here is a first release candidate for Teensyduino 1.19:


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


Please give this a try and report any bugs. Try to include a sample program that reproduces the problem!


Here's a list of the changes since Teensyduino 1.18:


Add support for 72 MHz on Teensy 3.1
Fix relative positioning on Teensy 3.x USB mouse (now has hybrid relative+absolute)
Add more AVR emulation on Teensy 3.x: wdt.h, crc16.h, sleep.h, EMISK
Fix USB Serial break on Teensy3 (needed by some Labview applications)
Fix USB endpoint read with no data (thanks nox771)
Workaround for auto-reboot problems on Teensy 2.0 when using watchdog
Fix initialization of local static vars from non-const data on Teensy 3.x
Make all Teensy 3.1 HardwareSerial functions virtual (fixes issue with pointers to objects)
Add extra zero to USB serial number, works around a Macintosh CDC driver bug
Add Kinetis register definitions: DMA bits, VREF bit, ADC PGA
Fix IRQ_PRIORITY hard-coding in Serial3
Fix lockup in AVR emulation of SPI.setDataMode(SPI_MODE0)
Fix lockup in AVR emulation of TWBR when running at 24 MHz
Fix rare lockup in repeated Wire.begin() on Teensy 3.1
Update DS1307 library with workaround Arduino Due names.
Update Entropy library, now fully compatible with Teensy 3.x.
Add overclocking code (not enabled by default) for Teensy 3.x at 120, 144 & 168 MHz
Drop Teensy 1.0 support

PaulStoffregen
05-29-2014, 12:05 AM
Please be aware, using USB Serial on Windows will result in a new COM port number assigned.

The USB serial number code was changed to add an extra zero onto the end of the serial number, which works around a bug in all versions of Macintosh OS-X. Windows remembers the serial number and other info to keep the same COM port number for each board. Windows should reliably keep a COM port associated with each Teensy3 board, but it will be different between version 1.18 and 1.19.

Pedvide
05-29-2014, 01:11 PM
Very nice!

I made a mistake in the post about the DMA registers (http://forum.pjrc.com/threads/25829-Bug-DMA-macros-only-work-for-Teensy-3-0) about the Channel n Priority Register DMA_DCHPRIn.
In the manual for Teesny 3.1 it says "Address: 4000_8000h base + 100h offset + (1d i), where i=0d to 15d", so I assumed that i=0 corresponded to DMA_DCHPRI0 and i=x to DMA_DCHPRIx, I even pointed out that in Teensy 3.0 this was different.
Well, reading the DMA memory map I see that in fact the addresses are:

4000_8100 Channel n Priority Register (DMA_DCHPRI3) 8 R/W See section 21.3.16/414
4000_8101 Channel n Priority Register (DMA_DCHPRI2) 8 R/W See section 21.3.16/414
4000_8102 Channel n Priority Register (DMA_DCHPRI1) 8 R/W See section 21.3.16/414
4000_8103 Channel n Priority Register (DMA_DCHPRI0) 8 R/W See section 21.3.16/414
4000_8104 Channel n Priority Register (DMA_DCHPRI7) 8 R/W See section 21.3.16/414
4000_8105 Channel n Priority Register (DMA_DCHPRI6) 8 R/W See section 21.3.16/414
4000_8106 Channel n Priority Register (DMA_DCHPRI5) 8 R/W See section 21.3.16/414
4000_8107 Channel n Priority Register (DMA_DCHPRI4) 8 R/W See section 21.3.16/414
4000_8108 Channel n Priority Register (DMA_DCHPRI11) 8 R/W See section 21.3.16/414
4000_8109 Channel n Priority Register (DMA_DCHPRI10) 8 R/W See section 21.3.16/414
4000_810A Channel n Priority Register (DMA_DCHPRI9) 8 R/W See section 21.3.16/414
4000_810B Channel n Priority Register (DMA_DCHPRI8) 8 R/W See section 21.3.16/414
4000_810C Channel n Priority Register (DMA_DCHPRI15) 8 R/W See section 21.3.16/414
4000_810D Channel n Priority Register (DMA_DCHPRI14) 8 R/W See section 21.3.16/414
4000_810E Channel n Priority Register (DMA_DCHPRI13) 8 R/W See section 21.3.16/414
4000_810F Channel n Priority Register (DMA_DCHPRI12) 8 R/W See section 21.3.16/414

So the definitions in mk20dx128.h should be:


#define DMA_DCHPRI3 *(volatile uint8_t *)0x40008100 // Channel n Priority Register
#define DMA_DCHPRI2 *(volatile uint8_t *)0x40008101 // Channel n Priority Register
#define DMA_DCHPRI1 *(volatile uint8_t *)0x40008102 // Channel n Priority Register
#define DMA_DCHPRI0 *(volatile uint8_t *)0x40008103 // Channel n Priority Register
#define DMA_DCHPRI7 *(volatile uint8_t *)0x40008104 // Channel n Priority Register
#define DMA_DCHPRI6 *(volatile uint8_t *)0x40008105 // Channel n Priority Register
#define DMA_DCHPRI5 *(volatile uint8_t *)0x40008106 // Channel n Priority Register
#define DMA_DCHPRI4 *(volatile uint8_t *)0x40008107 // Channel n Priority Register
#define DMA_DCHPRI11 *(volatile uint8_t *)0x40008108 // Channel n Priority Register
#define DMA_DCHPRI10 *(volatile uint8_t *)0x40008109 // Channel n Priority Register
#define DMA_DCHPRI9 *(volatile uint8_t *)0x4000810A // Channel n Priority Register
#define DMA_DCHPRI8 *(volatile uint8_t *)0x4000810B // Channel n Priority Register
#define DMA_DCHPRI15 *(volatile uint8_t *)0x4000810C // Channel n Priority Register
#define DMA_DCHPRI14 *(volatile uint8_t *)0x4000810D // Channel n Priority Register
#define DMA_DCHPRI13 *(volatile uint8_t *)0x4000810E // Channel n Priority Register
#define DMA_DCHPRI12 *(volatile uint8_t *)0x4000810F // Channel n Priority Register

and

#define DMA_DCHPRI_CHPRI(n) ((uint8_t)(n & 15)<<0) // Channel Arbitration Priority

I see you haven't included the wrong ones, probably because you realized my mistake. Maybe you can include these in the next update.

Nantonos
05-29-2014, 02:15 PM
Yes, I noticed after verify and upload, Windows 7 installed new drivers (which is slow as it checks windows update first).

Installed this rc on top of Arduino 1.0.5-r2/Teensyduino 1.18 without problems. Tested the 72Mhz, briefly:


// benchmark code
// originally from http://arduino.cc/forum/index.php/topic,121568.60.html
// change integers to fixed sizes, and float to double, however:
// "Note, Arduino floating point uses 32-bit values for float, double,
// and long double, while I believe the Arm boards use 64 bit. This
// means the mantissa and exponent ranges are higher.
// http://forum.arduino.cc/index.php?topic=128675.msg968187#msg968187

// 8 byte doubles
// ==============
// time elapsed = 18287 micros (Teensy 3.1, 96 Mhz = 1.755)
// time elapsed = 19763 micros (Teensy 3.1, 72 Mhz = 1.422)
// time elapsed = 23350 micros (Teensy 3.1, 48 Mhz = 1.121)
// time elapsed = 18713 micros (Arduino Due, 84 Mhz = 1.572)
// time elapsed = 29504 micros (Teensy 3.0, 96 Mhz = 2.832)
// time elapsed = 31417 micros (Teensy 3.0, 48 Mhz = 1.508)

// 4 byte doubles
// ==============
// time elapsed = 48480 micros (Teensy ++ 2.0, 16 Mhz = 0.776)
// time elapsed = 48484 micros (Teensy 2, 16 Mhz = 0.776)
// time elapsed = 48500 micros (Arduino Uno, 16MHz = 0.776)
// time elapsed = 50116 micros (Arduino Mega 2560, 16 Mhz = 0.802)


double sinanswers[400];

uint32_t time1 = 0;
uint32_t time2 = 0;
void setup()
{
Serial.begin(57600); // USB is always 12 Mbit/sec
delay(3000);
Serial.println("Here");
delay(1000);
time1 = micros();
for (int16_t i = 0; i < 400; i++)
{
sinanswers[i] = sin(i);
}
time2 = micros();

uint32_t elapsed = time2 - time1;
for (int16_t i = 0; i < 400; i++)
{
Serial.print(sinanswers[i],8);
Serial.print(" ");
Serial.println(i);
}

Serial.print("time elapsed = ");
Serial.print(elapsed);
Serial.print(" micros");
Serial.println();
Serial.print("Double size = ");
Serial.print(sizeof(sinanswers[0]));
}

void loop()
{

}

john-mike
05-29-2014, 04:41 PM
168 MHz Seems to be working fine for me but if USB type is set to MIDI I get:
Is there something else I need to un-comment?



C:\Users\nigel\Dropbox\arduino\hardware\teensy\cor es\teensy3\usb_midi.c: In function 'usb_midi_write_packed':
C:\Users\nigel\Dropbox\arduino\hardware\teensy\cor es\teensy3\usb_midi.c:89:37: error: 'TX_TIMEOUT' undeclared (first use in this function)
C:\Users\nigel\Dropbox\arduino\hardware\teensy\cor es\teensy3\usb_midi.c:89:37: note: each undeclared identifier is reported only once for each function it appears in

PaulStoffregen
05-29-2014, 05:53 PM
168 MHz Seems to be working fine for me but if USB type is set to MIDI I get:


Opps, looks like I missed USB MIDI in the update for 72, 120, 144 & 168 MHz.

Fixed:
https://github.com/PaulStoffregen/cores/commit/d380bcf5f77999b0d0d49e31cdac96cad9a1cc35

PaulStoffregen
05-29-2014, 06:13 PM
// time elapsed = 18287 micros (Teensy 3.1, 96 Mhz) (8 bytes)
// time elapsed = 19763 micros (Teensy 3.1, 72 Mhz) (8 bytes)
// time elapsed = 23350 micros (Teensy 3.1, 48 Mhz) (8 bytes)


Thanks for posting this!

I just tried it at 120, 144 & 168 MHz. At the clock gets higher, the slow flash memory really becomes the limiting factor.