-
Notifications
You must be signed in to change notification settings - Fork 418
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
waveforms and SYNC: unexpected behavior? #457
Comments
After a quick read I don't see anything wrong with you are doing. The use cases that I'm most familiar with will apply a new/different wave ID to sync to. Can you try another wave ID, ie, create two identical waves.
|
Thanks! I followed your suggestion to create two waves and then alternate between them. This behaves better in the case of widely separated pulses, in that there is no repeating train of spontaneous waves at the end. However, if a second pulse is requested before the first one is complete, the second is still dropped and never appears. |
The canonical use case: After your delay(s) you should make sure the wave has completed before requesting another synchronous wave |
Thank you, knowing the common use case is helpful and makes sense - I'm guessing I should use However, I'm then confused about the purpose of the |
The method is called
Yes. But what (I believe) needs to be avoided is to 'sync' to a wave that is already 'synced'. The internal structures are similar to liked lists. I think it's possible to create a 'repeat forever' situation if you are not careful. With all of that behind us, please send me your updated code snippet that shows unexpected behavior and I will look into it this week. |
I finally had time to test this again. I think what you're saying is that creating a new wave with a new ID each time a pulse is sent should work properly, because we saw that reusing wave IDs (or using a single ID for all pulses) can cause an infinite loop as you pointed out. Unfortunately I still see that some pulses are dropped. Here's a small modification that demonstrates this on my system.
My interpretation of the docs was that waveforms could / should be reused, and that using |
I've run your above example code but truncated it after sending the third wave just to focus on the first problem encountered. |
Indeed changing send_wave(pulses, 2, 1.5*pulse_width_ms); to send_wave(pulses, 2, 0.5*pulse_width_ms); appears to make your example work. |
(as mentioned in this raspberry pi forum post)
I'm using the pigpio C interface to generate a pulse signal (basically a single period of a square wave) at varying intervals. The behavior I'd like to see is that if a new pulse is created while the previous one is still being sent, that previous one will not be interrupted, but instead will run to completion before the new one begins.
According to the pigpio documentation here, I think I should use
PI_WAVE_MODE_ONE_SHOT_SYNC
when callinggpioWaveTxSend()
for each pulse:However, if the time between two consecutive pulses is shorter than the period, I have observed that the second pulse can be dropped. And if the time between the two pulses is longer, then both are generated correctly, but after that, new pulses are spontaneously and repeatedly generated at the maximum possible rate.
As an example, suppose my pulse is 50ms high followed by 50ms low. I call
gpioWaveTxSend(wave_id, PI_WAVE_MODE_ONE_SHOT_SYNC)
at t=0, and then call it a second time at t=200ms. I see a pulse starting at t=0 and a pulse at t=200, as expected, but I then also see pulses beginning at 300, 400, 500, ... repeating endlessly even though I have only called the send method twice.Here is a small example that produces this behavior for me:
I'm using a raspberry pi 4b with stock raspberry pi OS and v79 of pigpio.
The text was updated successfully, but these errors were encountered: