error compiling c app

[johnh]

:)

good point, but I just discovered a tiny "#endif", so this should be alright...

O.k., yes I overlooked the #endif but he's #defining AOUT6_L to be nothing

and this won't work in the asm code.  How did you get it to compile?  ???

[TK.]

You are using macros, which are not defined, and which do mostly not run on gpasm anyhow.

Replace "rgoto" by "bra"

IFSET by "btfsc ..." (see macros.h of a common assembly based application)

IFCLR by "btfss ..." (see macros.h of a common assembly based application)

and if there are still errors, search for other macros I forgot here.

In general, the savest thing when using inline assembly functions is not to use macros at all

Best Regards, Thorsten.

[moxi]

my problem is still the same, even removing macro...

I could also take a look into the other files if you made it available

here is the folder with all the files of my project:

http://soundandbreakfast.ifrance.com/divers/toolbox.html

[audiocommander]

Hi Moxi,

JohnH was right, it is indeed AOUT6_L!

if you look at the error:

[tt]_output/aout.asm:207:Error [113] Symbol not previously defined (FSR1).

[/tt]

and then in the generated aout.asm file you see this:

; ; Starting pCode block
S_aout__CV_AOUT_LC_Update_SRs	code
_CV_AOUT_LC_Update_SRs:
	lfsr FSR1, ; loads AOUT6_[LH] and AOUT7_[LH]
	rcall CV_AOUT_LC_LoadAOUTx_8_8
	lfsr FSR1, ; loads AOUT4_[LH] and AOUT5_[LH]
	rcall CV_AOUT_LC_LoadAOUTx_8_8
	lfsr FSR1, ; loads AOUT2_[LH] and AOUT3_[LH]
	rcall CV_AOUT_LC_LoadAOUTx_8_8
	lfsr FSR1, ; loads AOUT0_[LH] and AOUT1_[LH]
	rcall _CV_AOUT_LC_LoadAOUTx_8_8
	bsf LATC ; The latch enable input, 5 ; (CANNOT be shared with other outputs!) ; latch SID values
	bcf LATC ; The data pin, 4 ; (can be shared with other outputs) ; clear out pin (standby)
	bcf LATC ; The latch enable input, 5 ; (CANNOT be shared with other outputs!) ; release latch
	RETURN	

I am an ASM idiot, but at

[tt]lfsr FSR1, ; ; loads AOUT6_[LH] and AOUT7_[LH][/tt]

a parameter is missing and the warning about the ',' (comma) is right.

when you look in the corresponding void CV_AOUT_LC_Update_SRs(void) function you see:

[tt]lfsr FSR1, AOUT6_L ; loads AOUT6_[LH] and AOUT7_[LH][/tt]

which means, that you have to define [tt]AOUT6_L[/tt]!

I tried it with 1 and 0x1 but had no luck, because I simply don't know what this ASM function expects as value

;)

Cheers,

Michael

[moxi]

which means, that you have to define AOUT6_L!

does that mean i have to define it in aout.c instead of aout.h?

why this one make problem and not the AOUT_4, AOUT_2....?

[johnh]

does that mean i have to define it in aout.c instead of aout.h?

No, it can be defined in either place.  The key is to make sure that the compiler can replace the symbol AOUT6_L with the appropriate value.

[tt]#define AOUT6_L <something>[/tt]

why this one make problem and not the AOUT_4, AOUT_2....?

AOUT0_L, AOUT2_L, & AOUT4_L also need to be defined as something, they are also causing problems but AOUT6_L is the first one encountered by the compiler/assembler.

I hope this helps!

[audiocommander]

and one quick last hint from me (for today :) )

the pic18F datasheet sais:

LFSR f,k       Move literal (k, 12-bit) 2nd word to FSRx 1st word

that means the AOUT..s have to be 12-bit numbers (if I'm interpreting that right...)

cheers!

Michael

[moxi]

:)

great thanks all of you...i will spend the day to make this app works (after a too short night!)

[stryd_one]

We almost need a chat room for this ;)

Hey when we're done, we'll have a C based aout_lc driver :)

[moxi]

that means the AOUT..s have to be 12-bit numbers (if I'm interpreting that right...)

so i have to define them like this:

unsigned int AOUT0_L;

it's right?

[audiocommander]

so i have to define them like this:

unsigned int AOUT0_L;

no :)

the #define preprocessor directive syntax is like this:

[tt]#define SOMEWORD somevalue[/tt]

eg: [tt]#define CONTENTS_OF_MY_POCKETS emtpy[/tt]

or: [tt]#define NUMBER_OF_MY_ROLEX 12[/tt]

or: [tt]#define MY_POSTINGS_IN_HEX 0x168[/tt]

you can even define longer strings or whatever you like to see exchanged by the preprocesser (very early step in compiling).

now you did that:

[tt]#define AOUT0_L [/tt]

(which means practically that AOUT0_L gets exchanged to "" (in other words nothing)

that means that the preprocessor takes this line:

[tt]LFSR f, AOUT0_L[/tt]

and makes this out of it:

[tt]LFSR f, [/tt]

(which is obviously nonsense, 'cause you cannot move the literal 'nothing')

so you just have to take care that you define AOUT0_L to a 12 bit value like:

[tt]#define AOUT0_L 0xFFF[/tt]

so that the preprocessor would make this out of it:

[tt]LFSR f, 0xFFF[/tt]

see?

...I don't know really ASM, so this is all a bit cheesy to me and I'm really not sure what AOUT0_L does at all... but the principle should be clear now, is it?

[moxi]

so you just have to take care that you define AOUT0_L to a 12 bit value like:

#define AOUT0_L 0xFFF

Aout0_L is not a fixed value,i'm right?

does this type of define replace the word AOUT0_L by the defined number (0xfff in your example) or does it replace Aout0_L by a 12bit type value depending on what happend in the app?

hope i'm clear...

[audiocommander]

Aout0_L is not a fixed value,i'm right?

well, I don't know... ???

When you #define it in aout.h (like you did) it is a fixed value, but I don't know if it should be.

If you want it to be a variable so that it can contain different and changing values, it shouldn't be #defined, but rather declared as an unsigned int (as you stated before).

In general it is a good idea to match the naming conventions; therefore variables are normally written in lowercase, while #defines are written in UPPERCASE...

Sorry, besides having read that it sets some AOUT-values, I have no clue what the program does...  :-[

Hope this helps,

best,

Michael

[stryd_one]

AOUT0_L is a pointer to a memory location which is fixed... The value which changes, is not stored in AOUT0_L itself, but at the memory location which is specified by AOUT0_L... Did that make sense?

[stryd_one]

I should add, that the value of AOUT0_L is loaded into FSR0 to point to a memory location... If you search for FSR in the datasheet it makes more sense than I do ;)

[moxi]

AOUT0_L is a pointer to a memory location which is fixed

so i suppose AOUT0_L don't hold a 12bit value, but just refer to a 12bit value...

how to define it, so?

like this:

#define AOUT0_L [8]

or like this:

unsigned int AOUT0_L

?

when i try to compile with

line 45 :unsigned int AOUT0_L

line 46 :unsigned int AOUT1_L

line 47 :unsigned int AOUT2_L

line 48 :unsigned int AOUT3_L

line 49 :unsigned int AOUT4_L

line 50 :unsigned int AOUT5_L

line 51 :unsigned int AOUT6_L

line 52 :unsigned int AOUT7_L

i get the error:

aout.c:46: syntax error: token -> 'unsigned' ; column 8

sorry , i'm learning..

stryd one: i just send you a mail with my last prog'..

[stryd_one]

Moxi, many of the other compile errors are due to a need to refer to the variable with an _ before them, for eg _FSR0L, not FSR0L. This is because they've been defined in C.

Interesting... The C Wrapper doesn't define FSRx, but just FSRxL and FSRxH. This means that we cant refer to FSR0, but FSR0_L and FSR0_H, the low and high bytes of the address. As AC mentioned before, they're a 12 bit value, this is implemented by FSRx_L being the lower 8 bytes, and FSRx_H being the upper 4 bytes of FSRx. Only the lower bytes of FSRx_H are used, the upper bytes are discarded.

<             FSR0             >
 X X X X121110 9 8 7 6 5 4 3 2 1 
      FSR0_H    |    FSR0_L
 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 
 X X X X 0 0 0 0 0 0 0 0 0 0 0 0

As for the defines of AOUTx_LH, I think the MIDIBox CV's implentation (in app_defines.h) is the best point of reference. They could probably be defined in C, but I don't know if there's any point...

Although I'm not sure how to load the FSR's now :-\ Any clues?? I'm thinking maybe going from this:

lfsr FSR1, AOUT6_L ; loads AOUT6_[LH] and AOUT7_[LH]

to this:

lfsr _FSR1H, _AOUT6_L ; loads AOUT6_[LH] and AOUT7_[LH]

And just using the high byte to refer to the register. I suspect it will load the following FSR1L also... I think that might be one for TK ;)

[moxi]

trying this:

Although I'm not sure how to load the FSR's now  Undecided Any clues?? I'm thinking maybe going from this:

  lfsr  FSR1, AOUT6_L      ; loads AOUT6_[LH] and AOUT7_[LH]

to this:

  lfsr  _FSR1H, _AOUT6_L      ; loads AOUT6_[LH] and AOUT7_[LH]

i obtain:

.objs\aout.asm:221:Error [113] Symbol not previously defined (_FSR1)

i've tried to compile removing the part with the macro, and the error about undefined symbol go away...

[audiocommander]

stryd_one, I think the underscore before the name is just an indication that it's a renamed symbol for the linker (or compiler or what the heck... don't know exactly).

therefore I would recommend to find out what Moxi/theApplication wants to do with LFSR FSR1, AOUT6_L?

I cannot say anything about the values, because I simply don't know ASM (besides the barely nfo in the datasheet it all looks quite chinese to me  ::) ) and I don't know exactly what this app does at all, so I'm better saying nothing ;D

just find out what it's good for and give it the right parameters and everything should be fine... I mean it's a bit ridicilous to discuss if a value should be a constant defined or a volatile int if obviously noone has a clue what it's good for? isn't it so?

nevertheless...

:)

cheers,

ac

[moxi]

quote from the pic pdf:

An FSR register is used as a pointer to the

data memory location that is to be read or written. Since

this pointer is in RAM, the contents can be modified by

the program.

lfsr mean "load fsr"

Example: LFSR 2, 0x3AB

After Instruction

FSR2H = 0x03

FSR2L = 0xAB

in our file, it's "CV_AOUT_LC_LoadAOUTx_8_8" that it's called just after:

CV_AOUT_LC_LoadAOUTx_8_8

;; 8bit/8bit

swapf PREINC1, W ; AOUT0_H[3:0] -> TMP2[7:4]

landlw 0xf0

movwf TMP2

PREINC "Uses contents of FSR1 to address data memory - value of FSR1 pre-incremented (not a physical register)"

after, there is some magic operation i try to understand now...

[stryd_one]

Don't worry too much about preinc and postinc, I don't know if we'll need them... I've got a kinda long post coming up before I got to bed and leave you guys to find out if I've totally screwed up or not ;) It should be about 5 minutes or so (which probably means 30 minutes knowing me)

[stryd_one]

The FSR's are used as a fast way to move around the bytes before loading them into the AOUT pins... Maybe it would be easier done in C, and then optimising later... I'll get to that ;)

Here a quick example of how it works for a full aout module in the toolbox app:

in map.c, the incoming midi events are mapped to an aout like this:

  ///////////////////////////////////////////////////////////////////////////
  // AOUT #2: forward CC#1 (Modwheel) of MIDI channel #1
  aout_value[1] = CONV_7BIT_TO_12BIT(midi_cc_chn0[1]);

When the aout is requested by the application to be updated, it calls the update like so:

/////////////////////////////////////////////////////////////////////////////
// This function should be called from USER_Tick() to update the requested
// AOUT pins
/////////////////////////////////////////////////////////////////////////////
void AOUT_Update(void)
{

<--SNIP-->

  if( (aout_value[1] != last_aout_value[1]) || (aout_value[5] != last_aout_value[5]) ) {
    AOUT_Load2SR(aout_value[1] | (0x3000 | (1 << 14)), aout_value[5] | (0x3000 | (1 << 14)));

As you can see, the above aout_value was passed to the AOUT_Load2SR function, which loads 2 of the shift registers of the aout module. Ignore the (0x3000 | (1 << 14) for now, that sets flags which are used elsewhere. My suggestion is an alternate implementation of Load2SR that would be more comfortable in C. Obviously it is important to follow some optimisations so that could take some consideration after this, these are just quick ideas...: The MIDIBox CV has a good example of loading the AOUT_LC's SR with a 16 bit value. In ASM, it takes each bit from

	CV_AOUT_LC_WRITE_BIT TMP1, 7
	CV_AOUT_LC_WRITE_BIT TMP1, 6
	CV_AOUT_LC_WRITE_BIT TMP1, 5
	CV_AOUT_LC_WRITE_BIT TMP1, 4
	CV_AOUT_LC_WRITE_BIT TMP1, 3
	CV_AOUT_LC_WRITE_BIT TMP1, 2
	CV_AOUT_LC_WRITE_BIT TMP1, 1
	CV_AOUT_LC_WRITE_BIT TMP1, 0

	CV_AOUT_LC_WRITE_BIT TMP2, 7
	CV_AOUT_LC_WRITE_BIT TMP2, 6
	CV_AOUT_LC_WRITE_BIT TMP2, 5
	CV_AOUT_LC_WRITE_BIT TMP2, 4
	CV_AOUT_LC_WRITE_BIT TMP2, 3
	CV_AOUT_LC_WRITE_BIT TMP2, 2
	CV_AOUT_LC_WRITE_BIT TMP2, 1
	CV_AOUT_LC_WRITE_BIT TMP2, 0

This uses the macro below:

	CV_AOUT_LC_WRITE_BIT MACRO reg, bit
	bcf	CV_AOUT_LC_LAT_DOUT, CV_AOUT_LC_PIN_DOUT	; set out pin depending on register content (reg.bit)
	btfsc	reg, bit
	bsf	CV_AOUT_LC_LAT_DOUT, CV_AOUT_LC_PIN_DOUT
	nop
	bsf     CV_AOUT_LC_LAT_SCLK, CV_AOUT_LC_PIN_SCLK	; rising clock edge
	bcf     CV_AOUT_LC_LAT_SCLK, CV_AOUT_LC_PIN_SCLK	; falling clock edge
	ENDM

This clears the latch and pin, and then, if the bit which was passed to the macro is set, it sets the pin high, otherwise it leaves it low. Then, the clock is strobed. This macro's behaviour should be easily duplicated in C. The obvious solution is to setup some loops, but as you can see, TK has done manual 'unrolled' loops, to save on CPU, at the expense of code size. We should do the same... Remember the toolbox app will present the aout_value[] as a 12-bit variable because it's designed for the full AOUT module. What we would need to do is combine two of the values into a 16 bit value, or to be more true to the original, a pair of 8 bit values, with C functions that would replace the two functions seen in the other apps supporting the AOUT_LC: CV_AOUT_LC_LoadAOUTx_12_8 (Shouldn't that be CV_AOUT_LC_LoadAOUTx_12_4?) and CV_AOUT_LC_LoadAOUTx_8_8. Those two ASM functions take the two values (12+4 or 8+8) and put them in TMP1 and TMP2, so that they can be used by the above macro. We would be taking aout_value[1] and aout_value[5] (remember the top of this post? It was so long ago! heheh) which are both 12-bit values, and using them to set the value of a 16 bit variable (or 2 8-bit variables). I'm not sure what order the bytes need to go into the AOUT_LC module, but this is where that order should be set. Once we have our 16 bit variable (or 2 8-bit variables) then we just need to pass one bit at a time to a function like this...:

void CV_AOUT_LC_WRITE_BIT(unsigned bit thisbit){

__asm
    bcf    CV_AOUT_LC_LAT_DOUT, CV_AOUT_LC_PIN_DOUT    ; set it low
__endasm

if thisbit > 0{	//Only do this if the bit is set

__asm
    bsf    CV_AOUT_LC_LAT_DOUT, CV_AOUT_LC_PIN_DOUT    ;set it high
__endasm

};

once every bit of the 16 bit value has been passed to that function, we clock it in like this:

//Now clock that bit.

__asm
    nop
        bsf     CV_AOUT_LC_LAT_SCLK, CV_AOUT_LC_PIN_SCLK    ; rising clock edge
        bcf     CV_AOUT_LC_LAT_SCLK, CV_AOUT_LC_PIN_SCLK    ; falling clock edge

__endasm


}

And then there's the rest of the stuff to be taken care of in a similar fashion... If all that crud will even work :-\

Now you guys know I'm still learning C, so please double check my syntax, but hopefully you'll get my idea. What do you think?

Edit I already found one funny syntax error - "unsigned bit" LOL.. OK it's 1am, I'm outta here... I'll be interested to see what you say when I get up tomorrow morning!

Edit2: Made that code make sense

[moxi]

thanks for the explanation of the existing code, the concept are clear now,but i think it will take to me some month to learn how to do what you plan... :P

[audiocommander]

unsigned bit ;D that's nice...

thanks for that stryd_,

about loops I may add that there's a restriction in SDCC: no function calls are allowed inside loops... nasty terrain here and there :)

have a good sleep (it's 6pm here haha..)

cheers,

Michael

[moxi]

maybe to start someone could explain how to transform the macro to C?

Stryd_One: the example you mail me report error:

symbol not previously defined "reg"

and

symbol not previously defined "bit"..