Configure SourceTrail to accept embedded c/c++ header files with @ syntax

Question

I'm attempting to use Sourcetrail (https://www.sourcetrail.com/) to quickly get into some old embedded c/c++ source code for the pic18 series of microcontrollers.

I get errors when importing the hardware include files, which uses an exotic method to define the hardware address of the bit addressable hardware registers, such as the below from pic18f26k22.h.

typedef union {
    struct {
        unsigned ANSA0                  :1;
        unsigned ANSA1                  :1;
        unsigned ANSA2                  :1;
        unsigned ANSA3                  :1;
        unsigned                        :1;
        unsigned ANSA5                  :1;
    };
} ANSELAbits_t;

extern volatile ANSELAbits_t ANSELAbits @ 0xF38;

As you probably guessed, SourceTrail is confused by the @ 0xF38 part and expect just a semicolon. The method is used by a number of other c/c++ compilers for embedded systems, so I assume a simple fix exists.

Edit:

First, to clarify: The @ is used to place the volatile variable at a specific place in the memory map, either as a bit or a byte address. (Slightly similar to how the 8086 CPU had memory and IO addressing systems). It's used in the global includes (for hundredts of different microcontrollers) that in this case came with the MPLab c/c++ compiler. For analysis purpuse I can make a copy of the global include files, and set up a different path to the global includes in SourceTrail - so they can be modified as much as needed. I would prefer to not touch the project files, as they still need to compile in the original setup.

While attempting @Antti Haapala answer, I found the following types of usage that needs to be taken into account:

extern volatile unsigned char           BAUDCON1            @ 0xFB8;

#ifndef BANKMASK
#define BANKMASK(addr) ((addr)&0FFh)
#endif
extern volatile __bit                   ABDEN1              @ (((unsigned) &BAUDCON1)*8) + 0;
#define                                 ABDEN1_bit          BANKMASK(BAUDCON1), 0

I can not find __bit defined anywhere, but it's a special construct that holds the bit address (not byte address) of the bit.

Answer 1

@ is not a valid token in C, so you cannot use it as a macro identifier either. The easiest solution would be to handle the @ address with a macro, i.e.

#ifdef somethingsomething
#define AT(address) @ address
#else
#define AT(address)
#endif

extern volatile ANSELAbits_t ANSELAbits AT(0xF38);

The first definition should be guarded by a macro that is used only on the target. It should be quite easy to do the change with a simple Perl script like

perl -pi -e 's/@\s*([0-9a-fA-FxX]+)/AT($1)/g' *.c *.h

---

If this @ syntax is used in the vendor-provided header files as is, then shame on them.

Answer 2

For teh Microchip C18 compuler:

#if defined MCHP_C18
  #define AT(address) @ address
#else
  #define AT(address)
  #define __bit _Bool
#endif

Then if rewrite:

extern volatile __bit ABDEN1 @ (((unsigned) &BAUDCON1)*8) + 0;

as

extern volatile __bit ABDEN1 AT((((unsigned) &BAUDCON1)*8) + 0);

then when MCHP_C18 is not defined it will pre-process to:

extern volatile _Bool ABDEN1;

_Bool is not quite the same as __bit of course but has close enough semantic behaviour to be useful for this purpose perhaps.

Answer 3

So, the purpose of the @ token is to have the variable at a specific address? So why not have a variable like macro that accesses the memory through a hardcoded pointer?

#define ANSELAbits (* (ANSELAbits_t *) 0xF38) 

Or if you don't mind having the * operator sprinkled through you source code, you can get rid of the macro:

static ANSELAbits_t * const ANSELAbits_ptr = (ANSELAbits_t *) 0xF38;

And before somebody complains about UB. Yes, turning integers into pointers is not portable, but should work on most architectures where reading specific memory addresses makes sense.

Personally i prefer the pointer variant. The * and -> operators explicitly shows that you are accessing stuff at a specific memory position:

// This is in my humble opinion clearer code:
ANSELAbits_ptr->ANSA0 = 1;
// or
(* ANSELAbits_ptr).ANSA0 = 1; 

// ...rather than this: 
ANSELAbits.ANSA0 = 1;   // How do we know that ANSELAbits is "Magic"?