Oh, I just forgot … one more word about the getters and setters with assertions and logging. These features become especially useful once Kaleidoscope together with all of its plugins gains a test bench (see Jesse’s post about regression testing).
Of course, logging and assertions come with a lot of string literals that bloat binaries. @craigdissel’s Hardware-Virtual plugin enables running sketches on x86. There, memory resources are almost unlimited compared to the atmega32u4. I would, thus, in general recommend excessive use of assertions to everybody who develops core/plugins. Used in test benches, log output can shorten the time to find errors, sometimes without starting a debugger.
I am currently trying to find a way to simulate the 01 with simavr (see Model 01 Simulator). Even in a simulation of an avr with its naturally very limited resources, assertions and logging both are applicable. How, you might ask, is this supposed to be possible for a firmware sketch that is likely already at the limit, with respect to resource consumption? The answer is simple, however not obvious: Simulations have the intriguing property that they are not real.
What is not real is also not subject to real restrictions. All 8 bit avr processors are binary compatible when it comes to their data types and addressing. With simavr it is possible to run a firmware on an artificial hardware with extended resources. I did this in other occasions with an atmega1280 to debug code that was actually targeted for an atmega32u4, using gdb. Either I will find a avr processor that is like an atmega32u4 (including USB, etc.) with more flash and RAM (if there is such a beast) or I will just create a virtual one (let’s call him atgiga32u4). simavr allows you to specify the properties of the processor.
Eventually, the Hardware-Virtual plugin will find 99% of all errors. Together with a simulation it will hopefully be 99,9%. Make assertions your best friend!