ar-zz-duboy / arduboy Goto Github PK

The conflict is Timer 1 Compare A.

Temp workaround:
Do not use both RGB led and music.

These get compiled in and waste space for anyone not using enlarged font sizes. This uses 216 bytes extra just to compile in drawRect and all it's dependencies when it's never used.

Not sure about the best fix here, but open to suggestion.

If we want to just turn the screen on and off we could probably do that at the hardware level. For a buffer backed game I"m not super sure what the advantage of blanking the screen is with non blank data in the buffer. I think blank() could easily be confused with clearDisplay().

In keeping with the Arduino IDE 1.5 Library Specification, I think that files arduboy_logo.png and arduboy_screen.png should be moved into a directory named extras, and the assets directory removed. The specification doesn't mention allowing subdirectories in the root other than those described, so it's possible that it could cause problems in the future.

If we feel that it's desirable to have a directory specifically named assets for the above files, it could be made a subdirectory in the extras directory.

Quoting the specification:

Arduino libraries will be composed of a number of folders. Each folder has a specific purpose (sources, examples, documentation, etc). Folders not covered in this specification may be added as needed to future revisions.

and:

An extras folder can be used by the developer to put documentation or other items to be bundled with the library.

Reference:
http://community.arduboy.com/t/atomic-puzzle-pack-beta-version/459/22

I think this needs to happen. People want to do different things with audio (and I don't blame them, tunes kind of sucks) and it's impossible because we use ISRs for timer 1 and 3, which a lot of audio stuff also uses. As long as audio.cpp is getting compiled it holds those vectors and no other compiled software can use them... so it's impossible to replace tunes with something else... so that causes people to hack the library and create custom versions of it that then make upgrading to later versions of the library hard (or impossible).

Ripping out tunes would solve the need for this hacking. I propose we split what we've already done into ArduboyTunes and then a program would look something like:

Arduboy arduboy;
ArduboyTunes tunes;

// code
arduboy.audio.begin(); 
tunes.begin(); 
if (arduboy.audio.enabled()) {
  tunes.playSong(...)
}

It looks like the production Arduboy has both a TXLED and RXLED wired on the same pins as the Arduino Leonardo, Micro and Pro Micro (and likely others). Therefore, I assume the Arduboy's pins_arduino.h file will include the definitions for controlling these LEDs as others do. E.g.

#define TX_RX_LED_INIT  DDRD |= (1<<5), DDRB |= (1<<0)
#define TXLED0          PORTD |= (1<<5)
#define TXLED1          PORTD &= ~(1<<5)
#define RXLED0          PORTB |= (1<<0)
#define RXLED1          PORTB &= ~(1<<0)

#define LED_BUILTIN_RX 17
#define LED_BUILTIN_TX 30

For reference: Example 1: Blinkies!

Is this adequate to allow a sketch to control these LEDs or should we include library functions to make it easier?

Note that the RXLED is on the same pin as the DevKit's LED.

Can anyone tell me why we need this? I'm thinking it's a carry over from the tunes library we borrowed from in case you reused timer 0, but we already have the system delay() and timer 0 tracking time so I'm not sure why we need a second delay at all... it doesn't seem to be used internally in the audio class.

Any objections to snipping it?

A #define should be added, and maintained, in Arduboy.h (or core.h if that makes more sense) that gives the version of the library. I suggest ARDUBOY_LIB_VER as the name. This could be used by sketches for conditionally compiled code, so as to work with multiple non-compatible library versions.

The format should be the same as the ARDUINO define provided by the IDE to indicate its version:

• The actual version number, in the form of x.y.z, is represented as a single decimal number consisting of:
• The most significant digits are the primary version number of any length, with no leading zeros (leading zeros would be discarded anyway, when used as a numeric value).
• The two next most significant digits are the secondary version number, with a leading zero or just two zeros if necessary.
• The two least significant digits are the tertiary version number, again with a leading zero or just two zeros.

E.g, for version 1.5.42 it would be:
#define ARDUBOY_LIB_VER 10542
for 167.59.1
#define ARDUBOY_LIB_VER 1675901

For a sketch to work with library version 1.2.0 or higher, and still work with the version it's originally for, it would use:

#include <Arduboy.h>
Arduboy arduboy;
#if defined(ARDUBOY_LIB_VER) && ARDUBOY_LIB_VER >= 10200
AbPrinter text(arduboy);
#endif
// [...]
#if defined(ARDUBOY_LIB_VER) && ARDUBOY_LIB_VER >= 10200
text.print("Hello");
#else
arduboy.print("Hello");
#endif

Later, once the newer library version was well established and available, and it was unlikely anyone would still be using the older version, the sketch could be updated to remove the older version compatibility, if desired.

What are we doing with this example? If anything. Should we remove this folder?

https://github.com/Arduboy/Arduboy/tree/master/examples/Performance

Short answer: Not yet, maybe? TBC.

Bring it on, baby!

Make it easier to notify of new library changes or breaking changes, etc. I think we ought to encourage authors to compiled against the core lib and follow it when it upgrades (to make sure their stuf still compiles, etc).

At least until we have great binary installers.

As per the discussion here in issue #102.

I wrote:

Are removing the ArduboyAudio subclass, and having audioOn() and audioOff() write EEPROM immediately, still good ideas?

@yyyc514 replied:

I'm still thinking about that, sep issue - lets try not to confuse all sorts of things. That makes more sense if there is a mute. I'm not sure someone turning on/off audio in a game should override the system default that they set using the boot tool. Can you open a separate issue to discuss this?

Copied from my proposal here:

For the Arduboy library:

For starters, the ArduboyAudio class is quite small and simple now. I don't think it needs to be a separate sub-class. Let's just move its functions directly into the Arduboy class, adding audio to the beginning of each function. After all, we don't have display or buttons sub-classes. This makes it easier for beginners. They don't have to wonder why they have to use the strange syntax arduboy.audio.on() instead of arduboy.audioOn(). If desired, the function prototypes and code, etc. could still remain in separate audio.h and audio.cpp files (as they are with core), but not as a sub-class.

Next, I'd make audioOn() and audioOff() always set the state in EEPROM, instead of requiring the extra step of calling audioSaveOnOff() to do it. This is another simplification for beginners, and I don't think it causes any problems. There's a chance that a more advanced developer may wish to only temporarily set the on/off state without saving it to EEPROM, but this could be accomplished by making the audioEnabled (formerly audio_enabled) variable public and allow them to directly set it true or false. Also with audioEnabled exposed, there isn't a need for the audioEnabled() function but it could be kept if desired.

I don't think we need audioBegin() (at least as a public user function). Just do what's necessary in the Arduboy constructor or in boot(). We just need to read EEPROM_AUDIO_ON_OFF and set audioEnabled accordingly, and set speaker pin 2 to output low.

[Section about adding tone functions removed]

The new versions of the remaining audio functions:

// Private function, called from the constructor or boot()
void Arduboy::audioBegin()
{
  audioEnabled = EEPROM.read(EEPROM_AUDIO_ON_OFF);
  pinMode(PIN_SPEAKER_2, OUTPUT); // I still think this could just be added to pinBootProgram[]
  digitalWrite(PIN_SPEAKER_2, LOW);
}

void Arduboy::audioOn()
{
  audioEnabled = true;
  EEPROM.update(EEPROM_AUDIO_ON_OFF, true);
}

void Arduboy::audioOff()
{
  audioEnabled = false;
  EEPROM.update(EEPROM_AUDIO_ON_OFF, false);
}

// Optional. User can just use the public audioEnabled variable.
bool Arduboy::audioEnabled() 
{
  return audioEnabled;
}

If we hard code these values there is an easy 72 bytes to be had back - that is just the PROGMEM storage we get back from killing those large lookup tables. The main reason for them to be so abstracted is to support different chips with different port configurations. If we're pretty much locked into the Atmega32U4 for the foreseeable future these could easily be swapped out for hard-wired constants and that space could be used for more ambitious programs.

Thoughts?

It might be nice to include a markdown file with some information, including instructions and author information for each of the examples (ArduBreak, Floaty Ball) in the library.

The current library implements some fairly significant API changes (removal of audio and print functions) that make it non-backwards compatible, and will require many sketches to be modified to get them working again.

I wonder if it would be a good idea to bump up the major version number and call it 2.0.0 instead of 1.2.0? This makes an easy to remember delimiter for the point at which "lots of sketches broke".

When a developer uses Sketch -> Include Library -> Arduboy from the IDE menus, #include <ab_logo.h> is added to the sketch (along with #include <Arduboy.h>). This header shouldn't be included in a sketch.

The reason ab_logo is included is because the IDE includes all .h files residing directly in the src directory.
Possible ways to fix this:

• Move ab_logo.h to a subdirectory under src/ (such as bitmaps) and in Arduboy.cpp change #include "ab_logo.h" to #include "bitmaps/ab_logo.h"
• Change ab_logo.h to ab_logo.c, as glcdfont.c is. Why is one a .h file and one a .c file anyway? They both do the same thing, so should have the same extension. The library should be consistent.

Note that if we decide that glcdfont.c should be glcdfont.h, it should be moved to a subdirectory under src/ as well, for the same reason. It can be the same directory that we put ab_logo.h in.

Just an observation:
The example sketch is named FloatyBall but the intro screen says FlappyBall.

Hold up on boot to enable flashlight mode (screen on, bright).

Thoughts? :-)

I propose that we rename function beginNoLogo() to something like beginNoFrills() and have it free up even more memory for the sketch, while making things more "future proof".

In addition to the boot logo, we've added a "flashlight" feature within the begin() function. Like the boot logo, the flashlight will use some code space that a large sketch may wish to recover.

I've recently proposed a "system control" feature as issue #81 that, if implemented, would also use up some code. I tried to minimise code impact but @yyyc514 has suggested it include basic visual feedback, which could use a fair bit more code space than my original technique. In the future, there could also be other "frills" added that a developer may wish to suppress, if absolutely necessary, to free up code space for use by the sketch.

We could create a whole bunch of begin...() functions to suppress various features E.g. beginNoLogo(), beginNoFlashlight(), beginNoSysControl(), beginNoLogoAndFlashlight(), beginNoLogoAndSysControl() but the number of functions required to support all combinations is unwieldy and could become more so as features are added.

Instead, why not have just beginNoFrills() which leaves out all of these types of features, both current and future ones if possible. We would then strive to make functions for these features public and callable immediately after beginNoFrills().

So, a sketch using beginNoFrills() would start out with maximum memory available and then could pick and chose which "frills" to add back in, space permitting.

We would strongly recommend that a sketch use begin() unless space became tight. We could provide a commented template, and/or an example sketch, that could be cut and pasted in place of begin():

  beginNoFrills(); // use in place of begin to free up maximum memory

  // Each of the following can be commented out or removed to suppress the
  // feature and free up some memory.
  bootLogo(); // Displays the animated Arduboy logo on start up
  bootFlashlight(); // Turns on the RGB LED bright white if the UP button is held during start up
  bootSysControl(); // Allows control of audio mute and screen brightness if the B button is held during start up  

There could be a problem with features that require they be called before some other required internal code in the begin sequence, but I don't think this is currently the case. I don't believe there's a problem with doing the audio set up before doing the above features.

Any objections? This would probably have a significant space savings for programs using lot on the draw functions. I purposely decide a while back to leave X and Y as 16 bit but the screen is only 64 pixels tall and 128 wide... if there a reason someone would be drawing a image (or object) larger than 255x255 to our 128x64 screen?

For the rare person doing this I think it would be beneficial for them to rethink their code and for us to claim these savings. Thoughts?

A piano only has 88 notes... and covers a huge range. Perhaps 128 is overkill... the notes table is using up 256 bytes of flash regardless of whether those notes are every player or not.

Scott216/Arduino_Libraries@5402f18

Can we agree that (by default) unless a sketch chooses not to compile it (for space reasons) that at boot time we should scroll in the Arduboy logo? I downsized the graphics from Arduboy.com and rasterized it exactly but if there isn't agreement on this I probably won't go further.

I thought it would be nice to have some consistency and build in a standard "device experience" that would include toggling brightness, sound, boot logo, etc. Kind of help with the branding of the Arduboy experience.

Another option would be to compile the boot sequence into the Bootloader so that it's completely outside of a sketch... I'm very curious how much space is to spare there. I know the default on Atmega32U4 is to use 4k for the boot loaded, but I"m not sure how much of that space is actually used by the boot loaded now.

I'm trying to recall why we needed to copy and hack the entire library to get it working on Arduboy? The timers? It seems (by default) on our chip playtune would want to use 2, 1, and 0. We've hacked it to use 3 and 1 (which also conflicts with tone of course).

What is the reason this was necessary? USB, SPI, something else?

I wonder if we can't either push a fix upstream or at least push some configurability upstream so we could just use the official library and at the same time tell it we only want to use timers 3 and 1.

Looking at a batch file uploaded to the forums as a template:

@echo off
SET VAL1="C:\Program Files\Arduino\hardware\tools\avr\bin"
SET VAL2=COM5
SET VAL3="C:\Program Files\Arduino\hardware\tools\avr\etc\avrdude.conf"
SET VAL4=COM4

set PATH=%VAL1%;%PATH%

tool\reset %VAL2%
avrdude -C%VAL3% -v -patmega32u4 -cavr109 -P%VAL4% -b57600 -D -Uflash:w:test.hex:i

pause

I see a few questions here:

1. What software to use for the steps (including reset)... Ruby, Python, C#, Bash? I know there are many good choices on Mac/Linux but not sure about the cross-over to Windows.
2. How to do the USB reset (our language really just needs to support serial ports, right)?
3. How to detect the proper USB port for avrdude (or maybe avrdude can figure it out if it's not passed)
4. How to detect the binary and config location of avrdude

I assume for simplicity we'd require installing the Arduino IDE, so perhaps the answer to #4 is that we'd use the default locations for the various platforms.

So how about 1, 2, and 3?

The idea being someone would add "commando.hex" to their github and when somone downloaded the source they'd have not only the source + the binary and they'd know to use the standardize upload process to upload the binary (even if they have no idea how to use the source).

Any objection to including a bitmap image to show so someone knows they are in safe mode? Blinking the LED might be another option... in some cases you might be using safe mode to recover from a sketch that hasn't drawn anything to the screen, so it seems nice if it had some type of UI... but at the same time I don't want to REQUIRE linking in the font table or even drawBitmap. Those are big data sinks if someone isn't otherwise using them. Expensive to require them just to say "Safe" in safe mode... For a bitmap of "Safe" or "Safe mode" you're talking 24-54 bytes.

Though I guess you could get it as little as low as 15 bytes if you used a 3-4px font.

If production ships with a reset button we might change safe mode so it only is compiled for devkits - and prefer the reset button in production units.

I think a reset button and longer (say 16 second) delay would replace the need for safe mode - though I've found it super helpful with the devkit.

As soon as I get my prototype I'll make these changes. @rogosher can you confirm for sure the new pin assignments so I'm good to go as soon as I have the hardware?

Per Chris we make production the default option and you have to change the library to define DEVKIT if that's your intention (and I'll also update my board files - and we should considering forking that repository here).

Reference:
arduino/Arduino#3363

This is because write is a virtual function of Print and the compiler can't (or isn't being told) to figure out whether it's actually used or not. This results in a graphics only game being 1.5-2k larger than it would need to be if it doesn't use any print functions.

I'm thinking it's about time to have multiple subclasses of Arduboy that are situation specific.

If a user is using the frame routines right now a simple sketch might look like this:

void game_loop()
{
  // draw stuff
  // check buttons
  // move stuff
  // fun fun
}

void loop()
{
  // pause render until it's time for the next frame
  if (!(arduboy.nextFrame()))
    return;

  game_loop();
  arduboy.display();
}

You have to remember to call display() or you get nothing at all. I think we should move this into nextFrame()... so immediately after a game loop happens the screen is always displayed. I think this is what users would want 99% of the time. Gamebuino goes so far as to have a persistence option too that will auto-clear the screen before the next frame (or not). So someone can just concentrate on rendering each frame...

Thoughts? Objections?

Another underscore to camelCase change to comply with Arduino library guidelines. Does this one need to be deprecated?

I can created a pull request if desired.

I'd like to suggest cloning this repository and then pushing it back (so it's revision history stays intact) to github as "ArduBoy" and then let ArduBoy/ArduBoy be the official home for the core lib. (see my note about renaming below, that might be a lot easier) After that there are a few things we could do to make the library better compatible with the Arduino ecosystem:

• create examples folder
• create examples/ArdoBreakout and move ArdoBreakout (and it's explicit dependencies) to that folder
• other examples can easily be added at that point and will show up inside the Arduino IDE

I know we may support other toolchains in the future (ino, makefiles, etc) but I don't think this change will have an adverse effect on any of that work. Someone who wants to work on and contribute to the core library itself (vs just link against it) can just checkout the repository local to their project (I still need to test how this works). I think you can do that and still have the library installed globally as well. Or they could develop against the installed library if they were so inclined.

One small change apps will need to make after installing the library globally is that the include now becomes #include <Arduboy.h> vs #include "Arduboy.h" since it's a library not a local source file.

I can make a PR for these also but i think it'd be nice to get the repository moved to a more official location (or just rename it). Renaming it might be much easier actually. I'm hesitant to start contributing a lot until we have a permanent home for the Arduboy library (vs this being the repository for an example sketch).

Thoughts?

What game is the production Arduboy shipping with?

I think it would be a good idea to have this game included in the library examples. After a user loads something else, they may want go back to the default game. Having it as an example makes it easy to find and re-load.

We need to add this for performant games... we lose a lot of time with SPI and one way to get it back is to do the clear for the next frame while we paint the current frame to the hardware. That gives us almost 1% CPU performance back, or more time to sleep and save power.

I'm just not sure what to call it.

displayClearBuffer()
displayAndClear()
paintAndClear()

Thoughts?

Since the Arduboy doesn't have a physical volume control or mute switch, muting the speaker has to be done through software.

EEPROM location EEPROM_AUDIO_ON_OFF has been defined and used to control whether audio is on or off when the sketch calls begin(). There is also function audio.saveOnOff() which allows a sketch to set the EEPROM based on the current state. A sketch can change the state using audio.on() or audio.off() (which doesn't alter EEPROM). The state can be checked using audio.enabled().

I assume that sketches are expected to check the state using audio.enabled() and honor it until a user changes it via a menu or other means.

Let's say a game has set audio off state and saved it to EEPROM. The user then loads a simpler sketch that hasn't implemented audio mute control but just blindly uses audio, such as only calling audio.tunes.tone(). This new sketch won't produce any sound unless the user goes back and loads a sketch that can control audio, uses it to enable audio, and then reloads the simpler sketch.

I'd like to propose a method that would address this problem:

Specify the B button as the "System Control" button. (I like the B button but, if it's preferred, another button could be chosen.) The user would hold the B button down during power up and if a second button is pressed while B is held an operation assigned to the second button would be performed. For starters, I propose that the UP button would set EEPROM to "audio enalbled" and the DOWN button would set "audio disabled". The RIGHT, LEFT and A buttons could be used later for other operations, if need be.

More specifically: In the Arduboy::begin() function, add code that checks if the B button is pressed. While it's still held, loop and check for other assigned buttons pressed, and act accordingly. When B is released, exit the loop and continue on.

For simplicity, there would be no indication that the action had been performed, so the user would just have the hold the button for a sufficient amount of time. An alternative would be to only allow one operation per power up and exit as soon as the button for it was detected and handled, so for multiple changes, multiple power ups would be required.

I've written some code to implement this but I haven't yet tested it. If it's agreed that this is a good idea, I can test it, and clean it up if necessary, then create a pull request. The code is here:
https://github.com/MLXXXp/Arduboy/tree/sys_control

Note that holding the B button alone would just stay in the loop. This is basically the same as what "safe mode" currently does, using LEFT and UP, so we could probably remove the existing safe mode code. (Besides, there's a reset button now, so safe mode probably isn't even required regardless.)

Note that my code also changes audio.save_on_off() to audio.saveOnOff() as per Arduino guidelines. I've created issue #80 for this.

Ref:
http://harizanov.com/2013/02/power-saving-techniques-on-the-atmega32u4/

Not only do you power USB down you also have to freeze the clock.

Someone should be able to not use the very expensive and memory heavy Tunes stuff if they don't want to or if they need the space for a more ambitious program. It probably should not be compiled and linked by default if someone does not use the functionality.

Currently there is a function named not_pressed(), for testing the state of pressed buttons. In keeping with the Arduino Style Guide for Writing Libraries, which recommends using CamelCase instead of underscores in function names, this should be changed to notPressed().

Hopefully not too many sketches have used this function yet, so it's best to change it as soon as possible to minimise the impact.

The style guide also states:

Use begin() to initialize a library instance, usually with some settings. Use end() to stop it.

so start() should be begin(). This one would be harder to change since practically every existing sketch will be using it. Perhaps we could add begin() as a synonym of start(). All new sketches should use begin() and start() could be depreciated once all old sketches had been changed.

Reference:

https://github.com/arduino/Arduino/wiki/Library-Manager-FAQ

Looks like just adding the metadata (my PR already does this) and then just asking they add it to their batch job... and tagging official releases (so their job finds them).

Or pollButtonState()? pollButtonStatus()? getInput is too generic and makes me write library code like:

uint8_t button_state = getInput();
if (button_state & LEFT_BUTTON)

I do that because to me getInput is opaque and I want clarity. What input exactly am I getting? But then I realized the real problem is the name of the method, it could be more descriptive.

Not many should use this directly but we should still have the best name possible

This is done like so:

SPI.setClockDivider(SPI_CLOCK_DIV2);

I'm thinking this should be the default in the core lib. It reduces the wait time spent doing nothing but waiting on the SPI bus to repaint the screen. If the final production version is going to run at 8Mhz we definitely want to do this - just to preserve the current SPI speed. 16/4 = 8/2.

I don't have hard #s right this second but in my testing this reduced CPU % for a blank render loop by around 5-10%. Surprised? I was surprised that a blank render loop is so slow. If all you do is use nextFrame at 60FPS and call clear; print(cpuLoad()); display out of the box you're talking 31% CPU usage.

With this change and a few others I got that down to 18%.

Thoughts, objections? If this is good I can do the work and submit a PR.

Anyone interested? What I mean is removing the compiler defines and letting the software detect which version of the Arduboy it's running on. This would be more important in the future when games are readily swapped in a out via some tool, or on SD.

Questions:

• How much would this increase the compiled flash size?

Ideas on how:

• Poll a floating pin that is wired differently between the two boards (floating on one, connected on another) and would give clear differences
• Check the battery voltage (2.5 vs 3.7), though this would fail when plugged into USB
• Check bootloader? (though I assume right now it's the same across all)

See my comments about this over in #32. Unless we're going to hand-tune more than a few of these methods - and IF our API design is going to be pretty much exactly the same, why not just subclass them? What do we get my having to copy and maintain all those functions individually (and manually port upstream bug fixes, etc).

Obviously we have to implement out own drawPixel (it's a virtual function), and it behooves us to keep using our hardware optimized drawImage (or a better version)... but we're just providing a few low level primitives I'm not sure I see the advantage of having all that additional code to maintain outside of the library it originally came from.

http://community.arduboy.com/t/adding-font-and-removing-arduboy-font/855/3

Probably should make this easier. Providing a custom font isn't that unusual of a thing to want to do. The question is how to do this without getting both fonts linked or requiring you to always set the font after startup.

Easy enough to have a setFont(ptr)...

This is needed:

• So Arduino users don't have to choose "Leonardo" all the time... they can choose Arduboy.
• If we're going to allow 16 and 8Mhz compilation choices.
• It will be needed in the production version anyways to properly set the USB vendor and product ID.

Reference:
https://github.com/yyyc514/hardware_arduboy

This might be in another reposition Arduboy hosts, but since we just have the one now I'm filing this issue here.

Both speaker pins must be set to OUTPUT, or neither will work, like so:

pinMode(PIN_SPEAKER_1, OUTPUT);
pinMode(PIN_SPEAKER_2, OUTPUT);

This is already done in the Arduboy audio library but if someone wants to make their own and doesn't plan on using both pins it can be very difficult to track down why the speaker isn't working.

Reference:

http://marabesi.com/wp-content/uploads/2015/06/badges2.png

We need a badge that authors using ONLY properly linked external libraries can add to their readmes so users know the software will compile properly with core library. Libs that insist on bundling everything themselves wouldn't be eligible for the badge.

Thoughts?

The library generates three compile warnings due to using the always_inline attribute.

core.cpp:145:6: warning: always_inline function might not be inlinable [-Wattributes]
 void ArduboyCore::safeMode()
      ^
core.cpp:112:6: warning: always_inline function might not be inlinable []
 void ArduboyCore::bootLCD()
      ^
core.cpp:93:6: warning: always_inline function might not be inlinable [-Wattributes]
 void ArduboyCore::bootPins()
      ^

I don't like to see compiler warnings. It make me wonder if it might be more serious than just a warning, such as what I described in pull request #69. Is there something that can be changed to eliminate these warnings?

If you feel that the code is correct and the warnings can be ignored, via a quick search I found a possible solution using pragmas . Example (described here):

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-result"
    write(foo, bar, baz);
#pragma GCC diagnostic pop

I tried it, using -Wattributes and containing the entire function, and it worked.

I asked about this over in the tunes repository. I don't see why this should be necessary and it bloats the compiled binary for those not using the tunes stuff fully (or at all).

Related:

LenShustek/arduino-playtune@fc6ad90

I think it would be a good idea to create branches for development work and keep master at the latest tagged release. This way, users grabbing master will (hopefully) always get a stable, documented version of the library, equivalent to what the IDE Library Manager will provide.

The branches could be called development_x_x, where x_x is the next expected release number x.x

Once we're ready to do a new tagged release, we merge to master and tag it. Then, immediately create a new development branch for new work.