flashforth-devel Mailing List for FlashForth: for PIC and Atmega (Page 19)
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel — FlashForth users and developers
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
(22) |
Mar
(3) |
Apr
(4) |
May
(6) |
Jun
(8) |
Jul
|
Aug
(6) |
Sep
|
Oct
(20) |
Nov
(9) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(4) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(14) |
Nov
(1) |
Dec
|
| 2013 |
Jan
(4) |
Feb
(5) |
Mar
(4) |
Apr
(2) |
May
|
Jun
(29) |
Jul
(7) |
Aug
|
Sep
(20) |
Oct
(9) |
Nov
(2) |
Dec
(7) |
| 2014 |
Jan
|
Feb
(23) |
Mar
(113) |
Apr
(25) |
May
(31) |
Jun
(9) |
Jul
(47) |
Aug
(15) |
Sep
(1) |
Oct
(4) |
Nov
(8) |
Dec
(3) |
| 2015 |
Jan
(21) |
Feb
(1) |
Mar
(18) |
Apr
(16) |
May
(100) |
Jun
(33) |
Jul
|
Aug
(10) |
Sep
(8) |
Oct
(7) |
Nov
(5) |
Dec
|
| 2016 |
Jan
(12) |
Feb
(9) |
Mar
|
Apr
(7) |
May
(5) |
Jun
(9) |
Jul
(1) |
Aug
(2) |
Sep
(17) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
(6) |
Feb
(12) |
Mar
(9) |
Apr
(3) |
May
(7) |
Jun
|
Jul
(12) |
Aug
|
Sep
(13) |
Oct
|
Nov
|
Dec
(10) |
| 2018 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(4) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(21) |
Oct
(3) |
Nov
|
Dec
|
| 2019 |
Jan
(5) |
Feb
(4) |
Mar
|
Apr
|
May
(3) |
Jun
(11) |
Jul
(4) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
(9) |
Dec
(7) |
| 2020 |
Jan
(2) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(4) |
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(8) |
Apr
(40) |
May
(12) |
Jun
|
Jul
|
Aug
(3) |
Sep
(3) |
Oct
(4) |
Nov
(10) |
Dec
(4) |
| 2022 |
Jan
(29) |
Feb
(7) |
Mar
(10) |
Apr
|
May
(3) |
Jun
(3) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(6) |
| 2023 |
Jan
(8) |
Feb
|
Mar
(5) |
Apr
(9) |
May
(6) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(9) |
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Mikael N. <mik...@fl...> - 2015-09-01 18:39:48
|
Todays FF finally works with the PIC24FV32KA302. The PMD4 disabled the eeprom which was not good :-) It was not easy to find that bug, so for now all peripherals are left powered at startup. For PIC24FV16KM202 the ff30.inc include file and a new device cinfig file is needed. BR Mike On 30.08.2015 20:37, Mikael Nordman wrote: > Could you send me your config. > M > > On 29.08.2015 14:10, Peter Jacobs wrote: >> Mike, >> Your adjustment to the eeprom code allows the interpreter to >> start >> and I can manipulate SRAM locations, however, if I try to make a >> constant or define a new word, the interpreter aborts and restarts. >> Screen shot attached. >> Also, a secondary problem is that I don't seem to be able to get >> the PLL to run. Using config FOSCSEL, FNOSC_FRCDIV is fine for >> running at 4 MIPS so this is not a show stopper. I have had the PLL >> running on this chip from a C program but have not worked out how to >> coax FF into doing the same. >> Peter J. >> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2015-08-30 17:37:37
|
Could you send me your config. M On 29.08.2015 14:10, Peter Jacobs wrote: > Mike, > Your adjustment to the eeprom code allows the interpreter to start > and I can manipulate SRAM locations, however, if I try to make a > constant or define a new word, the interpreter aborts and restarts. > Screen shot attached. > Also, a secondary problem is that I don't seem to be able to get > the PLL to run. Using config FOSCSEL, FNOSC_FRCDIV is fine for > running at 4 MIPS so this is not a show stopper. I have had the PLL > running on this chip from a C program but have not worked out how to > coax FF into doing the same. > Peter J. > |
|
From: Peter J. <pe...@me...> - 2015-08-29 11:29:03
|
A more compact message with some example interaction included as text. BPE FlashForth PIC24 27.08.2015 ok<#,ram> ok<#,ram> $0744 constant clkdiv AS FlashForth PIC24 27.08.2015 $0744 @ hex u. 0 ok<$,ram> $0742 @ u. 7710 ok<$,ram> : sqr dup * ; AS FlashForth PIC24 27.08.2015 On 29/08/15 21:10, Peter Jacobs wrote: > Mike, > Your adjustment to the eeprom code allows the interpreter to start > and I can manipulate SRAM locations, however, if I try to make a > constant or define a new word, the interpreter aborts and restarts. > Screen shot attached. > Also, a secondary problem is that I don't seem to be able to get > the PLL to run. Using config FOSCSEL, FNOSC_FRCDIV is fine for > running at 4 MIPS so this is not a show stopper. I have had the PLL > running on this chip from a C program but have not worked out how to > coax FF into doing the same. > Peter J. > > On 28/08/15 09:37, Peter Jacobs wrote: >> Thank you. That's looking promising. I get the start-up message >> appearing but >> I need to do a little more fiddling to get the serial receive pin >> configured, I think. >> I've just used your current files and just changed the selected >> microcontroller >> in the project properties. I'll get back to this after class today. >> Cheers, >> Peter J. >> >> On 28/08/15 05:04, Mikael Nordman wrote: >>> Now it should work, please let me know. I don't have that chip. >>> >>> git pull >>> >>> BR Mike >>> >>> On 26.08.2015 19:34, Mikael Nordman wrote: >>>> It turns out I made some changes in that broke the EEPROM read code >>>> in >>>> this commit :-( >>>> >>>> >>>> https://sourceforge.net/p/flashforth/code/ci/f5563da4acad608e5fff53d9ed223853b780302e/ >>>> >>>> >>>> I'll fix it soon. >>>> >>>> BR Mike >>>> >>>> On 26.08.2015 16:08, Peter Jacobs wrote: >>>>> Mike, >>>>> After a long delay, I've returned to working with FF on a >>>>> PIC24FV16KM202, as I had used for the tutorial guide last year. I'm >>>>> building a couple of boards for one of my students. Since you have >>>>> done >>>>> quite a bit of development on FF in recent times, I thought that I >>>>> should port my small number of edits for this processor onto your >>>>> current code for FF. Unfortunately, I have failed to get it >>>>> working. >>>>> I >>>>> can rebuild the FF code from April 2014 with the current MPLAB-X >>>>> tools >>>>> and it runs nicely on the new boards, however, I get no boot message >>>>> at >>>>> all with the current FF code. >>>>> >>>> Regards, >>>>> Peter J. >>>>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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: Peter J. <pe...@me...> - 2015-08-29 11:11:16
|
Mike,
Your adjustment to the eeprom code allows the interpreter to start
and I can manipulate SRAM locations, however, if I try to make a
constant or define a new word, the interpreter aborts and restarts.
Screen shot attached.
Also, a secondary problem is that I don't seem to be able to get the
PLL to run. Using config FOSCSEL, FNOSC_FRCDIV is fine for running at 4
MIPS so this is not a show stopper. I have had the PLL running on this
chip from a C program but have not worked out how to coax FF into doing
the same.
Peter J.
On 28/08/15 09:37, Peter Jacobs wrote:
> Thank you. That's looking promising. I get the start-up message
> appearing but
> I need to do a little more fiddling to get the serial receive pin
> configured, I think.
> I've just used your current files and just changed the selected
> microcontroller
> in the project properties. I'll get back to this after class today.
> Cheers,
> Peter J.
>
> On 28/08/15 05:04, Mikael Nordman wrote:
>> Now it should work, please let me know. I don't have that chip.
>>
>> git pull
>>
>> BR Mike
>>
>> On 26.08.2015 19:34, Mikael Nordman wrote:
>>> It turns out I made some changes in that broke the EEPROM read code
>>> in
>>> this commit :-(
>>>
>>>
>>> https://sourceforge.net/p/flashforth/code/ci/f5563da4acad608e5fff53d9ed223853b780302e/
>>>
>>> I'll fix it soon.
>>>
>>> BR Mike
>>>
>>> On 26.08.2015 16:08, Peter Jacobs wrote:
>>>> Mike,
>>>> After a long delay, I've returned to working with FF on a
>>>> PIC24FV16KM202, as I had used for the tutorial guide last year. I'm
>>>> building a couple of boards for one of my students. Since you have
>>>> done
>>>> quite a bit of development on FF in recent times, I thought that I
>>>> should port my small number of edits for this processor onto your
>>>> current code for FF. Unfortunately, I have failed to get it
>>>> working.
>>>> I
>>>> can rebuild the FF code from April 2014 with the current MPLAB-X
>>>> tools
>>>> and it runs nicely on the new boards, however, I get no boot message
>>>> at
>>>> all with the current FF code.
>>>>
>>> Regards,
>>>> Peter J.
>>>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> 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: Peter J. <pe...@me...> - 2015-08-27 23:37:19
|
Thank you. That's looking promising. I get the start-up message appearing but I need to do a little more fiddling to get the serial receive pin configured, I think. I've just used your current files and just changed the selected microcontroller in the project properties. I'll get back to this after class today. Cheers, Peter J. On 28/08/15 05:04, Mikael Nordman wrote: > Now it should work, please let me know. I don't have that chip. > > git pull > > BR Mike > > On 26.08.2015 19:34, Mikael Nordman wrote: >> It turns out I made some changes in that broke the EEPROM read code >> in >> this commit :-( >> >> >> https://sourceforge.net/p/flashforth/code/ci/f5563da4acad608e5fff53d9ed223853b780302e/ >> >> I'll fix it soon. >> >> BR Mike >> >> On 26.08.2015 16:08, Peter Jacobs wrote: >>> Mike, >>> After a long delay, I've returned to working with FF on a >>> PIC24FV16KM202, as I had used for the tutorial guide last year. I'm >>> building a couple of boards for one of my students. Since you have >>> done >>> quite a bit of development on FF in recent times, I thought that I >>> should port my small number of edits for this processor onto your >>> current code for FF. Unfortunately, I have failed to get it >>> working. >>> I >>> can rebuild the FF code from April 2014 with the current MPLAB-X >>> tools >>> and it runs nicely on the new boards, however, I get no boot message >>> at >>> all with the current FF code. >>> >> Regards, >>> Peter J. >>> > > ------------------------------------------------------------------------------ > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2015-08-27 19:04:11
|
Now it should work, please let me know. I don't have that chip. git pull BR Mike On 26.08.2015 19:34, Mikael Nordman wrote: > It turns out I made some changes in that broke the EEPROM read code > in > this commit :-( > > > https://sourceforge.net/p/flashforth/code/ci/f5563da4acad608e5fff53d9ed223853b780302e/ > > I'll fix it soon. > > BR Mike > > On 26.08.2015 16:08, Peter Jacobs wrote: >> Mike, >> After a long delay, I've returned to working with FF on a >> PIC24FV16KM202, as I had used for the tutorial guide last year. I'm >> building a couple of boards for one of my students. Since you have >> done >> quite a bit of development on FF in recent times, I thought that I >> should port my small number of edits for this processor onto your >> current code for FF. Unfortunately, I have failed to get it >> working. >> I >> can rebuild the FF code from April 2014 with the current MPLAB-X >> tools >> and it runs nicely on the new boards, however, I get no boot message >> at >> all with the current FF code. >> > Regards, >> Peter J. >> |
|
From: Mikael N. <mik...@fl...> - 2015-08-26 16:34:13
|
It turns out I made some changes in that broke the EEPROM read code in this commit :-( https://sourceforge.net/p/flashforth/code/ci/f5563da4acad608e5fff53d9ed223853b780302e/ I'll fix it soon. BR Mike On 26.08.2015 16:08, Peter Jacobs wrote: > Mike, > After a long delay, I've returned to working with FF on a > PIC24FV16KM202, as I had used for the tutorial guide last year. I'm > building a couple of boards for one of my students. Since you have > done > quite a bit of development on FF in recent times, I thought that I > should port my small number of edits for this processor onto your > current code for FF. Unfortunately, I have failed to get it working. > I > can rebuild the FF code from April 2014 with the current MPLAB-X > tools > and it runs nicely on the new boards, however, I get no boot message > at > all with the current FF code. > Regards, > Peter J. > |
|
From: Peter J. <pe...@me...> - 2015-08-26 13:33:34
|
Mike,
After a long delay, I've returned to working with FF on a
PIC24FV16KM202, as I had used for the tutorial guide last year. I'm
building a couple of boards for one of my students. Since you have done
quite a bit of development on FF in recent times, I thought that I
should port my small number of edits for this processor onto your
current code for FF. Unfortunately, I have failed to get it working. I
can rebuild the FF code from April 2014 with the current MPLAB-X tools
and it runs nicely on the new boards, however, I get no boot message at
all with the current FF code.
I see in your new web pages that larger PIC24/dsPIC MCUs are mentioned
but not the 16KM202. Also, you suggest the MCU to have at least 24kB
flash. This may be my problem but MPLAB-X is indicating that 1099 words
are free following a build of the current FF code and that's not too
much less than the 1201 words free for the April 2014 FF code. It's
very likely that I forgotten to do something simple but I cannot see it
this evening.
If you have time to look and offer suggestions, I've put a complete copy
of both projects in the tar files:
(1) new code builds but doesn't run on the MCU
https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5p0-pic24-aug-2015-as-at-2015-aug-26.tar.gz
(2) old code builds and does run on the MCU
https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5p0-pic24fv32ka-apr-2014-as-at-2015-aug-26.tar.gz
The directory name makes this project seem like it's for another
processor but it really is for the 16KM202.
Within each project folder, I have a mercurial repository with a clean
copy your files as the initial commit.
Regards,
Peter J.
|
|
From: Peter F. <fis...@gm...> - 2015-08-15 23:32:37
|
Hi Mikael Thanks for the explanation. It wasn't immediately obvious that the config files referred to the Microstick 2 in the Microstick Plus board. For whatever reason Microchip reversed the TX and RX pins with the Microstick Plus board versus the stand alone Microstick 2. The usb-uart board I use is Sparkfun's 3.3V board which works well. I've modified my Microstick 2 board so it can be powered via Pin 3 (3.3V) on J6. I've also connected the Microstick 2 to Geoff Graham's ASCII Video Terminal, so FlashForth runs standalone with keyboard and monitor. Anyway, thanks for creating FlashForth. I'm having fun experimenting. Regards Peter. |
|
From: Mikael N. <mik...@fl...> - 2015-08-15 11:32:56
|
Hi Peter, I would not consider this a problem. Rather that you can configure FF for your application, which luckily FF supports. I think that the UART config in the download are the connections for the MicrostickPlus board. That is the board I have been using. The comment should be "microstick2 with microstickplus" I have never used J6 or FTDI for the UART. One improvement could be to have example configs for some specific boards, but since there are so many possibilities, I have not bothered... Unfortunately you need to read the datasheet in order to configure the UART connections. Best Regards Mikael On 15.08.2015 12:16, Peter Fischer wrote: > I note there are problems with the Microstick 2 config files for the > PIC24HJ and dsPIC33. > |
|
From: Peter F. <fis...@gm...> - 2015-08-15 09:16:34
|
I note there are problems with the Microstick 2 config files for the PIC24HJ and dsPIC33. This is the latest download FF5: Flashforth PIC24 14.06.02015 This is a bit of a killer if you are unfamiliar with these chips. The chips included with the Microstick 2 is the dsPIC33FJ128MC802 and the PIC24HJ128GP502. I haven't used the PIC24FJ64GB002 with FlashForth. p33_config.inc : The TX and DX pins are REVERSED in the config file. My amendment: ; Map UART1 pins .ifdecl RPINR18 ;.equ RPINR18VAL, 6 ; RP6 (U1RXPIN) ;.equ U1TXPIN, 5 ; RP5 .equ RPINR18VAL, 10 ; U1RXPIN RP42 PB10 pin21 microstick2 .equ U1TXPIN, 11 ; U1TXPIN RP43 PB11 pin22 microstick2 Likewise amended for p24hj_config.inc ; Map UART1 pins .ifdecl RPINR18 ;.equ RPINR18VAL, 0x000f ; (U1RXPIN) ;.equ U1TXPIN, 0xe .equ RPINR18VAL, 0x000a ; U1RXPIN RP10 pin21 microstick2 .equ U1TXPIN, 0xb ; U1TXPIN RP11 pin22 microstick2 With config __FOSCSEL, IESO_ON & FNOSC_FRCPLL in p33_config.inc and config __FOSCSEL, IESO_ON & FNOSC_FRCPLL config __FOSC, FCKSM_CSECMD & IOL1WAY_OFF & OSCIOFNC_OFF & POSCMD_NONE in p24hj_config.inc these chips should run Flashforth 5 after compiling with MPLAB X. FTDI usb to uart board connected to J6. Regards Peter. |
|
From: om1zz <om...@vo...> - 2015-06-10 15:19:15
|
Hi, in https://github.com/igor-m/EXPERIMENTAL_ZZ/blob/master/examples/Cfun/Cdistbear1.c you may find a demo which calculates distance(m) and bearing(deg) of two points on Earth called as a single user Cfunction, with float arguments (lats, longs), calculating with doubles, and returning 2 float results - distance and initial bearing. 50.0e 15.0e 60.0e 80.0e distbear fs. fe. 4.10780e6 48.9369e0 ok<#,ram> 50.0e 15.0e -60.0e -170.0e distbear fs. fe. 1.88591e7 166.025e0 ok<#,ram> Igor |
|
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
>
|
|
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: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: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 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 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 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 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 10:24:49
|
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. |
|
From: Mikael N. <mik...@fl...> - 2015-06-09 07:38:10
|
Nope, I did not see that comment. It is of course reasonable to init data segments when you link to C-code. I had unchecked that option just to save same some code space for pure FF compilations. 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. On 09.06.2015 10:08, om1zz wrote: > Have you read my note in the Ctest.c header? :) > > After some experimenting I found out following trick (my current > undrestanding how it works): > > 1. you have to enable "Init data segments" in the xc16-ld settings > 2. it puts crt0 at the beginning > 3. after that it places all calls to .external libs/functions > 5. after that it puts FF.s > 6. it jumps from crt0 at the point in FF.s you marked as ".text" > (COLDLIT/WARMLIT) > 7. then it runs through the FF.s as usual. > > I have got both floats (single lib) and Ctest (9degree test function > with double lib) placed in the segment from 0x0200 to 0x2000 and FF.s > from 0x2000 up (see your map file). > > Of course, that is ok for 128kB flash parts (43kWords), but we need > to place all the external functions somewhere above 196kB flash, as > it > is my understanding FF can only address "lower 64kWords" (what is > still quite a lot for a forth when you can call external functions > out > of it). With a 512kB dspic33EP flash parts it could be an interesting > combination. > > When using double (64bit), ie. in the Ctest.c 9degree demo, you must > enable "Use 64-bit double" in xc16-gcc settings, otherwise the double > will work as a float only (even when declared as a double). > |
|
From: om1zz <om...@vo...> - 2015-06-09 07:08:46
|
Have you read my note in the Ctest.c header? :)
After some experimenting I found out following trick (my current undrestanding how it works):
1. you have to enable "Init data segments" in the xc16-ld settings
2. it puts crt0 at the beginning
3. after that it places all calls to .external libs/functions
5. after that it puts FF.s
6. it jumps from crt0 at the point in FF.s you marked as ".text" (COLDLIT/WARMLIT)
7. then it runs through the FF.s as usual.
I have got both floats (single lib) and Ctest (9degree test function with double lib) placed in the segment from 0x0200 to 0x2000 and FF.s from 0x2000 up (see your map file).
Of course, that is ok for 128kB flash parts (43kWords), but we need to place all the external functions somewhere above 196kB flash, as it is my understanding FF can only address "lower 64kWords" (what is still quite a lot for a forth when you can call external functions out of it). With a 512kB dspic33EP flash parts it could be an interesting combination.
When using double (64bit), ie. in the Ctest.c 9degree demo, you must enable "Use 64-bit double" in xc16-gcc settings, otherwise the double will work as a float only (even when declared as a double).
Igor.
______________________________________________________________
> Od: Mikael Nordman <mik...@fl...>
> Komu: <fla...@li...>
> Datum: 08.06.2015 22:18
> Předmět: Re: [Flashforth-devel] Fwd: Re: C function with more parameters in W0-W7
>
>And to answer my own question.
>It can be done like below
>
>
>__attribute__((address(0x1000)))
>float Ctest(unsigned short a, unsigned short b, unsigned long int c,
>float x, float y)
>{
> a = a + 100;
> b = b / a;
> c = c * b;
> x = sqrtf( (float)c - x );
> y = y / x;
> return y; // 4.5894021E-1
>}
>
>
>On 08.06.2015 23:03, Mikael Nordman wrote:
>> How did you solve it ?
>>
>> In my tests you get this problem because the Ctest.c file is linked after
>> the FF binary code into a the area where FF thinks is free space for the
>> dictionary. Compiling some FF code will then overwrite the C code.
>>
>> This happens if you also include the float package into the compilation.
>> If you do not include the float package, Ctest code will fit into memory
>> before the FF binary code and all is fine.
>>
>> How can the linker be forced to link the C-code before the FF code ?
>> Bu defining some new sections for the linker perhaps.
>>
>> There is no reason to save W0..W7 before calling the C function because
>> these registers are not 'live' in FF between words.
>>
>> Mikael
>>
>> On 06.06.2015 19:30, om1zz wrote:
>>> Solved, see examples.
>>> I.
>>>
>>> _____________________________________________________________
>>>>> Od: "om1zz" <om...@vo...>
>>>>> Komu: Mikael Nordman <mik...@fl...>
>>>>> Datum: 04.06.2015 19:00
>>>>> Předmět: C function with more parameters in W0-W7
>>>>>
>>>>> MIke, I cope with following issue:
>>>>>
>>>>> I have a Cfunction, with 5 parameters, returning float.
>>>>>
>>>>> So I am using W0-W7 for params.
>>>>>
>>>>> The strange:
>>>>> First time after the fresh flash the Cfun (when pasting the below
>>>>> into teraterm) returns good result:
>>>>>
>>>>> decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36
>>>>> 3eea
>>>>>
>>>>> I can do it repeatedly, I always get good results.
>>>>>
>>>>> decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36
>>>>> 3eea
>>>>> decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36
>>>>> 3eea fa36 3eea
>>>>> decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36
>>>>> 3eea fa36 3eea fa36 3eea
>>>>>
>>>>> In the moment as I do something via prompt (before or after playing
>>>>> with Cfun), the Cfun returns garbage (and also it corrupts the system).
>>>>>
>>>>> For example, I cannot get good results when after the fresh flash I do:
>>>>> $0fdb $4049 2constant pi
>>>>> decimal 100 2000 5. pi pi Ctest hex
>>>>>
>>>>> I've tried push/pop W4-W7, but the same.
>>>>> I.
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> 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-08 20:18:13
|
And to answer my own question.
It can be done like below
__attribute__((address(0x1000)))
float Ctest(unsigned short a, unsigned short b, unsigned long int c,
float x, float y)
{
a = a + 100;
b = b / a;
c = c * b;
x = sqrtf( (float)c - x );
y = y / x;
return y; // 4.5894021E-1
}
On 08.06.2015 23:03, Mikael Nordman wrote:
> How did you solve it ?
>
> In my tests you get this problem because the Ctest.c file is linked after
> the FF binary code into a the area where FF thinks is free space for the
> dictionary. Compiling some FF code will then overwrite the C code.
>
> This happens if you also include the float package into the compilation.
> If you do not include the float package, Ctest code will fit into memory
> before the FF binary code and all is fine.
>
> How can the linker be forced to link the C-code before the FF code ?
> Bu defining some new sections for the linker perhaps.
>
> There is no reason to save W0..W7 before calling the C function because
> these registers are not 'live' in FF between words.
>
> Mikael
>
> On 06.06.2015 19:30, om1zz wrote:
>> Solved, see examples.
>> I.
>>
>> _____________________________________________________________
>>>> Od: "om1zz" <om...@vo...>
>>>> Komu: Mikael Nordman <mik...@fl...>
>>>> Datum: 04.06.2015 19:00
>>>> Předmět: C function with more parameters in W0-W7
>>>>
>>>> MIke, I cope with following issue:
>>>>
>>>> I have a Cfunction, with 5 parameters, returning float.
>>>>
>>>> So I am using W0-W7 for params.
>>>>
>>>> The strange:
>>>> First time after the fresh flash the Cfun (when pasting the below
>>>> into teraterm) returns good result:
>>>>
>>>> decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36
>>>> 3eea
>>>>
>>>> I can do it repeatedly, I always get good results.
>>>>
>>>> decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36
>>>> 3eea
>>>> decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36
>>>> 3eea fa36 3eea
>>>> decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36
>>>> 3eea fa36 3eea fa36 3eea
>>>>
>>>> In the moment as I do something via prompt (before or after playing
>>>> with Cfun), the Cfun returns garbage (and also it corrupts the system).
>>>>
>>>> For example, I cannot get good results when after the fresh flash I do:
>>>> $0fdb $4049 2constant pi
>>>> decimal 100 2000 5. pi pi Ctest hex
>>>>
>>>> I've tried push/pop W4-W7, but the same.
>>>> I.
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Flashforth-devel mailing list
>>> Fla...@li...
>>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>>
|
|
From: Mikael N. <mik...@fl...> - 2015-06-07 17:14:47
|
I changed all FF versions to use 16-bit task size parameters. It had been in the backlog for a while :-) It should not affect any user code. But you have to use the latest version of TASK: and TINIT with this change. git pull ! On 07.06.2015 13:28, om1zz wrote: > Hi, while playing with calling external C functions (with an intention to run larger drivers - fat, tft, etc) I see the rstack of max 256 bytes is not enough. Even a smaller Cfun (with rtc running in intr) consumes ~240bytes of rstack (rstack is used as the Cfun stack afaik). > > Igor > > ------------------------------------------------------------------------------ > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
17 messages has been excluded from this view by a project administrator.
