[ell-i-developers] Behaviour of writing to read-only bits.
- From: Ivan Raul <supra.material@xxxxxxxxx>
- To: ell-i-developers@xxxxxxxxxxxxx
- Date: Fri, 31 Jan 2014 16:08:13 +0200
Dear All.
What is the behaviour of writing to read-only bits? Should if definitively
be avoided?
While designing the initialization of GPIOx ports, the usage of
SystemInitRecordData32NoAddress
is quite appealing as it saves memory for initialisation records.
The problem is that through the initialisation routine, it also writes a
value (commonly zero if it was not specified) to all the registers between
the base register and the last register referenced.
The specific problem is that by referencing the AFRL and AFRH registers, it
passes through IDR, that has some read only bits.
MODER -> used
OTYPER -> used
OSPEEDR -> used
PUPDR -> used
IDR -> *read only bits
ODR
BSRR
LCKR
AFRL -> used
AFRH -> used
I think that the best option would be:
To use two initialization records, one for the first registers, and another
for the AFRx. It is doable as the system already supports two
initialization records apart from RCC. -> this will increase 3 bytes for
the extra initialization record, but reduce the InitRecordArray from 10
bytes to 6 bytes (two arrays, one of 4 and one of 2), what would lead to a
reduction of one byte in storage.
Another option I imagine was to use some kind of Value+Offset approach, but
an efficient implementation could be tricky, as it needs two tables for
space efficiency.
The non safe option would be to simply write to this bits and hope that
nothing will happen (that is why I ask about the behaviour of this write),
but after making the space calculation (while writing this message) I think
I will give a try to the two initialization records and report the results.
I'll keep you posted
With Warm Regards, Ivan Raul
Other related posts:
