Sign in
Search adsp
Subscribe to adsp
adsp by Keywords
AD1819 | AD7332 | ADSP-2106 | ADSP-21060 | ADSP-21065L | ADSP-2116 | ADSP-21160M | ADSP-2181 | ADSP-218x | ADSP-219 | ADSP-2199 | ADSP219 | BF531 | BF532 | BF533 | BF535 | Blackfin | FFT | JTAG | LDF | SDRAM | SHARC | SPORT | UART | VDSP++ | VisualDSP
Discussion Groups
Discussion Groups | Analog Devices DSPs | Re: VDSP++ V4.0
Technical discussions related to Analog Devices DSPs (including Blackfin, TigerSHARC, SHARC and ADSP-21xx DSPs).
VDSP++ V4.0 - Steve Holle - Feb 21 18:28:00 2005
|
I know, I'm a glutton for punishment. I loaded up 4.0 and am trying to get a project to compile that compiled under 3.5 and I get the following errors : [Error li1021] The following symbols referenced in processor 'P0' could not be resolved: '__vec_new [___vec_new]' referenced from 'CombinedOutputClass.doj' '__vec_new [___vec_new]' referenced from 'ProcessSamplesClass.doj' I use vecsmlt but have include vector.h. What am I missing? Steve Holle Link Communications, Inc. 1035 Cerise Rd. Billings, MT 59101 |
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: VDSP++ V4.0 - Eduardo - Feb 22 7:03:00 2005
|
Itīs happened to me either... Linker error where it didnīt exist. I had to go back and reinstall VDSP3.5. Regards, Eduardo. ---------------------------------------------------------- At 15:28 21/2/2005 -0700, you wrote: >I know, I'm a glutton for punishment. I loaded up 4.0 and am trying to get >a project to compile that compiled under 3.5 and I get the following errors : >[Error li1021] The following symbols referenced in processor 'P0' could >not be resolved: > '__vec_new [___vec_new]' referenced from 'CombinedOutputClass.doj' > '__vec_new [___vec_new]' referenced from 'ProcessSamplesClass.doj' >I use vecsmlt but have include vector.h. What am I missing? >Steve Holle >Link Communications, Inc. >1035 Cerise Rd. >Billings, MT 59101 |
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: VDSP++ V4.0 - Author Unknown - Feb 23 9:13:00 2005
|
Hi Steve, When you built the project in VisualDSP++4.0, was the LDF file used the same as that used for VisualDSP++ 3.5? If so I would create a new LDF based on the default one included in the new VisualDSP++ 4.0 install directory. It's not the first time I've received linker errors when upgrading from one version to the next. It can be due to any number of modifications that ADI have made in the linker. What can happen is that new memory sections are created in the new libraries. This requires new sections within the LDF. Using an old LDF may not have these segments defined. There are quite a lot of differences between the 3.5 and 4.0 LDFs. If you did transition the LDF over then it may be that if you do not use the $COMMAND_LINE_OBJECTS macro in the LDF (as should be the case with MP LDFs) then you may have simply missed out an object file in the list of objects to link to. It would appear the one that "__vec_new" is defined in, although I suspect that this is most likely a parameter from the libraries that has not been linked. Are there any other warnings indicating memory sections that have not been mapped? Regards Rich > >I know, I'm a glutton for punishment. I loaded up 4.0 and am trying to get >a project to compile that compiled under 3.5 and I get the following errors : >[Error li1021] The following symbols referenced in processor 'P0' could >not be resolved: >'__vec_new [___vec_new]' referenced from 'CombinedOutputClass.doj' >'__vec_new [___vec_new]' referenced from 'ProcessSamplesClass.doj' >I use vecsmlt but have include vector.h. What am I missing? >Steve Holle >Link Communications, Inc. >1035 Cerise Rd. >Billings, MT 59101 |
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: Re: VDSP++ V4.0 - Steve Holle - Feb 23 12:02:00 2005
|
I used the IDDE to create a new ldf and copied over my changes. I'm not absolutely sure I did all this correctly. I have sent the ldf to ADI but no response yet. Pardon the long post but I will insert it below minus the top comments : Thanks for your help. #ifndef __NO_STD_LIB SEARCH_DIR( $ADI_DSP/21k/lib ) #endif // The I/O library provides support for printing hexadecimal constants // using the "%a" conversion specifier, and for registering alternatives to // the default device driver that is supported by the VisualDSP++ simulator // and EZ-KIT Lite systems. Those applications that do not require this // functionality may define the macro __LIBIO_LITE which will select an // alternative I/O library and lead to reduced code occupancy. $DEF_LIBS = libdsp.dlb ; $C_CPP_LIBS = libc.dlb, libdsp.dlb, libio.dlb, libeh.dlb, libcpprt.dlb; $LIBRARIES = $DEF_LIBS, $C_CPP_LIBS; // Libraries from the command line are included in COMMAND_LINE_OBJECTS. $OBJECTS = 065L_cpp_hdr.doj, $COMMAND_LINE_OBJECTS; MEMORY { seg_rth { TYPE(PM RAM) START(0x00008000) END(0x000080af) WIDTH(48) } seg_init { TYPE(PM RAM) START(0x000080b0) END(0x000080be) WIDTH(48) } seg_int_code { TYPE(PM RAM) START(0x000080bf) END(0x000080ca) WIDTH(48) } seg_pmco { TYPE(PM RAM) START(0x000080cb) END(0x00009542) WIDTH(48) } seg_pmda { TYPE(PM RAM) START(0x00009e00) END(0x00009fff) WIDTH(32) } mem_ctdm { TYPE(DM RAM) START(0x0000c000) END(0x0000C01f) WIDTH(32) } seg_dmda { TYPE(DM RAM) START(0x0000c020) END(0x0000d91f) WIDTH(32) } seg_heap { TYPE(DM RAM) START(0x0000d920) END(0x0000d99f) WIDTH(32) } seg_stak { TYPE(DM RAM) START(0x0000d9a0) END(0x0000dfff) WIDTH(32) } seg_pm_sram { TYPE(PM RAM) START(0x00020000) END(0x00027fff) WIDTH(32) } seg_dm_sram { TYPE(DM RAM) START(0x00030000) END(0x0005ffff) WIDTH(32) } } PROCESSOR P0 { KEEP( _main,___ctor_NULL_marker,___lib_end_of_heap_descriptions ) OUTPUT( $COMMAND_LINE_OUTPUT_FILE ) SECTIONS { // .text output section seg_dm_sram { INPUT_SECTIONS( CombinedOutputClass.doj(seg_dm_sram) Sport1Interrupts.doj(seg_dm_sram)) } > seg_dm_sram seg_pmco { INPUT_SECTIONS( CombinedOutputClass.doj(seg_pmco) fir_ary.doj(seg_pmco) HP4kHz_16ksps.doj(seg_pmco) InputSplitConvert_V3_01.doj(seg_pmco) LP4kHz_16ksps.doj(seg_pmco) Mix.doj(seg_pmco) ProcessInt.doj(seg_pmco) Sport0Interrupts.doj(seg_pmco) Sport1Interrupts.doj(seg_pmco) TDM_SPORT0_Init.doj(seg_pmco) libc.dlb [ int_cncbl.doj (seg_pmco) ] libc.dlb [ int_cnfl.doj (seg_pmco) ] libc.dlb [ int_cnsl.doj (seg_pmco) ] libc.dlb [ int_cnss.doj (seg_pmco) ] libc.dlb [ int_cntl.doj (seg_pmco) ] libc.dlb [ int_sprt.doj (seg_pmco) ] libc.dlb [ int_tabl.doj (seg_pmco) ] libc.dlb [ interrup.doj (seg_pmco) ] libc.dlb [ interrupnsm.doj (seg_pmco) ] libdsp.dlb [ fir.doj (seg_pmco) ] ProcessSamplesClass.doj(seg_pmco) SigLib.dlb [ dtmf.doj (seg_pmco) ] SigLib.dlb [ filter.doj (seg_pmco) ] SigLib.dlb [ minmax.doj (seg_pmco) ] libc.dlb [ fabs.doj (seg_pmco) ] libdsp.dlb [ rms_nonSIMD.doj (seg_pmco) ] libdsp.dlb [ vecsmlt_nonSIMD.doj (seg_pmco) ] libc.dlb [ flagset.doj (seg_pmco) ] DelayClass.doj(seg_pmco) libc.dlb [ idle.doj (seg_pmco) ] libc.dlb [ raise.doj (seg_pmco) ] DTMFDecodeClass.doj(seg_pmco) GoertzelClass.doj(seg_pmco)) } >seg_pmco seg_pm_sram // Catch whatever we deon't specifically put in internal mem { INPUT_SECTIONS( $OBJECTS(seg_pmco) $LIBRARIES(seg_pmco) $C_CPP_LIBS(seg_pmco)) } > seg_pm_sram seg_rth { INPUT_SECTIONS( $OBJECTS(seg_rth) $LIBRARIES(seg_rth)) } >seg_rth seg_init { INPUT_SECTIONS( $OBJECTS(seg_init) $LIBRARIES(seg_init)) } >seg_init seg_int_code { INPUT_SECTIONS( $OBJECTS(seg_int_code) $LIBRARIES(seg_int_code)) } >seg_int_code seg_pmda { INPUT_SECTIONS( $OBJECTS(seg_pmda) $LIBRARIES(seg_pmda)) } >seg_pmda dxe_ctdm { __ctors = .; /* points to the start of the section */ INPUT_SECTIONS( $OBJECTS(seg_ctdm) $LIBRARIES(seg_ctdm)) INPUT_SECTIONS( $OBJECTS(seg_ctdml) $LIBRARIES(seg_ctdml)) } > mem_ctdm .bss ZERO_INIT { INPUT_SECTIONS( $OBJECTS(.bss) $LIBRARIES(.bss)) } > seg_dmda seg_dmda { INPUT_SECTIONS( $OBJECTS(seg_dmda) $LIBRARIES(seg_dmda)) } > seg_dmda .gdt { INPUT_SECTIONS( $OBJECTS(.gdt) $LIBRARIES(.gdt)) INPUT_SECTIONS( $OBJECTS(.gdtl) $LIBRARIES(.gdtl)) } > seg_dmda .frt { INPUT_SECTIONS( $OBJECTS(.frt) $LIBRARIES(.frt)) INPUT_SECTIONS( $OBJECTS(.frtl) $LIBRARIES(.frtl)) } > seg_dmda .cht { INPUT_SECTIONS( $OBJECTS(.cht) $LIBRARIES(.cht)) INPUT_SECTIONS( $OBJECTS(.chtl) $LIBRARIES(.chtl)) } > seg_dmda .edt { INPUT_SECTIONS( $OBJECTS(.edt) $LIBRARIES(.edt)) INPUT_SECTIONS( $OBJECTS(.edtl) $LIBRARIES(.edtl)) } > seg_dmda dxe_vtbl { INPUT_SECTIONS( $OBJECTS(seg_vtbl) $LIBRARIES(seg_vtbl)) } > seg_dmda stackseg { // allocate a stack for the application ldf_stack_space = .; ldf_stack_length = MEMORY_SIZEOF(seg_stak); } > seg_stak heap { // allocate a heap for the application ldf_heap_space = .; ldf_heap_length = MEMORY_SIZEOF(seg_heap); ldf_heap_end = ldf_heap_space + ldf_heap_length - 1; } > seg_heap } } At 06:13 AM 2/23/2005, wrote: >Hi Steve, > >When you built the project in VisualDSP++4.0, was the LDF file used the >same as that used for VisualDSP++ 3.5? If so I would create a new LDF >based on the default one included in the new VisualDSP++ 4.0 install >directory. It's not the first time I've received linker errors when >upgrading from one version to the next. It can be due to any number of >modifications that ADI have made in the linker. > >What can happen is that new memory sections are created in the new >libraries. This requires new sections within the LDF. Using an old LDF may >not have these segments defined. There are quite a lot of differences >between the 3.5 and 4.0 LDFs. > >If you did transition the LDF over then it may be that if you do not use >the $COMMAND_LINE_OBJECTS macro in the LDF (as should be the case with MP >LDFs) then you may have simply missed out an object file in the list of >objects to link to. It would appear the one that "__vec_new" is defined >in, although I suspect that this is most likely a parameter from the >libraries that has not been linked. > >Are there any other warnings indicating memory sections that have not been >mapped? > >Regards >Rich > > > > > > > > > >I know, I'm a glutton for punishment. I loaded up 4.0 and am trying to > get > >a project to compile that compiled under 3.5 and I get the following > errors : > >[Error li1021] The following symbols referenced in processor 'P0' could > >not be resolved: > >'__vec_new [___vec_new]' referenced from 'CombinedOutputClass.doj' > >'__vec_new [___vec_new]' referenced from 'ProcessSamplesClass.doj' > >I use vecsmlt but have include vector.h. What am I missing? > > > > > >Steve Holle > >Link Communications, Inc. > >1035 Cerise Rd. > >Billings, MT 59101 > > > > > > > > > > > > > > > > > Steve Holle Link Communications, Inc. 1035 Cerise Rd. Billings, MT 59101 |
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: VDSP++ V4.0 - russell_washington - Feb 23 13:42:00 2005
|
Steve -- I'm not sure what processor you are targeting, I grep'ed through the SHARC .dlb files (in ...\21k\lib_ and found __vec_new in the C++ libraries (STL maybe?). Given that the two filenames you mention have "Class" in their name, it is safe to assume these are C++ sources? It may just be a matter of adding the right library (libcpp.dlb perhaps) to your LDF. I don't use C++ myself, so I cannot give you a lot of guidence in this area, but I looked through the on-line help and perhaps this topic will be useful (again, this is assuming for SHARC): ->Manuals ->Software Tool Manuals ->SHARC Compiler Manual ->VisualDSP++ 4.0 C/C++ Compiler and Library Manual for SHARC Processors ->C/C++ Run-Time Library ->C and C++ Run-Time Library Guide ->Linking Library Functions Regards, RUSS --- In , Steve Holle <sholle@l...> wrote: > > I know, I'm a glutton for punishment. I loaded up 4.0 and am trying to get > a project to compile that compiled under 3.5 and I get the following errors : > [Error li1021] The following symbols referenced in processor 'P0' could > not be resolved: > '__vec_new [___vec_new]' referenced from 'CombinedOutputClass.doj' > '__vec_new [___vec_new]' referenced from 'ProcessSamplesClass.doj' > I use vecsmlt but have include vector.h. What am I missing? > Steve Holle > Link Communications, Inc. > 1035 Cerise Rd. > Billings, MT 59101 > sholle@l... |
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: Re: VDSP++ V4.0 - Author Unknown - Feb 23 14:28:00 2005
|
Hi Steve, My guess is that you've left out the libcpp.dlb from the $C_CPP_LIBS macro. Regards Rich > > > I used the IDDE to create a new ldf and copied over my changes. I'm not >absolutely sure I did all this correctly. I have sent the ldf to ADI but >no response yet. Pardon the long post but I will insert it below minus >the top comments : > >Thanks for your help. > >#ifndef __NO_STD_LIB >SEARCH_DIR( $ADI_DSP/21k/lib ) >#endif ............... ............... >> > >> >Steve Holle >> >Link Communications, Inc. >> >1035 Cerise Rd. >> >Billings, MT 59101 >> |
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: Re: Re: VDSP++ V4.0 - Steve Holle - Feb 23 16:10:00 2005
|
Yup, your right. A big "duh" on my part. Thanks for the help. At 11:28 AM 2/23/2005, wrote: >Hi Steve, > >My guess is that you've left out the libcpp.dlb from the $C_CPP_LIBS macro. > >Regards >Rich > > > > > > > > > I used the IDDE to create a new ldf and copied over my changes. I'm not > >absolutely sure I did all this correctly. I have sent the ldf to ADI but > >no response yet. Pardon the long post but I will insert it below minus > >the top comments : > > > >Thanks for your help. > > > >#ifndef __NO_STD_LIB > >SEARCH_DIR( $ADI_DSP/21k/lib ) > >#endif >............... >............... > >> > > >> >Steve Holle > >> >Link Communications, Inc. > >> >1035 Cerise Rd. > >> >Billings, MT 59101 > >> Steve Holle Link Communications, Inc. 1035 Cerise Rd. Billings, MT 59101 |
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )