A few comments:
- I agree that you need to run at or near full speed for this to be useful.
- I suggest removing the WAIT 0 and just keep the WAIT 1. The WAIT0 is only needed for the first time round the loop (as subsequently you always reach that point having just detected the pin at zero), and the code as written will have trouble if the gap between pulses is very small - the next pulse has already started by the time you are waiting for it to be zero.
- I suggest push noblock in place of just push. When the system is working normally, the ARM side should be clearing the FIFO before it fills so this makes no difference. However, if it ever does block then that will mess up the counting of the next pulse. Better to just drop one measurement and go on to making the next one; in this application it doesn't actually matter if one gets lost.
- Stylistic only: I suggest using wait 1 pin 0 rather than wait 1 gpio xxx. This will work exactly the same, but now your code is parameterised by the pin mapping registers, hence you can use one copy of the code for up to 4 of these PWM inputs because you no longer have the pin number burned in to the PIO code. You are already doing sm_config_set_in_pins() to enable this (and that statement is actually having no effect with the program as you have it now).
But these are largely fine-tuning comments: your code looks like it should mostly work as it is now.
It is worth checking carefully with a 'scope that the pulses being generated by the external hardware are actually what you think they are. I have some code that does exactly what you are doing; unfortunately I can't share it with you for commercial reasons, but you wouldn't want it anyhow since it's now full of horrible kludges to recover from the glitchy behaviour of the chip generating the pulses that I'm trying to measure. On that particular chip, what's supposed to be a simple PWM like you have described appears to be sampling the raw measurement on some other clock that's asynchronous to the PWM clock, and you get a glitch on the output at the beat rate of the two clocks. It all works fine if the PWM is just used to drive a loudspeaker (which is the chip manufacturer's intention), but it is a royal pain to capture the audio for further processing. You obviously aren't using this same chip, but I mention this just as a cautionary tale that PWM outputs intended to be treated as analogue are not necessarily easy to sample digitally.
- I agree that you need to run at or near full speed for this to be useful.
- I suggest removing the WAIT 0 and just keep the WAIT 1. The WAIT0 is only needed for the first time round the loop (as subsequently you always reach that point having just detected the pin at zero), and the code as written will have trouble if the gap between pulses is very small - the next pulse has already started by the time you are waiting for it to be zero.
- I suggest push noblock in place of just push. When the system is working normally, the ARM side should be clearing the FIFO before it fills so this makes no difference. However, if it ever does block then that will mess up the counting of the next pulse. Better to just drop one measurement and go on to making the next one; in this application it doesn't actually matter if one gets lost.
- Stylistic only: I suggest using wait 1 pin 0 rather than wait 1 gpio xxx. This will work exactly the same, but now your code is parameterised by the pin mapping registers, hence you can use one copy of the code for up to 4 of these PWM inputs because you no longer have the pin number burned in to the PIO code. You are already doing sm_config_set_in_pins() to enable this (and that statement is actually having no effect with the program as you have it now).
But these are largely fine-tuning comments: your code looks like it should mostly work as it is now.
It is worth checking carefully with a 'scope that the pulses being generated by the external hardware are actually what you think they are. I have some code that does exactly what you are doing; unfortunately I can't share it with you for commercial reasons, but you wouldn't want it anyhow since it's now full of horrible kludges to recover from the glitchy behaviour of the chip generating the pulses that I'm trying to measure. On that particular chip, what's supposed to be a simple PWM like you have described appears to be sampling the raw measurement on some other clock that's asynchronous to the PWM clock, and you get a glitch on the output at the beat rate of the two clocks. It all works fine if the PWM is just used to drive a loudspeaker (which is the chip manufacturer's intention), but it is a royal pain to capture the audio for further processing. You obviously aren't using this same chip, but I mention this just as a cautionary tale that PWM outputs intended to be treated as analogue are not necessarily easy to sample digitally.
Statistics: Posted by arg001 — Tue Dec 10, 2024 9:53 pm