This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Help with embedded code linking
- From: Niklas GÃrtler <profclonk at gmail dot com>
- To: Grzesiek Gajoch <gajoch at gmail dot com>
- Cc: gcc-help at gcc dot gnu dot org
- Date: Mon, 21 Jul 2014 13:30:21 +0200
- Subject: Re: Help with embedded code linking
- Authentication-results: sourceware.org; auth=none
- References: <CAHipV2ARtuWX3YvDj4uCYwcHF_GOOHM17=5=oYhQyv_dkDKkrQ at mail dot gmail dot com> <53CCE32A dot 4010005 at gmail dot com> <CAHipV2C4YTjL7rKKb9AnSi7txCCJ8vfvCkaFxjxf0xBZL1ZO6g at mail dot gmail dot com>
You need to define the linker symbols for the functions. You could do
that in the linker script, but there are probably better ways. Maybe ask
the binutils mailing list about how to define a lot of symbols.
On 21.07.2014 12:17, Grzesiek Gajoch wrote:
> Thanks for reply,
> faster programmer is not a option - programming is done via WiFi (it
> has to be done that way).
> Yes, that's what I want to do - but the question is how to tell the
> linker about libraries (which are already somewhere in memory)?
> Pozdrawiam,
>
> Grzegorz Gajoch
>
>
>
> 2014-07-21 11:53 GMT+02:00 Niklas GÃrtler <profclonk@gmail.com>:
>> That is possible by placing the library in one part of the flash via a
>> linker script, and the remainder of the code in another part.
>> Alternatively you could buy a faster programming device such as Segger
>> J-Link which can flash even big microcontrollers in <1s ...
>>
>> On 21.07.2014 11:37, Grzesiek Gajoch wrote:
>>> all,
>>> My "problem" is as follows:
>>> I have relatively big code for STM32 microcontroller (~300KB binary file).
>>> Every time I want to test new software version I have to recompile all
>>> of it and then reflash whole memory (which takes time).
>>>
>>> I have a question:
>>> is it possible to compile "library" part of code (it does not change
>>> but takes a lot of memory) and burn it in static place in memory,
>>> when compiling "user" code (it uses functions from library) tell the
>>> linker somehow to map jumps to part of memory where the lib is (i.e.
>>> take the adresses from memory map of staticly burned lib) - the goal
>>> is to place it in "user" place in memory (and only reflash this part).
>>>
>>> Thanks for replay and help!
>>> Best regards,
>>>
>>> Grzegorz Gajoch