Memory Mapping in Microcotroller - c

Question

1. #define timers ((dual_timers *)0x03FF6000)
This is a memory map definition used in an ARM Microcontroller
where the structure definition is
2. struct dual_timers
{
special_register TMOD;
special_register TDATA0;
special_register TDATA1;
special_register TCNT0;
special_register TCNT1;
};
What the meaning of(dual_timers *)0x03FF6000) ?, is it type casting .
if it is typecasting please explain its influence in the code.
How would the compiler see the definition 'timers' after this?

Answer 1

This has been asked and answered countless times here.
First off the structure thing is a bad idea, not portable not reliable, even though it is used as often as it isnt in vendors code. Little time bombs waiting to go off and have you pay them for support perhaps.
Your define is just elementary C. It is a typecast, I have this address happens to be hardcoded, in C programming class we might have used the name of some other pointer and likely not the define
unsigned int *bob;
unsigned char *ted = (unsigned char *)bob;
(yet another programming trick you should never use). And you can spin that around as a define
#define ted (unsigned char *)bob
Or something to that effect. bob is just an address with a human readable name.
For this to work you need a volatile in there (which it isnt?) and they have yet another typedef somewhere that defines dual_timers so they dont have to keep typing volatile unsigned int or volatile uint32_t or volatile uint8_t or whatever size the registers are. The volatile is because you know but the compiler doesnt that you are pointing at hardware not ram, you need the compiler to perform all of the loads and stores and not optimize any out.
In addition you need the compiler to perform the right sized loads and stores, if it is a register that can only be accessed with 32 bit wide transactions, you need the compiler to implement this with the right instructions. And no matter what you do that is not a guarantee, this programming style can and if you are unlucky will fail for you. It is a very wide spread practice, but it is not foolproof. It and even worse than making pointers to absolute addresses is using structures across a compile domain, hardware is a separate compile domain from your code. You cannot guarantee no matter how many compiler specific directives you find, that that code will remain working as time goes on and compilers are upgraded or if god forbid you try to compile on some other computer. It may work 99.9999% of the time but that time that it fails is a massive failure that earthquake once in a zillion years that wipes out all of Tokyo. As you see in kernel drivers using an abstraction makes for portable code, in bare metal you can implement that abstraction in assembly language and guarantee the correct instruction is used. It can cost you some cycles, so you can create a define/typedef just like the one you are asking about for the abstraction, but your code is not forced into that and a complete re-write of your code is not required if you need to port that code or work around a chip errata, etc. the latter is my personal opinion and style based on decades of experience in bare metal programming.
The define is just an elementary C typedef nothing special or fancy just read it like any other C syntax to understand what it is doing. The struct is a way of applying offsets to that address, so if we assume that all of these registers are 32 bit then the "desire" is to have accesses to TMOD be at address 0x03FF6000+0x00, accesses to TDATA0 be at address 0x03FF6000+0x04, TDATA1 0x03FF6000+0x08 and so no. But again there is nothing here that insures that is actually going to happen nor does it insure that 32 bit loads or stores are used. A simple disassembly of the code will show these addresses being generated for these accesses.
I assume you tried using code like this to see what it did:
typedef volatile unsigned int special_register;
typedef struct
{
special_register TMOD;
special_register TDATA0;
special_register TDATA1;
special_register TCNT0;
special_register TCNT1;
} dual_timers;
#define timers ((dual_timers *)0x03FF6000)
unsigned int fun ( void )
{
timers->TMOD=5;
timers->TDATA0|=1;
timers->TCNT0=timers->TCNT1;
return(timers->TDATA1);
}
for arm as you mentioned producing
00000000 <fun>:
0: e3a02005 mov r2, #5
4: e59f301c ldr r3, [pc, #28] ; 28 <fun+0x28>
8: e5832000 str r2, [r3]
c: e5932004 ldr r2, [r3, #4]
10: e3822001 orr r2, r2, #1
14: e5832004 str r2, [r3, #4]
18: e5932010 ldr r2, [r3, #16]
1c: e583200c str r2, [r3, #12]
20: e5930008 ldr r0, [r3, #8]
24: e12fff1e bx lr
28: 03ff6000 mvnseq r6, #0

Answer 2

Yes it is type casting. It basically says that starting from address 0x03FF6000 you can consider that there is a dual_timers structure.
In this context, I guess that special_register is defined as something like volatile unsigned uint32_t.
This is a typical way of easily accessing the registers of a microncontroller. For accessing the register TDATA0 for example, in your code you will need to use timers->TDATA0

Answer 3

It means that there is a pointer to the structure dual_timers and the value of the pointer is 0x03FF6000, i.e. it is pointing to the structure located at 0x03FF6000.
The compiler (in fact preprocessor) sees the expression (dual_timers *)0x03FF6000) every time it looks at the word timers. For you it looks like timers->TDATA0 but for the compiler it looks like (dual_timers *)0x03FF6000)->TDATA0, take TDATA0 field of dual_timers structure located at 0x03FF6000.