|
Topic : DMA in multiprocessor enviroment (TigerSHARC) Tools : VisualDSP++ 2.0 & ADSP-TS101S EZ-KIT lite Hi @ all, I'm trying to implement DMA transfers from internal memory of one DSP to internal memory of another. I read Analog Devices' EE-167 where there is the following example: // External Port transfer from ID0 to ID1 xr0 = tx_ID0;; // xr0=index= ID0 xr1 = 0x00100004;; // count=0x10,modify=4 xr3 = 0x47000000;; // int mem,prio=norm, xr3 = 0x47000000;; // int mem,prio=norm, //2D=no,word=quad,int=yes,RQ=enbl,chain=no DCS0 = xr3:0;; // Source yr0 = rx_ID1;; // xr0=index= ID1 yr1 = 0x00100004;; // count=0x10,modify=4 yr3 = 0x87000000;; // ext mem,prio=norm, //2D=no,word=quad,int=yes,RQ=enbl,chain=no DCD0 = yr3:0;; // Destination I think a possible C/C++ implementation is this: myTCB.DI = data_gen; myTCB.DX = 0x04 | (word_count << 16); //word count is a constant myTCB.DY = 0; myTCB.DP = TCB_INTMEM | TCB_QUAD | TCB_INT; Qword = __builtin_compose_128((long long)myTCB.DI | (long long) myTCB.DX << 32, (long long)(myTCB.DY | (long long)myTCB.DP << 32)); __builtin_sysreg_write4(DCS0, Qword); myTCB.DI = trans_buf; myTCB.DX = 0x04 | (word_count << 16); myTCB.DY = 0; myTCB.DP = TCB_EXTMEM | TCB_QUAD | TCB_INT; Qword = __builtin_compose_128((long long)myTCB.DI | (long long) myTCB.DX << 32, (long long)(myTCB.DY | (long long)myTCB.DP << 32)); __builtin_sysreg_write4(DCD0, Qword); where... - data_gen is a 256-elements array (defined/declared in DSP-A source code) int dm data_gen[256]; - trans_buf is a 256-elements array (defined/declared in DSP-B source code) int dm trans_buf[256]; The problem is to resolve "trans_buf" correctly. Linker manual states: "A LINK_AGAINST() command directs the Linker to check specific executables to resolve variables and labels that have not been resolved locally." Then I have to add LINK_AGAINST on .LDF : MPMEMORY { p0 { START(0x02000000) } p1 { START(0x02400000) } } PROCESSOR p0 { LINK_AGAINST(DIR\Xmem04_B.dxe) OUTPUT(DIR\Xmem04_A.dxe) SECTIONS (...sections omitted...) } PROCESSOR p1 { LINK_AGAINST(DIR\Xmem04_A.dxe) OUTPUT(DIR\Xmem04_B.dxe) SECTIONS (...sections omitted...) } But Linking finishes with one error: [Error li1113] The symbol '_trans_buf' referenced in file 'C:\DOCUMENTS AND SETTINGS\ALBERT\DMA_MP\XMEM TEST 004 \DEBUG\XMEM04_B.DOJ' in the project 'p1' could not be resolved Any suggestion ? Tnx in advance. |
|
|
DMA in multiprocessor enviroment
Started by ●June 26, 2003
Reply by ●June 26, 20032003-06-26
|
hi Albert, this topic was covered in this list a month or two ago, so you may want to check out the archive. I had to tackle a similar problem. I was never able to get "LINK_AGAINST" to work as advertised, so I tried something else: I combined everything into a single executable. Inside main(), a switch statement jumps to the appropriate entry point for DSP X's routines. In your case, you could combine Xmem04_A.dxe and Xmem04_B.dxe into Xmem04.dxe. When you use a single executable, the addresses of data_gen and trans_buf are identical on both DSPs, so you simply add an appropriate address offset to address the corresponding array on the other DSP. -Robert --- albert89k <> wrote: > Topic : DMA in multiprocessor enviroment (TigerSHARC) > Tools : VisualDSP++ 2.0 & ADSP-TS101S EZ-KIT lite > > Hi @ all, > I'm trying to implement DMA transfers from internal memory of one DSP > to internal memory of another. > I read Analog Devices' EE-167 where there is the following example: [snip] > > But Linking finishes with one error: > > [Error li1113] The symbol '_trans_buf' referenced in > file 'C:\DOCUMENTS AND SETTINGS\ALBERT\DMA_MP\XMEM TEST 004 > \DEBUG\XMEM04_B.DOJ' in the project 'p1' could not be resolved > > Any suggestion ? > Tnx in advance. ===== ===================================== Poison clam rocks the world!! ===================================== __________________________________ |
|
|
Reply by ●June 27, 20032003-06-27
|
Hi Robert, you're right ... there are some posts about multiprocessing and I read them before posting: making one .dxe with switches is a smart way to go around the problem. How about assigning a fixed memory address to arrays? Do you think that's another right way? But...there must be a way to use "LINK_AGAINST"...someone used it with success (see message 1766). I have to find a working example for TigerSHARC. I think upgrading from VDSP++ 2.0 to 3.0 (released a few days ago) may help me (there is a LDF wizard). Regards, Marco Albertini CNIT - Florence University --- In , "R. Yu" <snewdl@y...> wrote: > hi Albert, > > this topic was covered in this list a month > or two ago, so you may want to check out the > archive. > > I had to tackle a similar problem. I was > never able to get "LINK_AGAINST" to work as > advertised, so I tried something else: I > combined everything into a single executable. > Inside main(), a switch statement jumps to the > appropriate entry point for DSP X's routines. > In your case, you could combine Xmem04_A.dxe > and Xmem04_B.dxe into Xmem04.dxe. When you > use a single executable, the addresses of > data_gen and trans_buf are identical on both > DSPs, so you simply add an appropriate > address offset to address the corresponding array > on the other DSP. > > -Robert > > --- albert89k <albert@l...> wrote: > > Topic : DMA in multiprocessor enviroment (TigerSHARC) > > Tools : VisualDSP++ 2.0 & ADSP-TS101S EZ-KIT lite > > > > Hi @ all, > > I'm trying to implement DMA transfers from internal memory of one DSP > > to internal memory of another. > > I read Analog Devices' EE-167 where there is the following example: > [snip] > > > > > But Linking finishes with one error: > > > > [Error li1113] The symbol '_trans_buf' referenced in > > file 'C:\DOCUMENTS AND SETTINGS\ALBERT\DMA_MP\XMEM TEST 004 > > \DEBUG\XMEM04_B.DOJ' in the project 'p1' could not be resolved > > > > Any suggestion ? > > Tnx in advance. > > |
