search

bbcmicrobit / micropython

Port of MicroPython for the BBC micro:bit
https://microbit-micropython.readthedocs.io
Other
603 stars 284 forks source link

music.pitch latches #643

Closed rhubarbdog closed 5 years ago

rhubarbdog commented 5 years ago

I am writing the game 'simon says'. This issue may have been fixed by pull #607 After a few presses of the correct buttons the note latches and is not effected by music.stop().

here's the code simon.py.txt

It picks a button at random allowing 2 seconds to press the correct button which plays a note on pin2 and displays an arrow pointing at the button. After a few goes the note latches and continues through multiple selections ignoring the music.stop()

dpgeorge commented 5 years ago

I can't reproduce the problem. I can press the correct buttons many times (>20) in a row and the music stops and starts correctly. I used version micro:bit v1.0.1+a92ca9b (from os.uname()).

If you can state the version of the firmware you use, and also provide a test program that exhibits the problem and doesn't need user interaction, that would be helpful.

rhubarbdog commented 5 years ago

No neither can i with just a microbit or my expanded microbit. which has buttons soldered to pin8 and pin16. Tho output from os.uname() is (sysname='microbit', nodename='microbit', release='1.0.1', version='micro:bit v1.0.1+b0bf4a9 on 2018-12-13; MicroPython v1.9.2-34-gd64154c73 on 2017-09-01', machine='micro:bit with nRF51822')

But with a simiar program for this device it latches in a few goes (<5) as per this video https://youtu.be/5ywh9gKy138 . the output for os.uname() for this microbit is (sysname='microbit', nodename='microbit', release='1.0.1', version='micro:bit v1.0.1+b0bf4a9 on 2018-12-13; MicroPython v1.9.2-34-gd64154c73 on 2017-09-01', machine='micro:bit with nRF51822')

How do i get the (newer?) firmware your using? I think it may be an issue with the device, but i think i have had music latching on a lone microbit.

dpgeorge commented 5 years ago

How do i get the (newer?) firmware your using?

I made the newest firmware available here: https://micropython.org/resources/firmware/microbit_1.0.1+a92ca9b.hex

And also the same, but with the PWM patch from #607 applied: https://micropython.org/resources/firmware/microbit_1.0.1+a92ca9b_pwm_fix.hex

Please try both firmware to see if it fixes it.

rhubarbdog commented 5 years ago

Neither firmware helped. There is a slight issue. I updated my copy of uflash a few days ago. How difficult is it to supply a firmware that was used by my copy of uflash when i logged this. These newer firmware seem to have solved the problem for microbit only versions of the program, but not for my device. I'll log it as an issue with them and point them at this conversation

rhubarbdog commented 5 years ago

i found an older copy of uflash on my raspberry pi, it uses this firmware (sysname='microbit', nodename='microbit', release='1.0.1', version='micro:bit v1.0.1+b0bf4a9 on 2018-12-13; MicroPython v1.9.2-34-gd64154c73 on 2017-09-01', machine='micro:bit with nRF51822')

The code in the original post has a latching effect with ~10 presses

dpgeorge commented 5 years ago

Neither firmware helped ... These newer firmware seem to have solved the problem for microbit only versions of the program, but not for my device.

This is a bit confusing... does it mean that both firmware I posted above (with hash a92ca9b) have fixed the issue on a micro:bit only device? But that the bug is still there on your custom device? If so then not much progress can be made here, rather you'll need to work out why your particular device has the problem (maybe due to power supply issues?).

i found an older copy of uflash on my raspberry pi, it uses this firmware ...

That's the same version as you use above.

rhubarbdog commented 5 years ago

Yes it solves the version which supports a microbit and button_a and button_b only. My device has pull up resistors and switches accross pin8, pin12, pin13, pin14, pin16 and pin16.

The thing is the new firmware solves glitches on my expanded microbit which has buttons between +3v and pin8, pin16 with no external circuits, just the pull_down resistors built in to .read_digital()

dpgeorge commented 5 years ago

It sounds like this issue can be closed then?

rhubarbdog commented 5 years ago

Yes i'll do it now

dpgeorge commented 5 years ago

Great!

rhubarbdog commented 5 years ago

I spoke out of turn i wasn't using a copy of the above code to test things i was using a similar program. I have modified the above program to work with my expanded microbit and use pin5.read_digital == 0 rather than button_a.is_pressed() and music.pitch latches.

I think the problem is switches which aren't debounced. The switches on the 3rd party device aren't debounced electronically, and neither are any of my pins in file simon2.py.txt

Is this worthy of reopening, or is it one of those things and poorly constructed electronics are unsupportable?

dpgeorge commented 5 years ago

I just noticed in your code that music.pitch() is called to act on pin2, but music.stop() is called without any arguments, so it assumes music was played on pin0 and stops it on that pin. Instead the code should do music.stop(ubit.pin2) to stop the music.

rhubarbdog commented 5 years ago

Nice one. Now the music stops at least. There's something weird happening that was causing the latching. Until i invent a test that causes it to happen with little or no human intervention leave this closed. Does it require someting in the documentation that music.pitch() can latch, but music.stop() resolves it

dpgeorge commented 5 years ago

There's something weird happening that was causing the latching.

It could be that it's not handling wrap-around of the internal timeout to stop the pitch, but this shouldn't be seen until the device is running for over 1000 hours.

Otherwise, to make progress, there really needs to be a reproducible test for this problem.