Dealing with FAR pointers in code library for multiple embedded platforms

7
votes

I'm trying to maintain a library of code, with samples, for multiple embedded platforms. I need to support the concept of "far" (non 16-bit) pointers for some function parameters.

I thought I had a good solution with defining the macro FAR to be __far on some platforms and nothing on platforms with 32-bit pointers (embedded Linux, Win32, etc.). With that macro, I could easily define pointers as somestruct_t FAR *foo.

But then I started working with Freescale processors, and their compiler requires the FAR to go between the asterisk and variable name. (somestruct_t * __far foo).

The best solution I've come up with to handle this case is to define a macro FARPTR as either __far *, * __far or just * depending on the platform. This allows for somestruct_t FARPTR foo.

Are there cleaner solutions out there? In particular, I don't like that there isn't a * visible to someone reading that code. I'm also worried that I will run into problems when it comes to function declarations. Get a load of this syntax from the Freescale compiler help:

int __far *f();          // __far function returning a pointer to int
int * __far f();         // Function returning a __far pointer to int
int __near * __far f();  // __near function returning a __far pointer to int

That last one kills me -- a qualifier inside of the return type indicates a near function?! And I've recently learned that adding the __near isn't enough to actually compile a function to near memory -- I need to wrap it in pragmas.

So, has anyone seen a nicer solution than my FARPTR macro idea?

5
cembedded
Is your embedded system really so constrained that you can't just compile with the "large" model and make all pointers far? That's the cleanest solution. - R.. GitHub STOP HELPING ICE
This syntax seems to mirror the way const works with pointers, with __near mirroring C++'s mutable. It doesn't seem very alien to me. - Fred Foo
Can't your original idea of defining FAR to __far (and similar for NEAR) still work? You just have to make sure the FAR/NEAR go where the Freescale compiler wants them (like it or not). On other platforms those macros will be whitespace, so where they're used in the declarations is of no concern for them. - Michael Burr
@R: Not all of the embedded platforms I've worked with support a "large" model. @Michael Burr: the problem is that I need to support some platforms that require the __far before * and some that require it after. - tomlogic
Are you sure that the compilers that support the first syntax do not also support the Freescale syntax? i.e. it may be possible to standardise on that. - Clifford

5 Answers

2
votes

The freescale processor's usage is more consistent with standard type qualifiers such as const, that placement causes it to refer to the pointer not the data being pointed to. That said, since "far data" rather than a "far pointer" would be meaningless, you'd have thought that it would not matter, but greater consistency presumably makes for a simpler compiler parser.

You could use something kludgey such as:

#if defined __SOME_ARCHITECTURE__

    #define DECLARE_FARPTR( type, identifier ) type __far * identifier

#if defined __SOME_OTHER_ARRCHITECTURE__

    #define DECLARE_FARPTR( type, identifier ) type * __far identifier

#else

    #define DECLARE_FARPTR( type, identifier )

#endif

Then your declarations would look like:

DECLARE_FARPTR( somestruct_t, foo ) ;

or in a function prototype taking a pointer parameter:

void fn( DECLARE_FARPTR( somestruct_t, foo )  ) ;

or a function returning a far pointer:

DECLARE_FARPTR( somestruct_t, fn( void ) ) ;

As you can see it quickly gets hard to read and a declarative function-like macro is generally a thing best avoided.

2
votes

I don't have a specific better solution for you. However, having dealt with the same problem on several occasions, I recommend a review of the AUTOSAR Specification of Compiler Abstraction (PDF).

It includes a detailed approach to dealing with multiple compilers.

1
votes

To add to Clifford's post, although function-like macros are probably a bad idea, you could use a macro to create typedefs:

#ifdef SOME_ARCH
#define DEF_FAR_PTR(type, farptr_typename) typedef type __far *farptr_typename;
#elsif SOME_OTHER_ARCH
#define DEF_FAR_PTR(type, farptr_typename) typedef type * __far farptr_typename;
#else
#define DEF_FAR_PTR(type, farptr_typename) typedef type * farptr_typename;
#endif
1
votes

I also work with Freescale and my own solution to this is either of the following:

1) Replace far pointers with plain integers when possible. This doesn't work in every situation, but is particularly useful when dealing with function pointers, for example when writing interrupt vector tables.

2) Instead of using far pointers, write code that is identical to what the compiler will produce during a far pointer access. Here is an example for a Freescale MCU:

unsigned char readFromPage (unsigned char page, const unsigned char* address) 
{   
  unsigned char value;   
  unsigned char tmp = PPAGE;

  SAFE_DisableInterrupts;
    PPAGE = page;
    value = *address;
    PPAGE = tmp;
  SAFE_EnableInterrupts;

  return value; 
}

(this code may be inlined depending on the case)

3) Use #pragmas as far as possible.

As a result, I don't have a single far or near pointer in my code, it is portable (as portable as hardware-related code gets), and I can check it with static analysers that only understand standard C.

0
votes

It might just be cleaner to define two FAR macros: one for before the * and another for after the *.