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 === ===== __________________________________ |