On 18 Oct 2004 13:26:40 -0700
ri**@advancedbioelectric.com (Jimbo) wrote:
I'm porting code from one embedded system to another.
Rather than declaring a pointer to memory/peripheral of interest and
dereferencing it, the original system had provisions for locating
variables at a specific address using proprietary c extensions.
The linker on the new tool set is all but inaccessible I'd I really
not rather modify the code to use a dereferenced pointer. The best I
can fathom is below:
typedef struct peripheral_tag
{
...
int some_val;
...
} peripheral;
You need to read the documentation to find out if the compiler will
introduce and padding to the struct which might move things from where
you think they are.
#define P_ADD 0x1000
#define Peripheral_var (*((peripheral *)P_ADD))
You should probably also use the volatile keyword to prevent accesses to
the data from being optimised away or the order being changed.
So that in use, I'd have
Peripheral_var.some_val++;
If anyone considers this a revolting solution I'd appreciate they're
alternative.
I think that I would not use the struct. I would probably do something
like:
#define DEVICE_BASE (0x1000)
#define DEVICE_VAR (*(volatile int *)(DEVICE_BASE+0x04))
....
DEVICE_VAR++;
This avoids as many changes if structure padding changes, and obviously
it is up to you to ensure that everything is properly aligned, but then
you already have problems if you have a hardware register that is not
properly aligned for the processor.
Obviously we are well in to implementation defined (or is it undefined?)
behaviour when constructing and using pointers to fixed addresses.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.