New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
digitalPulse() not working for very short pulse lengths #1749
Comments
Sun 2020.01.19 I made a later comment post 9 at: regarding non whole numbers within an array. I was working with the MDBT42Q breakout board and ran into a simmilar issue. While still unresolved and not fully researched at 'C' code level, I seem to run into issues when pulses got down to around the 200usec range, approx 8000Hz. The docs really don't explain the limits here, and I still can't locate (just haven't put in the time) where the under the hood timing stuff takes place. Simple math 1 / 8000 = 125usec As an observation, if the divisor is from a (not chceked) 16MHz clock crystal, this might explain things. Working on a project/tutorial to replace an Arduino interrupt driven frequency counter example, but need pulses around 1usec width and detection around 10usec duration. Would this be possible? Will continue to gather test data to determine current limits with 2v04 and when sufficient data has been gathered, start a forum post. Robin |
I think the issue you're hitting here is that the timings on ESP8266 are most likely done with the 32kHz RTC. Same thing happens on the NRF52, however STM32 based boards do some crazy stuff to allow them to use a much more accurate timer. While the high speed timer used for digitalPulse is more accurate, it uses the RTC to re-sync itself, and that means that the actual pulse accuracy for long trains of pulses is pretty limited. Basically this is the last bullet point on #1444 We could switch to not using the RTC, but that would mean that if for instance you did a 4000Hz waveform capture of 4000 samples, then a |
Why was this change reverted? Should the issue maybe be re-opened? |
I forget where the discussion on this was now... It didn't seem to make things noticeably better, and was a bit too risky right before the 2v08 release. I've just re-applied it though so I'd be interested to see whether you find real improvements with it |
I compiled and flashed the latest master branch, but it doesn't appear to have made a difference. I'm still seeing pulse trains of 30ms or more, when they should be 27.5ms (referring to http://forum.espruino.com/conversations/354435/). |
see http://forum.espruino.com/comments/15067891/ for details.
The text was updated successfully, but these errors were encountered: