TDuino
Convenient functionality for Arduino
Tweaking TDuino

By uncommenting or modifying some of the #defines in the file TDefs.h which is found in the library folder, you can tweak the behaviour of TDuino. The following defines can be used for tweaks:

 
//#define ENABLE_64BIT

Uncommenting the line above will enable the use of 64 bit integers. These large numbers are only used to prevent limitations caused by 32 bit rollover in timing related calculations used in the following method(s): TTimeline::hasOverlap(). Please note that 64 bit integers are slower to handle than 32 bit integers. Also, 64 bit integers uses more memory and the size of the compiled sketch will increase because the compiler needs to add code to handle 64 bit integers.

 
//#define DISABLE_32BIT_ROLLOVER_CHECKS

Uncommenting the line above will remove code used to avoid unwanted 32 bit rollover in timing calculations for the following methods: TTimeline::hasOverlap(). By default 32 bit rollover will be checked in order to avoid unstable behaviour which may otherwise occur if 32 bit addition rolls over. If a TTimeline or TTimelineT has multiple slots which combined will take longer time than can be stored in 31 bits (~24 days using millis() or 35 seconds using micros()) you may run into issues with 32 bit rollover.

The define is ignored if 64 bit integers are enabled.

 
//#define ENABLE_TIGHT_TIMING

By default TDuino will perform timings after "best effort". This means that any timed action may not actually be 100% accurate and a couple of milliseconds may be lost down the line. If a timer is set to trigger each 100ms and the loop phase of the entire sketch is taking 200ms to execute, then the default behaviour is to handle the timer and set the next timer event to trigger in 100ms minus the time it takes to execute the timer. This means that the interval of the timer may actually be up to 200ms in a worst case scenario and the missed timer intervals are lost.

If tight timing is enabled, timed events will be as close to the specified interval as possible and "missed" events will be postponed. This means that if a timer is set to trigger with an interval of 100ms and the entire loop phase of the sketch takes 200ms to execute, then the timer would have events "piling up". If at some point the loop phase speeds up then the timer may trigger with intervals below 100ms in order to "catch up" with the missed events. If the loop phase is continuously slower than an interval then tight timing may cause issues due to 32 bit rollover.

 
//#define TIMING_WITH_MICROS

By default TDuino uses millis() for all timing related functions. If you rather want to use micros() for timing, you can do this by uncommenting this define. Please note that all arguments given in milliseconds throughout TDuino must be given as microseconds instead. If timing with micros() is enabled, the following TTimer will trigger each 100 milliseconds:

TTimer timer(timerCallback);
timer.set(100000);

The same behaviour will be the case for: TPinOutput, TTimeline and TTimelineT. It will also change the behaviour of debouncing used by TPinInput and TButton, so be careful when using micros() for timing.

 
//#define TPININPUT_FLOAT_MATH

By default TPinInput (since V1.6) uses integer division to calculate the average value of multiple samples. This yields the best performance but since integer division always truncates any fraction instead of rounding it to nearest value it is not as accurate as floating point division. If you want to loose some performance in order to increase accuracy by a smidgeon, you can uncomment the line above and use floating point division.