Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: The Natural Philosopher <tnp@invalid.invalid>
Newsgroups: comp.sys.raspberry-pi
Subject: Re: Fscking Pointers.
Date: Thu, 27 Mar 2025 06:47:23 +0000
Organization: A little, after lunch
Lines: 99
Message-ID: <vs2s9r$3kqov$2@dont-email.me>
References: <vs1jgs$2co6s$3@dont-email.me> <m4j56iF31mcU1@mid.individual.net>
 <auh*Pis+z@news.chiark.greenend.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 27 Mar 2025 07:47:23 +0100 (CET)
Injection-Info: dont-email.me; posting-host="05d7e3be59ea89065d57852c75c92217";
	logging-data="3828511"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+U0Vfoxso2+8QJbcePKfGNWIkbnPg74LA="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Vf4+vQ7P++WMlR8OTlYgCCRa/gU=
In-Reply-To: <auh*Pis+z@news.chiark.greenend.org.uk>
Content-Language: en-GB
Bytes: 4704

On 26/03/2025 23:07, Theo wrote:
> 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;
> 
Essentially yes. There are no functions to read flash, but to write and 
to erase are discrete functions taking offset, not absolute addresses

>>> 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.
> 
Thanks for that. I think for readability that is preferable to char * as 
there is a hint of 'this is a string' about that.

uint8_t* means 'a pointer that increments by one for each byte'


>>> 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.
> 
You CAN only write chunks of 256 bytes and erasure is a whole 4k block.


> Theo

Thanks for that. Having slept on it I think that I will go for 'the 
closest to assembler' and  use uint8_t *  except where accessing the 
structure contents. Then I can explicitly cast it to a structure pointer.

I had forgotten about packing arrays too. Pico is a 32 bit chip. No idea 
how wide its data bus is - ah that's 32 bits as well.

So I guess byte accesses are 32 bit access with the answer shifted right ...


Rethink needed there as well

Thanks for all the hints



-- 
“The ultimate result of shielding men from the effects of folly is to 
fill the world with fools.”

Herbert Spencer