Lpc2000

Before anyone points it out, the line:

"if (REG(GPIO_IOPIN0 & bit_pos))"

should be replaced with:

"if (REG(GPIO_IOPIN0) & bit_pos)"

Sorry about this

Brendan

--- In lpc2000@yahoogroups.com, "brendanmurphy37" 
<brendan.murphy@...> wrote:
>
> 
> This indeed came up a while ago. 
> 
> To recap:
> 
> The reason bit-fields are a bad idea for hardware register access, 
is 
> that it is completely undefined in ANSI 'C' as to how they are 
mapped 
> to memory (which in turn is mapped to a hardware register). Bottom 
> line: it may work, or it may not.
> 
> Even if you verify that the complier is doing what you expect by 
> looking at the assembler output, it can change (an obvious change 
is 
> if you change the optimisation setting on the compiler, or move to 
a 
> new version of the compiler, or move to a new compiler, etc. etc.). 
> You're faced with having to check every time you do a change like 
> this. Fine if your happy to do this, but...
> 
> An exception to this is where particular copilier vendors (IAR? 
> Keil?) have provided some degree of built-in support, where they 
> essentially guarentee if you use the defined mechanism for 
accessing 
> hardware registers that it'll work OK.
> 
> A standard way of accessing (reliably) hardware registers, is 
> something like the following, which will work with any ANSI 'C' 
> compiler (given the correct type definition to get the right 
register 
> size):
> 
> /* define a 32-bit object */
> 
> typedef unsigned int uint32;
> 
> /* MACRO to access hardware registers: note the use of volatile to 
> avoid compiler optimising out the access */
> 
> #define REG(addr) (*(volatile unsigned uint32 *)(addr))
> 
> /* define the register address */
> 
> #define GPIO_IOSET0        (0xE0028004)
> 
> /* set a particular bit position */
> 
> REG(GPIO_IOSET0) = (1 << bit_position);
> 
> /* can also be used to read a particular bit(s) */
> 
> if (REG(GPIO_IOPIN0 & bit_pos))
> {
>    /* bit set in here */
> }
> else
> {
>    /* bit clear in here */
> }
> 
> It's not clear whether the original questioner on this topic wanted 
> to maintain the same source code to run on both 8085 and LPC2000 
> (which will be tough, however it's done) or just to use it as a 
> starting point (a lot easier: some combination of global search and 
> replace and use of the pre-processor should do the trick).
> 
> Hope this helps.
> 
> Brendan
>