I created / modified an Arduino chestsheet to include those items I often forget the syntax. And to aid in keeping my code more consistent.
This is a draft, if you have a mind to, please provide constructive criticism and/or suggestions.
I am planning a rear sheet that will include the Arduino Reference Index. The goal is to have a quick reference for a complete list of functions etc.
CheatSheets_draft_v01.pdf (420.5 KB)
while loop return x; // Or ‘return;’ for voids.
They are functions not voids.
A void is a return type or a completely empty space. 
50 days overflow
of millis(). True but almost 100 percent irrelevant, if you do the maths correctly. Just sayin'.
unsigned char (0 to 255) use byte
Nooo! Old school, sorry. My favorite data type. Known everywhere by everyone, I can actually type unsigned char faster than I can type byte and be sure I remember what it means...
volatile - use RAM (nice for ISR)
most variable variables use RAM, volatile has special use for ISR and, for all I know a few other niche areas. Just say for safe sharing ISR variables or something like tht.
* value pointed to
Maybe a cogent fleshier example, I'll ask the crew.
//Write High to inputs to use pull-up res
Lose that... true but obsolete by INPUT_PUKLUP. Comes in with direct port manipulation, which I think I see you get to…
except you leave off the DDRX register, which is the third leg along with PORTX and PINX.
But a heroic effort draft document, it is amazing how compact C is and how much of what many ppl ever do with an Arduino can fit like this on a reference card. Not cheating, no.
I am reminded of those laminated 8 x 11.5 cards covering, for example, organic chemistry. LOL, worthless.
Here, much more claim to usefulness.
Looking forward to being picky about the next version.
Oh, can you work
( ) parenthesis, parentheses
[ ] brackets
{ } braces
on in there somewhere?
Hot dogs are up. Just in time, CU.
a7
Thanks John.
Maybe add Casting examples too ? 
Maybe how to turn off internal pull-ups also.
Write High to inputs to use pull-up resistors
AVR specific
Thanks for the great suggestions. You've pointed some areas that need attention 
about "unsigned char" vs "byte" I couldn't find anything that identified more that just preference. I have been using uint8_t and am trying to move to more common terminology.
BTW if I were to start using "unsigned char" I would:
#define unsigned char uchar
I'll try to better describe volatile.
Thanks, I'll add Casting as soon as I figure how to clearly describe it (and understand it).
Turn off internal pull-ups is good
Thanks, I will either remove the "write High" option or add an AVR notation. Really I think removal is best else it could cause confusion.
In general the goal of this sheet is to make my code more consistent.
I also plan to expand the ++j and j++ section
On top of what other said
You have the Qualifiers twice, one is probably enough
On arrays, as this one is for pins
int myPins[] = {2, 4, 8, 3, 6};
I would suggest
const uint8_t myPins[] = {2, 4, 8, 3, 6};
As pins are usually constant and don’t require more than a byte to store…
Thanks I'll trash the second "Qualifiers" and instead duplicate "Constants"
seriously thank you for noticing.
I'll made some note somehow that pins should/could be "const".
int myPins[] = {2, 4, 8, 3, 6};
I would suggest
const uint8_t myPins[] = {2, 4, 8, 3, 6};
As pins are usually constant and don’t require more than a byte to store…
I was trying to get away from uintn_t so it could be byte.
The advantage of uint8_t is that it is part of C++
byte is just a #define for uint8_t anyway… that’s arduino’s environment specific. (As boolean instead of bool)
Side note: some of your comments apply to AVR / 8 bit MCU, like the min and max values of int, an int would be 4 bytes on a MKR or ESP32 for example.
I have been trying… old habits die hard. And in "regular" programming, you don't get all those standard names w/o including stdint.h. It looks like Arduino rolls that in behind the scenes. But I def love the unambiguous and portable plain old declarations.
PORTB |= bit(BP2) | (PB5); // same as above, recommended
should be
PORTB |= bit(BP2) | bit(PB5); // same as above, recommended
EIMSK |= bit (INT0); // set INT0 bit
should be in one bubble. Or... not on there at all! Interrupts could take a very big bubble…
But don't forget
digitalPinToInterrupt()
which can save some hair
conspicuously absent, maybe you don't use
strcpy
strcmp
sprintf
and so forth.
a7
I would recommend their n or l versions (strncpy, strlcpy) then as well for safety
I'm struggling here to define (for the consistency of my code). While i like int32_t, I'm more comfortable with byte than uint8_t. And I don't know the xxx_t form of boolean.
And I like "bool" but it seems Arduino pushes "boolean"
should be (fixed, thanks)
PORTB |= bit(BP2) | bit(PB5); // same as above, recommended
Maybe all anything to do with interrupts, includingEIMSK |= bit (INT0); // set INT0 bit
[/quote]
I changed this to a different bubble. It was to show the syntax of setting a register bit not interrupt related.
I've read C "strings" are evil. Not sure they should be here, the implication is that they are recommended.
Do you mean this?
It’s about the String class, not cStrings (and is somewhat biased).
cStrings are not evil but require attention and care to not overflow the underlying buffer. As long as you take the necessary steps to test and catch that, you’ll be fine. That’s why I referred to strlcpy() or strncpy() where the buffer size or amount of bytes is taken into account.
Understanding cStrings is good for mastering arrays in general so a worthwhile time investment. They are also more memory and CPU efficient than using the String class which helps on small arduinos.
reconsider that. See what Arduino is using in wiring_digital.h and use that type.
Just came across this while trying to catch up to the 21st century:
std::bytecannot have arithmetic performed on it, which might be a deal breaker.
I'm not where I can run and see if this is true. If it is, def a deal breaker. Even if it is somehow not true for Arduino.
L8R:
So, a little incompetent experimentation has left me cold to the idea of using Arduino's unique data type byte instead of either unsigned char or uint8_t.
Just to keep as much the same in different programming circumstances.
The std::byte type does indeed restrict the kinds of things that can be done with it, the Arduino byte behaves and must be typedef somewhere as uint8_t. As unsinged char.
Now let's do bool and boolean, which have some odd things about them!
As I said, old habits die hard. true and false, no thanks. bool, not gonna use it. byte? whose byte?
and, or, not? I don't think so. Get over it.
a7
Hate to p**s on your chips here - but there are a number of cheat sheets which you might like to look at
That’s the C++ thingy meant really for bitwise operations.
std::byteis a distinct type that implements the concept of byte as specified in the C++ language definition.
Like char and unsigned char, it can be used to access raw memory occupied by other objects (object representation), but unlike those types, it is not a character type and is not an arithmetic type. A byte is only a collection of bits, and the only operators defined for it are the bitwise ones.
Byte in arduino land is just a #define for uint8_t so an arithmetic type on which you can do maths
