-
Notifications
You must be signed in to change notification settings - Fork 1.3k
pulseio.PWMOut() instantiation fails sometimes with constant same frequencies on CPX #1626
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
Comments
For what it's worth I tried it on I've written some python code that now tries to initialise them with retries and then reverses order. My current implementation doesn't seem to be that useful as a workaround. Control-C/Control-D for a soft reset will eventually work but it often takes ten attempts :( |
Try this uf2. I made one minor change to wait for a reset of a TCC before proceeding. But I don't see anything else wrong, like uninitialized variables. |
Also, if that doesn't fix things, I'd be interested to know if you see any difference when using a lower frequency (like 2000 instead of 2000000) |
|
The uf2 I gave you fixes something that's probably inconsequential, but I would keep that change anyway, so test against that. Have you looked at the |
From some brief testing, 2kHz seems like similar behaviour with many failures using I can't see a clear pattern yet, maybe a power off makes it more likely to initialise ok but it's not on the first execution of code.py as one might expect. The second attempt (i.e. power off/on, auto-execute code.py, soft reset post exception, second code.py execution) seems pretty successful though. I've not yet fully grasped the whole TC/TCC sharing thing. I got excited when @tannewt suggested something which then worked (some of the time) and have focussed on the application coding since that. |
OK, it was an arg processing bug. Even though you said |
I've just tested that latest version, |
I just using I think we can rule out user error here because the whole lib directory has gone AWOL and that takes ages to delete so I would have noticed if I'd done this accidentally. If this is a bug it's a nasty one especially for anyone who only saves code to the device. Is there anyway the file system can be auto reinitialised to this state? |
It's getting weirder, the wavs have disappeared and a |
My
but earlier it had a large hex number with some hypens with braces on either end. I've also noted that if i leave the CPX doing not much in REPL (I had a for loop printing the time every 10 seconds) then if I control-c that ten minute later then control-D for a soft reset the soft reset doesn't complete. |
I've decided to go back to 4.0.0 beta 3 to see if that's stable. I put that on and this popped out when I connected to serial console afterwards:
and has a date of 1-Jan-2000 which is a bit odd (date may not be off, these things dont have battery backed clocks on them, of course). I'm going to |
4.0.0 beta 5 looks good, btw. |
I'm seeing some rather non-deterministic behavior with creation of
pulseio.PWMOut()
. I've been discussing how to get the most PWM outputs on a Circuit Playground Express: https://forums.adafruit.com/viewtopic.php?f=60&t=148017. I can sometimes get four by using the same frequency andvariable_frequency=False
but not always! Example below is a variant of 4.0.0 beta 2 with nocode.py
/main.py
and after a power off/on to rule out any accumulated-weirdness(tm):Note in that last attempt where a "retry" surprisingly works, the order is reversed for p2 & p3 instantiation. Although in general, I've had more success with p3 first then p2.
I'd welcome a workaround too if this can't be fixed in 4.0.0. Perhaps I could code it up so it makes p2, then tries p3 ten times and if that doesn't work then then cleans up, makes p3 then tries p2 ten times?
The text was updated successfully, but these errors were encountered: