[fpc-devel] Problem with bitpacked records and STM32F107 Controller

[Sven Barth]

Am 11.12.2013 10:03, schrieb Sergei Gorelkin:
> 11.12.2013 12:28, Sven Barth пишет:
>> Am 11.12.2013 08:43, schrieb Michael Ring:
>>> The strb command seems to be the problem, documentation from STM 
>>> states:
>>>
>>> Each I/O port bit is freely programmable, however the I/O port 
>>> registers have to be accessed as
>>> 32-bit words (half-word or byte accesses are not allowed).
>>>
>>> So, is there some way to make the bitset operations word-aligned?
>> Better say 32-bit aligned to avoid confusion. Words in Pascal are 
>> 16-bit although I know that you
>> are talking about the CPUs word size...
>>> Are there any good reasons for not doing so?
>> What when you really have a byte that you want ot access? Then using 
>> 32-bit writes/reads could(*)
>> result in unnecessary cycles.
>>
>> * I don't know about ARM especially, but I know that for e.g. the 
>> m68k a 32-bit store is more
>> expensive than a 16-bit or 8-bit store
>>
>> That said I don't have a solution for your specific problem except by 
>> doing it by hand.
>>
> Maybe size of memory access must be guided by size of record? For ARM 
> the record will be 32-bit, and for m68k it can be 8 or 16-bit.
The problem for ARM is that byte sized accesses for bitfields are done 
correctly except if it's an I/O port where 32-bit accesses are required. 
Let's assume that ARM also has different cycle times for different sizes 
then it would be overkill to change EVERY bitfield access to 32-bit. 
Maybe a local compiler directive would be better that tells the compiler 
what size it should use? Then Michael could use it like this:

=== code begin ===

{$push}
{$bitaccesssize 4} // in Byte
   TGPIO_ODR_bits = bitpacked record
     ODR0: 0..1;
     // ...
   end;
{$pop}

   TSomeNonIOStruct = bitpacked record
     Field1: 0..1;
     // ...
   end;

=== code end ===

For TGPIO_ODR_bits the compiler would then use 32-bit writes and for 
TSomeNonIOStruct it would continue to use 8-bit writes.

Regards,
Sven