On Tue, Mar 10, 2009 at 2:44 PM, David Brown <david.br...@hesbynett.no>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.
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
