Add tone support to StandardFirmata.

[damellis]

As described here:
https://github.com/firmata/protocol/blob/master/tone-proposal.md

The tone branch provides support for tone() and noTone() in ConfigurableFirmata, but it would be great to have them in StandardFirmata too.

[soundanalogous]

I've been hesitant to add Tone to StandardFirmata, especially since it has been proven to achieve using digital write alone. However the use of Tone would be more efficient.

If including Tone consumes very little memory and is not likely to create conflicts with other features in StandardFirmata it may be okay to add. I just want to make sure it won't prevent adding features (in terms of memory usage and any potential timer or other resource conflicts) such as SPI and Software/Hardware Serial.

[rwaldron]

TONE_MESSAGE

[damellis]

Wow, I figured that sending repeated digital write commands would be too slow or jittery to generate good tones. Do you have a sense of how well that works?

This pull request uses a little bit of memory. Flash usage (on the Uno) goes from 12,192 bytes (37%) to 13,732 bytes (42%) and RAM usage from 940 bytes (45%) to 963 bytes (47%).

I would agree that serial and SPI are more important than tone, but it doesn't seem so likely that these bytes will make the difference in being able to support serial and SPI. Do you have a sense of how much memory those features will need?

I don't think there should be timer conflict problems because, I think, SPI and serial don't use the timers. (SoftwareSerial uses the pin change interrupts and tuned assembly delays. The rest are handled by their own hardware, I believe.)

[soundanalogous]

I still need to do memory profiling for SPI and Serial. Serial may use a fair amount of memory depending on where I land with the buffer situation. I haven't looking into SPI support further than an initial protocol (in that I haven't written any code yet) so that will take more work before I have a good idea about memory consumption for SPI.

Tone doesn't consume too much RAM which is nice. One thing to test with your branch is using Tone, a servo and PWM (adjust LED brightness for example) simultaneously and in a few different pin combinations (using PWM pins). See if anything unexpected happens in any of those combinations.

Another thing you'll need to add to your branch is call noTone() on any TONE pins in the system reset callback function.

Wow, I figured that sending repeated digital write commands would be too slow or jittery to generate good tones. Do you have a sense of how well that works?

@rwaldron would know (this is regarding the performance of piezo.js)

[rwaldron]

Actually, let's get @Resseguie @julian_duque @lyzadanger to weigh in on that, since they've done the most work with Piezo

[soundanalogous]

NM about calling noTone() in system reset, I see now that will happen in lines 235-237 when the pins mode are reset in the system reset callback.