|
Hello guys, Working on ADSP-21065L, VisualDSP++ 3.5 Nov'04 update. I my application I'd get good benefit form the sprintf function, which one links to with #include <stdio.h>. However, I don't need the full of the library. But (as expected) the full library plus my code do not fit within the internal memory of the '065L. I tried to change the .ldf in order to make some part of Block1 (0xc000 to 0xc100) available for code. The ldf was not the problem. The problem is that I couldn't make this new segment (which I named seg_pmco2) visible for the linker to use it for placing some part of the code within it. So, my questions are: 1. How can I make another PM segment, defined in Block 1, visible to the linker for (automatically) placing code within it? 2. The source code for the sprintf function is available in a file named sprint.c. How can I build ONLY THIS FUNCTIONwithin my project? It has the following includes: #include "_stdio.h" #include "stdio.h" #include "stdarg.h" #include "adi_threads.h" I suspect that it would call many things more, again, not fitting into the 065's internal memory. All of your comments/suggestions are very welcome. TIA -- ------------------------------ Jaime Andr Aranguren Cardona SanJaaC Electronics Soluciones en DSP www.sanjaac.com |
SHARC: Linker, libraries, etc. Advise needed
Started by ●March 17, 2005
Reply by ●March 18, 20052005-03-18
|
On Fri, 18 Mar 2005, [iso-8859-1] Jaime Andr Aranguren Cardona wrote: > Hello guys, Howdy Jaime, > Working on ADSP-21065L, VisualDSP++ 3.5 Nov'04 update. > > I my application I'd get good benefit form the sprintf function, > which one links to with #include <stdio.h>. However, I don't need > the full of the library. > > But (as expected) the full library plus my code do not fit within > the internal memory of the '065L. > > I tried to change the .ldf in order to make some part of Block1 > (0xc000 to 0xc100) available for code. The ldf was not the problem. > The problem is that I couldn't make this new segment (which I named > seg_pmco2) visible for the linker to use it for placing some part of > the code within it. Rather than use the C code, you might want to write a very small assembler routine that does what you want. sprintf does formatting as well as data movement. If you only do simple formatting, your own routines can be pretty small. floating point gets to be a pain, but again it's not that hard if you use a fixed format (like always 0.xxxxe+/-yy). It is all the exceptions that C must deal with that makes it big. Patience, persistence, truth, Dr. mike |
Reply by ●March 18, 20052005-03-18
|
Mike, Thanks for the suggestion. I'll try to figure it out. It's use will be mainly to format floating point data (damn!) into a string of cahracters, for later writting to a LCD. Any suggestions about where to start, to write my own? One further question... when one uses a library function (sprintf, in this case for instance), the linker only links that function, and not the whole library. Am I right? Regards, JaaC --- Mike Rosing <> wrote: > On Fri, 18 Mar 2005, [iso-8859-1] Jaime Andr > Aranguren Cardona wrote: > > > Hello guys, > > Howdy Jaime, > > > Working on ADSP-21065L, VisualDSP++ 3.5 Nov'04 > update. > > > > I my application I'd get good benefit form the > sprintf function, > > which one links to with #include <stdio.h>. > However, I don't need > > the full of the library. > > > > But (as expected) the full library plus my code do > not fit within > > the internal memory of the '065L. > > > > I tried to change the .ldf in order to make some > part of Block1 > > (0xc000 to 0xc100) available for code. The ldf was > not the problem. > > The problem is that I couldn't make this new > segment (which I named > > seg_pmco2) visible for the linker to use it for > placing some part of > > the code within it. > > Rather than use the C code, you might want to write > a very small assembler > routine that does what you want. sprintf does > formatting as well as data > movement. If you only do simple formatting, your > own routines can be > pretty small. floating point gets to be a pain, but > again it's not that > hard if you use a fixed format (like always > 0.xxxxe+/-yy). It is all the > exceptions that C must deal with that makes it big. > > Patience, persistence, truth, > Dr. mike Jaime Andr Aranguren Cardona __________________________________ |
Reply by ●March 18, 20052005-03-18
|
Hi, After struggling for a while, I could make it fit. I created another section on the LDF, named seg_pmco2, from 0xC000 to 0xC7FF. The original seg_pmco is configured to overflow into seg_pmco2. Now it fits. But very few free space remains available, simply calling sprintf took around 2kWords. Maybe overlays are a solution if the program gets even bigger. I've read it works via DMA. The only external memory I have is SDRAM. Is it possible to mix them to make overlays work? If so, how? Any pointers are very welcome. JaaC --- Mike Rosing <> wrote: > On Fri, 18 Mar 2005, [iso-8859-1] Jaime Andr > Aranguren Cardona wrote: > > > Hello guys, > > Howdy Jaime, > > > Working on ADSP-21065L, VisualDSP++ 3.5 Nov'04 > update. > > > > I my application I'd get good benefit form the > sprintf function, > > which one links to with #include <stdio.h>. > However, I don't need > > the full of the library. > > > > But (as expected) the full library plus my code do > not fit within > > the internal memory of the '065L. > > > > I tried to change the .ldf in order to make some > part of Block1 > > (0xc000 to 0xc100) available for code. The ldf was > not the problem. > > The problem is that I couldn't make this new > segment (which I named > > seg_pmco2) visible for the linker to use it for > placing some part of > > the code within it. > > Rather than use the C code, you might want to write > a very small assembler > routine that does what you want. sprintf does > formatting as well as data > movement. If you only do simple formatting, your > own routines can be > pretty small. floating point gets to be a pain, but > again it's not that > hard if you use a fixed format (like always > 0.xxxxe+/-yy). It is all the > exceptions that C must deal with that makes it big. > > Patience, persistence, truth, > Dr. mike Jaime Andr Aranguren Cardona __________________________________ |
Reply by ●March 18, 20052005-03-18
|
On Fri, 18 Mar 2005, Jaime Andres Aranguren Cardona wrote: > After struggling for a while, I could make it fit. I > created another section on the LDF, named seg_pmco2, > from 0xC000 to 0xC7FF. The original seg_pmco is > configured to overflow into seg_pmco2. > Now it fits. But very few free space remains > available, simply calling sprintf took around 2kWords. > > Maybe overlays are a solution if the program gets even > bigger. I've read it works via DMA. The only external > memory I have is SDRAM. Is it possible to mix them to > make overlays work? If so, how? > > Any pointers are very welcome. I have not done overlays with the ldf. One way to do it would be to link independent files, then combine them as raw data with a #include. Klunky, but it would work. To your previous question about how to write a floating point conversion, check out the routines here: www.eskimo.com/~eresrch/float/bigio.c and look at the routine float_to_ascii. I use my own format for the floating point format, but it should give you the basic idea of what to do. Good luck with it! Patience, persistence, truth, Dr. mike |
Reply by ●March 18, 20052005-03-18
|
This is what we use. In our c file we use : seg_pm_sram { TYPE(PM RAM) START(0x230000) END(0x23ffff) WIDTH(48) } In the ldf file it looks like this : MEMORY { . . . seg_pm_sram { TYPE(PM RAM) START(0x230000) END(0x23ffff) WIDTH(48) } } SECTIONS { // .text output section. Added NO_INIT below to reduce loading times (3/8/05). seg_dm_sram NO_INIT { INPUT_SECTIONS( CombinedOutputClass.doj(seg_dm_sram) Sport1Interrupts.doj(seg_dm_sram)) } > seg_dm_sram seg_pmco { INPUT_SECTIONS( OutputToneClass.doj (seg_pmco) CombinedOutputClass.doj(seg_pmco)) } >seg_pmco // Catch whatever we don't specifically put in internal mem seg_pm_sram { INPUT_SECTIONS( $OBJECTS(seg_pmco) $LIBRARIES(seg_pmco) $OBJECTS(seg_pm_sram) $LIBRARIES(seg_pm_sram) $C_CPP_LIBS(seg_pmco)) } > seg_pm_sram Does this look like what you want to do? At 07:16 PM 3/17/2005, Jaime Andr Aranguren Cardona wrote: >Hello guys, > >Working on ADSP-21065L, VisualDSP++ 3.5 Nov'04 update. > >I my application I'd get good benefit form the sprintf function, >which one links to with #include <stdio.h>. However, I don't need >the full of the library. > >But (as expected) the full library plus my code do not fit within >the internal memory of the '065L. > >I tried to change the .ldf in order to make some part of Block1 >(0xc000 to 0xc100) available for code. The ldf was not the problem. >The problem is that I couldn't make this new segment (which I named >seg_pmco2) visible for the linker to use it for placing some part of >the code within it. > >So, my questions are: > >1. How can I make another PM segment, defined in Block 1, visible to >the linker for (automatically) placing code within it? >2. The source code for the sprintf function is available in a file >named sprint.c. How can I build ONLY THIS FUNCTIONwithin my project? >It has the following includes: > >#include "_stdio.h" > >#include "stdio.h" >#include "stdarg.h" > >#include "adi_threads.h" > >I suspect that it would call many things more, again, not fitting >into the 065's internal memory. > >All of your comments/suggestions are very welcome. > >TIA > >-- >------------------------------ >Jaime Andr Aranguren Cardona > >SanJaaC Electronics >Soluciones en DSP >www.sanjaac.com > > Steve Holle Link Communications, Inc. 1035 Cerise Rd. Billings, MT 59101 |
Reply by ●March 18, 20052005-03-18
|
At 09:42 PM 3/17/2005, Jaime Andres Aranguren Cardona wrote: >Mike, > >Thanks for the suggestion. I'll try to figure it out. >It's use will be mainly to format floating point data >(damn!) into a string of cahracters, for later >writting to a LCD. Any suggestions about where to >start, to write my own? > >One further question... when one uses a library >function (sprintf, in this case for instance), the >linker only links that function, and not the whole >library. Am I right? Have you tried enabling elimination in your ldf file? >Regards, > >JaaC > >--- Mike Rosing <> wrote: > > On Fri, 18 Mar 2005, [iso-8859-1] Jaime Andr > > Aranguren Cardona wrote: > > > > > Hello guys, > > > > Howdy Jaime, > > > > > Working on ADSP-21065L, VisualDSP++ 3.5 Nov'04 > > update. > > > > > > I my application I'd get good benefit form the > > sprintf function, > > > which one links to with #include <stdio.h>. > > However, I don't need > > > the full of the library. > > > > > > But (as expected) the full library plus my code do > > not fit within > > > the internal memory of the '065L. > > > > > > I tried to change the .ldf in order to make some > > part of Block1 > > > (0xc000 to 0xc100) available for code. The ldf was > > not the problem. > > > The problem is that I couldn't make this new > > segment (which I named > > > seg_pmco2) visible for the linker to use it for > > placing some part of > > > the code within it. > > > > Rather than use the C code, you might want to write > > a very small assembler > > routine that does what you want. sprintf does > > formatting as well as data > > movement. If you only do simple formatting, your > > own routines can be > > pretty small. floating point gets to be a pain, but > > again it's not that > > hard if you use a fixed format (like always > > 0.xxxxe+/-yy). It is all the > > exceptions that C must deal with that makes it big. > > > > Patience, persistence, truth, > > Dr. mike >Jaime Andr Aranguren Cardona > >__________________________________ > > Steve Holle Link Communications, Inc. 1035 Cerise Rd. Billings, MT 59101 |
Reply by ●March 18, 20052005-03-18
|
At 08:09 AM 3/18/2005, Steve Holle wrote: >This is what we use. In our c file we use : > seg_pm_sram { TYPE(PM RAM) START(0x230000) END(0x23ffff) WIDTH(48) } Sorry, ignore the line above. That's how we place arrays in external memory. >In the ldf file it looks like this : >MEMORY >{ > . > . > . > seg_pm_sram { TYPE(PM RAM) START(0x230000) END(0x23ffff) WIDTH(48) } >} > > SECTIONS > { > > // .text output section. Added NO_INIT below to reduce loading times >(3/8/05). > seg_dm_sram NO_INIT > { > INPUT_SECTIONS( >CombinedOutputClass.doj(seg_dm_sram) Sport1Interrupts.doj(seg_dm_sram)) > } > seg_dm_sram > > seg_pmco > { > INPUT_SECTIONS( OutputToneClass.doj (seg_pmco) >CombinedOutputClass.doj(seg_pmco)) > } >seg_pmco > > // Catch whatever we don't specifically put in internal mem > seg_pm_sram > { > INPUT_SECTIONS( $OBJECTS(seg_pmco) >$LIBRARIES(seg_pmco) $OBJECTS(seg_pm_sram) $LIBRARIES(seg_pm_sram) >$C_CPP_LIBS(seg_pmco)) > } > seg_pm_sram > >Does this look like what you want to do? > >At 07:16 PM 3/17/2005, Jaime Andr Aranguren Cardona wrote: > >Hello guys, > > > >Working on ADSP-21065L, VisualDSP++ 3.5 Nov'04 update. > > > >I my application I'd get good benefit form the sprintf function, > >which one links to with #include <stdio.h>. However, I don't need > >the full of the library. > > > >But (as expected) the full library plus my code do not fit within > >the internal memory of the '065L. > > > >I tried to change the .ldf in order to make some part of Block1 > >(0xc000 to 0xc100) available for code. The ldf was not the problem. > >The problem is that I couldn't make this new segment (which I named > >seg_pmco2) visible for the linker to use it for placing some part of > >the code within it. > > > >So, my questions are: > > > >1. How can I make another PM segment, defined in Block 1, visible to > >the linker for (automatically) placing code within it? > >2. The source code for the sprintf function is available in a file > >named sprint.c. How can I build ONLY THIS FUNCTIONwithin my project? > >It has the following includes: > > > >#include "_stdio.h" > > > >#include "stdio.h" > >#include "stdarg.h" > > > >#include "adi_threads.h" > > > >I suspect that it would call many things more, again, not fitting > >into the 065's internal memory. > > > >All of your comments/suggestions are very welcome. > > > >TIA > > > >-- > >------------------------------ > >Jaime Andr Aranguren Cardona > > > >SanJaaC Electronics > >Soluciones en DSP > >www.sanjaac.com > > > > > > > > > > > > > > > > > > > > > >Steve Holle >Link Communications, Inc. >1035 Cerise Rd. >Billings, MT 59101 > Steve Holle Link Communications, Inc. 1035 Cerise Rd. Billings, MT 59101 |
Reply by ●March 18, 20052005-03-18
|
Thanks Mike, --- Mike Rosing <> wrote: > I have not done overlays with the ldf. One way to > do it would be > to link independent files, then combine them as raw > data with a > #include. Klunky, but it would work. Seems complicated... > To your previous question about how to write a > floating point > conversion, check out the routines here: > www.eskimo.com/~eresrch/float/bigio.c and look at > the routine > float_to_ascii. Will have a look at it. > I use my own format for the > floating point format, but > it should give you the basic idea of what to do. That's exactly the kind of information I was looking for. Let's see what it takes to make it work for me. > Good luck with it! > > Patience, persistence, truth, > Dr. mike Jaime Andr Aranguren Cardona __________________________________ |
Reply by ●March 18, 20052005-03-18
|
Hi Steve, Thanks for the inforation. --- Steve Holle <> wrote: > This is what we use. In our c file we use : > seg_pm_sram { TYPE(PM RAM) START(0x230000) > END(0x23ffff) WIDTH(48) } This is external memory, mapped to external bank 0, and from your naming, seems tobe SRAM. I am working on the EzKit, on which the external memory is SDRAM and mapped to bank 3. So I cannot store instructions there for execution (065's User's Manual says on page 5-48 "if you want to run code from xternal memory, you msut do so from bank 0" So, I'll need to add my own SRAM! > In the ldf file it looks like this : > MEMORY > { > . > . > . > seg_pm_sram { TYPE(PM RAM) START(0x230000) > END(0x23ffff) WIDTH(48) } > } > > SECTIONS > { > > // .text output section. Added NO_INIT below > to reduce loading times > (3/8/05). > seg_dm_sram NO_INIT > { > INPUT_SECTIONS( > CombinedOutputClass.doj(seg_dm_sram) > Sport1Interrupts.doj(seg_dm_sram)) > } > seg_dm_sram > > seg_pmco > { > INPUT_SECTIONS( > OutputToneClass.doj (seg_pmco) > CombinedOutputClass.doj(seg_pmco)) > } >seg_pmco > > // Catch whatever we don't specifically put in > internal mem > seg_pm_sram > { > INPUT_SECTIONS( > $OBJECTS(seg_pmco) > $LIBRARIES(seg_pmco) $OBJECTS(seg_pm_sram) > $LIBRARIES(seg_pm_sram) > $C_CPP_LIBS(seg_pmco)) > } > seg_pm_sram > > Does this look like what you want to do? More or less. I could make it work by letting seg_pmco to overflow over another section, defined in (internal) bank 1. Thanks a lot! JaaC Jaime Andr Aranguren Cardona __________________________________________________ |
