when I stumbled across a post somewhere else saying that printing to serial consumes 1ms of time per character you print so if you print anything to serial you're going to lose at least a couple of ms worth of whatever you were doing prior to that.
So, if I'm using input capture to measure frequency and it's calling the input capture interrupt on every falling edge, at a frequency of say 2kHz, I can't send that ICP value I'm saving each cycle to the PC because while I'm doing that I'll miss several subsequent events.
I could try to buffer the events in an array and send them all at once but that won't do anything but make a bigger delay occur less often so there will still be a big hole in my data transmission.
What is the correct means of employing input capture with the intent of measuring ICR and sending each ICR value to the PC over serial without losing any data?
I'm wondering if this is why my ICR values jump all over the place instead of being predictable like the wave I'm generating for detection.
I stumbled across a post somewhere else saying that printing to serial consumes 1ms of time per character you print so if you print anything to serial you're going to lose at least a couple of ms worth of whatever you were doing prior to that.
That's not true, printing to serial either takes very little time, or blocks waiting for buffer space to become
freed up by the serial interrupts that actually drive the hardware. The time can vary significantly.
So long as you don't print too many characters at once and overflow the buffer, or try to output characters
faster than the baudrate permits, it should be very processor-time efficient - there already is a buffer and its
being processed in the background for you by interrupts. All Serial.write() has to do is check there's room
in the buffer and stick the char in.
If you use some sort of software serial library however, then it will be very different.
Ok well that cancels that out I guess. In that case, could there be any other reason you can think of, why Input Capture acting on a clean square wave of decreasing pulse width would spit out random hanging number instead of the steadily decrimenting values I would expect? Does prescaler have something to do with how often the ICU can detect events?
Gahhhrrrlic:
Ok well that cancels that out I guess. In that case, could there be any other reason you can think of, why Input Capture acting on a clean square wave of decreasing pulse width would spit out random hanging number instead of the steadily decrimenting values I would expect? Does prescaler have something to do with how often the ICU can detect events?
Is sounds like you are using interrupts to capture the data, do you have the variables used in both the interrupt service routine and the main code declared as volative, and are you temporarily disabling interrupts while accessing the variable outside the interrupt service routine?
In regards to your comment about serial taking 1mS per character, that is the approximate time it take per character at 9600 baud, hopefully you are using a higher baud rate (1,000,000 baud or higher is possible over the USB interface).
I was using a higher baud but because I can't nail down the cause of the weirdness I didn't know whether it was due to the baud being wrong, the prescaler being wrong or some other coding error. Here is the code in question: