Re: Fscking Pointers.

Andy Burns <usenet@andyburns.uk> wrote:

The Natural Philosopher wrote:
 

It seems C has caught the disease of 'we will modify your code according
to what WE think it means'..
 
..my pointers to 254 byte structures are going haywire when I add 256
bytes to them...I have to add one instead...

 
if C knows the thing being pointed to is a 254 byte struct, then adding
256 to it will move it by 65024 bytes surely?
 
 
adding 1, will move it by 254 bytes.

When you point to an object of type X, incrementing that pointer is in
increments of the in-memory size of X, plus rounding.  ie you might have a
254 byte structure but your compiler may decide to lay those out at it's
convenience.  It could be that it pads the size to 256 bytes to avoid
unaligned accesses which your architecture may not support.  To avoid that,
declare the struct as packed (which is a compiler specific directive), which
would save memory but could force it to break operations into aligned
accesses (eg an unaligned 32 bit load might turn into two aligned loads plus
some AND/OR/shift logic)

..add that to the fact that to write to flash RAM you need to specify
the *offset* from flash RAM base, but to read it you need to use the
actual hardware address...

 
are you casting pointers?

I suspect the flash is mapped as readable at some base address, but to write
you need to issue a write command.  ie to read you can just do:

int data = *(FLASH_READ_BASE + flash_offset);

but writing might be something like:

*(FLASH_WRITE_ADDR) = flash_offset;
*(FLASH_WRITE_DATA) = 0x12345678;
*(FLASH_WRITE_GO) = true;

What is the generic type for a simple pointer to presumably bytes, in
ARM C?

 
traditionally char*

Slightly less traditionally (C99 and later):
#include <stdint.h>

and then you have the type uint8_t* as a pointer to unsigned 8 bit ints, and
int8_t* pointing to signed 8 bit ints.

Or should I resign myself to doing everything in 256byte chunks? the
structure to be read and written from Flash  is exactly that big for
obvious hardware reasons...

I don't know the flash type or block size (this is a Pico?) but if you write
chunks you're likely to cause fewer erase cycles than writing random bytes
here and there.  It's going to cause less wear to round to 256 then have
things unaligned and span block boundaries.

Theo