Teensyduino 1.12 Released

[Paul]

Teensyduino 1.12 has been release. This is the first non-beta version to support Teensy 3.0.

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

For use without Arduino, see the sample makefile in hardware/teensy/cores/teensy3 after installing.

Several bugs were fixed since beta12: fixed Java exception at startup on Mac, fixed millis bug, added and fixed DMA register definitions, fixed delayMicroseconds(0), and fixed usb serial latency with 64 byte strings. A memory type "DMAMEM" was added, to allocate buffers in memory optimized for DMA transfers. The memory reserved for USB buffers was reduced. A boards.txt option "build.additionalobject" was added, allowing extra libraries to be linked.

Now that Teensy 3.0 support is "official" and no longer beta, my priority will shift more to documentation and Arduino libraries. Of course, development will continue, but especially documentation will become a much higher priority.

As always, please report any bugs. Try to include a sample program that reproduces the problem!

[virtualdave]

Hey Paul,
I seem to be having issues other reported elsewhere where I can't seem to get the "next" button to hilight using the Mac installer once I've pointed it to the Arduino.app folder (even navigating inside the folder). Any suggestions?
Thanks,
David

[Nantonos]

Congratulations on Teensy 3.0 going out of beta!

Are there any potential downsides to the reduction of USB buffer sizes?

[virtualdave]

Hey Paul,
I seem to be having issues other reported elsewhere where I can't seem to get the "next" button to hilight using the Mac installer once I've pointed it to the Arduino.app folder (even navigating inside the folder). Any suggestions?
Thanks,
David

Nevermind! Installing this over a fresh copy of Arduino works fine (as you suggested in another thread). Sorry for the noise!
David

[PaulStoffregen]

Are there any potential downsides to the reduction of USB buffer sizes?

Unlikely. In fact, the USB code is probably still reserving more memory than is really necessary.

If you'd like to experiment, you can set the number of buffers in usb_desc.h. Each USB Type has its own setting. The other parameter that matters is "TX_PACKET_LIMIT", which occurs separately in each of the interface types. The idea is to prevent a tight loop of Serial.print() from rapidly filling all available buffers. If memory is available, you can receive data very efficiently. The lower level USB code will properly deal with a shortage of memory, causing the PC to keep retrying until a buffer is available.

To keep things in perspective, Teensy 2.0 has a fixed 2 buffers for each endpoint. On AVR, there's dedicated buffer memory, so you can't configure things any other way (well, except for 1 buffer per endpoint). For USB Serial, the 2 data endpoints on AVR have 4 buffers. On Teensy 3.0, they can share 12 buffers (actually 10, since 2 will be allocated to the notification endpoint) and the transmit limit itself to 8 buffers. If you send a lot of data in 1 direction, the memory automatically gets used as needed. Being able to buffer several packets means you can more easily maintain good throughput, even if your code has some latency because it (or a library you're using) needs to do other work.

Of course, the actual performance you get in any specific application depends on many complex factors. If you have a need to move fairly large amounts of data (eg, over 200 kbytes/sec) in one or both directions, you might try fiddling with the number of buffers and transmit limits. The max is 31 packets. It's entirely possible you might find a case where adding more buffers helps?

On Teensy 3.0, the USB buffers are allocated in normal memory, so the downside to allocating more than you need is less memory available for your application.

[Bambu]

Thank you Paul!

[keithg]

Paul,

I use the New Liquid Crystal library and a PCF8574A to control a display. I hope it is not a mistake I made, but this code compiles and runs correctly on Beta 11+Arduino 1.0.3 but not with 1.12+Arduino 1.0.3. It compiles with no errors, but nothing displays on the LCD.
edit1: I am using a Teensy 3.0 for this project.
edit 2: I thought I was using beta 12, but it was actually beta 11. This is on Win7 64 bit.

The version of the library is 1.21 and is here:
https://bitbucket.org/fmalpartida/ne...stal/wiki/Home

#include <Wire.h> 
#include <LiquidCrystal_I2C.h>

#define I2C_ADDR    0x3f  // Sainsmart pin defs I2C Address for PCF8574A 
#define BACKLIGHT_PIN     3
#define En_pin  2
#define Rw_pin  1
#define Rs_pin  0
#define D4_pin  4
#define D5_pin  5
#define D6_pin  6
#define D7_pin  7
LiquidCrystal_I2C	lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin,BACKLIGHT_PIN,POSITIVE);


// Creat a set of new characters
const uint8_t charBitmap[][8] = {
   { 0xc, 0x12, 0x12, 0xc, 0, 0, 0, 0 },
   { 0x6, 0x9, 0x9, 0x6, 0, 0, 0, 0 },
   { 0x0, 0x6, 0x9, 0x9, 0x6, 0, 0, 0x0 },
   { 0x0, 0xc, 0x12, 0x12, 0xc, 0, 0, 0x0 },
   { 0x0, 0x0, 0xc, 0x12, 0x12, 0xc, 0, 0x0 },
   { 0x0, 0x0, 0x6, 0x9, 0x9, 0x6, 0, 0x0 },
   { 0x0, 0x0, 0x0, 0x6, 0x9, 0x9, 0x6, 0x0 },
   { 0x0, 0x0, 0x0, 0xc, 0x12, 0x12, 0xc, 0x0 }
   
};

void setup()
{
   int charBitmapSize = (sizeof(charBitmap ) / sizeof (charBitmap[0]));

  // Switch on the backlight
  pinMode ( BACKLIGHT_PIN, OUTPUT );
  digitalWrite ( BACKLIGHT_PIN, HIGH );
  
  lcd.begin(20,4);               // initialize the lcd 

   for ( int i = 0; i < charBitmapSize; i++ )
   {
      lcd.createChar ( i, (uint8_t *)charBitmap[i] );
   }

  lcd.home ();                   // go home
  lcd.print("Hello, ARDUINO ");  
  lcd.setCursor ( 0, 1 );        // go to the next line
  lcd.print (" FORUM - fm   ");
  delay ( 1000 );
}

void loop()
{
   lcd.home ();
   // Do a little animation by writing to the same location
   for ( int i = 0; i < 4; i++ )
   {
      for ( int j = 0; j < 20; j++ )
      {
         lcd.print (char(random(7)));
      }
      lcd.setCursor ( 0, 1 );
   }
   delay (200);
}

Keith

[PaulStoffregen]

but this code compiles and runs correctly on Beta 11+Arduino 1.0.3 but not with 1.12+Arduino 1.0.3. It compiles with no errors, but nothing displays on the LCD.
edit1: I am using a Teensy 3.0 for this project.
edit 2: I thought I was using beta 12, but it was actually beta 11. This is on Win7 64 bit.

Do you have physical pullup resistors on SDA & SCL?

The older versions attempted to activate the on-chip pullup resistors. However, it was discovered that doesn't work properly... it seems to work for some chips, but the pullups turned out to be a full strength drive (not a weak pullup), which does not work for some chips and is not good for those where it does work.

[keithg]

Paul,

No, I do not. When I added 4.7k pullups, it all came back.

Thanks! I figured it was something I was doing wrong.

Keith

[sumotoy]

Here's for reference the status of the libraries included in this release and compatibility with Teensy3, hope it can be useful.
RED Don't compile, GREEN It compile.
*note that if compile doesn't necessary mean that will work! This it's just for reference!!!
----------------------------------------------------------------------------------------------------------
AccelStepper
AltSoftSerial
ArdOSC
Bounce
CapacitiveSensor
DmxSimple
DogLcd *it compile but not checked with specified hardware
EEPROM *not applicable to Teensy3
Encoder
Entropy
Esplora
Ethernet *it compile but not checked with specified hardware
FastSPI_LED
Firmata
FlexiTimer2
FreqCount
FreqMeasure
FrequencyTimer2
IRremote *This link for a working version!
Keypad
ks0108
LedControl *Modify pgm_read_byte!!!
LedDisplay
LiquidCrystal
LiquidCrystalFast
LowPower
Metro
MIDI
MsTimer2
NewSoftSerial
OneWire * Ths Link for a working beta!
Ping
PS2Keyboard
PWMServo
SD
Servo
ShiftPWM
SoftPWM
SoftwareSerial
SPI
Stepper
Time
TimerOne
TimerThree
TinyGPS
Tlc5940 *should be easy to fix
VirtualWire
WiFi
Wire * needs 1,5K to 4,7K pullup resistors on SDA and SCL!!!
x10
XBee

[JasonM.]

Paul, thanks for all your hard work and commitment to this project. I'm still amazed at what I can do with this little Teensy 3.0. Is there any way to prioritize the FreqCount and FreqMeasure libraries being included? I have a couple of projects that are going to rely on them heavily (combustion engine RPM) and will likely have to get a Teensy 2.0 or learn real programming to get it off the ground, the latter of which is unlikely because I lack skill!

[nop]

I've also got the problem with the "Next" button that don't work in Teensyduino installer. It seams that it doesn't recognize the Arduino directory?

I've downloaded "arduino-1.0.3-windows.zip" (md5: e30c41138aa4f4a5721c0a1f55a06690) and extracted to various places c:\bin\arduino-1.0.3, c:\program files (x86)\arduino-1.0.3 etc without success.

Using Windows 7 64-bit. I've used the beta versions (without installer) successfully.

Any ideas?

[PaulStoffregen]

I've also got the problem with the "Next" button that don't work in Teensyduino installer. It seams that it doesn't recognize the Arduino directory?

Please download a fresh copy from Arduino's website.

One of the bug fixes, involving a java exception on startup for certain files (especially on Macs), caused the signatures the installer checks to change. So the 1.12 installer will not recognize a copy of Arduino that has beta 10, 11 or 12 installed. It will only recognize a fresh copy of Arduino, or one it has modified, or (maybe) ones modified by earlier beta versions before that change/bug was introduced. Ideally the installer would "know" how to detect the signatures for every modification made for every prior version of Teensyduino (even the betas). The installer isn't that smart (or I'm not that good). It only "knows" signatures for a fresh copy and reinstalled to one it's already changed. I designed those signatures to only check stuff that rarely changes between Teensyduino releases, but allows an extremely high level of confidence on the version of Arduino. Usually each installer can install into an Arduino modified by the previous version. But in this case, that particular bug was triggered by code in the Base class, so a chance was necessary that breaks reinstalling on top of a previous install.

Just download a fresh copy of Arduino and it should install fine.

[nop]

Right, thanks. I now got it to work.

The problem was that the arduino zip was not the correct size. After downloading again I got a bigger arduino-1.0.3-windows.zip (md5: 8b3380554781e0341b3c780eeee5995d). Strange.

[THT]

Beta12 actually broke the SPI transfers I'm doing in the RFM12B driver. Something changed here. My code has the same issue with release 1.12. Beta10 works.

This is how I do SPI:

    SPI0_CTAR0 = 0xF8010000; // 16bit transfers @16MHz
    digitalWriteFast(10, LOW);
    SPI0_PUSHR = (1<<26) | data;    // send data (and clear transfer counter)
    
    while (! SPI0_TCR) ; // loop until transfer is complete
    
    digitalWriteFast(10, HIGH);
    return SPI0_POPR;

Not nice but it worked and as I do have some special requirements (keep CS down while switching SPI transfer speed and frame size) I do need to do SPI manually.

The above code works up to Beta10 but breaks on Beta12 (I do not have a beta11-installation). On Beta12 the while-loop exits too early. Actually about 0.2µs after raising clock the first time. This only allows three bits to pass out of 16. This happens always, except for the first frame transfer.

    while (SPI0_TCR) ;   // loop until counter is reset
    while (! SPI0_TCR) ; // loop until transfer is complete

This solves the problem. Looks like the counter is reset a bit too late so I have to wait until it's reset and transfer is completed afterwards. It works but it's even worse than the first code.

What changed between Beta10 and Beta12 which could have introduced this behavior and how should I do it correctly?

[ploveday]

Maybe try polling until the FIFO is empty, and then poll TCF (as the transfer will have started).

Here's what I do:

void spiwait()
{
    while ((SPI0_SR & SPI_SR_TXCTR) != 0);
    while (!(SPI0_SR & SPI_SR_TCF));
    SPI0_SR |= SPI_SR_TCF;
}

Not entirely ideal, but it works for me, and doesn't rely on the initial state of TCF.

- Peter

[THT]

Thanks Peter, I like your solution and will give it a try.