[Solved - Tone is now blocking] Updated Core, Serial out now appears to block

Post here first, or if you can't find a relevant section!
danSTM
Posts: 8
Joined: Wed Mar 23, 2016 2:29 am

[Solved - Tone is now blocking] Updated Core, Serial out now appears to block

Post by danSTM » Wed Dec 06, 2017 5:47 pm

Greetings,

I'm wondering if anyone has seen this issue. I was using the master branch (core was downloaded on 7/23/17). After updating from the master today, I noticed that my Serial.prints now take 100x longer or so. They appear to block and are not buffered.

So some change between the end of July and now seemed to cause this. Am I missing something?

Thanks!
Last edited by danSTM on Wed Dec 06, 2017 8:37 pm, edited 1 time in total.

User avatar
mrburnette
Posts: 2026
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Blue Pill - Updated Core, Serial out now appears to block

Post by mrburnette » Wed Dec 06, 2017 6:07 pm

Not to be rude, but you could diff the two images if you backed up the old one. Or, you could look at Roger's change-log on github.

I remember some changes in serial, but nothing that will not be shown from this query:
https://www.google.com/search?q=serial+ ... 2duino.com

Ray

danSTM
Posts: 8
Joined: Wed Mar 23, 2016 2:29 am

Re: Blue Pill - Updated Core, Serial out now appears to block

Post by danSTM » Wed Dec 06, 2017 8:07 pm

I was throw off by the fact I use a tone during my elapsed time benchmark. There was a change to the tone.cpp https://github.com/rogerclarkmelbourne/ ... e.cpp#L189 that now blocks until the tone completes. This wasn't the case before.

Glad I found it. Cheers!

User avatar
RogerClark
Posts: 7541
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: [Solved]Blue Pill - Updated Core, Serial out now appears to block

Post by RogerClark » Wed Dec 06, 2017 9:19 pm

Changes were made to tone to bring them inline with the official Arduino API

victor_pv
Posts: 1791
Joined: Mon Apr 27, 2015 12:12 pm

Re: [Solved - Tone is now blocking] Updated Core, Serial out now appears to block

Post by victor_pv » Thu Dec 07, 2017 2:24 am

Roger, I haven't tried tone in an Arduino board, but from the examples and the code itself, it seems like tone should not block.

User avatar
RogerClark
Posts: 7541
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: [Solved - Tone is now blocking] Updated Core, Serial out now appears to block

Post by RogerClark » Thu Dec 07, 2017 3:37 am

I'll have to take another look, but I thought there were 2 modes of operation, i.e blocking and non-blocking

i,.e if you specify a duration, it blocks and if you don't it just returns and keeps the tone going

stevestrong
Posts: 1950
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany
Contact:

Re: [Solved - Tone is now blocking] Updated Core, Serial out now appears to block

Post by stevestrong » Thu Dec 07, 2017 10:29 am

RogerClark wrote:
Thu Dec 07, 2017 3:37 am
i,.e if you specify a duration, it blocks and if you don't it just returns and keeps the tone going
Yea, that was my interpretation, too (it was my PR which caused the change 8-) )
I found this having the same context: https://github.com/adafruit/Adafruit_Ci ... /issues/17
Accordingly, we could eventually add a fourth parameter for tone() to specify blocking or not blocking, so that backwards compatibility is kept.

Or, we can check at the beginning of tone() whether a previous tone is still playing on the same pin, and only block in this case.

User avatar
RogerClark
Posts: 7541
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: [Solved - Tone is now blocking] Updated Core, Serial out now appears to block

Post by RogerClark » Thu Dec 07, 2017 10:48 am

Steve

I just tried it on a Uno, and it doesnt seem to block

So we'll need to change it back to non-blocking

stevestrong
Posts: 1950
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany
Contact:

Re: [Solved - Tone is now blocking] Updated Core, Serial out now appears to block

Post by stevestrong » Thu Dec 07, 2017 10:50 am

OK, but then at least block at the beginning if a previous tone is playing on the same pin with a given duration.

User avatar
mrburnette
Posts: 2026
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: [Solved - Tone is now blocking] Updated Core, Serial out now appears to block

Post by mrburnette » Thu Dec 07, 2017 1:31 pm

Respectfully ...

This discussion is why I am generally opposed to hacking around on the core files without a clear technical mandate as to the change ... interpretation of what is and what is not being done in the Arduino.cc code base. Then, there is the history of the Leaflabs core that I feel needs to be taken into account as there is a mountain of forum materials over on that site that our efforts here will affect. This concern was voiced yesterday by myself in another post.

There was a time in the past where ever member of this forum was capable of hacking the core to satisfy their particular desires. We have this expertise today throughout only a portion of our user community; many users are novices with ArduinoIDE and Arduino'ish hardware. Every day I read some post that simply should not have been posted because the answer is easily obtained with a search or with a test script.

In my thinking, it is not a critical concern to follow the Arduino.cc methodology exactly - provided that the WiKi reflects the changes and that we offer a work-around for our code base to mimic the Arduino.cc code base, whenever possible. In this regard, I believe that the STM32 silicon is significantly different such that a perfect 1::1 correspondence is not necessary.

Why should an advanced architecture even have blocking commands? We older programmers articulate the evils of blocking - why on earth would we purposefully create a blocking command in the core?

Core names for classes can be different from the Arduino official name. Just document same. If someone does not like it, they can hack the core and change the class names and accept responsibility for their stuff. Or, they can inherit from the core class and provide the class a new name. There is simply no justification to changing something just to be changing a name ... who know what ramifications will occur?

Adding parameters to commands is a sensible solution but still must be documented in the WiKi... we cannot get away from doing the paperwork. The additional parameters must be implemented such that the old behavior is the default without the parameter being specified and the new behavior implemented only when the additional parameter is specified.

I have a lots of other opinions about "stuff" being proposed here ... but this is not the time or place to expand on my opinions.

Ray


The Official Tone command from the .cc site:
Generates a square wave of the specified frequency (and 50% duty cycle) on a pin. A duration can be specified, otherwise the wave continues until a call to noTone(). The pin can be connected to a piezo buzzer or other speaker to play tones.

Only one tone can be generated at a time. If a tone is already playing on a different pin, the call to tone() will have no effect. If the tone is playing on the same pin, the call will set its frequency.

Use of the tone() function will interfere with PWM output on pins 3 and 11 (on boards other than the Mega).

It is not possible to generate tones lower than 31Hz. For technical details, see Brett Hagman’s notes.
The official description of noTone:
Stops the generation of a square wave triggered by tone(). Has no effect if no tone is being generated.
If you want to play different pitches on multiple pins, you need to call noTone() on one pin before calling tone() on the next pin.
Maple documentation from the static Leaflabs.com site:
Generates a square wave of the specified frequency (and 50% duty cycle) on a pin. A duration can be specified, otherwise the wave continues until a call to noTone(). The pin can be connected to a piezo buzzer or other speaker to play tones.

Only one tone can be generated at a time. If a tone is already playing on a different pin, the call to tone() will have no effect. If the tone is playing on the same pin, the call will set its frequency.

Use of the tone() function will interfere with PWM output on pins 3 and 11 (on boards other than the Mega).

NOTE: if you want to play different pitches on multiple pins, you need to call noTone() on one pin before calling tone() on the next pin.

Post Reply