Teensy Quick Reference: Code Examples, Tips and Tricks

As people are starting to design add-on boards and shields for the Teensy 3.x, it might be useful to incorporate links into the top posting. Some of the shields are listed in this thread: http://forum.pjrc.com/threads/25620-Teensy-3-1-to-Arduno-Shield-DIY-Adaptor

The one's I'm aware of include (last edit December 2nd, 2014):

AdamSoftTech used to sell a Teensy 3.1 board and shield to bring out the underneath pins, but it is now retired.

Edit, June 19th, 2015:
Sparkfun now has added two shields for Teensy 3.1.

Edit, January 20th, 2016:
 
Last edited:
That reminds, many years ago when I worked at Cygnus, I thought it might be useful for embedded customers for the compiler to realize when long long or floating point was passed to printf/scanf, and in the appropriate newlib environment, issue the appropriate magic behind the user's back to pull in the right printf/scanf. I never got around to doing it, primarily because we thought that the majority of our embedded customers did not use printf/scanf (and on some of the machines, you had very little memory left if the printf with floating point pulled in the fp emulator). Of course the embedded users that use Arduinos/Teensys are somewhat different than the people 10-15 years ago trying to put out a commercial product.
 
I got a pair of these: tindie.com _pico_ rfx-teensy-3x-nrf24l01-carrier-board-w-prototyping-area

for v3.1: I also ordered some POGO pins from Amazon-
Amico 10 Pcs Spherical Radius Tip Spring Loaded Test Probes Pins
0.87mm Dia Round Tip Spring Loaded Test Probes Pins (very small 1.44mm / 0.056"; Overall Length(Each): 7mm / 0.27")
Click to expand...
I'd like to find a way to solder them to straight double wide male header pins instead of direct solder - if I do I'll post. If the height works out to the socketed Teensy the problem will be aligning/holding the pins to solder them on the header.

[edit: I hope one of these works ideally with the LC - it brings out dual SPI - hopefully it hits the hardware pins on the LC, where one was 3.1 software - I didn't check. Anyhow this board and the PJRC IL display all fit in a mint tin with nrf24/9dof/mic and onehorse battery charger addon - I didn't solder yet, but I visualize the display attached outside the tin bottom so the lid exposes/covers the innards.]
 
Last edited:
are there any examples for Ports (8 bit simultaneous signals for example, d0-d7)

i have seen a lot of references to using 'port D' or 'port B' etc. they are different for every model of Teensy i understand. are there examples or a wiki page in order to discover the usage and implementation methods?
 
Hi All,

It would be nice to have this in some sort of Wiki page or something to have an up to date list: no need to read every posting when a better suggestion is made on the intial post which is a briljant overview.

Second suggestion is write something on best pratice. My first posting was on a old 2013 or so thread dealing with processing in an ISR of a UART : what is the best practice ( see here) which discusses difficult aspects of what to process and what no to do in an ISR and how this affects the design and how to solve this using Queues and processing threads etc to prevent stalling or freezing other devices when a lot of processing is done within a UART ISR. It would also be desirable to explain why it is bad practice to poll for an occurance of an event or condition which are clear indicators that somebody doesn't understand some fundamental aspects of using a Real Time Operating system which has a steep learning curve to begin with. I would like to suggest also a demo application that has proper UART ISR for a Teensy 3.2 (green print/board) that shows how this is properly done.

Any comment on these suggestions is appriciated
 
Spix said:
Hi All,

It would be nice to have this in some sort of Wiki page or something to have an up to date list
Click to expand...

I started this thread when WiKi got traction: Wiki-Coming-Please-link-worthy-posts

It was realized the wiki may be better integrated if the Forum software is changed so that lead to extra work items that hasn't gotten resolved as there isn't a clear best choice and with all else going on, so this placeholder list is a good place to scan and leave ideas that the WiKi needs to cover.

<edit: Spix that looks like a good post and note - I hope you copy it to the WiKi thread, along with any other key resource info you've seen that isn't already posted>
 
Last edited:
@defragster : I think it is better to start a brand new thread specific on ISR code design guide lines or best practices and use a UART as an example: it is far from trivial understanding the true context of an ISR in a RTOS and add that new thread to the general Wiki-like-tread
 
defragster said:
If you have your own set of links or reference info - maybe post them on a good thread and link that post here.
Click to expand...

Spix: Go for it - just be sure to link the thread into that WiKi thread.

I created a sketch with two teensies going out serial1 and serial2 to each other crossed and doing the opposite, and on Teensy_3's it will run at 6,000,000 baud. The start code was in serialEvent based on the Arduino sample - I just duplicated it's message mechanism and did it for two ports at once. This code is on a thread somewhere.

Another cool thing I did the other day was take all USB Input echoed to Serial1 and vice versa so I could make a USB free Teensy that could have all debug messages logged on USB from the second Teensy but still take USB input - just read from Serial1. Reading yesterday - apparently this is a coded example included USB > USBtoSerial. I just opened that sketch and it does it by POLLING - very wasteful - exactly as you say above! It is an OLD example - and should be re-written using your comments above - along the lines of my serialEvent code below.

I'll attach my full sample - that does some other diagnostic cool things I collected. If you want to clean this up and make sure it does what the 'USBtoSerial' sketch does I think it would make a good thread - I'd be happy to review the code. I'd write it myself but it you think it would be a good lesson you would like to see done give it a try.

USB to Serial - Teensy becomes a USB to Serial converter
http://dorkbotpdx.org/blog/paul/teensy_as_benito_at_57600_baud

You must select Serial from the "Tools > USB Type" menu
Click to expand...

Code: 
void serialEvent() {
  while (Serial.available()) {
    Serial1.write(Serial.read());
  }
}

void serialEvent1() {
  while (Serial1.available() ) {
    Serial.write(Serial1.read());
  }
}

View attachment qBlinkS_Oct15a.ino
 
Cool.

Ever seen this? http://dangerousprototypes.com/docs/Bus_Pirate vèry handy for this serial stuff

I am soooo green on Teensy : I bought the board 3 months ago and it is still in it's sealed package.. and I have to setup a development dev in (thank God) in Eclipse my favorite IDE so it will take a while before I am up and running.

So there are at least 3 threads discussing different aspects on the UART serial line driver driver......

BTW I think increasing the size of the ring buffers is normally an indication that there is a "hair in your soup" : something is wrong and it is very hard to find. Increasing buffer sizes until the problem goes away is delaying the problem: I prefer to invest the time to understand it to solve it once and for all. But serial line drivers ain't chickenshit

Question: is the UART itself responsible for flow control (XON/XOFF)?
 
There is no native flow control on serial UARTS - look at the post just linked in the other thread there is a library that works with flow control pins.

I've glanced at Bus pirate - could be handy.

The code above shows the built in system interrupt handling - it does USB and the UARTS with serialEvent. Interrupts are tricky things and these have been tamed. As you note ISR's have to be kept minimal and focused. The interrupt powers of the Teensy MCU are powerful and supportive, but getting re-entered or taking too long or messing stuff up is still up to coding.

So far I'm only as far as dabbling and suffering through the Arduino IDE. In my programming days the IDE was a text editor of your choice and a dos box with make files for building MS-DOS and MS-Windows. So anything beyond that is gravy. My inclination would be VisualStudio and the VisualMicro add on for that now that it has caught up to the new Arduino and Teensy, but I haven't bothered to set that up yet with my distractions after first trying it months back when it broke from the Arduino changes.

Indeed - making buffers bigger just prolongs the time until they fill. But running serial at 4Mbit/sec is a challenge and that is what the other poster was doing from a device that would hang if it got ignored in the wrong way. As powerful as the Teensy is - there are limits on RAM and getting data processed and queued on some devices so allowances need to be made. Having it interrupt drive and handled in the background while you keep up with a firehose and other tasks can be a fun problem to solve, and polling is a waste of time and effort. The Teensy is also blessed with DMA that is processor driven magic beyond a mere FIFO or buffer where stuff is fully sent from or populated to RAM with near zero processor overhead.

My Teensy's sat wrapped for months as well as I played with another smaller family and then saw Teensy moving to 1.6.0 IDE and jumped in. It is pretty awesome and a very stable and well supported system.

If you find UART or other gems not in the WiKi list please add to the list.
 
defragster said:
My inclination would be VisualStudio and the VisualMicro
Click to expand...

I would have a serious look at Eclipse because it is used in so many diff env: from Java, C etc etc and used even in professional environments so it would be another plus on your CV.

And I guess that it is possible to have Teensy and Eclipse being able to control the actual application in Eclipse being able to set breakpoints etc etc which is a very big bennefit when you try to tackle something as difficult as a bug that is caused by timing: these are normally the hardest bugs to solve so anything that make your life easier to control the application is a great benefit because it will the smallest distraction
 
It was suggested I add the list of #defines that are set by the default environment to this thread:

For Teensy 3.x/LC:
  • __arm__ is defined for Teensy 3.x/LC, but it is also defined for Arduino Zero, etc.;
  • CORE_TEENSY is defined for Teensy 3.x/LC (probably 2.0/2.0++, but I don't have experience with those);
  • If __MK20DX128__ is defined, it is a Teensy 3.0 (not 5v tolerant);
  • If __MK20DX256__ is defined, it is a Teensy 3.1 or Teensy 3.2 (adds 2nd i2c bus, 5v tolerant, pins 26-31 are capable of analog input, pin 14 is the DAC, reset moved underneath board) ;
  • If __MKL26Z64__ is defined, it is a Teensy LC (not 5v tolerant, no underneath pads, 2nd i2c bus on A8-A9, 3/4 are touch pins, pin 12 is the DAC, Vbat replaced by A3 level conversion to VIN).
 
You must log in or register to reply here.
Back
Top