Skip to content
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

tone() with a frequency of 0 will crash Oak #75

Open
pfeerick opened this issue Dec 20, 2016 · 1 comment
Open

tone() with a frequency of 0 will crash Oak #75

pfeerick opened this issue Dec 20, 2016 · 1 comment

Comments

@pfeerick
Copy link
Contributor

pfeerick commented Dec 20, 2016

This bug originates from the ESP8266 Arduino core implementation, but I am also referencing it here as I will crosslink the two issues so it is easy to implement a solution once the best course of action is decided.

As per a discussion thread on the forum, an issue has been idenfied in the tone() function that caused the example sketch to fail. Whenever the tone command is issues with a frequency of 0, it will crash the sketch, and the Oak just freezes (on the pure ESP8266 core it instead reboots).

The workaround I have suggested for now at the sketch level for the example sketch is to use an if statement to catch a zero frequency call, and issue the noTone() command instead and then delay for the specified duration. In the example this happens as there is a series of notes specified in an array, and a '0' is used as a pause in the melody... with unexpected results on the ESP8266! 😢

i.e. Instead of

tone(3, melody[thisNote], noteDuration);

to use

if (melody[thisNote] == 0)
{
  noTone(3);
  delay(noteDuration);
}
else
{
  tone(3, melody[thisNote], noteDuration);
}
@pfeerick
Copy link
Contributor Author

A second tone related issue has come up on the forum on the same thread, where tone() will only work on P3. Due to a fluke in P3 aligning with GPIO3, and the tone melody example using P3, it was probably not detected that esp8266_pinToGpio was not needed in this library. I'll submit a pull request to remove these calls, along with some test code to demonstrate that it isn't needed. I'll also patch the tone '0' issue, with the same fix I proposed over on the ESP8266 github.

pfeerick added a commit to pfeerick/OakCore that referenced this issue Dec 21, 2016
The '_pin = esp8266_pinToGpio[_pin];' pin remapping is not needed in the tone library - this actually broke the tone support, and only worked with P3 as it remaps to GPIO3. Demo code is included in digistump#75
pfeerick added a commit to pfeerick/OakCore that referenced this issue Dec 21, 2016
The '_pin = esp8266_pinToGpio[_pin];' pin remapping is not needed in the tone library - this actually broke the tone support, and only worked with P3 as it remaps to GPIO3. Demo code is included in digistump#75
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant