I had a small test program still around which tests the InterruptIn speed: roughly 90kHz max, so that is close to what you observe. I did look into improving it, but a small note for myself: First check if what you want to do is possible: The LPC1768 could be improved by using a special instruction that the core M3 has, the core M0+ of the KL25Z doesn't have that instruction. So no luck there.
So for you a plan B: is it really needed to continiously check the duty cycle of everyone of those sensors? It isn't only checked when you read the value, it is always calculated.
Two options I see:
1. Modify the library so you can disable and enable the measurements. Then keep one enabled, get the value, disable it, do the next one, etc. Downside is that you have to wait a bit after enabling one to get the duty cycle.
2. Combine the four PwmIns into one big class. Then in the class automatically if the pulsewidth of one is measured, measure the pulsewidth of the next one, etc. Upside is that the duty cycle of all your sensors is always known (well it can be delayed a few cycles, but you never have to wait). Downside is that the Interrupts are always being called, method 1 only does it when you need to know the value. Still I think this is the nicest option.
Hi there,
I have four sensors connected to the KL25Z. Each sensor produces a PWM pulse train at 5 kHz, the test signal has a fixed duty cycle of 50%.
With only one sensor connected the program works fine it give nice stable reading, perfect. With two sensors connected the results fluctuate say 10%, With 3 or more sensors the readings fluctuate unacceptably.
The PwmIn library (by Simon Ford) works on basis of interrupts, start timer at the rising transition, read the timer at the falling transition. So the total number of interrupts is 4 (sensors) x 5 (kHz) x 2 (transitions) 40 k/second. Is the KL25Z being overloaded ?
Any suggestions or idea's ?
Thanks,
Gerrit