How is IT different from DMA at a hardware level ?

[PRedd.5]

In DMA mode, the DMA block does copying. In normal mode the controller does the copying. So which block does copy in interrupt mode?

[waclawek.jan]

The controller.

JW

[Tesla DeLorean]

..under interrupt/callback context. Not burning cycles in polling loop, but interrupt entry/exit does have cost.

[PRedd.5]

So the bus controller is the one doing the transfers instead of DMA. If the controller can do full size transfers , why is DMA used at all ?

When would you choose DMA over controller interrupt ?

[Tesla DeLorean]

Do they just skip computer architecture completely these days?

The DMA *controller* automates the simple service of peripheral data requests. The peripheral can also be simpler, as the same USART RXNE (for example) could be gated to drive a request into a generic DMA unit, or via a different gate into the NVIC to generate an interrupt.

DMA allows for longer data transfers to occur autonomously without a lot of caretaking or busy-work on the micro-controller. For an interrupt, you have to disrupt normal operation, push context, go to a handler, figure out the specific source of the request, service it, and unwind. This could easily take several dozen processor cycles.

Think of DMA being a minion or servant, doing simple transactional work that the processor and application can be freed from doing.

[PRedd.5]

"Do they just skip computer architecture completely these days ?" : Uncalled for.

The computer architecture they taught 12 years ago is far behind modern DMA and bus controller implementations. These DMA's are far more capable than what my course ever covered. In addition, the UART itself has gone from simple register buffer clocked out to full blown controllers. This is where the issue comes from.

It becomes much clearer once you look up the implementation of :

HAL_StatusTypeDef HAL_UART_Transmit_DMA(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)

HAL_StatusTypeDef HAL_UART_Transmit_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)

both of them can do arbitrary size transfers.

Reading the TRM. RM0316 : page 885 Sec 29.2 :

"Received/transmitted bytes are buffered in reserved SRAM using centralized DMA"

They are basically the same operation using different channels and modes of DMA. If all you care is to perform UART input/output without the processing unit getting involved, either mode (IT or DMA) will do fine.

As you said, The use of DMA peripheral mode is to allow peripheral to peripheral transfer and peripheral triggered data transfer without invoking the processing unit. However, with that said, the processing unit still has to service the corresponding DMA interrupts for the said transfers.

[PRedd.5 · Accepted solution]

It becomes much clearer once you look up the implementation of :

HAL_StatusTypeDef HAL_UART_Transmit_DMA(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)

HAL_StatusTypeDef HAL_UART_Transmit_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)

both of them can do arbitrary size transfers.

Reading the TRM. RM0316 : page 885 Sec 29.2 :

"Received/transmitted bytes are buffered in reserved SRAM using centralized DMA"

They are basically the same operation using different channels and modes of DMA. If all you care is to perform UART input/output without the processing unit getting involved, either mode (IT or DMA) will do fine.

The use of DMA peripheral mode is to allow peripheral to peripheral transfer and peripheral triggered data transfer without invoking the processing unit.

[Piranha]

> They are basically the same operation using different channels and modes of DMA. If all you care is to perform UART input/output without the processing unit getting involved, either mode (IT or DMA) will do fine.

No, you are wrong. Polling and interrupt modes are both done by CPU. This is the line where in interrupt mode CPU reads a byte from Tx buffer and writes it to peripherals Tx register:

https://github.com/STMicroelectronics/STM32CubeF3/blob/e684e8712c42ad70d801adf73ba3b509ed04a7ff/Drivers/STM32F3xx_HAL_Driver/Src/stm32f3xx_hal_uart.c#L2678

> The computer architecture they taught 12 years ago is far behind modern DMA and bus controller implementations.

The original IBM PC in year 1981 had Intel 8237 DMA controller working on the same principles...