I’m creating a project to control my Fujitsu mini-split heat pump that sends ~200 ms IR pulse trains. Unfortunately, there’s no way to know whether the unit receives the signal, so I’m trying to make sure the signal is sent as reliably as possible. Is there a way to make sure system generated interrupts don’t come in the middle of the pulse train? Will running with SYSTEM_THREAD(ENABLED) do that? Currently, I’m generating the pulses with pinSetFast, pinResetFast, and System.ticksDelay() to create the necessary timing. The function that does this is called from the callback function of a Particle.function().
For strict timing requirements, I plan to allow the application to disable task switching for short periods so that timing sensitive code isn’t switched out.
If the pulses are 200ms, you might be better off using the SparkIntervalTimer library, since that’s a long time to stop task switching.
1 Like
how timing sensitive? Stopping scheduler (!) still leaves interrupts occuring, e.g., systicks. That’s in the 2-10 microsecond realm.
@mdma, does the SparkIntervalTimer do what I want? It appears from the code, that the interrupt priority isn’t that high (though I suppose I could change that). Also, I’m not sure whether microsecond timing is fine enough to generate the 38 kHz carrier (I don’t know how sensitive the receiver is to that frequency – I get either 38.5 or 37.5 kHz when I use delayMicroseconds() instead of System.ticksDelay()).
@Ric, so what you really want is a 200ms gated 38KHz signal. You may want to use an external modulator which you can gate with a GPIO pin at 200ms intervals.
As for the microsecond timing, it is possible to run the timers at higher frequencies to get sub-microsecond accuracy. However, you would still need to service interrupts at 26.3 us intervals which leaves little time for ISR code.
1 Like
@peekay123, It’s not a single 200 ms pulse, it’s a series of pulses that last approx. 200 ms. The whole sequence is 16 bytes long with 16 cycles of carrier-on interspersed with either 16 cycles (for a 0) or 46 cycles (for a 1) of carrier-off.
I did think about using an external modulator to create the carrier, though I was hoping to avoid that. If I did it that way, I would need to turn it off for 420 or 1200 us interspersed with on for 420 us. If I used the SparkIntervalTimer library to do that, would that still not get interrupted by high priority system interrupts?
search for hardware PWM in the forum or uPWM,
You will be able to do this with both,
BTW the UART is designed for stuff like this!
2 Likes