A 8 bites AVR GCC esetén a size_t 16 bit unsigned, a ptrdiff_t viszont 16 bit signed, hogy a pointerekkel végzett műveletek n lógjanak ki a tartományból. Így hiába 16 bitesek a pointerek, egy tömb mérete nem 64 kB, hanem annak a fele, 32 kB. Nem az elemszáma, hanem a mérete.
A byte mérete 8 bites Arduinon 8 bit, vagyis 1 byte. Ezért egy tömb maximum 32767 elemből állhat. 1*32767=32767
Az unsigned int mérete 8 bites Arduinon 16 bit, vagyis 2 byte. Ezért egy tömb maximum 16383 elemből állhat. 2*16383=32767
Az unsigned long int mérete 8 bites Arduinon 32 bit, vagyis 4 byte. Ezért egy tömb maximum 8191 elemből állhat. 4*8191=32767

Ezért sem érdemes ilyen típusokat használni, mint byte, meg long int. Az adott implementációra van bízva a méretük. Például az Arduino Due az 32 bites, más méretek lesznek.
Helyettük ezek sokkal beszédesebbek: uint8_t, int16_t, stb. Ha van u, akkor unsigned. Utána a szám az pedig a mérete bitben. Ez egyértelmű. És minden platformon ugyanakkora.

Az AVR-GCC limitációja a 32 kB, a hardveré a 64 kB. A pointerek kezelése 16 bites.
De ezzel kezdünk túlmenni az Arduino keretein.
Az AVR Harvard architektúrájú CPU-t használ, a kód és az adat fizikailag külön memóriaterületen található. Külön címtér, fizikailag másik busz. Az egyik a flashben van, a másik a RAM-ban.
Ezért van az, hogy ha létrehozol egy konstanst PROGMEM annotáció nélkül, akkor az a flashben is foglalja a helyet, hiszen nem veszhet el az értéke. De az AVR az adatokat a RAM-ban tárolja, kezeli, ezért bekapcsoláskor ezeket a konstansokat MIND átmásolja a RAM-ba, így ott IS foglalja a helyet.
Nagyméretű konstansoknál, konstans tömböknél ez nem jó. Ezért van beépített utasítás az AVR CPU-ban a flash adatok közvetlen elérésére. Vagyis amikor te PROGMEM annotációval látsz el egy konstanst, akkor az bekapcsoláskor NEM másolódik a RAM-ba. Amikor hivatkozol rá, akkor ugyanúgy teszed, mint bármely másik változóval, tömbbel. Viszont ez másik utasítássá fog lefordulni, mert az adat valójában máshol található. Lassabb is lesz az elérése. Nem csak azért, mert a flash lassabb, mint a SRAM, hanem több és más CPU utasítás kell hozzá.
Ahogy fejlődtek az AVR-ek, igény lett 64 kB feletti memória méretre is. A vas megengedi, hogy több memóriát címezz, mint ami az eredeti 16 bites címtérbe fért. Csakhogy azt már nem éred el natív, 16 bites módon. A 24 bites címekhez több regisztert kell használni (Z és RAMPZ együtt), ami több és más utasítást jelent.
A jó hír, hogy ezt majdnem teljesen elrejti az AVR-GCC. Tehát a megszokott C/C++ utasításokat használhatod, mindegy hol vannak az adataid. Valójában egész más utasításokká fordulnak le.
A rossz hír, hogy mindennek ára van. A RAM kevés, de az ottani konstanst éred el a leggyorsabban. Az első 64 kB flash címzése belefér 16 bitbe, így gyorsabban érhető el, mint az utána lévő terület. Vagyis akárhány darab 32 kB méretű tömböd lehet.
A másik rossz hír, hogy ezeket neked kell szervezned. Ha a konstans tömbjeid elfoglalják az első 64 kB flasht, akkor a kódod már kilóg belőle. Működni fog, de a 24 bites címzés miatt lassabban. Tehát ekkor már a memória térképet sem biztos, hogy érdemes a fordító logikájára bíznod.