Pointers, Arrays, and Addresses

uint32_t a[6]; reserves $6 \times 4 = 24$ consecutive bytes. In almost every expression the name a decays to a pointer to its first element (§6.3.2.1). Subscripting is defined in terms of that pointer, §6.5.2.1:

$$a[i] \equiv *(a + i)$$

and pointer addition is scaled: a + i is not the address plus $i$ bytes but plus $i \times \text{sizeof}(*a)$ bytes, so that it lands on element $i$ whatever the element size.

↑ This step uses the figure at the top of the page.

Switch the element type in the figure. The same index 2 reaches 2 bytes into an array of uint8_t, 4 into uint16_t and 8 into uint32_t. This scaling is why a pointer has a type at all: p + 1 must know how big one thing is. It also means (uint8_t *)a + 2 and a + 2 are different addresses; a cast changes the step size.

The standard allows you to compute the address one past the last element, a + 6, and to compare against it, which is what makes for (p = a; p < a + 6; p++) legal. It does not allow you to read or write there, and it does not define pointers any further out (§6.5.6 ¶8). There is no bounds check: a[6] = 0 compiles, and writes 4 bytes into whatever variable the linker placed after a. CERT ARR30-C collects the ways this goes wrong.

Inside void fill(uint32_t buf[], int n), the parameter buf is a pointer, whatever the brackets suggest, and sizeof(buf) is 4, the size of a pointer, not 24. The length must travel with it as a separate argument, or as a struct that carries both. The idiom for a real array in scope is

#define COUNT(arr) (sizeof(arr) / sizeof((arr)[0]))

which works only where arr is still an array, not once it has decayed to a pointer. Compilers will happily compute sizeof(ptr)/sizeof(ptr[0]) = 1 and say nothing.

The processor does not distinguish a memory cell from a peripheral register: both are addresses on the bus. The datasheet says a GPIO output register lives at, say, 0x4001_4014. To write it from C you convert that integer to a pointer and go through it:

#define GPIO_OUT (*(volatile uint32_t *)0x40014014u)
GPIO_OUT |= (1u << 5);       /* set pin 5 */

Read it inside out: the integer literal is cast to “pointer to volatile 32-bit unsigned”, the * dereferences it, and the macro then behaves like a variable. Converting an integer to a pointer is implementation-defined in standard C (§6.3.2.3 ¶5): the standard does not promise the address means anything. Every embedded compiler defines it the obvious way, so this is universal practice, but it is a target convention, not a language guarantee. The volatile is essential and is the subject of lesson 5.

A DMA engine fills uint16_t adc[64] and the linker placed it at 0x2000_0400. Where is adc[17], and what does the DMA see?

$$\&adc[17] = 0\text{x}2000\,0400 + 17 \times 2 = 0\text{x}2000\,0422$$

The element occupies bytes 0x2000_0422 and 0x2000_0423. The whole buffer is $64 \times 2 = 128$ bytes, ending at 0x2000_047F; the one-past-the-end address 0x2000_0480 is what you would give as a loop bound or as “buffer end” to the DMA, never as a place to write. A DMA controller is programmed with exactly these numbers: a start address and a byte or element count. It does not know the array’s name or type; the scaling you get for free in C is your responsibility in its registers.

If a colleague declares the buffer as uint8_t and reads 16-bit samples with *(uint16_t *)&buf[1], the address 0x2000_0401 is odd: a 16-bit load from an odd address is an unaligned access, which lesson 4 covers, and which a Cortex-M0+ will refuse with a fault.