> If I wanted fast and small, I'd have done it in ASM. But half of the point > of this exercise was to get my feet wet with C. > So, both points accomplished. I have GCC up under AVR studio, a working > project, and I feel reasonably confident with the code. > Despite avr-gcc being fairly dim about optimisations*, the results can be pretty reasonable. I had to write one program for a Mega48 in assembly language to get it fast enough. The goal was to linearly interpolate 16 bit values from a table stored in flash fast enough to output a 192kHz signal with the processor running at 20MHz. That gives just over 100 cycles to fetch the values, do the interpolation, output the value and update the pointers. I couldn't do it in C, even with inline assembly, but managed it in assembly. Part of the trick was storing everything in registers, which JUST fit for two channels. However, the C compiler was able to do it in something like 160-180 cycles. So I wouldn't discount C performance being quite acceptable if you are careful.
* On the other hand, it would be great if avr-gcc could perform some basic optimisations that even a fairly inexperienced amateur could manage. For example, things like "unsigned char x, y; x = y>>4" could use the nibble swap instruction rather than four shifts, and things like "unsigned short a; unsigned char b; b = a>>8" could pretty much just be a single instruction. These are examples of things I've seen the compiler waste cycles on, that are fairly obvious. In future if I see the compiler doing silly things like this, is it worth me posting the code & assembly output to this list? Nicholas _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
