Teensy "Boot" time?
- Thread starter BuckyKatt
- Start date
- Status
GremlinWrangler
Well-known member
Not very long. Blink sketch seems to be kicking in under a second. if you are downloading code to restart it's going to be a bit slower, but the way the Teensy bootloader works means there is no 'waiting for download' wait at the start. Other than preping the USB port it's pretty much heading off to run your first line of code. If even faster booting is required options exist to strip overhead out, but will make downloading more complex.
PaulStoffregen
Well-known member
Teensy boots TOO FAST!
One of the common problems involves other chips that have brief start-up times. Motion sensors and Asian counterfeits of popular LED driver chips are the usual culprits. If you (or an Arduino library you use) makes a single attempt at startup to initialize the hardware, before it's booted up, the result can appear like Teensy isn't running your program. But in fact, your program is running and trying to make use of a chip that never got initialized, which is a case few people anticipate, so their programs usually "play dead" when the hardware isn't responding. The solution is usually just to add a delay at the beginning of setup(), before attempting to initialize other chips. Simple as that sounds, the problem usually manifests as Teensy appearing to not run your program, rather than an understanding that the boot time is too short.
But to answer your specific question, the boot time is approx 5 ms after the 3.3V power rises past approx 1.7 volts.
Most of that is an intentional 4 ms delay in the code, so you can delete that delay if you really want faster startup. Also consider any time spent in C++ constructors.
If you need fast startup, you can also put your own code into mk20dx128.c (or use one of the hooks provided in that code) to run functions very early in the boot process. The earliest one gives you control within just a few clock cycles of startup, but it's tough to use because almost nothing is set up... and the power supply isn't even fully settled and of course the CPU runs from a quick-starting internal oscillator. If you need *extremely* fast boot up, Teensy 3.2 can do it, within microseconds of the voltage rising to the point where the CPU can run.
But the normal ~5ms from power to setup() running is pretty fast, and in many cases so fast that conventional programs developed for slow-starting Arduino boards can have unexpected issues!
Last edited:
[/quote]
Very cool. Fast boot time is one of the features that has drawn me to Teensy.
In an attempt to keep battery usage to a minimum, I'm considering using a very tiny MCU (attiny85? attiny13?) to watch a PIR and a FM receiver (instead of WiFi) and power ip a Teensy with a camera, LED array and WiFi to do its actual work... hopefully these items don't require a lot of setup time.
What is the easiest way to communicate between, say, an attiny13 and a Teensy? Only actually need a small amount of data... probably less than 256 characters... and it doesn't really need to be two-way.
I'm very impressed with my reading about the Teensy. I can't wait to order a couple and play.
BKNJ
Disclaimer... Arduino/MCU newbie here...
I would, but I haven't found a radio unit that would make things wake up. I originally would have liked to have the system do a Wake On WLAN... via WiFi, but that doesn't seem to be a possibility.
I had found a 433Mhz radio that seemed to be a low power RX-only... but I forgot the US is region 2, not region 1. Oops... now looking at 915Mhz.
I'm not married to any radio solution except the one that can deliver low power and still be able to push 2~5 Mbps back to the AP.
Don't get me wrong, I'm sure I'm going to buy a lot of very tiny (or teensy ;-) ) hardware and will be constantly reconfiguring it until I get decent battery life.
BKNJ
MichaelMeissner
Senior Member+
Here is a link to Duff's snooze library for low power mode on the Teensy: https://github.com/duff2013/Snooze
Here's a non-obvious boot-up-time comment...
A professional app I've been working on for some time has a strict requirement to get to the application code in less than 20mSec from power on. I found that a significant portion of my time budget is consumed by the C startup code zero'ing BSS and initializing RAM resident variables' values. Though I've avoided C++ constructors in my project for several reasons, these can have a big impact. One thing I did is to disable initializing bss to 0 (alter linker script) and make sure all code does not rely on zero'd RAM.
A complicating factor is that most (all ?) Cortex MCUs run this init code using the slow internal clock (often 8 or 16MHz), before switching to the faster PLL clock.
A professional app I've been working on for some time has a strict requirement to get to the application code in less than 20mSec from power on. I found that a significant portion of my time budget is consumed by the C startup code zero'ing BSS and initializing RAM resident variables' values. Though I've avoided C++ constructors in my project for several reasons, these can have a big impact. One thing I did is to disable initializing bss to 0 (alter linker script) and make sure all code does not rely on zero'd RAM.
A complicating factor is that most (all ?) Cortex MCUs run this init code using the slow internal clock (often 8 or 16MHz), before switching to the faster PLL clock.
After double checking the data sheets, the reason I am considering using a lesser MCU to watch the PIR/radio and kick on the Teensy is that I figured that the lesser MCU would use less power.
For example, assuming I'm reading the data sheet right, the attiny13 is 240uA at full power and <0.1uA while sleeping... I'm not sure yet if it has low power states. In any case, the K20 series seems to required double that (509uA) in very low power mode.
To be honest, this all may be a rounding error compared to whatever PIR/radio I need to use when I actually get parts working on my desk, so I'm not sure exactly how this will pan out.
Interesting. My only confusion at this point (i.e. without parts on my desk to play with), is which of these modes will work with the PIR and WiFi/other radio.
Is there a preferred WiFi unit that can run in a low power mode, but still get decent throughput? I can't seem to find any throughput rates.
BKNJ
- Status