How to find implementation details on Teensy 4.0 Libraries?

Status
Not open for further replies.

JimKazmer

Well-known member
I am new to Teensy development. I switched from using a 16Mhz Arduino because it was too slow for the type of real-time robotics control we needed. I had optimized the program to be completely interrupt driven, and had an average loop time of ~500ns which was still not fast enough (read controls, read sensors, software algorithm, update servos, update motors). I am excited to use the Teensy 4.0; it should exceed timing requirements for my application, as long as I can get all the I/O to be done via libraries that don't use delay/wait/sleep.

My question is mostly about getting information about the implementation used on each library specifically for the Teensy 4.0. Efficiency and implementation are often a point of discussion with many Arduino libraries (I seem to be missing these details in the Teensy realm).

For example, how are the native Teensy Serial1..6 UART libraries implemented? Do they use interrupts, are they efficient, and how much blocking do they do?

Once again, I'm asking for tips and insights on how to learn about the software libraries' implementation details.
Thanks
 
All Teensy libs that come with Teensyduino are very efficient and you'll find many optimizations.
Best is to download Teensyduino and take a look at the core (you'll find your UART code there) and the special Teensy libraries.
You will not find many things that can be optimized further.

One (single) thing is: If you want it effcient use
void loop() {
while(1) { your code here }
}
beacause we have a "eventresponder" running in the loop - it is still in development - best is to use the while in the loop.

The T4 is very new and there still may be some minor problems - the 3.x libs are more stable.
 
The serial code does use interrupts and does leverage the FIFOs, on the ports which have them.

Writing to serial does block if you write more than will fit into the transmit buffer. That's why there's an availableForWrite() function to tell you how much it can take without blocking. Full documentation here:

https://www.pjrc.com/teensy/td_uart.html

As for whether you think the code is efficient (a matter of opinion), feel free to read the source code or run some of your own tests.
 
Frank, Paul, Thank you for your responses. Both were helpful to me.

I am doing a project in combat robotics, which relies heavily on RC technologies. My previous implementation was using an Arduino. The Teensy provides so many more options! I've been examining many different software libraries, and trying out many different ways to do generate dShot, reading ESC-telemetry, and reading SBUS (RC receiver).

I know I am being a bit extreme in my approach of using the Teensy's peripherals to minimize the reliance on the CPU. Most of the implementations I've been reviewing still make use of delays() or polling loops. I found a few that make a heavy reliance on timers and interrupts (which still consumes CPU resources). My goal is to have all of the robots i/o performed asynchronously outside of my main loop (using the Teensy peripherals) such that the algorithm can access arrays of volatile memory for the motor telemetry, sensor values, and RC controls.... And, update arrays of volatile memory to update motor behavior.

I've been investigating (a) DMA with UARTs, or (b) DMA driving GPIO (dShot, output-only). I have a few questions for you...
(1) it occurs to me that option (b) the DMA driving GPIO, although it can be done independent of the CPU, can have a big (negative) impact on Teensy performance since the DMA driving the buses will interfere with the CPU's resources more than option (a). It seems the using a UART is more efficient. Is that correct?
(2) Besides a UART (and GPIO port toggling) are there other techniques I should investigate?
(3) Has anyone put together a good reference that discusses the conceptual approaches to using these peripherals for various purposes?

Thank you for your guidance.
 
My opinion:
I think you should just try to use not to over-optimize it.
Use a 3.6, get rid of all 8-bit optimizations (often they slow down things on a 32bit cpu), use 32bit variables, und use the existing libraries. You will be surprised how fast a 32bit cpu is (its faster even with the same MHz)

If you then notice that you need more speed, overclock the 3.6 to 240Mhz. Overclock the bus. If it's still not enought, try to optimize the code. As last step.
Why a 3.6? A 3.6 is much easier to handle, and I/O isn't that much slower than on a T4 or sometimes even faster.
Use a T4 only if you need the memory or 600MHz-1GHz for calculations.

I know, its fun top optimize :) I do it all the time. But if you just want to make it work on a new system like Teensy and ARM Cortex, begin without. This will save you an incredible amount of time.
Get used to the Cortex M4.

That's just my opinion. You will hear other opnions from other people :)

Edit: DMA:
No, it does not slow down als long it's running "free" (hardware triggered) and gets not startet/stopped too often.
I have a complete C64 Emulator with ili934 Display (driven with DMA, ~50FPS!) and sound (driven with DMA) - with 6510 cpu, sound and videochip emulation and (almost) exact C64 timing running on a Teensy3.6
It runs original games with original speed and has still enough power to drive the usb-core and can print diagnostic information faster than you can read it.
 
Last edited:
Most (current) RC electronics are still 5v... if I was to switch, would the Teensy 3.5 be a bad choice? Eliminating the electronics for converting between 3.3v and 5v woud be helpful (one less component to worry about as the robot is getting hammered). I was thinking yesterday that I could have lived with the 16Mhz arduino if it had the DMA peripherals that Teensy 4.0 has.
 
RC is usually slow enough that you can use levelshifters (I think).
The 3.6 is not 5V compatible - yes, the next choice would be a Teensy 3.5, which is a bit slower but can resist 5v (output is still 3.3 Volt)
DMA is on all 32Bit teensy available.
 
Status
Not open for further replies.
Back
Top