|
Don't know anything about LINK_AGAINST. But the manual says for example the SHARC has internal memory somewhere $0008000-$000DFFF or so**. If you attach external memory to your system for example to MS1 it can be seen at $01000000... or so**. ** The real address depends on the chip adsp21xxx derivate. If tell the DSP to do "*ptr = var;" in your C-code it depends on the pointer if this is a local or global access. For most DSPs (not for 065L and 161N) you can think of the DSPs internal memory as of a great array. dsp_ram[7][???] dsp[0][] will on each DSP access its own memory dsp[1][] will access DSP1 memory from all DSPs point of view. Please feel free to take a closer look at the manual pages "multiprocessor memory map". For me it helped a lot ;-) Jens ----- Original Message ----- From: "Vanbellinghen, Paul" <> To: "'Jens Michaelsen'" <>; <>; <>; "Liyju Janardhan" <> Sent: Thursday, May 08, 2003 3:09 PM Subject: RE: [adsp] ADSP 14060 -- Multiprocessing using C > In other words, the same global variable (name) defined for all DSPs will be > local to each DSP where it is defined. However, if you wish to define ONE > variable to be shared between all DSPs, you would define it only in the link > of one DSP and reference it as an extern on the others. As long as you > correctly use the LINK_AGAINST statement in the ldf file, the linker will > know to look for the address of the variable on the DSP where it is defined. > > Another point is that SHARC shared "networking" between DSPs is not like > VxWorks where there is a master processor on the bus and the others are > slave. Any DSP can access the global memory of any other DSP on the same > board in the same way - although there is a priority scheme for bus > contention issues. > > > From: Jens Michaelsen [SMTP:] > > > > Hi there, > > > > each Sharc has its own internal SRAM, > > here it can execute code AND hold variables. > > only the external global memory is shared. > > > > > > Jens Michaelsen > > > > b.t.w. > > "We have both Contry AND Western" > > (Put your sunglasses on) > > > > ----- Original Message ----- > > From: "Liyju Janardhan" <> > > To: <>; <> > > Sent: Wednesday, May 07, 2003 10:33 AM > > Subject: RE: [adsp] ADSP 14060 -- Multiprocessing using C > > > > > > > Hi all, > > > Thanks for your replies. > > > > > > Running the single executable for all processor is a > > > good solution for the multiple main() error. > > > > > > But what about inter-processor communication. There > > > won't be any variable local to a particular processor. > > > > > > So all the variable defined will belong to the bus > > > master. How can a salve access these variable. > > > > > > I didn't get what you mean by putting the processorID > > > value in non-volatile memory. > > > I am reading the processor id this way: > > > > > > int sys,pro_id; > > > ...... > > > sys = getIOP(SYSTAT); > > > pro_id = getID(sys); > > > > > > Though the above code will be running in all the > > > proccesors, pro_id will contain the id of the bus > > > master, I guess. > > > > > > So, How can I determine that this particular code is > > > running on processor 2, and execute a routine specific > > > > > > to processor 2 using switch/case.(because pro_id will > > > contain id of bus master) > > > > > > If I use two different build and create two differnet > > > dxe's, how to call a variable of one code in other > > > code, using C. > > > In assembly it is possible. Refer ffton2pe example > > > in C:\Program Files\Analog > > > Devices\VisualDSP\21k\Examples\ASM_Examples\FFTON2PE > > > > > > But note that all the asm files are there in same > > > build. I can't put all the C files in same bulid > > > because it gives multiple main() error. > > > > > > > > > Please help > > > > > > Regards > > > > > > Liyju > > > > > > > > > > > > > > > > > > > > > > > > --- "R. Yu" <> wrote: > > > > > > > > When working with multiple processors, each running > > > > a different executable, I found it easier to create > > > > a > > > > single executable containing code for both > > > > processors. > > > > By "easier," I mean from a > > > > development/build/maintenance > > > > standpoint. It's easy to get confused when building > > > > and loading a bunch of different executables. > > > > > > > > Load the same executable onto all the processors. > > > > Inside the main(), a switch statement determines > > > > which > > > > processor it is running on, then executes the > > > > appropriate > > > > entrypoint to the actual code. > > > > > > > > You can put a "processor ID" value in non-volatile > > > > memory. > > > > > > > > > > > > --- "Waldron, Donald M" > > > > <> wrote: > > > > > Liyju, > > > > > > > > > > What you need is a main for both .dxe's. Use the > > > > LDF file to specify which > > > > > main() function .doj's gets loaded into what > > > > processor. See Analog Device's > > > > > "Linker and Utilities Manual" especially the > > > > section "Linking for > > > > > Multiprocessor and Shared Memory". > > > > > > > > > > I have four processors, and elected to not use a > > > > shared memory image. > > > > > Instead, I used the LINK_AGAINST macro, and linked > > > > each DSP against all > > > > > others (this allws globals to be shared between > > > > processors). I've read > > > > > VisualDSP++ 3.0 provides an LDF wizard, but I was > > > > able to do everything with > > > > > VisualDSP++ 2.0. > > > > > > > > > > Keep in mind, the Simulator only supports one .dse > > > > at a time. You can load > > > > > ps1.dxe or ps2.dxe, but not both at the same time. > > > > > > > > > > Don Waldron > > > > > > > > > > > -----Original Message----- > > > > > > From: Liyju Janardhan [SMTP:] > > > > > > Sent: Saturday, May 03, 2003 8:16 AM > > > > > > To: > > > > > > Subject: RE: [adsp] ADSP 14060 -- > > > > Multiprocessing using C > > > > > > > > > > > > Thanks Don, including 060_hdr.doj to the objects > > > > in > > > > > > ldf file solved the problem. > > > > > > > > > > > > Now on buliding it create two dxe files ID1.dxe > > > > and > > > > > > ID2.dxe which get loaded to p0 and p1 processor > > > > > > respectively. > > > > > > > > > > > > But, on excuting code on simulator (cntrl F11) > > > > it only > > > > > > > > > > > > steps through ID1.c, the code in p1(ID2.c) > > > > dosen't > > > > > > run. > > > > > > > > > > > > That's because it doen't have a main function. > > > > > > > > > > > > The code is as given below: > > > > > > > > > > > > ID1.c======> > > > > > > #include<stdio.h> > > > > > > > > > > > > int arr_id1[3] = {1,2,3}; > > > > > > extern int arr_id2[3]; > > > > > > extern void man(); > > > > > > > > > > > > main() > > > > > > { > > > > > > printf("%d",arr_id2[0]); > > > > > > > > > > > > while(1); > > > > > > > > > > > > } > > > > > > > > > > > > ID2.c======> > > > > > > #include<stdio.h> > > > > > > > > > > > > int arr_id2[3] = {12,23,35}; > > > > > > extern int arr_id1[3]; > > > > > > > > > > > > void man() > > > > > > { > > > > > > printf("%d",arr_id1[0]); > > > > > > > > > > > > while(1); > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > As soon as the processors boot P0 will start > > > > executing > > > > > > > > > > > > the code because it has main function. > > > > > > How to make P1 execute its code. > > > > > > Is there any direct solution to it? > > > > > > > > > > > > The other way round is to issue an VIRPT > > > > interrupt by > > > > > > writing the address of man() to the VIRPT > > > > register of > > > > > > P1. > > > > > > So when the processor P0 write to the VIRPT > > > > > > register of P1, P1 gets an interrupt and will > > > > execute > > > > > > the void man() function. > > > > > > > > > > > > Correct me if I am wrong. > > > > > > > > > > > > But the point is how to get the address of man() > > > > > > fuction. > > > > > > Functions like interrupt(SIG_XXX,man) write the > > > > > > address of isr to the interrupt vector address. > > > > > > > > > > > > How can use this? > > > > > > > > > > > > Thanks again Bhaskar,Paul, Don for the reply. > > > > > > > > > > > > Regards > > > > > > > > > > > > Liyju > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- "Waldron, Donald M" > > > > > > <> wrote: > > > > > > > I believe you need to include 060_hdr.doj in > > > > your > > > > > > > build (via the LDF file). > > > > > > > I think the default LDF file has this. > > > > > > > > > > > > > > Don Waldron > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Liyju Janardhan > > > > [SMTP:] > > > > > > > > Sent: Friday, May 02, 2003 11:24 AM > > > > > > > > To: > > > > > > > > Subject: Re: [adsp] ADSP 14060 > > > > > > > > > > > > > > > > Thanks for the reply. > > > > > > > > > > > > > > > > Well Bhaskar I have already rename the main > > > > of one > > > > > > > > C file to some other function. That has > > > > resolved > > > > > > > the > > > > > > > > conflict. But now I the following error: > > > > > > > > > > > > > > > > [Error li2007] symbol '___lib_prog_term' > > > > > > > > referenced in file 'C:\PROGRAM FILES\ANALOG > > > > > > > > > > > > DEVICES\VISUALDSP\21K\LIB\LIBC.DLB(EXIT.DOJ)' > > > > > > > > could not be resolved > > > > > > > > > > > > > > > > How to remove this error. > > > > > > > > Paul I can use inline assembly to convert > > > > the > > > > > > > assmebly > > > > > > > > > > > > > > > > file to C, But what about the main. Will it > > > > create > > > > > > > two > > > > > > > > > > > > > > > > dxe file one for each processor. > > > > > > > > Right know it get the above error. So no dxe > > > > is > > > > > > > > created. > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Liyju > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- Bhaskar Das <> > > > > wrote: > > > > > > > > > Hey, how do u exepct 2 main enteries under > > > > 1 > > > > > > > > > project? So first u rename > > > > > > > > > either of ur main() by some other func. > > > > name > > > > > > > that > > > > > > > > > suits u. That should > > > > > > > > > resolve the conflict. > > > > > > > > > > > > > > > > > > > > > > > > > > > Bhaskar Das > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Liyju Janardhan" > > > > <> > > > > > > > > > To: <> > > > > > > > > > Sent: Friday, May 02, 2003 2:18 PM > > > > > > > > > Subject: RE: [adsp] ADSP 14060 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > I had tried some multiprocessing code > > > > written > > > > > > > in > > > > > > > > > > assmebly on adsp-14060, which works > > > > fine. > > > > > > > > > > > > > > > > > > > > Lately I have switched to C. I am > > > > encountering > > > > > > > few > > > > > > > > > > problems. > > > > > > > > > > I have two C files (ID1.c and ID2.c) and > > > > 1 asm > > > > > > > > > file > > > > > > > > > > (shared.asm). > > > > > > > > > > I have include above three file to the > > > > same > > > > > > > > > project in > > > > > > > > > > vdsp++2.0. > > > > > > > > > > > > > > > > > > > > id1.c=====> > > > > > > > > > > #include<stdio.h> > > > > > > > > > > > > > > > > > > > > extern int arr_id1[3] = {1,2,3}; > > > > > > > > > > > > > > > > > > > > main() > > > > > > > > > > { > > > > > > > > > > printf("%d",arr_id1[0]); > > > > > > > > > > > > > > > > > > > > while(1); > > > > > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > id2.c=====> > > > > > > > > > > #include<stdio.h> > > > > > > > > > > > > > > > > > > > > extern int arr_id2[3] = {1,2,3}; > > > > > > > > > > > > > > > > > > > > main() > > > > > > > > > > { > > > > > > > > > === message truncated === > > > > > > > > > > > > ===== > > > > > > > > > > > > __________________________________ > > > > > > > > > > > > _____________________________________ > > > > Note: If you do a simple "reply" with your email > > > > client, only the author of this message will receive > > > > your answer. You need to do a "reply all" if you > > > > want your answer to be distributed to the entire > > > > group. > > > > > > > > _____________________________________ > > > > About this discussion group: > > > > > > > > To Join: Send an email to > > > > > > > > > > > > To Post: Send an email to > > > > > > > > To Leave: Send an email to > > > > > > > > > > > > Archives: http://groups.yahoo.com/group/adsp > > > > > > > > Other Groups: http://www.dsprelated.com/groups.php3 > > > > > > > > > > > > ">http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > > > > > > __________________________________ > > > > > > > > > _____________________________________ > > > Note: If you do a simple "reply" with your email client, only the author > > of this message will receive your answer. You need to do a "reply all" if > > you want your answer to be distributed to the entire group. > > > > > > _____________________________________ > > > About this discussion group: > > > > > > To Join: Send an email to > > > > > > To Post: Send an email to > > > > > > To Leave: Send an email to > > > > > > Archives: http://groups.yahoo.com/group/adsp > > > > > > Other Groups: http://www.dsprelated.com/groups.php3 > > > > > > > > > ">http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > > > _____________________________________ > > Note: If you do a simple "reply" with your email client, only the author > > of this message will receive your answer. You need to do a "reply all" if > > you want your answer to be distributed to the entire group. > > > > _____________________________________ > > About this discussion group: > > > > To Join: Send an email to > > > > To Post: Send an email to > > > > To Leave: Send an email to > > > > Archives: http://groups.yahoo.com/group/adsp > > > > Other Groups: http://www.dsprelated.com/groups.php3 > > > > > > ">http://docs.yahoo.com/info/terms/ > > _____________________________________ > Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. > > _____________________________________ > About this discussion group: > > To Join: Send an email to > > To Post: Send an email to > > To Leave: Send an email to > > Archives: http://groups.yahoo.com/group/adsp > > Other Groups: http://www.dsprelated.com/groups.php3 > ">http://docs.yahoo.com/info/terms/ |
|
|
Re: ADSP 14060 -- Multiprocessing using C
Started by ●May 8, 2003
Reply by ●May 8, 20032003-05-08
|
Yes, I remember now. When trying to access data via the multi-processor memory mechanism, the docs implied that the linker could automatically add the correct processor offset to a variable. I never got this feature to work, so I just added the offset manually in my code. I agree, a good look at the multiprocessor memory map will clarify things. --- Jens Michaelsen <> wrote: > Don't know anything about LINK_AGAINST. > But the manual says for example the SHARC has > internal memory somewhere $0008000-$000DFFF or so**. > If you attach external memory to your system for example > to MS1 it can be seen at $01000000... or so**. > ** The real address depends on the chip adsp21xxx derivate. > > If tell the DSP to do "*ptr = var;" in your C-code > it depends on the pointer if this is a local or global access. > > For most DSPs (not for 065L and 161N) you can > think of the DSPs internal memory as of a great array. > dsp_ram[7][???] > dsp[0][] will on each DSP access its own memory > dsp[1][] will access DSP1 memory from all DSPs point of view. > > Please feel free to take a closer look at the > manual pages "multiprocessor memory map". > For me it helped a lot ;-) > > Jens > > ----- Original Message ----- > From: "Vanbellinghen, Paul" <> > To: "'Jens Michaelsen'" <>; <>; > <>; "Liyju Janardhan" <> > Sent: Thursday, May 08, 2003 3:09 PM > Subject: RE: [adsp] ADSP 14060 -- Multiprocessing using C > > In other words, the same global variable (name) defined for all DSPs will > be > > local to each DSP where it is defined. However, if you wish to define ONE > > variable to be shared between all DSPs, you would define it only in the > link > > of one DSP and reference it as an extern on the others. As long as you > > correctly use the LINK_AGAINST statement in the ldf file, the linker will > > know to look for the address of the variable on the DSP where it is > defined. > > > > Another point is that SHARC shared "networking" between DSPs is not like > > VxWorks where there is a master processor on the bus and the others are > > slave. Any DSP can access the global memory of any other DSP on the same > > board in the same way - although there is a priority scheme for bus > > contention issues. > > > > > From: Jens Michaelsen [SMTP:] > > > > > > Hi there, > > > > > > each Sharc has its own internal SRAM, > > > here it can execute code AND hold variables. > > > only the external global memory is shared. > > > > > > > > > Jens Michaelsen > > > > > > b.t.w. > > > "We have both Contry AND Western" > > > (Put your sunglasses on) > > > > > > ----- Original Message ----- > > > From: "Liyju Janardhan" <> > > > To: <>; <> > > > Sent: Wednesday, May 07, 2003 10:33 AM > > > Subject: RE: [adsp] ADSP 14060 -- Multiprocessing using C > > > > > > > > > > Hi all, > > > > Thanks for your replies. > > > > > > > > Running the single executable for all processor is a > > > > good solution for the multiple main() error. > > > > > > > > But what about inter-processor communication. There > > > > won't be any variable local to a particular processor. > > > > > > > > So all the variable defined will belong to the bus > > > > master. How can a salve access these variable. > > > > > > > > I didn't get what you mean by putting the processorID > > > > value in non-volatile memory. > > > > I am reading the processor id this way: > > > > > > > > int sys,pro_id; > > > > ...... > > > > sys = getIOP(SYSTAT); > > > > pro_id = getID(sys); > > > > > > > > Though the above code will be running in all the > > > > proccesors, pro_id will contain the id of the bus > > > > master, I guess. > > > > > > > > So, How can I determine that this particular code is > > > > running on processor 2, and execute a routine specific > > > > > > > > to processor 2 using switch/case.(because pro_id will > > > > contain id of bus master) > > > > > > > > If I use two different build and create two differnet > > > > dxe's, how to call a variable of one code in other > > > > code, using C. > > > > In assembly it is possible. Refer ffton2pe example > > > > in C:\Program Files\Analog > > > > Devices\VisualDSP\21k\Examples\ASM_Examples\FFTON2PE > > > > > > > > But note that all the asm files are there in same > > > > build. I can't put all the C files in same bulid > > > > because it gives multiple main() error. > > > > > > > > > > > > Please help > > > > > > > > Regards > > > > > > > > Liyju > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- "R. Yu" <> wrote: > > > > > > > > > > When working with multiple processors, each running > > > > > a different executable, I found it easier to create > > > > > a > > > > > single executable containing code for both > > > > > processors. > > > > > By "easier," I mean from a > > > > > development/build/maintenance > > > > > standpoint. It's easy to get confused when building > > > > > and loading a bunch of different executables. > > > > > > > > > > Load the same executable onto all the processors. > > > > > Inside the main(), a switch statement determines > > > > > which > > > > > processor it is running on, then executes the > > > > > appropriate > > > > > entrypoint to the actual code. > > > > > > > > > > You can put a "processor ID" value in non-volatile > > > > > memory. > > > > > > > > > > > > > > > --- "Waldron, Donald M" > > > > > <> wrote: > > > > > > Liyju, > > > > > > > > > > > > What you need is a main for both .dxe's. Use the > > > > > LDF file to specify which > > > > > > main() function .doj's gets loaded into what > > > > > processor. See Analog Device's > > > > > > "Linker and Utilities Manual" especially the > > > > > section "Linking for > > > > > > Multiprocessor and Shared Memory". > > > > > > > > > > > > I have four processors, and elected to not use a > > > > > shared memory image. > > > > > > Instead, I used the LINK_AGAINST macro, and linked > > > > > each DSP against all > > > > > > others (this allws globals to be shared between > > > > > processors). I've read > > > > > > VisualDSP++ 3.0 provides an LDF wizard, but I was > > > > > able to do everything with > > > > > > VisualDSP++ 2.0. > > > > > > > > > > > > Keep in mind, the Simulator only supports one .dse > > > > > at a time. You can load > > > > > > ps1.dxe or ps2.dxe, but not both at the same time. > > > > > > > > > > > > Don Waldron > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Liyju Janardhan [SMTP:] > > > > > > > Sent: Saturday, May 03, 2003 8:16 AM > > > > > > > To: > > > > > > > Subject: RE: [adsp] ADSP 14060 -- > > > > > Multiprocessing using C > > > > > > > > > > > > > > Thanks Don, including 060_hdr.doj to the objects > > > > > in > > > > > > > ldf file solved the problem. > > > > > > > > > > > > > > Now on buliding it create two dxe files ID1.dxe > > > > > and > > > > > > > ID2.dxe which get loaded to p0 and p1 processor > > > > > > > respectively. > > > > > > > > > > > > > > But, on excuting code on simulator (cntrl F11) > > > > > it only > > > > > > > > > > > > > > steps through ID1.c, the code in p1(ID2.c) > > > > > dosen't > > > > > > > run. > > > > > > > > > > > > > > That's because it doen't have a main function. > > > > > > > > > > > > > > The code is as given below: > > > > > > > > === message truncated === ===== __________________________________ |
