C18 problems, of course.

[Ambient]

C18 variables problem

First off, Microchip needs fix their crap. Half of the example code in the C18 guide does not work with the compiler. Even some of the code supplied with the compiler!

Question 1: how do I use the "-p18f4685" command line option? From what it tells me, it should be: "mcc18 -p18f4685". But this does not work (syntax error!)

Question 2: I get the message: "Error - section '.tmpdata' can not fit the section. Section '.tmpdata' length=0x00000020" This happens whenever I uncomment the function I have that crunches through some IK equations. I have no idea how to fix this, or why the problem exists. I am assuming that the reserved .tmpdata variable section is not big enough. How would I create a new temp data section and have the function use that? Microchip really needs to read their own stuff.

 

[Ambient]

Why does it use sections anyways? This is very frustrating. Here is how I defined the variables so far. Most of them are used by the void IK(void) function.

#pragma udata access my_access
near float tempIK1,tempIK2,tempIK3;
near float leg,m,n,X,Y,Z;
near unsigned int Hip_Height; //Hip joint height
near unsigned int Body_Height; //bottom chassis clearance
near float Tmp_Angle,HipH_Angle,HipV_Angle,Knee_Angle;
near float Ltotal,l,ltemp;

#pragma romdata
rom unsigned float Femur_L = 57;
rom unsigned float Tibia_L = 143;
rom unsigned float Hip_L = 28;

#pragma code
void IK(void)
{
//IK trig equations
}

 

[Ambient]

I broke up the one function into 3 functions. But now it says that the MATH_DATA has that same problem. If I use any cosine, sine, etc. functions it tells me:

"Error - section 'MATH_DATA' can not fit the section. Section 'MATH_DATA' length=0x00000014"

What a crappy compiler. Any suggestions? It won't even let me use ONE cos() function.

 

[Torben]

Hi Ambient,

Just guessing here as I haven't used PICs (just some older 8051s so far) but: if those are true trig functions then perhaps it's the floating point math which doesn't fit. I've seen a smaller uC choke on floating point before, so I changed the code to fixed point to get around the space limitation.

One common way to speed up and shrink trig functions is to use lookup tables instead of the floating point math functions. I don't know whether C18 internally uses the floating point routines though, so this might not even be your problem.

Anyway, good luck!


Torben

 

[Ambient]

These are built-in trig functions included in a header file. So they probably do not use a lookup table. The functions specify that they take in a float and output a float.

 

[aussiepoof]

Can you show us the linker script you're using?

P.
PS: the compiler's error messages are crap... the compiler itself is fine.

 

[Torben]

These are built-in trig functions included in a header file. So they probably do not use a lookup table. The functions specify that they take in a float and output a float.

I've just done a bit of googling and it appears that for at least some purposes the PIC18 should be able to handle floating point trig. I've found some other lookup-table solutions but most mention the PIC16 and smaller.

One I found: http://www.brouhaha.com/~eric/pic/sine.html

It'll take someone who is familiar with the PIC18 to tell you whether you need to do this or not for sure, but I generally try to avoid floating point unless I either have lots of spare space and speed is not important, or there is hardware support for it.


Torben

 

[Ambient]

Thanks. There is lots of space, 96k program, 3,328 bytes RAM. A lookup table is going to have to work if I can't solve this.

I guess I am just using the linker for the 18f4685 that comes with C18. That is the only linker I specified when I started the project. Is that what you need to see?

I am hoping to get this resolved somehow, I wanted to get the robot walking so I can take it on my interview lol.

 

[Ambient]

I think I figured it out. Since the PIC has banks, it has to split up these memory sections that it uses. I then realized that maybe the MATH_DATA was trying to fit into the access bank. But I had already declared my udata section to be in the access ram. I got rid of the access ram variables, not it works. How annoying.

 

[Ambient]

I think I figured it out. Since the PIC has banks, it has to split up these memory sections that it uses. I then realized that maybe the MATH_DATA was trying to fit into the access bank. But I had already declared my udata section to be in the access ram. I got rid of the access ram variables, now it works. How annoying.

 

[3v0]

Welcome to the world of banked memory.

 

[Torben]

I think I figured it out. Since the PIC has banks, it has to split up these memory sections that it uses. I then realized that maybe the MATH_DATA was trying to fit into the access bank. But I had already declared my udata section to be in the access ram. I got rid of the access ram variables, now it works. How annoying.

Good job--I'll squirrel this away under things to try to remember when I get around to working with PICs (although for some reason I think I might go to AVR instead, if only because it's what the hardware guys at work use).


Torben

 

[Ambient]

Now I just gotta finish the damn thing lol. I have till next wed. Hopefully I can get the hexapod moving by then at least. I just got in the servo controller, which accepts serial commands. So that is the next part.

Anyone know where the command line is for specifying the processor? I thought it would be in the source code, but I have a feeling now that it is somewhere in the options.