An example of a data transfer between peripheral 1 and dual port SRAM is shown here. The DMA transfer bus has been expanded in the slide to also show address bus activity. DMA channel number 5 is configured to operate with DMA-ready peripheral number 1. When data is ready to be read in the peripheral, an interrupt is issued by the peripheral, shown in orange. The architecture is such that either the CPU or the DMA controller can respond to a peripheral interrupt request. The user can therefore select any peripheral interrupt to be a DMA request, the term given to an interrupt when it is directed to the DMA. It is of course assumed that when a DMA channel is configured to respond to a particular interrupt as a DMA request, the corresponding CPU interrupt is disabled, otherwise a CPU interrupt will also be requested. The DMA request will be arbitrated with any other coincident requests, and if this channel wins, the transfer will completed during the next cycle. The DMA controller will first execute a data read from the peripheral address, which is user defined within the active channel, then write that data to the DPSRAM address which is also typically defined within the active channel. I say “typically” because there is one mode of operation where the address is partially derived from the peripheral, but that will be discussed later. The DMA channel concurrently moves the data element, and updates and checks a block transfer counter, which also acts as a dual port SRAM address offset when required. When the transfer counter reaches a user defined limit, the block transfer is considered complete and a CPU interrupt is asserted to alert the CPU to process the newly received data. During the data transfer cycle, the DMA controller also continues to arbitrate pending or subsequent DMA requests to maximize throughput.