add compatibility for PlatformIO

[beau-seidon]

PlatformIO for VSCode is a cross-platform IDE for microcontrollers, and I have found it much easier to use than manually installing the avr-gcc compiler and avrdude then manually burning fuses, compiling, and uploading using the CLI etc. On Linux I didn't experience too much difficulty doing all that manually, but this is the only way I have been able to get it to work on Windows.

This pull request includes configuration files sufficient to simply clone the repo, burn fuse bits, and compile/upload with just a few clicks. I also modified a few source files to fix some errors reported during compilation.

I have tested it on Windows and Linux, but I don't have a Mac to test.

Using PlatformIO with this PR might resolve the compilation issue (#17) circuitcreature reported after changing the optimization level from -O3 to -O2. I have had no compilation issues with -O2.

It should also help n00bs like me who didn't even know what fuse bits meant when I found this repo. It will decrease the extra work required for those who just want a cool new instrument to play with.

[beau-seidon]

The upload_* parameters in the committed platformio.ini file are for flashing the NESizer2 using an Arduino Uno (stk500v1) as an ISP.

My Uno ISP uses the default configuration in the ArduinoISP.ino sketch included with the Arduino IDE.

The upload_* parameters can be modified to use any programmer.

[Jaffe-]

Really nice @beau-seidon , I hope you can help out if someone has questions about using this? I'll merge it if you think it's ready, just let me know. Otherwise just let me know when you want to get it in.

[beau-seidon]

Yes, I'd be happy to help with any issues related to building with VSCode+PlatformIO. I'll also add some instructions and reference links to my half-finished build guide which I will upload... eventually.

Everything seems to be functional after using PIO, and I even figured out how to compile the extra tools, and use them to convert and load samples via VSCode and MIDIOX a few nights ago.

I think it's ready for a merge as is, for the purpose of PIO compatibility. There's an extra .gitignore file in /tools that's not strictly necessary for PIO but I have been fiddling around with sample conversion and I didn't want to upload a pile of windows binaries and Linndrum wav's lol.

Also, would you be receptive to a future pull request strictly for refactoring? I have found a few small styling inconsistencies and things that don't really matter but bother me anyway :). For example, spacing and alignment differences here and there, a mixture of tab characters and spaces, a couple headers which don't have #pragma once, and I found most function declarations have named parameters, but in a few headers they just have the types. There are also a few undefined function declarations in headers, and a few unused variables in the .c files.

I have already cleaned up the header files in one of my branches, but if it's not something you're interested in, I won't bother. If you ARE interested, do you have any personal preferences or recommendations, or specifics I should look out for? I have just been trying to determine your stylistic preferences by reading the code and fixing little differences I find. It's actually helping me understand the way the NESizer works a bit better because I'm reading everything and becoming more familiar with the code.

I'd be happy to continue this topic in a Discussion thread.

[circuitcreature]

Tested this on MacOS (Intel) w/ VSCodium and its working as expected. This did solve my compile issue in the other thread.

Thank you for finding this this looks like it will solve my issue getting a windows 'make' system setup fo me.

[beau-seidon]

Turns out it PlatformIO doesn't even use Make. It uses something called SCons on the backend, and the configuration is all defined in the environment (atmelavr in this case). Environment variables such as build and upload flags can be overridden in platformio.ini.

I have been doing some reading, and found that the default compiler optimization level is -Os (size), but can be changed using:

build_unflags = -Os
build_flags = -O2

I'm not qualified to recommend one over the other. But with the default setting, the memory usage is:

RAM:   [=====     ]  45.3% (used 928 bytes from 2048 bytes)
Flash: [======    ]  60.8% (used 19916 bytes from 32768 bytes)

and I haven't noticed any performance problems. I haven't tried all the built-in sequencer features with the recent commit, but all audio channels and sample playback work normally with an external MIDI sequencer / DAW.

I have only tested the NESizer with the default level, but -O2 compiles to:

RAM:   [=====     ]  45.3% (used 928 bytes from 2048 bytes)
Flash: [=======   ]  71.1% (used 23308 bytes from 32768 bytes)

-O3 doesn't compile because resulting Flash usage is 130.9%.

I'll upload via PlatformIO with build_flags = -O2 this evening and check for a difference in behavior.

[Jaffe-]

Yes, I'd be happy to help with any issues related to building with VSCode+PlatformIO. I'll also add some instructions and reference links to my half-finished build guide which I will upload... eventually.

Everything seems to be functional after using PIO, and I even figured out how to compile the extra tools, and use them to convert and load samples via VSCode and MIDIOX a few nights ago.

That's awesome! I think it's ready for a merge as is, for the purpose of PIO compatibility. There's an extra .gitignore file in /tools that's not strictly necessary for PIO but I have been fiddling around with sample conversion and I didn't want to upload a pile of windows binaries and Linndrum wav's lol.

.gitignore is a good idea, we could move it to the root level so it applies to all directories too.

Also, would you be receptive to a future pull request strictly for refactoring? I have found a few small styling inconsistencies and things that don't really matter but bother me anyway :). For example, spacing and alignment differences here and there, a mixture of tab characters and spaces, a couple headers which don't have #pragma once, and I found most function declarations have named parameters, but in a few headers they just have the types. There are also a few undefined function declarations in headers, and a few unused variables in the .c files.

I'd be happy with a general cleanup PR! I see you already found some errors in headers etc. as part of this PR.

I have already cleaned up the header files in one of my branches, but if it's not something you're interested in, I won't bother. If you ARE interested, do you have any personal preferences or recommendations, or specifics I should look out for? I have just been trying to determine your stylistic preferences by reading the code and fixing little differences I find. It's actually helping me understand the way the NESizer works a bit better because I'm reading everything and becoming more familiar with the code.

Please do! The base style is 4 spaces (no tab) indentation, and otherwise quite K&R-like. Brace on the same line as expressions for if, for, while, etc. Brace on new line for functions. Single line if's might have no braces. I had a phase where comments between the function name and starting brace seemed like a good idea, but not any more. Some files still have that old style which is more than ripe for changing. I'd be happy to continue this topic in a Discussion thread.

[Jaffe-]

Turns out it PlatformIO doesn't even use Make. It uses something called SCons on the backend, and the configuration is all defined in the environment (atmelavr in this case). Environment variables such as build and upload flags can be overridden in platformio.ini.

I have been doing some reading, and found that the default compiler optimization level is -Os (size), but can be changed using:

build_unflags = -Os
build_flags = -O2

I'm not qualified to recommend one over the other. But with the default setting, the memory usage is:

RAM:   [=====     ]  45.3% (used 928 bytes from 2048 bytes)
Flash: [======    ]  60.8% (used 19916 bytes from 32768 bytes)

and I haven't noticed any performance problems. I haven't tried all the built-in sequencer features with the recent commit, but all audio channels and sample playback work normally with an external MIDI sequencer / DAW.

I have only tested the NESizer with the default level, but -O2 compiles to:

RAM:   [=====     ]  45.3% (used 928 bytes from 2048 bytes)
Flash: [=======   ]  71.1% (used 23308 bytes from 32768 bytes)

-O3 doesn't compile because resulting Flash usage is 130.9%.

I'll upload via PlatformIO with build_flags = -O2 this evening and check for a difference in behavior.

The flag was -O3 until I rewrote the sample storage file system back in the fall. Then I switched it to -O2 because of the flash size. I think we'll keep it at -O2 for now, but if more space is needed we might look at -Os again. The last time I tried -Os it did not reliably play samples at the correct speed, but that was quite a long time ago. If you run it compiled with -Os for a while and don't see any trouble, let me know.