>>> The half-word is half-word aligned albeit on an 8 bit bus.
>>
>> I haven't used the LPC2994, but in general that's OK on the
>> other parts with which I'm familiar.
>
> I agree therefore my surprise.
>
> I've looked with a 'scope and it seems as if there's a single
> read. The higher byte of the half word mirrors the lower
> byte.
Bummer. IMO, what you have isn't really an 8-bit bus. It's
half of a 16-bit bus or a quarter of a 32-bit bus.
I can just hear the marketing guys saying "Can't use 16-bit
operations on the peripherals? That's OK, will just add '8-bit
bus support' to the list of features".
--
Grant Edwards grante Yow! I will SHAVE and
at buy JELL-O and bring my
visi.com MARRIAGE MANUAL!!
Reply by Fred●October 18, 20052005-10-18
"Grant Edwards" <grante@visi.com> wrote in message
news:11la1a7jqkh3ib4@corp.supernews.com...
> On 2005-10-18, Fred <fred@nowhere.com> wrote:
>
>>> A word is 32 bits in the ARM world and must be word-aligned. A half-word
>>> is 16 bits and must be half-word aligned. The LPC2294 is an ARM7tdmi
>>> MCU and thus doesn't support unaligned accesses in hardware.
>>>
>> The half-word is half-word aligned albeit on an 8 bit bus.
>
> I haven't used the LPC2994, but in general that's OK on the
> other parts with which I'm familiar.
>
I agree therefore my surprise.
I've looked with a 'scope and it seems as if there's a single read. The
bigher byte of the half word mirrors the lower byte.
>> Temporarily I have used byte access and concatenated the
>> bytes. However this really isn't an ideal and is a slow
>> solution. I've been looking through the datasheets and can't
>> see any proviso that a half-word read won't access a variable
>> on an 8 bit bus.
>
Reply by Grant Edwards●October 18, 20052005-10-18
On 2005-10-18, Fred <fred@nowhere.com> wrote:
>> A word is 32 bits in the ARM world and must be word-aligned. A half-word
>> is 16 bits and must be half-word aligned. The LPC2294 is an ARM7tdmi
>> MCU and thus doesn't support unaligned accesses in hardware.
>>
> The half-word is half-word aligned albeit on an 8 bit bus.
I haven't used the LPC2994, but in general that's OK on the
other parts with which I'm familiar.
> Temporarily I have used byte access and concatenated the
> bytes. However this really isn't an ideal and is a slow
> solution. I've been looking through the datasheets and can't
> see any proviso that a half-word read won't access a variable
> on an 8 bit bus.
Try it and see. :)
--
Grant Edwards grante Yow! Life is selling
at REVOLUTIONARY HAIR
visi.com PRODUCTS!
Reply by Fred●October 18, 20052005-10-18
"Grant Edwards" <grante@visi.com> wrote in message
news:11l8pinci380ccd@corp.supernews.com...
> On 2005-10-17, Wilco Dijkstra <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>
>>> Can this ARM processor fetch a word in two byte-wide fetches?
>>> Just that I know of others which do. Or must word fetches be
>>> from word or 32bit wide sources?
>>
>> A word is 32 bits in the ARM world and must be word-aligned. A
>> half-word is 16 bits and must be half-word aligned. The
>> LPC2294 is an ARM7tdmi MCU and thus doesn't support unaligned
>> accesses in hardware.
>>
>> Compilers for ARM typically support unaligned (or packed)
>> pointers which have no alignment requirement. If a CPU doesn't
>> support unaligned accesses directly in hardware, they are
>> split up into a sequence of reads/writes, shifts and masking
>> operations - this is obviously slow and so should avoided as
>> much as possible.
>
> And remember that this only works when the compiler _knows_ the
> pointer is misaligned. If you pass a misaligned pointer to a
> function that was declared as taking a word or half-word
> pointer, it's not going to work.
>
> Been there, done that. :/
>
> --
The pointer is definitely half-word aligned.
Reply by Fred●October 18, 20052005-10-18
"Wilco Dijkstra" <Wilco_dot_Dijkstra@ntlworld.com> wrote in message
news:iDU4f.2669$WI4.1839@newsfe4-gui.ntli.net...
>
> "Fred" <fred@nowhere.com> wrote in message
> news:4353956a$0$323$da0feed9@news.zen.co.uk...
>>
>> "Paul Black" <nospam@nospam.oxsemi.com> wrote in message
>> news:divrf2$65f$1@jupiter.oxsemi.com...
>>> Fred wrote:
>
>> Can this ARM processor fetch a word in two byte-wide fetches? Just that
>> I know of others which do. Or must word fetches be from word or 32bit
>> wide sources?
>
> A word is 32 bits in the ARM world and must be word-aligned. A half-word
> is 16 bits and must be half-word aligned. The LPC2294 is an ARM7tdmi
> MCU and thus doesn't support unaligned accesses in hardware.
>
The half-word is half-word aligned albeit on an 8 bit bus.
> Compilers for ARM typically support unaligned (or packed) pointers which
> have no alignment requirement. If a CPU doesn't support unaligned accesses
> directly in hardware, they are split up into a sequence of reads/writes,
> shifts and masking operations - this is obviously slow and so should
> avoided
> as much as possible. Note there is no guarantee compilers produce exactly
> 2 byte reads for an unaligned half-word access (in the order you wanted) -
> this means that it is incorrect to use packed pointers on peripherals.
>
> So if your peripheral doesn't support aligned halfword accesses the only
> way
> to read 2 bytes is to use 2 volatile byte reads and do the masking
> yourself.
> However I would be surprised if any peripheral on the LPC was like that...
>
Temporarily I have used byte access and concatenated the bytes. However
this really isn't an ideal and is a slow solution. I've been looking
through the datasheets and can't see any proviso that a half-word read won't
access a variable on an 8 bit bus.
Reply by Fred●October 18, 20052005-10-18
"Andrew Jackson" <alj@nospam.com> wrote in message
news:Hp6dnbdqWZSsAs7eRVnyjg@eclipse.net.uk...
>> Can this ARM processor fetch a word in two byte-wide fetches? Just
>> that I know of others which do. Or must word fetches be from word or
>> 32bit wide sources?
>
> If you disable half-word accesses then the ARM will fetch a half-word as
> two
> bytes. Whether you *want* this behaviour is another matter!
>
> You want to declare your pointers to hardware registers as volatile too to
> avoid the compiler optimising away accesses.
>
> Andrew
>
>
Many thanks.
Yes I forgot about volatile variables etc.
I would have thought setting the BCFG register to be 8 bit memory width
would have inherently forced byte access. What you're suggesting is to use
the switch for all half-word accesses, something I really don't want to do.
Where is this switch?
Reply by Grant Edwards●October 18, 20052005-10-18
On 2005-10-17, Wilco Dijkstra <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>> Can this ARM processor fetch a word in two byte-wide fetches?
>> Just that I know of others which do. Or must word fetches be
>> from word or 32bit wide sources?
>
> A word is 32 bits in the ARM world and must be word-aligned. A
> half-word is 16 bits and must be half-word aligned. The
> LPC2294 is an ARM7tdmi MCU and thus doesn't support unaligned
> accesses in hardware.
>
> Compilers for ARM typically support unaligned (or packed)
> pointers which have no alignment requirement. If a CPU doesn't
> support unaligned accesses directly in hardware, they are
> split up into a sequence of reads/writes, shifts and masking
> operations - this is obviously slow and so should avoided as
> much as possible.
And remember that this only works when the compiler _knows_ the
pointer is misaligned. If you pass a misaligned pointer to a
function that was declared as taking a word or half-word
pointer, it's not going to work.
Been there, done that. :/
--
Grant Edwards grante Yow! I would like to
at urinate in an OVULAR,
visi.com porcelain pool --
Reply by Wilco Dijkstra●October 17, 20052005-10-17
"Fred" <fred@nowhere.com> wrote in message
news:4353956a$0$323$da0feed9@news.zen.co.uk...
>
> "Paul Black" <nospam@nospam.oxsemi.com> wrote in message
> news:divrf2$65f$1@jupiter.oxsemi.com...
>> Fred wrote:
> Can this ARM processor fetch a word in two byte-wide fetches? Just that I
> know of others which do. Or must word fetches be from word or 32bit wide
> sources?
A word is 32 bits in the ARM world and must be word-aligned. A half-word
is 16 bits and must be half-word aligned. The LPC2294 is an ARM7tdmi
MCU and thus doesn't support unaligned accesses in hardware.
Compilers for ARM typically support unaligned (or packed) pointers which
have no alignment requirement. If a CPU doesn't support unaligned accesses
directly in hardware, they are split up into a sequence of reads/writes,
shifts and masking operations - this is obviously slow and so should avoided
as much as possible. Note there is no guarantee compilers produce exactly
2 byte reads for an unaligned half-word access (in the order you wanted) -
this means that it is incorrect to use packed pointers on peripherals.
So if your peripheral doesn't support aligned halfword accesses the only way
to read 2 bytes is to use 2 volatile byte reads and do the masking yourself.
However I would be surprised if any peripheral on the LPC was like that...
Wilco
Reply by ●October 17, 20052005-10-17
Yep, there are variety of subtle punishments in store for treating the
C compiler as a macro assembler... at times it can be downright
stubborn about insisting that you don't know the architecture better
than it does - convincing it that you do, to the point of making all
the warnings go away, takes just the right declarations.
Reply by Andrew Jackson●October 17, 20052005-10-17
> Can this ARM processor fetch a word in two byte-wide fetches? Just
> that I know of others which do. Or must word fetches be from word or
> 32bit wide sources?
If you disable half-word accesses then the ARM will fetch a half-word as two
bytes. Whether you *want* this behaviour is another matter!
You want to declare your pointers to hardware registers as volatile too to
avoid the compiler optimising away accesses.
Andrew