Accessing assembler-defined data in C as an array

[AirDragon]

I've upgraded my code for the quadrotor quite a bit, but it appears I need to expand the output range of the singeltons to beyond the unsigned char limit.

This is a bit of a bear, however, because I don't know how to go from 8-bit unsigned chars to 16-bit signed shorts with this equation in assembler:

sum( S[ i ] * Fo[ i ] ) / sum( Fo[ i ] );

Since my project is mixed language, I decided to port this equation over to C. The equation works just fine, but now I'm having data access errors for Fo[ i ].

So my question boils down to this:

What's the best way to access a data list defined in .asm with the C language?

Note that I cannot port Fo[ i ], the data definied in the .asm, to C so easily... I'd pretty much have to convert the whole .asm into a .c function.

[bigmac · Accepted solution]

Hello,

Within the ASM file, I assume that you have the label Fo: followed by a sequence of DC.W directives, and the comma separated table data.

Did you export the Fo label using the XDEF Fo directive, at the top of the ASM file?

Within the C file (or within an associated header file) you would also need to declare:

extern short Fo[];

This should make the table data visible from the C file.

Regards,

Mac

[AirDragon]

Hello bigmac,

I did just as you said with the XDEF and Fo: declarations, but with DS.B directives instead of DC.W.

The C file... well, I tried to use a pointer and have it point to the beginning address of the Fo array, but that didn't work out.

I'm going to try the extern char Fo[] and will see if that will work.

Thanks

[bigmac]

Hello AD,

I was under the impression that you needed to change the data type from unsigned 8-bit, to signed 16-bit, or did I misunderstand?  If the table contains constant data, and is located in flash memory, the directive DC.W or DC.B is appropriate.  The data would be programmed at the same time that the code is programmed.

The use of the DS.B (or DS.W) directive would indicate that the table data is RAM based.  For example,  DS.B 100 would define a memory block of 100 bytes that is not initialised - which would be done by your assembly code.  What is the actual scenario?

From the C standpoint, an array name used alone represents the address of the first array element, which can then be assigned to a pointer of the appropriate type.

extern char Fo[];

char *p;

p = Fo;

Regards,

Mac

[AirDragon]

I'm sorry for the confusion, but the S[] table is in ROM, and the Fo[] table is in RAM (or at least it should be).

The assembler function I was working on made use of the HCS12's fuzzy logic instructions, MEM, REV, and WAV. These instructions are 8-bit only, and will not work for 16-bit systems. So, in order to get a 16 or higher bit fuzzy logic function, you'd have to program it yourself.

Since the application is time critical (quad rotor balancing), I did not want to do too much programming in C as far as the controller subroutine goes... plus I didn't really feel like trying to make C versions of the MEM, REV, and WAV instructions.

After some initial testing, I had concluded that the 8-bit range of the defuzzification phase wouldn't suffice. So I want to try using the same 8-bit data (the Fo[] table) with a larger, 16-bit, S[] table.

The problem I was having earlier was that I didn't know how to use a pointer in C, nor did I know how to declare an array that's been externally declared in C... if that's how its said?

The good news is that I tried what you suggested, and it appears to be working, I'll have to do more tests now to see what else might be going on with it.