On Tue, Mar 10, 2009 at 2:44 PM, David Brown
<address@hidden> wrote:
As I've told you before, if you think there is something odd about the generated assembly code, no one can give you more than very general guesses unless you post a minimal compilable code snippet.
Given that this is something that comes and goes, and I have not had any luck figuring out the dependency, I don't know how I could deliberately generate code to reproduce it.
At first glance, I agree with Eric - I think you probably have a mixup between word addresses and byte addresses and the generated code is correct (i.e., the call is to *byte* address 0x62c, while the lcd_init routine is at *word* address 0x62c).
The call is going to the bottom of the LCD_Init routine, I can step it through in the disassembler. Also, the C function is always returning the value "9", even when the input data is 0.
The line in question is:
Bin = (New_A_Data / (Raw_Samples / Sample_Bins));
New_A_Data is in RAM, so I can set it to 0, or any other value.
Raw_Samples is a constant, 512
Sample_Bins is a constant, 32
No matter how you slice it, nine should never be the result of (0 / (constant1 + constant2))
gcc likes to think in terms of byte addresses, while avr studio (I'm guessing that's what you are using) will probably show things in flash with word addresses.
I don't completely understand, but single-stepping the code gives me the results that I expect everywhere else.
As well as the assembly files listing suggested by Eric, generate a map file and look at that - it might give you a clue.
I'll try.