STM32 examples for USART using DMA for efficient RX and TX transmission

Overview

STM32 UART DMA RX and TX

This application note contains explanation with examples for 2 distinct topics:

  • Data reception with UART and DMA when application does not know size of bytes to receive in advance
  • Data transmission with UART and DMA to avoid CPU stalling and use CPU for other purposes

Table of Contents

Github supports ToC by default. It is available in the top-left corner of this document.

Abbreviations

  • DMA: Direct Memory Access controller in STM32
  • UART: Universal Asynchronous Receiver Transmitter
  • USART: Universal Synchronous Asynchronous Receiver Transmitter
  • TX: Transmit
  • RX: Receive
  • HT: Half-Transfer Complete DMA event/flag
  • TC: Transfer Complete DMA event/flag
  • RTO: Receiver Timeout UART event/flag
  • IRQ: Interrupt

General about UART

STM32 has peripherals such as USART, UART or LPUART. Difference between them is not relevant for this purpose since concept can be applied to all of them. In few words, USART supports synchronous operation on top of asynchronous (UART) and LPUART supports Low-Power operation in STOP mode. When synchronous mode or low-power mode is not used, USART, UART and LPUART can be consideted identical. For complete set of details, check product's reference manual and datasheet.

For the sake of this application note, we will only use term UART.

UART in STM32 allows configurion using different transmit (TX) and receive (RX) modes:

  • Polling mode (no DMA, no IRQ)
    • P: Application is polling for status bits to check if any character has been transmitted/received and read it fast enough in order to not-miss any byte
    • P: Easy to implement, simply few code lines
    • C: Can easiy miss received data in complex application if CPU cannot read registers quickly enough
    • C: Works only for low baudrates, 9600 or lower
  • Interrupt mode (no DMA)
    • P: UART triggers interrupt and CPU jumps to service routine to handle each received byte separately
    • P: Commonly used approach in embedded applications
    • P: Works well with common baudrates, 115200, up to ~921600 bauds
    • C: Interrupt service routine is executed for every received character
    • C: May decrease system performance if interrupts are triggered for every character for high-speed baudrates
  • DMA mode
    • DMA is used to transfer data from USART RX data register to user memory on hardware level. No application interaction is needed at this point except processing received data by application once necessary
    • P: Transfer from USART peripheral to memory is done on hardware level without CPU interaction
    • P: Can work very easily with operating systems
    • P: Optimized for highest baudrates > 1Mbps and low-power applications
    • P: In case of big bursts of data, increasing data buffer size can improve functionality
    • C: Number of bytes to transfer must be known in advance by DMA hardware
    • C: If communication fails, DMA may not notify application about all bytes transferred

This article focuses only on DMA mode for RX operation and explain how to handle unknown data length

Every STM32 has at least one (1) UART IP and at least one (1) DMA controller available in its DNA. This is all we need for successful data transmission. Application uses default features to implement very efficient transmit system using DMA.

While implementation happens to be pretty straight-forward for TX (set pointer to data, define its length and go) operation, this may not be the case for receive. Implementing DMA receive, application should understand number of received bytes to process by DMA before its considered done. However, UART protocol does not offer such information (it could work with higher-level protocol, but that's way another story that we don't touch here. We assume we have to implement very reliable low-level communication protocol).

Idle Line or Receiver Timeout events

STM32s have capability in UART to detect when RX line has not been active for period of time. This is achieved using 2 methods:

  • IDLE LINE event: Triggered when RX line has been in idle state (normally high state) for 1 frame time, after last received byte. Frame time is based on baudrate. Higher baudrate means lower frame time for single byte.
  • RTO (Receiver Timeout) event: Triggered when line has been in idle state for programmable time. It is fully configured by firmware.

Both events can trigger an interrupt which is an essential feature to allow effective receive operation

Not all STM32 have IDLE LINE or RTO features available. When not available, examples concerning these features may not be used.

An example: To transmit 1 byte at 115200 bauds, it takes approximately (for easier estimation) ~100us; for 3 bytes it would be ~300us in total. IDLE line event triggers an interrupt when line has been in idle state for 1 frame time (in this case 100us), after third byte has been received.

IDLE LINE DEMO

This is a real experiment demo using STM32F4 and IDLE LINE event. After IDLE event is triggered, data are echoed back (loopback mode):

  • Application receives 3 bytes, takes approx ~300us at 115200 bauds
  • RX goes to high state (yellow rectangle) and UART RX detects it has been idle for at least 1 frame time (approx 100us)
    • Width of yellow rectangle represents 1 frame time
  • IDLE line interrupt is triggered at green arrow
  • Application echoes data back from interrupt context

General about DMA

DMA in STM32 can be configured in normal or circular mode. For each mode, DMA requires number of elements to transfer before its events (half-transfer complete, transfer complete) are triggered.

  • Normal mode: DMA starts with data transfer, once it transfers all elements, it stops and sets enable bit to 0.
    • Application is using this mode when transmitting data
  • Circular mode: DMA starts with transfer, once it transfers all elements (as written in corresponding length register), it starts from beginning of memory and transfers more
    • Applicaton is using this mode when receiving data

While transfer is active, 2 (among others) interrupts may be triggered:

  • Half-Transfer complete HT: Triggers when DMA transfers half count of elements
  • Transfer-Complete TC: Triggers when DMA transfers all elements

When DMA operates in circular mode, these interrupts are triggered periodically

Number of elements to transfer by DMA hardware must be written to relevant DMA register before start of transfer

Combine UART + DMA for data reception

Now it is time to understand which features to use to receive data with UART and DMA to offload CPU. As for the sake of this example, we use memory buffer array of 20 bytes. DMA will transfer data received from UART to this buffer.

Listed are steps to begin. Initial assumption is that UART has been initialized prior reaching this step, same for basic DMA setup, the rest:

  • Application writes 20 to relevant DMA register for data length
  • Application writes memory & peripheral addresses to relevant DMA registers
  • Application sets DMA direction to peripheral-to-memory mode
  • Application puts DMA to circular mode. This is to assure DMA does not stop transferring data after it reaches end of memory. Instead, it will roll over and continue with transferring possible more data from UART to memory
  • Application enables DMA & UART in reception mode. Receive can not start & DMA will wait UART to receive first character and transmit it to array. This is done for every received byte
  • Application is notified by DMA HT event (or interrupt) after first 10 have been transferred from UART to memory
  • Application is notified by DMA TC event (or interrupt) after 20 bytes are transferred from UART to memory
  • Application is notified by UART IDLE line (or RTO) in case of IDLE line or timeout detected on RX line
  • Application needs to reach on all of these events for most efficient receive

This configuration is important as we do not know length in advance. Application needs to assume it may be endless number of bytes received, therefore DMA must be operational endlessly.

We have used 20 bytes long array for demonstration purposes. In real app this size may need to be increased. It all depends on UART baudrate (higher speed, more data may be received in fixed window) and how fast application can process the received data (either using interrupt notification, RTOS, or polling mode)

Combine UART + DMA for data transmission

Everything gets simplier when application transmits data, length of data is known in advance and memory to transmit is ready. For the sake of this example, we use memory for Helloworld message. In C language it would be:

const char
hello_world_arr[] = "HelloWorld";
  • Application writes number of bytes to transmit to relevant DMA register, that would be strlen(hello_world_arr) or 10
  • Application writes memory & peripheral addresses to relevant DMA registers
  • Application sets DMA direction to memory-to-peripheral mode
  • Application sets DMA to normal mode. This effectively disables DMA once all the bytes are successfully transferred
  • Application enables DMA & UART in transmitter mode. Transmit starts immediately when UART requests first byte via DMA to be shifted to UART TX register
  • Application is notified by TC event (or interrupt) after all bytes have been transmitted from memory to UART via DMA
  • DMA is stopped and application may prepare next transfer immediately

Please note that TC event is triggered before last UART byte has been fully transmitted over UART. That's because TC event is part of DMA and not part of UART. It is triggered when DMA transfers all the bytes from point A to point B. That is, point A for DMA is memory, point B is UART data register. Now it is up to UART to clock out byte to GPIO pin

DMA HT/TC and UART IDLE combination details

This section describes 4 possible cases and one additional which explains why HT/TC events are necessary by application

DMA events

Abbrevations used on image:

  • R: Read pointer, used by application to read data from memory. Later also used as old_ptr
  • W: Write pointer, used by DMA to write next byte to. Increased every time DMA writes new byte. Later also used as new_ptr
  • HT: Half-Transfer Complete event triggered by DMA
  • TC: Transfer-Complete event triggered by DMA
  • I: IDLE line detection event triggered by USART

DMA configuration:

  • Circular mode
  • 20 bytes length memory
    • HT event triggers at 10 bytes
    • TC event triggers at 20 bytes

Possible cases:

  • Case A: DMA transfers 10 bytes. Application gets notification by HT event and may process received data
  • Case B: DMA transfers next 10 bytes. Application gets notification by TC event. Processing now starts from last known position until the end of memory
    • DMA is in circular mode, thus it will continue from beginning of buffer to transfer next byte
  • Case C: DMA transfers 10 bytes, but not aligned with HT nor TC events
    • Application gets notification by HT event when first 6 bytes are transfered. Processing may start from last known read location
    • Application gets IDLE event after next 4 bytes are successfully transfered
  • Case D: DMA transfers 10 bytes in overflow mode and but not aligned with HT nor TC events
    • Application gets notification by TC event when first 4 bytes are transfered. Processing may start from last known read location
    • Application gets notification by IDLE event after next 6 bytes are transfered. Processing may start from beginning of buffer
  • Case E: Example what may happen when application relies only on IDLE event
    • If application receives 30 bytes in burst, 10 bytes get overwritten by DMA as application did not process it quickly enough
    • Application gets IDLE line event once there is steady RX line for 1 byte timeframe
    • Red part of data represents first 10 received bytes from burst which were overwritten by last 10 bytes in burst
    • Option to avoid such scenario is to poll for DMA changes quicker than burst of 20 bytes take; or by using TC and HT events

Example code to read data from memory and process it, for cases A-D

/**
 * \brief           Check for new data received with DMA
 *
 * User must select context to call this function from:
 * - Only interrupts (DMA HT, DMA TC, UART IDLE) with same preemption priority level
 * - Only thread context (outside interrupts)
 *
 * If called from both context-es, exclusive access protection must be implemented
 * This mode is not advised as it usually means architecture design problems
 *
 * When IDLE interrupt is not present, application must rely only on thread context,
 * by manually calling function as quickly as possible, to make sure
 * data are read from raw buffer and processed.
 *
 * Not doing reads fast enough may cause DMA to overflow unread received bytes,
 * hence application will lost useful data.
 *
 * Solutions to this are:
 * - Improve architecture design to achieve faster reads
 * - Increase raw buffer size and allow DMA to write more data before this function is called
 */
void
usart_rx_check(void) {
    static size_t old_pos;
    size_t pos;

    /* Calculate current position in buffer and check for new data available */
    pos = ARRAY_LEN(usart_rx_dma_buffer) - LL_DMA_GetDataLength(DMA1, LL_DMA_CHANNEL_5);
    if (pos != old_pos) {                       /* Check change in received data */
        if (pos > old_pos) {                    /* Current position is over previous one */
            /*
             * Processing is done in "linear" mode.
             *
             * Application processing is fast with single data block,
             * length is simply calculated by subtracting pointers
             *
             * [   0   ]
             * [   1   ] <- old_pos |------------------------------------|
             * [   2   ]            |                                    |
             * [   3   ]            | Single block (len = pos - old_pos) |
             * [   4   ]            |                                    |
             * [   5   ]            |------------------------------------|
             * [   6   ] <- pos
             * [   7   ]
             * [ N - 1 ]
             */
            usart_process_data(&usart_rx_dma_buffer[old_pos], pos - old_pos);
        } else {
            /*
             * Processing is done in "overflow" mode..
             *
             * Application must process data twice,
             * since there are 2 linear memory blocks to handle
             *
             * [   0   ]            |---------------------------------|
             * [   1   ]            | Second block (len = pos)        |
             * [   2   ]            |---------------------------------|
             * [   3   ] <- pos
             * [   4   ] <- old_pos |---------------------------------|
             * [   5   ]            |                                 |
             * [   6   ]            | First block (len = N - old_pos) |
             * [   7   ]            |                                 |
             * [ N - 1 ]            |---------------------------------|
             */
            usart_process_data(&usart_rx_dma_buffer[old_pos], ARRAY_LEN(usart_rx_dma_buffer) - old_pos);
            if (pos > 0) {
                usart_process_data(&usart_rx_dma_buffer[0], pos);
            }
        }
        old_pos = pos;                          /* Save current position as old for next transfers */
    }
}

Examples

Examples can be used as reference code to implement your own DMA TX and RX functionality.

There are 2 sets of examples:

  • Examples for RX only
    • Available in projects folder with usart_rx_ prefix
    • DMA is used to receive data, polling is used to echo data back
  • Examples for RX & TX
    • DMA is used to receive data and to transmit data back
    • It uses ring buffer to copy data from DMA buffer to application before it is sent back

Common for all examples:

  • Developed in STM32CubeIDE for easier evaluation on STM32 boards
  • Fully developed using LL drivers for various STM32 families
  • UART common configuration: 115200 bauds, 1 stop bit, no-parity
  • DMA RX common configuration: Circular mode, TC and HT events enabled
  • DMA TX common configuration: Normal mode, TC event enabled
  • All RX examples implement loop-back functionality. Every character received by UART and transfered by DMA is sent back to same UART
STM32 family Board name USART STM32 TX STM32 RX RX DMA settings TX DMA settings
STM32F1xx BluePill-F103C8 USART1 PA9 PA10 DMA1, Channel 5
STM32F4xx NUCLEO-F413ZH USART3 PD8 PD9 DMA1, Stream 1, Channel 4 DMA1, Stream 3, Channel 4
STM32G0xx NUCLEO-G071RB USART2 PA2 PA3 DMA1, Channel 1
STM32G4xx NUCLEO-G474RE LPUART1 PA2 PA3 DMA1, Channel 1
STM32L4xx NUCLEO-L432KC USART2 PA2 PA15 DMA1, Channel 6, Request 2
STM32H7xx NUCLEO-H743ZI2* USART3 PD8 PD9 DMA1, Stream 0 DMA1, Stream 1
  • It is possible to run H743 (single-core) examples on dual-core STM32H7 Nucleo boards, NUCLEO-H745 or NUCLEO-H755. Special care needs to be taken as dual-core H7 Nucleo boards use DCDC for MCU power hence application must check clock configuration in main file and uncomment code to enable SMPS.

Examples demonstrate different use cases for RX only or RX&TX combined.

Examples for UART + DMA RX

Polling for changes

  • DMA hardware takes care to transfer received data to memory
  • Application must constantly poll for new changes in DMA registers and read received data quick enough to make sure DMA will not overwrite data in buffer
  • Processing of received data is in thread mode (not in interrupt)
  • P: Easy to implement
  • P: No interrupts, no consideration of priority and race conditions
  • P: Fits for devices without USART IDLE line detection
  • C: Application takes care of data periodically
  • C: Not possible to put application to low-power mode (sleep mode)

Polling for changes with operating system

  • Same as polling for changes but with dedicated thread in operating system to process data
  • P: Easy to implement to RTOS systems, uses single thread without additional RTOS features (no mutexes, semaphores, memory queues)
  • P: No interrupts, no consideration of priority and race conditions
  • P: Data processing always on-time with maximum delay given by thread delay, thus with known maximum latency between received character and processed time
    • Unless system has higher priority threads
  • P: Fits for devices without UART IDLE line detection
  • C: Application takes care of data periodically
  • C: Uses memory resources dedicated for separate thread for data processing
  • C: Not possible to put application to low-power mode (sleep mode)

UART IDLE line detection + DMA HT&TC interrupts

  • Application gets notification by IDLE line detection or DMA TC/HT events
  • Application has to process data only when it receives any of the 3 interrupts
  • P: Application does not need to poll for new changes
  • P: Application receives interrupts on events
  • P: Application may enter low-power modes to increase battery life (if operated on battery)
  • C: Data are read (processed) in the interrupt. We strive to execute interrupt routine as fast as possible
  • C: Long interrupt execution may break other compatibility in the application

Processing of incoming data is from 2 interrupt vectors, hence it is important that they do not preempt each-other. Set both to the same preemption priority!

USART Idle line detection + DMA HT&TC interrupts with RTOS

  • Application gets notification by IDLE line detection or DMA TC/HT events
  • Application uses separate thread to process the data only when notified in one of interrupts
  • P: Processing is not in the interrupt but in separate thread
  • P: Interrupt only informs processing thread to process (or to wakeup)
  • P: Operating system may put processing thread to blocked state while waiting for event
  • C: Memory usage for separate thread + message queue (or semaphore)

This is the most preferred way to use and process UART received character

Examples for UART DMA for TX (and optionally included RX)

  • Application is using DMA in normal mode to transfer data
  • Application is always using ringbuffer between high-level write and low-level transmit operation
  • DMA TC interrupt is triggered when transfer has finished. Application can then send more data

Demo application for debug messages

This is a demo application available in projects folder. Its purpose is to show how can application implement output of debug messages without drastically affect CPU performance. It is using DMA to transfer data (no CPU to wait for UART flags) and can achieve very high or very low data rates

  • All debug messages from application are written to intermediate ringbuffer
  • Application will try to start & configure DMA after every successfive write to ringbuffer
  • If transfer is on-going, next start is configured from DMA TC interrupt

As a result of this demo application for STM32F413-Nucleo board, observations are as following:

  • Demo code sends 1581 bytes every second at 115200 bauds, which is approx 142ms.
  • With DMA disabled, CPU load was 14%, in-line with time to transmit the data
  • With DMA enabled, CPU load was 0%
  • DMA can be enabled/disabled with USE_DMA_TX macro configuration in main.c

How to use this repository

  1. run git clone --recurse-submodules https://github.com/MaJerle/stm32-usart-dma-rx-tx to clone repository including submodules
  2. run examples from projects directory using STM32CubeIDE IDE
Issues
  • help with RX

    help with RX

    Hello,

    First off thank you for these examples. I am trying to use the usart_rx_idle_line_irq_ringbuff_G0 example. But would like some guidance on checking what is coming in from the terminal. I want to send commands from the terminal and act on them but only act on them once. I have looked in the usart_rx_dma_buffer for my commands and see them, but is this the correct way of doing this? I want to check some buffer to see if the command is there, act on it, and then clear the buffer. Any help would be appreciated.

    Thanks, Mike

    opened by mjphillips1981 5
  • USART3 Not Found on F411 Nucleo Board

    USART3 Not Found on F411 Nucleo Board

    Hi MaJerle,

    I want to study your code, but I only have F411 Nucleo board. I found your code for F4 uses UART3 with PD8,9 and Tx/Rx pins. They are not available on my board. Yet, I want to try your code. Any suggestion?

    opened by djsg 4
  • Good Idea to add a int16_t uart_get_byte(void)

    Good Idea to add a int16_t uart_get_byte(void)

    Hi,

    Many thanks for the great samples. Do you have any good idea to add a uart_get_byte? Do you think it is a good idea to add a ringbuffer and then fill this buffer in the usart_rx_check function then I can add a general usart_get_byte() as normal.

    thx mathias

    opened by mgiaco 4
  • /bin/sh: arm-none-eabi-objcopy.exe: command not found

    /bin/sh: arm-none-eabi-objcopy.exe: command not found

    arm-none-eabi-objcopy.exe -O ihex "usart_dma_rx_idle_line_irq_rtos_L4.elf" "usart_dma_rx_idle_line_irq_rtos_L4.hex" /bin/sh: arm-none-eabi-objcopy.exe: command not found make[1]: *** [makefile:80: post-build] Error 127 make: *** [makefile:48: all] Error 2 "make -j7 all" terminated with exit code 2. Build might be incomplete.

    opened by LingxiaoGao 3
  • usart_process_data() gets called with zero length

    usart_process_data() gets called with zero length

    Hello, thanks for sharing this framework. I've ported the F4 project to IAR here: https://github.com/bluehash/STM32_USART_DMA_RX

    One thing I've noticed is that usart_process_data() gets called with zero length. It is as if the IDLE line interrupt takes over when the DMA HT/FT finishes. I'm not sure if there is a way to ignore this. If I have alot of data coming in, that is a good number of interrupts that use up CPU cycle time with zero length.

    I put in a simple check here(https://github.com/bluehash/STM32_USART_DMA_RX/commit/e2a180a7f5f1310a15a7303da12f15b407ec0aca) so that I can breakpoint the code.

    I've also added a test under idle_line_irq_rtos_F4/test using TeraTerm. My environment: STM32F413ZH Nucleo Board IAR 8.30.2

    opened by bluehash 3
  • re-entrance protection?

    re-entrance protection?

    Thank you very much for your clear and very well documented code examples. I'm using it for F0.

    In your code, the interrupt handlers call usart_rx_check which in turn calls usart_process_data. There is a chance that the IDLE interrupt follows very quickly after TC or HT, regardless of the buffer length.

    This can, in theory, cause re-entrancy issues in usart_rx_check() like if the second interrupt falls between reading pos and updating last_pos.

    You clear the interrupt flags before the usart_rx_check() call. Wouldn't it be more protective against re-entrancy to clear them only after usart_rx_check() returns?

    Do you see a need for further measures like pausing the DMA etc.?

    opened by FrankBau 2
  • ESP8266 - Examples?

    ESP8266 - Examples?

    Hi,

    I was wondering if you have worked with the STM32F769 Discovery board and the dedicated connector it has for an ESP8266?

    I want to leverage the async IO pattern that you talk about here but not really sure how much of your source code is portable to the STM32F769, I'm using Visual GDB and Visual Studio for this.

    I've actually designed and developed a pretty powerful API in C# that runs on a PC and controls an ESP8266, this is fully async in nature and includes a very flexible and quite powerful RingBuffer class.

    I'd now like to rewrite this in C++ and get the board working with the ESP8266.

    I can't even find out which USART is tied to the ESP8266 connector, pretty much no documentation.

    Thanks

    opened by Korporal 2
  • Use correct path to FreeRTOS include directory

    Use correct path to FreeRTOS include directory

    On case sensitive file systems we got an error message telling us that FreeRTOS.h could not be found.

    This fixes that by changing the include path from FreeRTOS/Source/Include to FreeRTOS/Source/include.

    opened by jakeru 1
  • dma receive size will be zero

    dma receive size will be zero

    https://github.com/MaJerle/stm32-usart-uart-dma-rx-tx/blob/master/projects/usart_rx_idle_line_irq_ringbuff_G0/Src/main.c#L91

    pos = ARRAY_LEN(usart_rx_dma_buffer) - LL_DMA_GetDataLength(DMA1, LL_DMA_CHANNEL_2);
    

    pos will be zero if receive size equal ARRAY_LEN(usart_rx_dma_buffer)

    opened by tiantian1645 1
  • Error cloning the repository

    Error cloning the repository

    Not sure It is important but got the following error cloning the repo: Also you mention

    Examples for RX & TX Available in projects folder with usart_tx_ prefix DMA is used to receive data and to transmit data back It uses ring buffer to copy data from DMA buffer to application buffer first

    However there are no usart_tx_ prefix projects in the rep.

    C:\Temp>git clone --recurse-submodules https://github.com/MaJerle/stm32-usart-dma-rx-tx
    Cloning into 'stm32-usart-dma-rx-tx'...
    remote: Enumerating objects: 539, done.
    remote: Counting objects: 100% (539/539), done.
    remote: Compressing objects: 100% (363/363), done.
    remote: Total 1713 (delta 256), reused 405 (delta 160), pack-reused 1174
    Receiving objects: 100% (1713/1713), 2.93 MiB | 5.48 MiB/s, done.
    Resolving deltas: 100% (919/919), done.
    Submodule 'middlewares/ringbuff' (https://github.com/MaJerle/ringbuff) registered for path 'middlewares/ringbuff'
    Cloning into 'C:/Temp/stm32-usart-dma-rx-tx/middlewares/ringbuff'...
    remote: Enumerating objects: 362, done.
    remote: Counting objects: 100% (362/362), done.
    remote: Compressing objects: 100% (192/192), done.
    remote: Total 883 (delta 164), reused 276 (delta 91), pack-reused 521
    Receiving objects: 100% (883/883), 233.31 KiB | 1.08 MiB/s, done.
    Resolving deltas: 100% (393/393), done.
    Submodule path 'middlewares/ringbuff': checked out '247155c50a36cd09cec473368acd76527039c2ca'
    Submodule 'third_party/Embedded_Libs' (https://github.com/MaJerle/Embedded_Libs) registered for path 'middlewares/ringbuff/third_party/Embedded_Libs'
    fatal: No url found for submodule path 'middlewares/ringbuff/third_party/embedded-libs' in .gitmodules
    Failed to recurse into submodule path 'middlewares/ringbuff'
    
    C:\Temp>
    
    opened by icodk 1
  • Uninitialized variable

    Uninitialized variable

    in the following line https://github.com/MaJerle/stm32-usart-uart-dma-rx-tx/blob/master/projects/usart_rx_idle_line_irq_ringbuff_G0/Src/main.c#L92 you use a not initialized variable: static size_t old_pos; Is it a bug?

    opened by maroviher 1
  • Using CubeMX and HAL for UART DMA on H7

    Using CubeMX and HAL for UART DMA on H7

    I'm trying to do the same functionality on H750 but with using CubeMX (From within CubeIDE) and using HAL function (Mainly HAL_UARTEx_ReceiveToIdle_DMA) but it is not working for me. Is there any reason for you to use the LL over the HAL?

    opened by egoltzman 5
  • G4 flash latency too high

    G4 flash latency too high

    https://github.com/MaJerle/stm32-usart-uart-dma-rx-tx/blob/d567cb9ae0b8f01fa8cd33f7a4c4a47f462f4681/projects/usart_rx_idle_line_irq_ringbuff_tx_loopback_G4/Src/main.c#L333

    enhancement 
    opened by MaJerle 0
Owner
Tilen Majerle
Trust is a dangerous game
Tilen Majerle
A small proof-of-concept for using disk devices for DMA on Windows.

ddma A small proof-of-concept for using disk devices for DMA on Windows. Why Some native hypervisors (i.e. Hyper-V) allow the guest unvirtualized devi

null 42 Jun 7, 2022
Userspace I/O library for Xilinx AXI S2MM DMA

Userspace DMA I/O This library should simplify the use of the Xilinx AXI DMA controller when used in S2MM (Stream to Memory-Mapped) mode. A typical us

MicroTCA Technology Lab 3 Jun 8, 2022
A repo containing examples of embedded systems based on the STM32 micro-controller.

STM32 Embedded Development A repo containing examples of embedded systems based on the STM32 micro-controller. I use a Nucleo-F446RE and the STM32Cube

Vincent Ho 1 Jan 10, 2022
A tiny external monitor for PC using STM32 and ST7789. Connects to PC over USB and displays the captured screen on ST7789 (240x240) display.

STM32 Tiny Monitor A super tiny monitor for your PC, suitable for your pet ant. A python script sends the captured screen over USB to the STM32 microc

Avra Mitra 61 Jul 2, 2022
Minimal setup required to develop firmware for STM32 using ceedling

STM32 & Ceedling Base Project I created this project as a starting point for anyone looking to create production quality firmware for an embedded syst

null 6 Jun 5, 2022
In DFS-BFS Implementation In One Program Using Switch Case I am Using an Simple And Efficient Code of DFS-BFS Implementation.

DFS-BFS Implementation-In-One-Program-Using-Switch-Case-in-C Keywords : Depth First Search(DFS), Breadth First Search(BFS) In Depth First Search(DFS),

Rudra_deep 1 Nov 17, 2021
Brain-Computer Interface, ADS1299 and STM32

Brain-Computer Interface, ADS1299 and STM32

Ildaron 381 Jun 17, 2022
Set of examples how to use CLion with various unsupported compilers using Custom Defined Compiler feature

About This repository contains: Set of examples how to use CLion with various unsupported compilers using Custom Defined Compiler feature Public set o

JetBrains 30 Jun 15, 2022
STM32 firmware for a physical switch to set the GRUB boot selection

STM32 firmware for a physical switch to set the GRUB boot selection

Stephen Holdaway 307 Jun 14, 2022
A place to collaborate on code for the Embedded.fm book club. Currently reading "STM32 ARM Programming for Embedded Systems".

Welcome to the Book Club Code site! This is a place for the Embedded.fm book club to collaborate and learn together. Repo Structure Guide Top-level fo

Peter Griffin 10 Jan 13, 2022
HD44780 peripheral library for stm32 microcontrollers.

stm32-HD44780 This is a peripheral driver library for interfacing stm32 microcontrollers with the HD44780 display driver. The implementation uses the

Lorenzo Murarotto 17 Jan 20, 2022
somfy remote receiver for stm32 platform

SOMFY library for STM32 http://www.github.com/NimaLTD https://www.instagram.com/github.nimaltd/ https://www.youtube.com/channel/UCUhY7qY1klJm1d2kulr9c

Nima Askari ----- نیما عسکری 2 Mar 2, 2022
Use cmake with your stm32 project.

cmake bare metal (cbm) Overview This Repo is project using cmake to develop stm32fxx projects under the same repo. And thereby sharing commmon functio

null 6 Jun 16, 2022
ADXL345 Library for STM32-HAL

ADXL345-STM32 ADXL345 Library for STM32-HAL This library is not complete so this library may run unstable. How to use this library Change the header f

Can Guveren 2 May 26, 2022
Kalman Filter Implementation for MPU6050 with STM32-Nucleo. Via CubeIDE

Kalman Filter Implementation for MPU6050 on STM32 Nucleo Board Kalman Filter Implementation for MPU6050 with STM32-Nucleo I implemented a Kalman Filte

Ibrahim Ozdemir 16 May 13, 2022
Library for STM32 microcontrollers with HAL to communicate with absolute orientation sensor Bosh BNO055.

Bosh BNO055 sensor library fro STM32 with HAL Library for STM32 microcontrollers with HAL to communicate with absolute orientation sensor Bosh BNO055.

Eryk Możdżeń 1 Nov 20, 2021
Boilerplate to create a project with: STM32 + Ethernet + micro-ROS + FreeRTOS + Arduino + PlatformIO

micro_ros_stm32_template Boilerplate to create a project with: STM32 + Ethernet + micro-ROS + FreeRTOS + Arduino + PlatformIO Default config STM32F407

Husarion 11 May 7, 2022
STM32+LVGL ==> WATCH

HWatch STM32+LVGL ==> WATCH 网盘链接: 源码: 链接:https://pan.baidu.com/s/1h0YSe5Ja6y8xVL-h4-vCUg 提取码:8pxz 参考资料: 链接:https://pan.baidu.com/s/13PEog4OyJ0LQ3oz

null 53 Jun 27, 2022
STM32 OOP library

STM32 OOP Library The basic OOP library of STM32. Published on PlatformIO (stm32_oop_lib). Features / 功能 GPIO Only tested on STM32F103RB (NUCLEO-F103R

ZiTe 3 Nov 13, 2021