Lpc2000

Dear All,

Sometime ago, I asked the below question to Philips apps. It appears 
they are too busy in handling more important issues as I did not 
receive a reply yet.

The user manual of LPC2214 states that a reserved bit should not be 
set to 1. Is it because of future compatibility issues or is it a 
hardware requirement?, i.e., what if we set a reserved bit to 1. 
will the IC burn or present undefined behaviour?

The reasons is to avoid additional code needed to make sure all 
reserved bits are 0 after accessing used bits of a register.

I appreciate if someone could shed some light on this

Kerem

> The user manual of LPC2214 states that a reserved bit should not be 
> set to 1. Is it because of future compatibility issues or is it a 
> hardware requirement?, i.e., what if we set a reserved bit to 1. 
> will the IC burn or present undefined behaviour?

If you need to ask this question, you're living too close to the
bleeding edge. Undefined bits might, if set:

1. do nothing
2. do nothing on current masks, but do something spectacularly strange
on a future mask
3. activate an internal test mode feature that fries your external
hardware by activating "impossible" combinations of I/Os

I'm not surprised you didn't get an answer. The behavior is undefined.
You would get exactly the same (non-) answer if you asked "How safe is
it to run the chip twenty degrees above its absolute maximum rating?"

-- 
Lewin A.R.W. Edwards
Consulting - http://www.zws.com/
Personal   - http://www.larwe.com/
Check out my books on embedded engineering!
<http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20/>
<http://www.amazon.com/exec/obidos/ASIN/0750677783/zws-20/>

Thanks for the answer. Actually I'm not intentionally setting a reserved bit 
to one. I just want to use bitfields in C. I cant now as the generated code 
only deals with the bits accessed (naturally). So I have to use 
read-modify-mask off reserved-write type of instructions. This way I cant 
take advantage of bitfields which makes life a bit easier. More code is 
another disadvantage.
If we new that this limitation is due to future compatibility concerns, then 
it would be nice to use bitfields.

kerem


----- Original Message ----- 

From: "Lewin A.R.W. Edwards" <larwe@...>
To: <lpc2000@yahoogroups.com>
Sent: Monday, December 20, 2004 4:40 PM
Subject: Re: [lpc2000] reserved bits of LPC2214


>
>
>> The user manual of LPC2214 states that a reserved bit should not be
>> set to 1. Is it because of future compatibility issues or is it a
>> hardware requirement?, i.e., what if we set a reserved bit to 1.
>> will the IC burn or present undefined behaviour?
>
> If you need to ask this question, you're living too close to the
> bleeding edge. Undefined bits might, if set:
>
> 1. do nothing
> 2. do nothing on current masks, but do something spectacularly strange
> on a future mask
> 3. activate an internal test mode feature that fries your external
> hardware by activating "impossible" combinations of I/Os
>
> I'm not surprised you didn't get an answer. The behavior is undefined.
> You would get exactly the same (non-) answer if you asked "How safe is
> it to run the chip twenty degrees above its absolute maximum rating?"
>
> -- 
> Lewin A.R.W. Edwards
> Consulting - http://www.zws.com/
> Personal   - http://www.larwe.com/
> Check out my books on embedded engineering!
> <http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20/>
> <http://www.amazon.com/exec/obidos/ASIN/0750677783/zws-20/>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

At 05:22 PM 12/20/04 +0200, you wrote:

>Thanks for the answer. Actually I'm not intentionally setting a reserved bit
>to one. I just want to use bitfields in C. I cant now as the generated code
>only deals with the bits accessed (naturally). So I have to use
>read-modify-mask off reserved-write type of instructions. This way I cant
>take advantage of bitfields which makes life a bit easier. More code is
>another disadvantage.
>If we new that this limitation is due to future compatibility concerns, then
>it would be nice to use bitfields.

Bitfields are one of those items that look like a nice way to interface to 
the HW but usually end up being more trouble than use.  I've succumbed to 
the temptation before and usually regretted it.

The only upside to them is that they look neat (in the original sense of 
the word).  They don't result in better machine code.  Macros look almost 
as nice and are easier to maintain.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III