On Feb 28, 2008, at 10:23 AM, Shaun Jackman wrote:
The solution you're recommending is possible, and in fact probably the only solution with the current architecture. The only catch is that it requires one device-specific function for each location of the EEPROM registers. How many EEPROM register locations are there across the AVR product line? Cheers, ShaunOn Thu, Feb 28, 2008 at 9:53 AM, Rick Altherr <[EMAIL PROTECTED]> wrote:While it's possibly a bit late for this option, you could write device- specific methods with different function names. Then, the header filecan defined a macro that expands the generic function name that gets used in the source code to one of the specific methods. That should result in a larger library overall, but only the function used by the device will actually be pulled into the final binary. It would prevent inlining any code at all.
Well, it would require one function per unique EEPROM register location. In fact, even that isn't true. It requires one function per unique code sequence required. The register locations could be arguments to the function that are supplied in the header's generic macro.
-- Rick Altherr [EMAIL PROTECTED]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Slashdot signature
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
