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
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
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
On 11 Dec 2013, at 08:43, Michael Ring wrote:
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
Could you give me a hint on where this is handled in code-generator? (I
never wanted to touch this beast so I do not know which files are relevant)
Could it be acceptable to change behaviour of the Code-Generator when
compiling for arm-embedded? (or by implementing {$bitaccesssize 4},
which
Michael Ring wrote:
Could it be acceptable to change behaviour of the Code-Generator when
compiling for arm-embedded? (or by implementing {$bitaccesssize 4},
which looks like a nice syntax for this to me)?
What I have in Mind is that arm seems to support unaligned access, so it
might for a
Hi, while playing arround I found a strange behaviour that seems to have
to do with the fact that writes to bitpacked records are byte aligned.
Here are the details:
I have create a bitpacked record set for the GPIO Registers of the
processor. On Port D of the processor I have 16 LED's, one
