Thread: Re: [Flashforth-devel] Fwd: Re: C functions/libs at 0x11000 and up
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel
|
From: Mikael N. <mik...@fl...> - 2015-06-09 12:06:03
|
<div style="font-size:10pt;"><p style="margin-top:0;margin-bottom:0;">You need to modify the linker script to move relevant sections to a memory region starting at 0x11000</p><p style="margin-top:0;margin-bottom:0;"> </p><div><signature_tag><p style="margin-top:0;margin-bottom:0;">Sent from my LG Mobile</p></signature_tag></div><p id="last_enter" style="margin-top:0;margin-bottom:0;"> </p><p style="margin-top:0;margin-bottom:0;"> </p><p style="margin-top:0;margin-bottom:0;">------ Original message------</p> <p style="margin-top:0;margin-bottom:0;"><b>From: </b>om1zz<om...@vo...></p><p style="margin-top:0;margin-bottom:0;"><b>Date: </b>Tue, 09/06/2015 13:24</p><p style="margin-top:0;margin-bottom:0;"><b>To: </b>fla...@li...;</p><p style="margin-top:0;margin-bottom:0;"><b>Subject:</b>Re: [Flashforth-devel] Fwd: Re: C functions/libs at 0x11000 and up</p><p style="margin-top:0;margin-bottom:0;"> </p><pre>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 </pre></div> |
|
From: om1zz <om...@vo...> - 2015-06-09 15:54:01
|
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
>
|
|
From: Mikael N. <mik...@fl...> - 2015-06-09 17:02:53
|
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
>>
|
|
From: om1zz <om...@vo...> - 2015-06-09 17:46:57
|
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
>
|
|
From: Mikael N. <mik...@fl...> - 2015-06-09 18:17:06
|
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
>
|
|
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
>
|
|
From: Mikael N. <mik...@fl...> - 2015-06-09 18:45:44
|
It seems my compilation behaves differently than yours
My user Cfunctions end up after the lib code
.text 0x011d18 0x242
build/default/debug/_ext/1360937237/float.o
0x011d18 _fpow
0x011d32 _testt
0x011d4a _Ctest
0x011dce _Ctest2
0x011e52 _Ctest3
0x011ed6 _Ctest4
On 09.06.2015 21:31, om1zz wrote:
> 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
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>
|
|
From: om1zz <om...@vo...> - 2015-06-09 18:57:10
|
Ok, you are right - I've refreshed the settings and now I get with your script
0x0127a8 _fmodf
0x0127ac __fmodrem
0x01284a __dmodrem
0x01291a _Ctest
That is the 3rd option with the Cfunctions :)
I.
______________________________________________________________
> Od: Mikael Nordman <mik...@fl...>
> Komu: <fla...@li...>
> Datum: 09.06.2015 20:45
> Předmět: Re: [Flashforth-devel] Fwd: Re: C functions/libs at 0x11000 and up
>
>It seems my compilation behaves differently than yours
>My user Cfunctions end up after the lib code
>
> .text 0x011d18 0x242
>build/default/debug/_ext/1360937237/float.o
> 0x011d18 _fpow
> 0x011d32 _testt
> 0x011d4a _Ctest
> 0x011dce _Ctest2
> 0x011e52 _Ctest3
> 0x011ed6 _Ctest4
>
>
>
>On 09.06.2015 21:31, om1zz wrote:
>> 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
>>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> 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
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X