I’m not sure what’s confusing about
If you turn the sound on then the sound will be played regardless of the user’s EEPROM settings, which generally isn’t desirable.
generateRandomSeed() is fairly explicit about the idea that it should be used to seed a PRNG.
Admittedly it doesn’t say outright that “this function isn’t suitable to be used like a PRNG”,
but it’s supposed to be strongly implied at least.
If you’re wondering why that’s the case, basically the noise it uses as a source is random enough to act as a seed but probably not random enough to be a suitable PRNG.
And even if it were suitable, it’s somewhat slower than a PRNG would be anyway because it has to:
- enable the ADC
- wait for some pin states to change
- disable the ADC
All of which is pretty time consuming compared to the mathematical operations a PRNG would use.
If it’s only for the title screen then yes, an image would probably be a fair bit cheaper.
A common mantra in C++ is that “you don’t pay for what you don’t use”.
In this case if you don’t use a function, it doesn’t end up in the compiled executable (
There’s some more useful bits and pieces here.
A lot of people don’t realise this, but the Arduino library is actually backed by an implementation of the C standard library called ‘avr-libc’, which has a number of AVR-specific features, including all the progmem manipulation functions and macros.
If by ‘formatting’ you mean
printf-style format strings then no.
But if you mean “can I give it an integer and have the integer printed” then yes, It has overloads for various different types.
print(10) will call
print(0.5f) will call
print(float) et cetera.
(You can see a list of these in
Print.h. In case you’re wondering,
const __FlashStringHelper * is part of what makes the
F macro work.)
Using those functions possibly requires more progmem (it might, it might not - I’ve never measured it),
but because it’s printed directly to where it’s needed you don’t need a
char buffer as a middle man so it uses less RAM.
If you absolutely have to have a
char buffer then it’s possible that there might be a class somewhere that acts as a
char buffer and inherits
in which case that might be cheaper than using
snprintf because it wouldn’t need to do the parsing that
snprintf has to do.
(If there isn’t one, I’m pretty sure that I know how to write one.)
You’re not doing anything wrong, you actually can’t do that.
Reading from AVR’s progmem actually requires a different machine code instruction to reading from RAM.
pgm_read_ptr et cetera all end up as inline assembly that use that special machine code instruction,
memcpy_P is essentially a rewrite of
memcpy that uses that special progmem-reading instruction instead of the RAM-reading instruction.
Also it’s impossible (as far as I know) to automatically detect whether something is in progmem because objects in progmem and objects in RAM have the same datatype (
PROGMEM is actually implemented as a compiler-specific attribute).
There are a few ways to differentiate,
but all the ones I’m aware of require extra work from the programmer.
As mentioned earlier in my comment, using the various overloads of
print provided by
Print might save memory because they don’t involve parsing a format string.
Any form of
printf-like function has to go through the format string, look for
%s and then use the following characters to determine which type to interpret its variadic arguments as.
Print::print simply relies on function overloading,
so the type detection is done at compile time instead of runtime.
(There is also a mechanism for introducing new types that can be printed,
but the developers chose a bad way to implement it,
so it costs more memory than it should and it will only work for
If you have any more questions or want any more suggestions, don’t hesitate to ask.