Rick,
Why is your flash programming routine so large? Only the part that does the
actual flash programming has to be in ram. This is just a few lines of
code. Perhaps you need to split the function in a part that stays in flash
and a small part that does the actual programming.
Nico Coesel
At 11:07 17-11-2009 -0700, Rick Jenkins wrote:
>Thanks to all who have replied to this enquiry. I must admit I'm somewhat
>astonished that there is not a simple answer to this.
>
>Nico Coesel and David Brown suggest linking the function in the data
section.
>Since in my application, the RAM occupancy of the flash reprogramming
function
>can approach 100% on the smaller processors, linking it permanently into the
>RAM section, the cleanest solution, seems not to be an option. In fact, on
>the tiny programmers, I even overwrite the stack and the heap with my
>programming function, secure in the knowledge that it does not use them.
>
>I am entirely in agreement with JMGross that a global symbol emitted by
.size
>is the perfect solution, provided that optimisation does not fool it. As a
>matter of fact, I'm not sure that "optimisation" is always as good as it
>should be. I've found instances where it produces a jump to a "RETI"
>instruction, which is a waste of code space and run time. Merely replacing
>the jump with a second "RETI" is clearly more efficient.
>
>All in all, I think I'll stick with my somewhat kludgy use of a separate
>section for the function to be moved. The optimiser does not jump to code
>outside the section, and the linker reliably reports the memory address of
>the end of the section.
>
>extern int __foobar_start, __foobar_end; // Provided by linker
>int size_of_programmer; // Computed at runtime
>
>static void __attribute__ ((section (".foobar"))) __attribute__ ((naked)) \
>programmer(void)
>{
>...
>}
>
>size_of_programmer = __foobar_end - __foobar_start;
>
>Seems to work well, at the expense of maintaining a linker file with the
>section "foobar" defined.
>--
>Rick Jenkins <[email protected]>
>Hartman Technica http://www.hartmantech.com
>Phone +1 (403) 230-1987
>221 35 Avenue. N.E., Calgary, Alberta, Canada T2E 2K5
>
>---------------------------------------------------------------------------
---
>Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>trial. Simplify your report design, integration and deployment - and focus
on
>what you do best, core application coding. Discover what's new with
>Crystal Reports now. http://p.sf.net/sfu/bobj-july
>_______________________________________________
>Mspgcc-users mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
