Re: [Flashforth-devel] Fwd: Re: C functions/libs at 0x11000 and up
Brought to you by:
oh2aun
Menu
▾
▴
Re: [Flashforth-devel] Fwd: Re: C functions/libs at 0x11000 and up
|
From: om1zz <om...@vo...> - 2015-06-09 18:31:48
|
Nope, that are the LIBS only which are put at 0x11000 with your script.
But there are also the "users Cfunctions", which are not called as the "xc16" libraries - those will be put inside the ffcode section with your script.
So you have 2 kinds of external calls:
1. external functions called from FF as "XC16 library functions" - ie. floats/doubles.s - those are from xc16 library libm etc. and will be placed into the "libs" section
2. external "user Cfunctions" called as for example my Ctest.c (not a part of XC16 library).
It seems we have got two choices with Cfunctions:
1. coloring Cfunctions and a having a special section for it (after the libs one) - as I did below, or,
2. creating a library from a Cfunction.o, and add it into the "libs" section.
Igor.
______________________________________________________________
> Od: Mikael Nordman <mik...@fl...>
> Komu: <fla...@li...>
> Datum: 09.06.2015 20:17
> Předmět: Re: [Flashforth-devel] Fwd: Re: C functions/libs at 0x11000 and up
>
>At least for me the C function is linked after the library code.
>Not into the ffcode section.
>
>Program Memory [Origin = 0x200, Length = 0x153fe]
>
>section address length (PC units) length (bytes)
>(dec)
>------- ------- -----------------
>--------------------
>.text 0x200 0xa0 0xf0
>ffcode 0x400 0x2400 0x3600
>libs 0x11000 0xd18 0x13a4
>.text 0x11d18 0x242 0x363
>
>On 09.06.2015 20:46, om1zz wrote:
>> But that puts user Cfunction into the ffcode section, that is not what we want, do we?
>> I.
>>
>> ______________________________________________________________
>>> Od: Mikael Nordman <mik...@fl...>
>>> Komu: <fla...@li...>
>>> Datum: 09.06.2015 19:03
>>> Předmět: Re: [Flashforth-devel] Fwd: Re: C functions/libs at 0x11000 and up
>>>
>>> To avoid decorating the C functions with sections
>>> you can put FF in its own section. On the PIC33FJ128GP802
>>> you can do this.
>>>
>>> p33FJ128GP802.gld:
>>> .text :
>>> {
>>> *(.init);
>>> *(.user_init);
>>> KEEP (*(.handle));
>>> KEEP (*(.isr*));
>>> } >program
>>>
>>>
>>> ffcode 0x400 :
>>> {
>>> *(ffcode);
>>> } >program
>>>
>>> libs 0x11000 :
>>> {
>>> *(.libc) *(.libm) *(.libdsp); /* keep together in this order */
>>> *(.lib*);
>>> } >program
>>>
>>> usercode :
>>> {
>>> *(usercode);
>>> } >program
>>>
>>> And then define the section if the FF source code.
>>>
>>> ff.s:
>>> ; Start of code !
>>> ;.text
>>> .section ffcode, code
>>> ;;; *************************************
>>>
>>> Then you have to use the large memory model to compile the C code
>>> and use call instead rcall to call the library and C functions.
>>> cinit is not needed.
>>>
>>>
>>> Mike
>>>
>>> On 09.06.2015 18:53, om1zz wrote:
>>>> I've modified the linker script and it seems it places the stuff properly:
>>>>
>>>> I took all the xc16 libs off the first section, and placed them into a new "libs" section at a specific address (here an example 0x4000 but it shall be 0x11000) for all the xc16 math float/double libs, and after the libs section there is the new "userfunc" section where all the new Cfunctions will come.
>>>>
>>>>
>>>> /*
>>>> ** User Code and Library Code
>>>> **
>>>> ** This section must not be assigned to __CODE_BASE,
>>>> ** because CodeGuard(tm) sections may be located there.
>>>> **
>>>> ** Note that input sections *(.text) are not mapped here.
>>>> ** The best-fit allocator locates them, so that .text
>>>> ** may flow around PSV sections as needed.
>>>> */
>>>> .text :
>>>> {
>>>> *(.init);
>>>> *(.user_init);
>>>> KEEP (*(.handle));
>>>> KEEP (*(.isr*));
>>>> } >program
>>>>
>>>>
>>>> /*
>>>> ** User-Defined Section in Program Memory
>>>> **
>>>> ** note: can specify an address using
>>>> ** the following syntax:
>>>> **
>>>> ** usercode 0x1234 :
>>>> ** {
>>>> ** *(usercode);
>>>> ** } >program
>>>> */
>>>> usercode :
>>>> {
>>>> *(usercode);
>>>> } >program
>>>>
>>>> libs 0x4000 :
>>>> {
>>>> *(.libc) *(.libm) *(.libdsp); /* keep together in this order */
>>>> *(.lib*);
>>>> } >program
>>>>
>>>> userfunc :
>>>> {
>>>> *(userfunc);
>>>> } >program
>>>>
>>>>
>>>> And you need to tell where to place your Cfunction:
>>>>
>>>> __attribute__((section("userfunc")))
>>>> double Ctest ( int degree_x) {...
>>>>
>>>>
>>>> And map file shows:
>>>> ..
>>>> 0x0025e4 build/default/production/_ext/1360937237/ff-pic24-30-33.o:MEMQADDR_N
>>>> 0x002600 build/default/production/_ext/1360937237/ff-pic24-30-33.o:lastword
>>>> 0x002800 build/default/production/_ext/1360937237/ff-pic24-30-33.o:KERNEL_END
>>>> 0x004000 _acos
>>>> 0x004000 _acosl
>>>> ....
>>>> 0x0057a0 _fmodl
>>>> 0x0057a8 _fmodf
>>>> 0x0057ac __fmodrem
>>>> 0x00584a __dmodrem
>>>> 0x00591a _Ctest
>>>>
>>>> Now it needs to be tested with a larger PIC.
>>>> Igor
>>>>
>>>>
>>>> ______________________________________________________________
>>>>> Od: Mikael Nordman <mik...@fl...>
>>>>> Komu: <om...@vo...>, <fla...@li...>
>>>>> Datum: 09.06.2015 14:06
>>>>> Předmět: Re: [Flashforth-devel] Fwd: Re: C functions/libs at 0x11000 and up
>>>>>
>>>>> You need to modify the linker script to move relevant sections to a memory region starting at 0x11000
>>>>>
>>>>> Sent from my LG Mobile
>>>>>
>>>>> ------ Original message------
>>>>>
>>>>> From: om1zz
>>>>>
>>>>> Date: Tue, 09/06/2015 13:24
>>>>>
>>>>> To: fla...@li...;
>>>>>
>>>>> Subject:Re: [Flashforth-devel] Fwd: Re: C functions/libs at 0x11000 and up
>>>>>
>>>>> dspic33EP512MC502 (and friends) seems to be a good candidate for such a setup. Now, how to push the C stuff and libs up there. I. >Note that FF also uses a flash area for the EEPROM emulation. >For 128 Kb and larger devices it is placed at 0x10000-0x10fff in flash. >You could place the c-code and libs at 0x11000 and up. >There is also some unused flash space in 0x10000 - RAMSIZE upto 0xffff. > >For smaller devices the EEPROM emulation is placed inside the FF core >dictionary area. ------------------------------------------------------------------------------ _______________________________________________ Flashforth-devel mailing list Fla...@li... https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>>>>
>>>>> ----------
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> ----------
>>>>>
>>>>> _______________________________________________
>>>>> Flashforth-devel mailing list
>>>>> Fla...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Flashforth-devel mailing list
>>> Fla...@li...
>>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>
>------------------------------------------------------------------------------
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>
|
