You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to this implementation's use of the SparkIntervalTimer library, in certain instances, this can cause PWM functionality to become inoperable on certain groups of pins on the Photon(NOTE: this may be true for other Particle devices, as well; I only have a Photon for testing), depending on which hardware timer is allocated to the timer_isr() function at the time of instantiation.
When the timer_isr() function is instantiated, the "dynamic timer allocation" feature will cause the timer to use interrupts generated by one of the following timers on the Photon:
TIM3
TIM4
TIM5
TIM6
TIM7
Now, this is all and well, however, the Photon uses the timers TIM3, TIM4, and TIM5 for the generation of PWM signals on various pins:
PIN
TIMER
NOTES
D0
TIM4
D1
TIM4
D2
TIM3
D3
TIM3
A4
TIM3
A5
TIM3
WKP
TIM5
Timer TIM6 and TIM7 are not (directly) connected to any I/O pins on the Photon, so it would be preferential to use these two timers by directly specifiying one of the two during the instantiation of the IntervalTimer object.
However, as both this library (IRRemote) and the SparkIntervalTimer library support both the Core and Photon as target platforms, it would not be wise to simply assume that TIM6 or TIM7 is available.
The Core has TIM2, TIM3, and TIM4 available, all of which as associated with PWM output pins, so at least some of the PWM functionality will be lost. Unfortunately, my Core is no longer working (the CC3000 WiFi module has failed solder connections, causing the device to remain in an unbootable state), so I am unable to perform any testing for this target.
Platform detection can be performed via conditional preprocessor directives:
#if defined(STM32F10X_MD) || !defined(PLATFORM_ID)
#definePIO_PLATFORM_CORE
#elif defined(STM32F2XX) && defined(PLATFORM_ID)
#definePIO_PLATFORM_PHOTON
#else
#error "--- ERROR: Device is not supported by this library. Only Particle Core and Particle Photon are supported. ---"
#endif/* <PLATFORM DETECTION> */
An ideal solution may be to allow the user to specify their preferred timer(in any case), use automatic allocation on the Core target, and (if not explicitly selected), use either TIM6 or TIM7 on the Photon target. I am currently unsure if TIM6 or TIM7 are used elsewhere; if they are used elsewhere, it may be ideal to select one based on some type of "priority" scheme.
The text was updated successfully, but these errors were encountered:
Due to this implementation's use of the SparkIntervalTimer library, in certain instances, this can cause PWM functionality to become inoperable on certain groups of pins on the Photon (NOTE: this may be true for other Particle devices, as well; I only have a Photon for testing), depending on which hardware timer is allocated to the
timer_isr()
function at the time of instantiation.When the
timer_isr()
function is instantiated, the "dynamic timer allocation" feature will cause the timer to use interrupts generated by one of the following timers on the Photon:Now, this is all and well, however, the Photon uses the timers TIM3, TIM4, and TIM5 for the generation of PWM signals on various pins:
Timer TIM6 and TIM7 are not (directly) connected to any I/O pins on the Photon, so it would be preferential to use these two timers by directly specifiying one of the two during the instantiation of the
IntervalTimer
object.However, as both this library (IRRemote) and the SparkIntervalTimer library support both the Core and Photon as target platforms, it would not be wise to simply assume that TIM6 or TIM7 is available.
The Core has TIM2, TIM3, and TIM4 available, all of which as associated with PWM output pins, so at least some of the PWM functionality will be lost. Unfortunately, my Core is no longer working (the CC3000 WiFi module has failed solder connections, causing the device to remain in an unbootable state), so I am unable to perform any testing for this target.
Platform detection can be performed via conditional preprocessor directives:
An ideal solution may be to allow the user to specify their preferred timer (in any case), use automatic allocation on the Core target, and (if not explicitly selected), use either TIM6 or TIM7 on the Photon target. I am currently unsure if TIM6 or TIM7 are used elsewhere; if they are used elsewhere, it may be ideal to select one based on some type of "priority" scheme.
The text was updated successfully, but these errors were encountered: