Teensyduino 1.21 Features

PaulStoffregen

Well-known member
I want to improve how we talk about features for future Teensyduino releases. This thread is meant to collect all requests and feedback and proposals for new features, rather than having them scattered across many old (and forgotten) threads.

Here's what I've got on the wish-list so far. As 1.21 develops, I'll be editing this list....

  • Emulate Arduino Uno restart behavior upon serial monitor open. Teensy 2.0 has this, 3.x needs it.
  • Improve Serial Monitor performance & fix memory leaks
  • Keep Serial Monitor window open (but temporarily disabled) during upload
  • Fix pin 33 bug (driving this pin low disrupts code upload and causes all sorts of other problems)
  • Breakpoint instruction to request software debug mode & disable C_DEBUGEN bit
  • Method to set the MK20 lock bit
  • AnalogRead should support differential inputs and using PGA
  • Ethernet should support UDP multicast
  • Command line loader update for Teensy 3.1 and include with installer
  • Wire library should define Wire1 for other I2C port on Teensy 3.1
  • Wire library should implement setClock(bitrate)
  • Wire library should have setSDA(pin) and setSCL(pin), to control which pins are used
  • Serial1,2,3 should have setRX(pin) and setTX(pin), to control which pins are used
  • SD library should release SPI bus while SD card is busy
  • Support MacOS 10.9.5 new app signature requirements (very difficult with lib installs)
  • SoftwareSerial support for any pins on Teensy 3.x, using CMT & DMA
  • detachInterruptVector()
  • pinMode to support more modes: INPUT_PULLDOWN, INPUT_DISABLE, INPUT_ANALOG
  • Fix IRremote at 72 MHz & other speeds
  • Prevent RobotIRremote from interfering with IRremote
  • Library install/update/uninstall manager
  • Update ARM toolchain from 4.7.2 to 4.8.4
  • Libraries to include or update:
    • USB Host Shield
    • ADC
    • SmartMatrix
    • LowPower_t3
    • i2c_t3
    • OpenGLCD
    • FastLED

Please understand not all of these will necessarily be in 1.21. My general goal is to release a new version every 3 to 4 months, rolling up all the new features and libraries that are stable at the time.
 
Last edited:
Perhaps Wire.h on Teensy 3.x should include i2c_t3.h instead of using the current implementation.

When I include i2c_t3 along with stuff still using Wire, I get a bunch of undefined function since i2c_t3 has upgraded the functions (write, requestFrom?) to be able to do requests of more than 256 bytes. Perhaps just adding variants of write and requestFrom that take/return byte arguments instead of size_t, would help.
 
how about release the vector interrupt? I thought you said you where going to update this?
 
Oh, opps, sorry Duff. That got lost in the shuffle (the github stuff somehow got closed too, how I'm not sure). I'll edit the post now, to put it on the list.

That's really the whole idea of this thread... to collect all this stuff into one well defined place, so things don't get lost.
 
Last edited:
I closed it when I updated my fork of your core, I screwed something up and had to delete my fork and refork;) I thought it might not be right anyway, though it did work but i was thinking it might need to be atomic.
 
My most sought-after features seem to be listed, but I'll put them here in the hopes that they don't fall off that list!

Emulating the Arduino restart-on-serial is great (would be best if it was a toggle-able option). I'm hoping this means the return of _restart_Teensyduino()!

Command Line loader for OSX and Windows (or at least, a GUI-free version of the current loader!) I've got something working with the current loader - I have two chips on one board, so I send commands to each one telling it when to reboot, and let Auto mode do it's thing - but a cleaner interface is always nice.

The OSX 10.9.5 signing requirements honestly don't bother me much - you only have to right-click and select 'open' once, and then it's fine.

Also.... can we call this update the Jigawatt update? Because that would make me giggle constantly.
 
Paul,
The Uno resets when the signal that is hooked up to auto reset circuit toggles.
Because of the total kludge auto-reset circuit they did with DTR, it toggles on every device/port open.
The big BUT that comes here is that this happens because DTR is controlled by the OS *before* the application
gets control so there is no way to prevent the DTR signal from dropping. (the auto reset cap converts it to a pulse)
The auto-reset circuit was a kludge in that it was a h/w solution to a s/w problem.
They used DTR with the cap to use the existing avrdude vs fixing avrdude to properly use RTS for full control of the
reset signal pulse.

Now that Avrdude has been updated to support using the RTS signal when you use the arduino protocol,
you can use either DTR or RTS for downloading with auto-reset.

If you use RTS instead of DTR, then since the signal is not altered by the OS, no reset occurs when the serial port is
opened by the application (like the serial monitor)
This is a valuable feature to me and is why I use RTS vs DTR on all my "uno" boards
as I specifically do not want the board to reset when the serial port is opened.

Using RTS vs DTR gives you the best of both worlds. You get a reset when downloading but no reset
when simply opening up the serial to connect to the Arduino board.


I bring this up because I believe that is not a given nor do I believe that it was part of the
intended design that the board would/should reset every time the serial monitor was
opened. I believe that the reset that occurs now when the serial monitor is opened
originally was an accident due to the DTR auto-reset circuit kludge that was used.
It seems to have been spun into a "feature" but I still believe that it is a bug.

Recently there seems to be cases where the Uno h/w issue behavior when using DTR for auto-reset
is now being emulating in s/w on the other boards
(i.e. reseting the board when the serial monitor is opened).
Maybe people like this, but I don't.

I think what would have been better is if Team Arduino had fixed this when they abandoned the FTDI chip.
It is a one line source code change to the U16 code to switch from using DTR to RTS.
That would allow you to open the serial port without reseting the UNO/Mega and then the
ideal scenario for resetting the board would be to have a button on the serial monitor to do that.
That way you could reset the board without having to close/re-open the serial monitor.
And for boards like Teensy that have no way to h/w reset using a button, you could do it from the serial monitor.

Today, it is kind of a pain to reset a teensy 2 since the "reset" button on the Teensy doesn't really reset the board.
I'd much rather see a reset button in the serial monitor than to have the board reset every time the serial
monitor is opened.



--- bill
 
What about Arduino 1.5x support? Is that on the horizon yet?
My fear is that if you don't start looking at this soon, that Team Arduino will eventually
kick out a 1.5x release that will have issues for 3rd party guys such as yourself
and it will be harder to get it changed after the release than now.

Anything I need to do for openGLCD library to make it easier to include?
(other that kick out a 1.0 release?)
 
What about Arduino 1.5x support? Is that on the horizon yet?

It was, then this happened. Well, it's still in the process of happening.... and that is really the problem.

1.5.x is still a moving target. They're probably never going to merge most of my Teensy-specific patches. I already spend quite a bit of time maintaining my patch set on each new 1.0.x release. Trying to do the same with 1.5.x while it's still undergoing so many structural changes would only consume a lot of my limited dev time, for little to no tangible benefit, other than the minor convenience of not needing 2 copies of Arduino if you're also using Due or Yun.

Stuff like the audio library, SPI transactions, fixing bugs and developing new hardware seem like far better uses for my limited time!


Anything I need to do for openGLCD library to make it easier to include?
(other that kick out a 1.0 release?)

Oh, opps, sorry Bill. This totally fell off my radar. Is this still on Google code?

Just let me know which version should be included with the Teensyduino 1.21 installer and I'll be happy to add it. You've done excellent work with GLCD.
 
I know this is extremely low priority, but it always sort of bothers me when I look at cores/teensy3/HardwareSerial.h. I tend to think it is a bit messy to have 3 types (HardwareSerial1, HardwareSerial2, HardwareSerial3) inherit from HardwareSerial. Instead, I think there should be virtual functions to handle all of the low level details, and the Serial{1,2,3} types should specify this in the global constructor, like the Arduino AVR versions do.
 
....like the Arduino AVR versions do.

Their approach leads to much less efficient implementation, due to an extra layer of indirection.

I'm willing to consider ideas. But if the choice is between 1 "clean" source file that compiles to slower code versus several duplicate copies that result in a faster, more efficient implementation, I'm very willing to maintain duplicate copies of the code.
 
The issue was I wanted to make pointers to things of HardwareSerial to pass around to use. You can use explicit casts to get the pointers to the sub-class (assuming if you only reference things through HardwareSerial, it will do everything).
 
I can agree with not using templates, as at heart I am a C programmer, and templates always seem to be even worse than levels of macro indirection. As I said, compared to everything else, it is a very minor thing.
 
Oh, opps, sorry Bill. This totally fell off my radar. Is this still on Google code?

Just let me know which version should be included with the Teensyduino 1.21 installer and I'll be happy to add it. You've done excellent work with GLCD.

The openGLCD repo is over on bitbucket:
https://bitbucket.org/bperrybap/openglcd/wiki/Home

I haven't yet released a 1.0 version yet.
(I probably should as it has been stable for quite some time)

I'll see if I can get a 1.0 release out over the next few weeks.
I create 3 versions of the package for each release.
One is documentation only, and I'm assuming you won't want/need that one.
Between the other 2, one includes all the html documentation which adds 750k to the zip image.
(.7mb vs 1.4mb)

These zip images are compatible with the IDE library installer.
Are these images compatible with your installer?


Another feature that would be useful for documentation
would be the ability of the IDE editor to recognized and support additional UREs other than "http:"
For example, it would be nice if it also recognized "file:" and supported relative paths (to the sketch)
as well as absolute paths.
This would allow adding lines in the example sketches that could point to local html
documentation so the user could click on the links inside the IDE editor and launch the browser using the local html documentation files.
This is merely a very very low priority "nice to have".

In the mean time, I'll try to see if I can get the documentation hosted on the repo
which works great with the current IDE editor link capabilities
as long as users have web access.
It's very easy on GoogleCode but not on BitBucket.


--- bill
 
Ok, I'm hearing "wait for version 1.0", right?

Another feature that would be useful for documentation
would be the ability of the IDE editor to recognized and support additional UREs other than "http:"
For example, it would be nice if it also recognized "file:" and supported relative paths (to the sketch)
as well as absolute paths.

This is the sort of thing that should be proposed and added upstream in Arduino.

If they add it only in 1.5.x, I'll be happy to back-port to 1.0.x on my next release that changes the IDE. But not every Teensyduino release had IDE changes (because it's a huge pain).
 
My christmas wish-list :)

- support usb_disk for teensy 3 (allow easy transfer of audio- and other files to sdcard)
- Audio 48 KHz, 44.1 KHz, 32 KHz support (MP3)
 
Can you update the newlib please ?
There are some optimizations for Cortex-m4, for example a faster memcpy etc.
ARM developed some patches.

I took the libs from launchpad.net, gcc 4.8.4 zip-archive and simply replaced the ones in teensyduino with them..
seems to work :)
 
Last edited:
  • Wire library should define Wire1 for other I2C port on Teensy 3.1
  • Wire library should implement setClock(bitrate)
  • Wire library should have setSDA(pin) and setSCL(pin), to control which pins are used

Since my update for the SPI documentation page was accepted, I'm working on updates to some more including the I2C/Wire page. I will lookout for a 1.21-rc or GitHub update with these changes to Wire, and update the docs when they appear.
 
Can you include this ?
http://forum.pjrc.com/threads/27140-GCC-optimization-level?highlight=Optimize

It makes it more easy to set an optimization level.
Well you can always use the optimize attribute or optimize pragma that I put in the GCC 4.5 time frame. It does cause some problems if you turn off specific optimizations (i.e. -f options) that optimization passes depend on, but it can help if you have one function that must be optimized. Note, in the syntax, there are two underscores before/after the attributes (it can sometimes be hard to see if it is one or two underscores):

Code:
6.30 Declaring Attributes of Functions
======================================

In GNU C, you declare certain things about functions called in your
program which help the compiler optimize function calls and check your
code more carefully.

 The keyword `__attribute__' allows you to specify special attributes
when making a declaration.  This keyword is followed by an attribute
specification inside double parentheses.  The following attributes are
currently defined for functions on all targets: `aligned',
`alloc_size', `alloc_align', `assume_aligned', `noreturn',
`returns_twice', `noinline', `noclone', `always_inline', `flatten',
`pure', `const', `nothrow', `sentinel', `format', `format_arg',
`no_instrument_function', `no_split_stack', `section', `constructor',
`destructor', `used', `unused', `deprecated', `weak', `malloc',
`alias', `ifunc', `warn_unused_result', `nonnull', `returns_nonnull',
`gnu_inline', `externally_visible', `hot', `cold', `artificial',
`no_sanitize_address', `no_address_safety_analysis',
`no_sanitize_undefined', `no_reorder', `error' and `warning'.  Several
other attributes are defined for functions on particular target
systems.  Other attributes, including `section' are supported for
variables declarations (*note Variable Attributes::), labels (*note
Label Attributes::) and for types (*note Type Attributes::).

 GCC plugins may provide their own attributes.

 You may also specify attributes with `__' preceding and following each
keyword.  This allows you to use them in header files without being
concerned about a possible macro of the same name.  For example, you
may use `__noreturn__' instead of `noreturn'.

 *Note Attribute Syntax::, for details of the exact syntax for using
attributes.

    ...

`optimize'
     The `optimize' attribute is used to specify that a function is to
     be compiled with different optimization options than specified on
     the command line.  Arguments can either be numbers or strings.
     Numbers are assumed to be an optimization level.  Strings that
     begin with `O' are assumed to be an optimization option, while
     other options are assumed to be used with a `-f' prefix.  You can
     also use the `#pragma GCC optimize' pragma to set the optimization
     options that affect more than one function.  *Note Function
     Specific Option Pragmas::, for details about the `#pragma GCC
     optimize' pragma.

     This can be used for instance to have frequently-executed functions
     compiled with more aggressive optimization options that produce
     faster and larger code, while other functions can be compiled with
     less aggressive options.

    ....

6.32 Attribute Syntax
=====================

This section describes the syntax with which `__attribute__' may be
used, and the constructs to which attribute specifiers bind, for the C
language.  Some details may vary for C++ and Objective-C.  Because of
infelicities in the grammar for attributes, some forms described here
may not be successfully parsed in all cases.

 There are some problems with the semantics of attributes in C++.  For
example, there are no manglings for attributes, although they may affect
code generation, so problems may arise when attributed types are used in
conjunction with templates or overloading.  Similarly, `typeid' does
not distinguish between types with different attributes.  Support for
attributes in C++ may be restricted in future to attributes on
declarations only, but not on nested declarators.

 *Note Function Attributes::, for details of the semantics of attributes
applying to functions.  *Note Variable Attributes::, for details of the
semantics of attributes applying to variables.  *Note Type Attributes::,
for details of the semantics of attributes applying to structure, union
and enumerated types.  *Note Label Attributes::, for details of the
semantics of attributes applying to labels.

 An "attribute specifier" is of the form `__attribute__
((ATTRIBUTE-LIST))'.  An "attribute list" is a possibly empty
comma-separated sequence of "attributes", where each attribute is one
of the following:

   * Empty.  Empty attributes are ignored.

   * A word (which may be an identifier such as `unused', or a reserved
     word such as `const').

   * A word, followed by, in parentheses, parameters for the attribute.
     These parameters take one of the following forms:

        * An identifier.  For example, `mode' attributes use this form.

        * An identifier followed by a comma and a non-empty
          comma-separated list of expressions.  For example, `format'
          attributes use this form.

        * A possibly empty comma-separated list of expressions.  For
          example, `format_arg' attributes use this form with the list
          being a single integer constant expression, and `alias'
          attributes use this form with the list being a single string
          constant.

 An "attribute specifier list" is a sequence of one or more attribute
specifiers, not separated by any other tokens.

    ....


6.57.13 Function Specific Option Pragmas
----------------------------------------

`#pragma GCC target ("STRING"...)'
     This pragma allows you to set target specific options for functions
     defined later in the source file.  One or more strings can be
     specified.  Each function that is defined after this point is as
     if `attribute((target("STRING")))' was specified for that
     function.  The parenthesis around the options is optional.  *Note
     Function Attributes::, for more information about the `target'
     attribute and the attribute syntax.

     The `#pragma GCC target' pragma is presently implemented for
     i386/x86_64, PowerPC, and Nios II targets only.

`#pragma GCC optimize ("STRING"...)'
     This pragma allows you to set global optimization options for
     functions defined later in the source file.  One or more strings
     can be specified.  Each function that is defined after this point
     is as if `attribute((optimize("STRING")))' was specified for that
     function.  The parenthesis around the options is optional.  *Note
     Function Attributes::, for more information about the `optimize'
     attribute and the attribute syntax.

     The `#pragma GCC optimize' pragma is not implemented in GCC
     versions earlier than 4.4.

`#pragma GCC push_options'
`#pragma GCC pop_options'
     These pragmas maintain a stack of the current target and
     optimization options.  It is intended for include files where you
     temporarily want to switch to using a different `#pragma GCC
     target' or `#pragma GCC optimize' and then to pop back to the
     previous options.

     The `#pragma GCC push_options' and `#pragma GCC pop_options'
     pragmas are not implemented in GCC versions earlier than 4.4.

`#pragma GCC reset_options'
     This pragma clears the current `#pragma GCC target' and `#pragma
     GCC optimize' to use the default switches as specified on the
     command line.

     The `#pragma GCC reset_options' pragma is not implemented in GCC
     versions earlier than 4.4.
 
Hi Michael,
i tried #pragma GCC optimize ("-O2"). Is this the correct syntax ?
And does it work correctly with -ffunction-sections ?
I was a bit in doubt, i tried this with my "codecs"-project and it seemed to me (i measured the decoding-speed) that -O2 as switch is much faster.
But maybe I did something wrong. Is there anything else to consider?
 
Do i have to include the pragme in every file, or is it sufficiant to include in a headerfile (which is used the the other files) ?
 
The syntax is without the - sign:

Code:
#pragma GCC optimize ("O2")

It should work with -ffunction-sections

Note, if you use the #pragma option, it should operate on any function defined after the #pragma. Switching optimization levels does kill inlining functions defined with a different optimization level. The way it was envisioned when I put it in was to decorate the couple of hot functions to have extra optimization, and decorate the functions that are for exceptional cases that don't need as much optimization in space constrained objects. Unfortunately, in the Ardunio environments, you don't have the type of tools to allow you to identify hot-spots that you have in hosted environments or in higher level embedded environments.

Given the Arduino IDE rewrites the C++ code, you might want to verify that #pragma's survive the rewriting process.

I put this in several years ago, and I know there have been problems with it since then, but I haven't tracked what the issues are. Part of the issue is when I spec'ed it and later wrote it, the compiler was more linear in terms of optimizing only a function at a time, and now it does more optimization, earlier in the process.
 
Back
Top