]]>
]]>
]]>
1. Normal SOURCE-DESTINATION DMA copy, where the DMA engine at the TRANSMITTER is active, and,
2. DMA-SLAVE mode, in which the DMA engine on the RECEIVER core is active (the source itself can be, but does not have to be a DMA process. Can be simple memcpy() as well).
In the former case, multiple source cores can DMA data on the destination core. They can write on different destination addresses, or on the same target buffer - where the ultimate data written on a memory location is the last to arrive. If so programmed, then when each of the source DMAs finish, it will generate the MSGMODE interrupt on the destination core. It is your responsibility to orchestrate this mess.
In the latter case, all sources write their data to a single destination address - the destination core's AUTO0DMA register. In this case, every incoming transaction advances the destination pointer to the next location in the memory, according to the DMASTRIDE parameter. Thus, in this case, the order of the incoming transaction is unpredicted and so will be the final buffer - interleaved in an unpredictable manner.
Statistics: Posted by ysapir — Wed Jul 31, 2013 4:28 pm
]]>
What *does* happen when there are several other cores attempting to act as DMA masters of the same slave? (someone else posted that the data sent by them would be interleaved in an unpredictable manner...)
Thanks
Mark
Statistics: Posted by mhonman — Wed Jul 31, 2013 4:07 pm
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
Have the destination buffer structured with a flag positioned at the very end. As DMA transfers are sequential across blocks of transferred data then this flag will be the last location to be written to. Assuming ( potential ) source cores are aware of this structure then :
(A) The target core sets the flag state to 'ready for data', as and when it pleases.
(B) Source cores can initiate DMA writes of data to the buffer by first checking the flag's value for 'ready for data' state.
(C) The flag is then set by the source core to a 'data being transferred' state.
(D) Must use TESTSET to achieve B and C here, atomically accessing and maybe changing in case there is a race with another source core also wanting to write to the destination buffer. This implies the 'ready for data' state of the flag must be of value binary zero.
(E) You need a 'data being transferred' state on your flag as (a) the target core ought know it's request is being fulfilled, but that the contents aren't yet valid, and (b) any other potential source cores must be excluded from writes to the buffer, else you may get overwrites during transfer ( one source core chasing the tail of another through the buffer, mutual overwrites etc depending on core locations and eMesh state and timings .. UGH ).
(F) The final address in the source buffer contains the flag value 'transfer complete', this is hence written to the flag's location in the destination buffer as the final act in the DMA transfer. Which is the desired behaviour !
(G) The target core checks the flag for 'transfer complete' state - busy waiting, non-blocking, whatever you like - before using the data in the buffer.
Rinse, lather, repeat .....
Cheers, Mike.
( edit ) You want DMA writes at source, with the status of that sampled locally on the target, as this fully leverages the asymmetry of the eMesh .....
Statistics: Posted by hewsmike — Tue Jul 30, 2013 10:58 pm
]]>