For desktop applications, optimization usually means “make the program run faster.” In embedded systems, optimization has a wider meaning. You may care about speed, flash usage, RAM usage, interrupt latency, power consumption, boot time, or debugging reliability. Choosing the wrong optimization level can result in larger firmware, increased difficulty in debugging, or even expose bugs that were previously hidden at lower optimization levels.

This tutorial explains what each optimization level does, when to use it, and what embedded developers should be aware of.

What Is Compiler Optimization?

Compiler optimization is the process of transforming your source code into more efficient machine code without changing the intended behavior of the program.

For example, this code:

int x = 5 * 10;

may be compiled as if it were written like this:

int x = 50;

The compiler can also remove unused code, simplify loops, inline small functions, reduce memory accesses, and store variables in CPU registers instead of RAM.

In embedded systems, these optimizations can make a big difference. A small 8-bit AVR, an ARM Cortex-M0, or an ESP32 has limited flash, limited RAM, and real-time timing requirements. The compiler’s optimization level affects all of these.

Common Optimization Levels

-O0 : No Optimization

-O0 means optimization is disabled. This is usually the default when no optimization flag is provided.

Example:

arm-none-eabi-gcc main.c -O0 -g -o firmware.elf

This level is commonly used during early debugging because the generated code closely follows the source code.

Advantages:

Disadvantages:

For embedded development, -O0 is useful while bringing up hardware, checking peripheral initialization, or stepping through code line by line. However, you should not assume that firmware tested only at -O0 will behave the same way at release optimization levels.

-O1: Basic Optimization

-O1 enables a basic set of optimizations. It improves code quality without being too aggressive.

Example:

arm-none-eabi-gcc main.c -O1 -g -o firmware.elf

At this level, the compiler may remove unused code, simplify expressions, reduce redundant memory loads, and make better use of CPU registers.

For embedded use, -O1 is a good first step when you want better performance than -O0 but still want debugging to remain somewhat manageable.

Use -O1 when:

- You want light optimization
- You are debugging a timing-sensitive issue
- `-O0` is too slow or too large
- You are not yet ready to use full release optimization

However, many embedded projects skip -O1 and use either -Og for debugging or -O2 / -Os for release builds.

-O2: Common Release Optimization

-O2 is one of the most common optimization levels for production firmware.

Example:

arm-none-eabi-gcc main.c -O2 -o firmware.elf

This level enables many optimizations that improve speed without usually causing a huge increase in code size.

In embedded systems, -O2 is often a good default for release builds when performance matters.

Typical effects of -O2 include:

- Faster loops
- Better register allocation
- Dead code elimination
- Common subexpression elimination
- Function inlining where reasonable
- Improved instruction scheduling

For microcontrollers like STM32, SAMD, ESP32, RP2040, and many ARM Cortex-M devices, -O2 often gives a good balance between speed and size.

Use -O2 when:

- You are building release firmware
- Execution speed matters
- Your flash size is not extremely tight
- You want a stable general-purpose optimization level

One important warning: debugging optimized code can be confusing. Variables may appear as “optimized out,” breakpoints may not behave exactly as expected, and the compiler may rearrange instructions.

-O3: Aggressive Speed Optimization

-O3 enables more aggressive optimizations than -O2.

Example:

arm-none-eabi-gcc main.c -O3 -o firmware.elf

It may perform more aggressive inlining, loop transformations, and other speed-focused optimizations.

However, -O3 is not always better for embedded firmware.

Why?

Because embedded systems often have limited flash, limited cache, and strict timing requirements. Aggressive inlining can make the firmware larger. Larger code may reduce instruction cache efficiency or exceed flash limits. In some cases, -O3 can make firmware slower than -O2.

Use -O3 only when:

- You have measured a real performance problem
- You have benchmarked `-O3` against `-O2`
- Your flash size is still acceptable
- You have tested timing-sensitive code carefully

Do not assume that -O3 is automatically the best release setting. In embedded work, measurement matters more than the optimization number.

-Os: Optimize for Size

-Os tells the compiler to optimize for smaller code size.

Example:

arm-none-eabi-gcc main.c -Os -o firmware.elf

This is very useful in embedded systems because flash memory is often limited.

For example, if your firmware is close to the flash limit of an ATmega328P, STM32F030, PIC32, or other small microcontroller, -Os may help the firmware fit.

Use -Os when:

- Flash memory is limited
- You are building for small MCUs
- Code size matters more than maximum speed
- You are near the firmware size limit

For many embedded projects, -Os is a better release choice than -O2, especially for small devices.

Common examples:

AVR/Arduino Uno: often use -Os
Small ARM Cortex-M0/M0+: often use -Os
Bootloaders: often use -Os
Tiny sensor nodes: often use -Os

However, smaller code is not always slower. In some MCUs, smaller code can perform well because it fits better in flash or cache.

-Og: Optimize for Debugging

-Og is designed to improve debugging while still enabling some optimizations.

Example:

arm-none-eabi-gcc main.c -Og -g -o firmware.elf

For embedded development, -Og is often better than -O0 once your project becomes more complex.

It keeps debugging usable while allowing the compiler to perform optimizations that do not heavily interfere with the debugging experience.

Use -Og when:

- You are actively debugging firmware
- You want better code than -O0
- You still need meaningful breakpoints and variable inspection
- You want your debug build to behave closer to release builds

A good embedded workflow is:

Debug build:   -Og -g
Release build: -O2 or -Os

Recommended Optimization Levels for Embedded Projects

A practical setup looks like this:

Development / debugging:
-Og -g

Early hardware bring-up:
-O0 -g

Normal release build:
-O2

Flash-limited release build:
-Os

Performance-critical release build:
-O3 only after benchmarking

For example, an STM32 project might use:

CFLAGS_DEBUG = -Og -g3
CFLAGS_RELEASE = -O2

An AVR project might use:

CFLAGS_DEBUG = -Og -g3
CFLAGS_RELEASE = -Os

A bootloader might use:

CFLAGS_RELEASE = -Os

Why Code Works at -O0 but Fails at -O2

This is one of the most common embedded firmware problems.

A developer writes code, tests it at -O0, and everything works. Then they enable -O2 or -Os, and the firmware stops working.

It is tempting to blame the compiler, but the real cause is usually a bug in the code. Optimization often exposes bugs that were already present.

Common causes include:

The Importance of volatile

In embedded C, volatile tells the compiler that a variable can change outside the normal program flow.

This is important for:

Consider this example:

int button_pressed = 0;

void EXTI0_IRQHandler(void)
{
    button_pressed = 1;
}

int main(void)
{
    while (button_pressed == 0)
    {
        // wait
    }

    // continue when button is pressed
}

At higher optimization levels, the compiler may assume that

button_pressed

while

The correct version is:

volatile int button_pressed = 0;

void EXTI0_IRQHandler(void)
{
    button_pressed = 1;
}

int main(void)
{
    while (button_pressed == 0)
    {
        // wait
    }

    // continue when button is pressed
}

Now the compiler knows it must reload button_pressed from memory each time.

Use volatile for variables that can change due to interrupts or hardware.

Do not use volatile as a general fix for all optimization problems. It is not a replacement for proper locking, atomic access, or good program design.

Hardware Registers and Optimization

Peripheral registers must usually be accessed through volatile-qualified pointers or structs.

Example:

#define GPIOA_ODR (*(volatile uint32_t *)0x48000014)

void led_on(void)
{
    GPIOA_ODR |= (1 << 5);
}

Without volatile, the compiler might remove or combine register accesses in ways that are valid for normal memory but incorrect for hardware registers.

Most vendor libraries already handle this correctly. For example, STM32 HAL, CMSIS, AVR headers, and ESP-IDF register definitions normally mark hardware registers as volatile.

Delay Loops Can Break Under Optimization

This is bad embedded code:

void delay(void)
{
    for (int i = 0; i < 100000; i++)
    {
    }
}

At higher optimization levels, the compiler may remove the loop because it does nothing.

A slightly better version is:

void delay(void)
{
    for (volatile int i = 0; i < 100000; i++)
    {
    }
}

But the best solution is to use a hardware timer, SysTick, RTOS delay, or vendor-provided delay function.

Better examples:

HAL_Delay(100);

or:

vTaskDelay(pdMS_TO_TICKS(100));

or a timer-based delay function.

In embedded firmware, timing should not rely on empty loops unless you fully understand the compiler, CPU clock, and generated assembly.

Code Size: -O2 vs -Os

In embedded work, smaller code is often better.

A typical comparison might look like this:

-O0:  42 KB
-O1:  31 KB
-O2:  28 KB
-Os:  24 KB
-O3:  36 KB

This is not universal, but it shows a common pattern.

-O0 is often large because the compiler does not simplify much.

-O2 often reduces size while improving speed.

-Os usually gives the smallest output.

-O3 may increase size because of aggressive inlining and loop optimizations.

Always check your firmware size after changing optimization levels.

For GCC-based embedded builds, you may see output like:

text    data     bss     dec     hex
24576   128      2048    26752   6880

Where:

text = code and constants in flash
data = initialized variables copied to RAM
bss  = zero-initialized variables in RAM

Useful Size Optimization Flags

For embedded firmware, -Os is commonly combined with section garbage collection.

Compiler flags:

-ffunction-sections -fdata-sections

Linker flag:

-Wl,--gc-sections

Example:

arm-none-eabi-gcc main.c \
  -Os \
  -ffunction-sections \
  -fdata-sections \
  -Wl,--gc-sections \
  -o firmware.elf

These options allow the linker to remove unused functions and data from the final firmware image.

This is especially useful when using large libraries where only a small part of the library is actually needed.

Optimization and Interrupts

Optimization can affect interrupt-related code if shared variables are not handled correctly.

Example:

uint8_t rx_ready = 0;

void USART_IRQHandler(void)
{
    rx_ready = 1;
}

int main(void)
{
    while (!rx_ready)
    {
    }

    process_data();
}

This should be:

volatile uint8_t rx_ready = 0;

void USART_IRQHandler(void)
{
    rx_ready = 1;
}

int main(void)
{
    while (!rx_ready)
    {
    }

    process_data();
}

For multi-byte variables shared with interrupts,

volatile

Example:

volatile uint32_t tick_count;

On an 8-bit MCU, reading a 32-bit value may require multiple instructions. An interrupt could update the value halfway through the read.

In that case, you may need to temporarily disable interrupts or use an atomic access method.

Example:

uint32_t get_tick_count(void)
{
    uint32_t value;

    __disable_irq();
    value = tick_count;
    __enable_irq();

    return value;
}

The exact method depends on your platform.

Optimization and Debugging

When optimization is enabled, debugging can become confusing.

You may see:

- Variables shown as <optimized out>
- Breakpoints skipped
- Source lines executed out of order
- Functions inlined and not visible in the call stack
- Loops transformed into different assembly

This does not necessarily mean the debugger is broken. It means the compiler changed the code structure while preserving the intended behavior.

For debugging, prefer:

-Og -g3

Instead of:

-O2 -g

You can still debug -O2 builds, but the experience is harder.

Per-Function Optimization

Sometimes you may want most of the firmware optimized normally, but one function optimized differently.

With GCC, you can use function attributes.

Example:

__attribute__((optimize("O0")))
void debug_sensitive_function(void)
{
    // Easier to debug
}

Or:

__attribute__((optimize("O3")))
void performance_critical_function(void)
{
    // Speed-critical code
}

Use this carefully. Per-function optimization can be useful, but it can also make the build harder to understand and maintain.

Practical Embedded Build Recommendations

For most embedded firmware projects, use separate debug and release configurations.

Debug Build

-Og -g3

Good for:

- Stepping through code
- Inspecting variables
- Debugging peripheral setup
- Testing logic

Release Build for Speed

-O2

Good for:

- General production firmware
- Motor control
- Communication stacks
- Real-time applications
- DSP-like code, if size is acceptable

Release Build for Size

-Os

Good for:

- Small microcontrollers
- Bootloaders
- Arduino/AVR projects
- Battery-powered sensor nodes
- Firmware near the flash limit

Aggressive Performance Build

-O3

Use only after testing and benchmarking.

Example Makefile Setup

MCU = cortex-m4

CC = arm-none-eabi-gcc

COMMON_FLAGS = \
    -mcpu=$(MCU) \
    -mthumb \
    -Wall \
    -Wextra \
    -ffunction-sections \
    -fdata-sections

DEBUG_FLAGS = -Og -g3
RELEASE_FLAGS = -O2

LDFLAGS = -Wl,--gc-sections

debug:
	$(CC) $(COMMON_FLAGS) $(DEBUG_FLAGS) main.c $(LDFLAGS) -o firmware_debug.elf

release:
	$(CC) $(COMMON_FLAGS) $(RELEASE_FLAGS) main.c $(LDFLAGS) -o firmware_release.elf

size:
	arm-none-eabi-size firmware_release.elf

For a size-focused release build, change:

RELEASE_FLAGS = -O2

to:

RELEASE_FLAGS = -Os

How to Choose the Right Optimization Level

A good decision flow is:

Are you debugging?
Use -Og -g3.

Are you doing early board bring-up?
Use -O0 -g or -Og -g3.

Are you building production firmware?
Use -O2.

Are you running out of flash?
Use -Os.

Are you chasing maximum speed?
Try -O3, but compare it against -O2.

Did the code break when optimization was enabled?
Look for missing volatile, undefined behavior, race conditions, timing assumptions, or stack problems.

Final Thoughts

Compiler optimization is not just a performance setting. In embedded systems, it affects code size, timing, debugging, interrupt behavior, and hardware access.

For most projects, a good default is:

Debug:   -Og -g3
Release: -O2 or -Os

Use -O2 when performance matters. When flash size matters, use -Os. Finally, use -O3 only after measuring. Avoid relying on -O0 behavior for final firmware.

Most importantly, when optimized firmware behaves differently from unoptimized firmware, do not immediately blame the compiler. In embedded C and C++, optimization often reveals hidden bugs such as missing volatile, unsafe interrupt sharing, undefined behavior, or timing assumptions.

A reliable embedded project should be tested using the same optimization level that will be used in production.

The post Understanding -O1, -O2, -O3, -Os, and -Og in Embedded Firmware appeared first on Microcontroller Tutorials.

One common source of confusion is the size of struct variables in C. Beginners often expect the size of a structure to be equal to the sum of the sizes of its members. But in many cases, sizeof(struct) returns a larger value than expected.

The reason is padding.

Structure padding is added by the compiler to make memory access faster and properly aligned for the target processor. In embedded systems, this can affect RAM usage, communication protocols, EEPROM layouts, flash storage, and hardware register mapping.

What Is a Structure in C?

A structure, or struct, is a user-defined data type that groups related variables together.

For example:

typedef struct {
    uint8_t id;
    uint16_t value;
    uint8_t status;
} SensorData;

At first glance, you might expect this structure to use:

uint8_t id;       // 1 byte
uint16_t value;  // 2 bytes
uint8_t status;  // 1 byte

Total:

1 + 2 + 1 = 4 bytes

But depending on the compiler and target architecture, this structure may actually occupy 6 bytes instead of 4.

Why? Because the compiler may insert unused bytes between members. These unused bytes are called padding bytes.

What Is Padding?

Padding is extra space inserted by the compiler between structure members or at the end of a structure.

The purpose of padding is to align data members to memory addresses that are efficient, or sometimes required, for the CPU to access.

For example, many 32-bit microcontrollers prefer 16-bit values to be placed at addresses divisible by 2, and 32-bit values to be placed at addresses divisible by 4.

Consider this structure:

typedef struct {
    uint8_t a;
    uint32_t b;
} Example;

You might expect:

a = 1 byte
b = 4 bytes
Total = 5 bytes

But the compiler may arrange it like this:

Offset 0: a
Offset 1: padding
Offset 2: padding
Offset 3: padding
Offset 4: b byte 0
Offset 5: b byte 1
Offset 6: b byte 2
Offset 7: b byte 3

So the actual size becomes:

8 bytes

The compiler inserted 3 padding bytes so that b starts at offset 4, which is properly aligned for a 32-bit value.

Why Alignment Matters in Embedded Systems

Memory alignment affects how efficiently a processor can read and write data.

On some processors, unaligned access is allowed but slower. On others, unaligned access can cause a fault or exception.

For example, reading a uint32_t from an address divisible by 4 is usually efficient. But reading the same value from an odd address may require multiple memory accesses, or may not be allowed at all.

This is especially important in embedded systems because firmware often interacts directly with:

• Peripheral registers
• Communication buffers
• EEPROM or flash memory
• DMA buffers
• Packed protocol frames
• Bootloaders
• Memory-mapped hardware

A structure that looks correct in C may not have the exact memory layout you expect unless you account for padding.

Example: Padding Changes Structure Size

Consider this structure:

#include <stdint.h>
#include <stdio.h>

typedef struct {
    uint8_t  id;
    uint32_t count;
    uint16_t voltage;
} DeviceData;

Expected size:

id      = 1 byte
count   = 4 bytes
voltage = 2 bytes
Total   = 7 bytes

But the actual layout may look like this:

Offset 0: id
Offset 1: padding
Offset 2: padding
Offset 3: padding
Offset 4: count
Offset 8: voltage
Offset 10: padding
Offset 11: padding

Actual size:

12 bytes

That is 5 extra bytes of padding.

On a desktop computer, this may not matter much. But on a microcontroller with only 2 KB of SRAM, wasting several bytes per structure can become a real problem, especially if you create large arrays.

For example:

DeviceData devices[100];

If each structure is 12 bytes instead of 7 bytes, the array uses:

12 × 100 = 1200 bytes

instead of:

7 × 100 = 700 bytes

That is 500 extra bytes of RAM.

Member Order Affects Padding

One simple way to reduce padding is to arrange structure members from largest to smallest.

Instead of this:

typedef struct {
    uint8_t  id;
    uint32_t count;
    uint16_t voltage;
} DeviceData;

Use this:

typedef struct {
    uint32_t count;
    uint16_t voltage;
    uint8_t  id;
} DeviceDataOptimized;

The new layout may be:

Offset 0: count   // 4 bytes
Offset 4: voltage // 2 bytes
Offset 6: id      // 1 byte
Offset 7: padding // 1 byte

Actual size:

8 bytes

By simply reordering the members, the structure size is reduced from 12 bytes to 8 bytes.

That may not seem like much for one variable, but it matters when the structure is used in arrays, queues, buffers, logs, and communication packets.

Checking Structure Size with

sizeof()

The

sizeof()

Example:

printf("Size of DeviceData: %u\n", sizeof(DeviceData));
printf("Size of DeviceDataOptimized: %u\n", sizeof(DeviceDataOptimized));

On embedded systems, you may not always have printf() available. In that case, you can inspect the size in the debugger, use a compile-time assertion, or view the map file generated by the compiler.

Example using a compile-time check:

_Static_assert(sizeof(DeviceDataOptimized) == 8, "Unexpected struct size");

This is useful when the structure size must not change, such as when it is used for a communication packet or saved data format.

Padding at the End of a Structure

Padding can also be added at the end of a structure.

For example:

typedef struct {
    uint32_t timestamp;
    uint8_t status;
} LogEntry;

The members use:

timestamp = 4 bytes
status    = 1 byte
Total     = 5 bytes

But the structure may still be 8 bytes because the compiler pads the end of the structure to maintain alignment when used in arrays.

Why?

Because in this array:

LogEntry logs[10];

each timestamp in each array element should still be aligned properly.

Without end padding, the second structure might start at an address that causes its timestamp member to become misaligned.

Packed Structures

Sometimes, you need the structure layout to match an exact byte format. This is common in communication protocols, file formats, EEPROM layouts, and binary packet parsing.

In GCC, you can use the packed attribute:

typedef struct __attribute__((packed)) {
    uint8_t  id;
    uint32_t count;
    uint16_t voltage;
} PackedDeviceData;

This tells the compiler not to insert padding bytes.

The structure size becomes:

1 + 4 + 2 = 7 bytes

For ARM compilers or other toolchains, the syntax may be different. Some compilers use pragmas such as:

#pragma pack(push, 1)

typedef struct {
    uint8_t  id;
    uint32_t count;
    uint16_t voltage;
} PackedDeviceData;

#pragma pack(pop)

However, packed structures should be used carefully.

The Danger of Packed Structures

Packed structures save memory, but they can also create problems.

When a structure is packed, members may be placed at unaligned addresses. Accessing those members directly can be slower or unsafe on some microcontrollers.

For example:

typedef struct __attribute__((packed)) {
    uint8_t header;
    uint32_t value;
} Packet;

In this structure, value may start at offset 1. That means it is not aligned to a 4-byte boundary.

On some processors, this access may be inefficient. On others, it may cause a hard fault.

A safer approach is to copy the unaligned data into an aligned variable before using it:

uint32_t value;
memcpy(&value, &packet.value, sizeof(value));

This may look unnecessary, but it avoids unaligned memory access problems and is often safer for portable embedded code.

Structures and Communication Protocols

Padding becomes very important when sending structures over UART, SPI, I2C, CAN, BLE, or Ethernet.

For example:

typedef struct {
    uint8_t command;
    uint16_t length;
    uint32_t checksum;
} Message;

If you send this directly:

uart_write((uint8_t *)&msg, sizeof(msg));

you may accidentally send padding bytes too.

The receiver may expect a compact packet, but the transmitted data may contain extra bytes inserted by the compiler. This can break communication between devices, especially if the other side is written in a different language, uses a different compiler, or runs on a different architecture.

For protocol data, it is often better to serialize the packet manually:

buffer[0] = command;
buffer[1] = length & 0xFF;
buffer[2] = (length >> 8) & 0xFF;
buffer[3] = checksum & 0xFF;
buffer[4] = (checksum >> 8) & 0xFF;
buffer[5] = (checksum >> 16) & 0xFF;
buffer[6] = (checksum >> 24) & 0xFF;

Manual serialization gives you full control over byte order, padding, and packet format.

Structures and EEPROM or Flash Storage

Another common mistake is saving a structure directly to EEPROM or flash:

eeprom_write((uint8_t *)&settings, sizeof(settings));

This works only if you are certain the structure layout will never change.

Problems can happen when:

• The compiler changes
• Optimization settings change
• The target architecture changes
• Members are reordered
• New fields are added
• Packing settings change
• Padding bytes contain random values

If the structure is used for persistent storage, consider adding:

typedef struct {
    uint32_t magic;
    uint16_t version;
    uint16_t size;
    uint8_t data[32];
    uint32_t crc;
} SettingsBlock;

A version number, size field, and CRC make the stored data easier to validate and migrate when the firmware changes.

Structures and Hardware Registers

In embedded systems, structures are often used to represent hardware registers.

Example:

typedef struct {
    volatile uint32_t CR;
    volatile uint32_t SR;
    volatile uint32_t DR;
} UART_TypeDef;

This works because the structure is designed to match the exact register layout described in the microcontroller datasheet.

However, hardware register structures must be written very carefully. If a register is reserved, the structure must include a reserved field to preserve the correct offset.

Example:

typedef struct {
    volatile uint32_t CR;
    volatile uint32_t SR;
    uint32_t RESERVED0;
    volatile uint32_t DR;
} UART_TypeDef;

Without the reserved field, DR would appear at the wrong offset, and the firmware would access the wrong register.

This is why vendor header files usually contain many RESERVED fields in peripheral structure definitions.

How to Inspect Member Offsets

The offsetof() macro from <stddef.h> can be used to check where each member is placed inside a structure.

Example:

#include <stddef.h>

printf("id offset: %u\n", offsetof(DeviceData, id));
printf("count offset: %u\n", offsetof(DeviceData, count));
printf("voltage offset: %u\n", offsetof(DeviceData, voltage));

This helps you confirm whether the compiler inserted padding between members.

For embedded debugging, this is useful when checking protocol structures, register maps, or memory layouts.

Best Practices for Embedded Systems

When using structures in embedded firmware, keep these guidelines in mind.

• First, do not assume that the size of a structure is equal to the sum of its members. Always check with sizeof().
• Second, arrange members from largest to smallest when RAM usage matters. This can reduce padding without needing compiler-specific packing attributes.
• Third, avoid sending raw structures directly over communication interfaces unless the layout is explicitly controlled.
• Fourth, be careful with packed structures. They are useful for matching exact byte layouts, but they can cause unaligned memory access.
• Fifth, use fixed-width integer types such as uint8_t, uint16_t, and uint32_t instead of plain int, short, or long when the binary layout matters.
• Sixth, use offsetof() and  _Static_assert() to verify structure sizes and member positions.
• Seventh, for EEPROM, flash, or protocol data, consider manual serialization instead of writing the raw structure directly.
• Finally, always check the compiler documentation for packing, alignment, and ABI behavior, especially when moving code between compilers or microcontroller families.

On classic AVR-based Arduino boards, structure padding is usually less noticeable because the CPU is 8-bit and has fewer strict alignment requirements. However, the habit of checking sizeof(), using fixed-width integer types, and avoiding raw struct transfers is still important—especially if the code may later run on ESP32, STM32, SAMD, RP2040, or other 32-bit boards.

Conclusion

Structure padding is one of those C language details that becomes very important in embedded systems. It affects RAM usage, binary compatibility, communication packets, EEPROM layouts, flash storage, DMA buffers, and hardware register definitions.

Padding is not a compiler bug. It is a normal part of how C structures are arranged in memory to satisfy alignment requirements.

For ordinary application-level data, padding is usually harmless. But for embedded systems, where memory layout often matters, you need to be aware of it.

The key rule is simple:

Do not guess the size or layout of a structure. Check it.

Use sizeof(), offsetof(), _Static_assert(), and careful member ordering. Use packed structures only when necessary, and be careful when accessing unaligned members.

Understanding structure padding will help you write embedded firmware that is smaller, safer, more portable, and easier to debug.

The post Structures and Padding in Embedded Systems: Why sizeof() Is Bigger Than You Expect appeared first on Microcontroller Tutorials.

This tutorial will cover:

1. What is a Linker File?
2. Understanding the STM32 Memory Layout
3. Structure of a Linker Script (.ld file)
4. Common Sections in an STM32 Linker Script
5. Modifying a Linker Script
6. Practical Example: Customizing RAM and Flash
7. Debugging and Troubleshooting Linker Errors

1. What is a Linker File?

A linker file (.ld file) is a script used by the GNU linker (ld) to define the memory regions of a microcontroller and specify where different parts of the program should be placed in memory.

In STM32 projects, the linker file tells the compiler where to place:

• The startup code
• The main application code
• Global/static variables
• Heap and stack memory

2. Understanding the STM32 Memory Layout

STM32 microcontrollers typically have two main types of memory:

• Flash Memory (Non-volatile)
  Stores the program (code and constants). Flash is usually located at 0x08000000.

• RAM (Volatile)
  Stores variables, stack, and heap. RAM is typically located at 0x20000000.

Example memory layout for an STM32F103C8T6 (64 KB Flash, 20 KB RAM):

3. Structure of a Linker Script (.ld file)

A typical STM32 linker script is divided into sections:

1. Header and Memory Definition

Defines the memory regions (Flash, RAM) available in the microcontroller.

MEMORY 
{ 
    FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K 
    RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K 
}

• rx : Flash is readable (r) and executable (x).
• rwx: RAM is readable, writable, and executable (rwx).

2. Entry Point Definition

Defines where execution starts.

ENTRY(Reset_Handler)

The Reset_Handler is defined in startup_stm32.s and is the first function executed after a reset.

3. Sections Definition

Organizes program sections into memory.

SECTIONS
{
   /* Code and Read-Only Data in Flash */
   .text :
   {
      KEEP(*(.isr_vector)) /* Interrupt Vector Table */
      *(.text*) /* Code */
      *(.rodata*) /* Read-only data */
      . = ALIGN(4);
   } > FLASH

   /* Initialized Data in RAM */
   .data :
   {
      *(.data*) /* Initialized global/static variables */
      . = ALIGN(4);
   } > RAM AT> FLASH

   /* Uninitialized Data in RAM */
   .bss :
   {
      *(.bss*) /* Uninitialized global/static variables */
      . = ALIGN(4);
   } > RAM

   /* Stack and Heap */
   _estack = ORIGIN(RAM) + LENGTH(RAM);
   _Min_Heap_Size = 0x100; /* Minimum heap size */
   _Min_Stack_Size = 0x400; /* Minimum stack size */
}

4. Common Sections in an STM32 Linker Script

Here’s a breakdown of important sections:

5. Modifying a Linker Script

1. Increasing the Stack Size

To change the stack size, modify _Min_Stack_Size:

_Min_Stack_Size = 0x800; /* Increase stack size to 2 KB */

2. Placing a Variable at a Specific Address

If you need a variable at a fixed RAM location:

__attribute__((section(".my_section"))) int my_var = 42;

Then add this section to the linker script:

.my_section : { *(.my_section) } > RAM

3. Allocating a Bootloader Region

If using a bootloader (e.g., 16 KB at the beginning of Flash), adjust Flash origin:

MEMORY
{
   FLASH (rx) : ORIGIN = 0x08004000, LENGTH = 48K /* Bootloader takes first 16 KB */
   RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
}

6. Practical Example: Customizing RAM and Flash

Suppose we want to:

• Allocate a special section for a DMA buffer
• Reserve memory for a bootloader

1. Define a Special Section for DMA Buffer

In main.c:

__attribute__((section(".dma_buffer"))) uint8_t dmaBuffer[1024];

In STM32F103_FLASH.ld:

.dma_buffer (NOLOAD) : 
{ 
   *(.dma_buffer) 
} > RAM

(NOLOAD prevents initialization in .data or .bss.)

2. Modify Flash for Bootloader

Modify memory layout:

MEMORY 
{ 
   FLASH (rx) : ORIGIN = 0x08004000, LENGTH = 48K 
   RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K 
}

7. Debugging and Troubleshooting Linker Errors

1. Common Errors

2. Check Memory Usage

Use arm-none-eabi-size:

arm-none-eabi-size -B firmware.elf

Example output:

text data bss dec hex filename 13500 800 3000 17300 439c firmware.elf

• text → Code size
• data → Initialized data in RAM
• bss → Uninitialized variables

Conclusion

Linker scripts are a critical part of STM32 firmware development, defining how memory is allocated and structured. By understanding and modifying linker files, you can:

• Optimize memory usage
• Relocate sections
• Implement bootloaders and special memory mappings

Mastering linker scripts helps ensure efficient and reliable embedded software development for STM32 microcontrollers.

The post What are Linker Files in STM32? appeared first on Microcontroller Tutorials.

Overview of ADC in STM32F407

The STM32F407 microcontroller comes with a 12-bit resolution ADC that can handle up to 16 multiplexed input channels. This makes it ideal for applications requiring the processing of multiple analog signals, such as reading from sensor arrays. The ADC supports single-shot and continuous conversion modes, with the ability to automatically scan through multiple channels in sequence. Conversion can be triggered either through software commands or external hardware signals, providing flexibility in its integration into various systems. The DMA module can be used in conjunction with the ADC to transfer conversion data directly to memory, which minimizes CPU load and allows real-time data collection for high-performance applications.

ADC Scan Mode with DMA

In scan mode, the ADC sequentially converts multiple channels, each identified by a specific rank. This ensures that channels are processed in the required order, which is especially important when dealing with structured or time-sensitive data. When used with DMA, the ADC can transfer the results of these conversions directly into a memory buffer without involving the CPU. This combination of ADC and DMA significantly enhances efficiency and reduces processing overhead, as the CPU is free to handle other tasks during data transfer.

Configuring ADC with DMA

To set up ADC in scan mode with DMA, you need to configure various peripherals and settings. First, enable the necessary clocks for the ADC and GPIO peripherals. For instance, enabling the clock for ADC1 and GPIOA can be achieved using the appropriate RCC commands. Next, configure the GPIO pins that will serve as analog inputs. For example, setting PA0 as an analog input involves configuring its mode to GPIO_Mode_AN and disabling any pull-up or pull-down resistors.

The ADC itself must be initialized with the desired resolution, scan mode, and conversion mode settings. You can enable scan mode by setting ADC_ScanConvMode to ENABLE, which allows the ADC to automatically move through the sequence of channels. The number of conversions in the sequence is set using ADC_NbrOfConversion, while each channel's rank in the sequence is configured using the ADC_RegularChannelConfig function. This ensures that the channels are converted in the required order, with each channel assigned a unique rank.

Of course, all of these can be easily done using STM32CubeMX. An example configuration is shown in the following section.

DMA configuration involves defining the memory buffer where the ADC data will be stored, specifying the size of the buffer, and setting the transfer mode. The base address of the ADC data register and the memory buffer address is linked in the DMA configuration, and the DMA mode is set to either normal or circular, depending on the application's needs. Finally, both the ADC and DMA modules must be enabled, and the ADC conversion process must be started using a software command or an external trigger.

Operational Modes of the ADC

The STM32F407 ADC can operate in continuous or non-continuous conversion modes. In continuous conversion mode, the ADC repeatedly converts data from the selected channels without any additional input or trigger, making it suitable for real-time data acquisition tasks. This mode is enabled by setting the ADC_ContinuousConvMode flag to ENABLE. On the other hand, the non-continuous conversion mode completes a single cycle of conversions and then stops, requiring a new trigger to restart. This mode is useful for applications that need periodic sampling or where power efficiency is critical.

DMA Modes

The DMA module operates in either normal or circular mode. In normal mode, data transfer stops once the specified number of conversions has been completed. This mode is best suited for applications where data is required only once or at periodic intervals. In contrast, circular mode continuously transfers data, looping back to the start of the memory buffer once it reaches the end. This mode is ideal for applications that require real-time monitoring or continuous data streams, as it eliminates the need for manual intervention to restart the transfer.

ADC Channel Ranking

Channel ranking is a crucial aspect of ADC configuration in scan mode. Each channel is assigned a rank that determines its position in the conversion sequence. For example, a channel with rank 1 will be converted first, followed by channels with higher ranks. This ensures that data is processed in a predictable order, which is important in multi-sensor systems where timing or channel order matters. The ranking is configured using the ADC_RegularChannelConfig function, which specifies the channel number, rank, and sample time for each channel.

STM32CubeMX Configuration

Here I am using ADC1 of the STM32F407 and its inputs Channel 0 to Channel 3. The ADC resolution is set to 12 bits, scan conversion mode enabled (to use multiple channels) and the End of Conversion Flag will be set at the end of a single channel conversion. For the multiscan to work, the number of conversions must be set to the number of channels used, in my case, 4 channels. Then I set the ranking of each channel according to the order I want the data to be stored. This means the first data will be coming from channel 0, the second data from channel 1, and so on.

Next, I add DMA to ADC1 where the mode is Normal and the increment address is set to memory. The data width is set to half-word only since our ADC resolution is just 12 bits. Remember that a whole word in STM32 is 32 bits.

My STM32F407 development board only has an 8 MHz external crystal but I want to maximize its performance. Here is my clock configuration:

Full Example Code

The following code is generated once you click "GENERATE CODE" in STM32CubeMX. I have removed the comments for brevity.

 #include "main.h"

ADC_HandleTypeDef hadc1;
DMA_HandleTypeDef hdma_adc1;

void SystemClock_Config(void);
static void MX_GPIO_Init(void);
static void MX_DMA_Init(void);
static void MX_ADC1_Init(void);

int main(void)
{

  HAL_Init();

  SystemClock_Config();

  MX_GPIO_Init();
  MX_DMA_Init();
  MX_ADC1_Init();
  while (1)
  {
  }
}

void SystemClock_Config(void)
{
  RCC_OscInitTypeDef RCC_OscInitStruct = {0};
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

  __HAL_RCC_PWR_CLK_ENABLE();
  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
  RCC_OscInitStruct.PLL.PLLM = 8;
  RCC_OscInitStruct.PLL.PLLN = 160;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
  RCC_OscInitStruct.PLL.PLLQ = 4;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }

  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5) != HAL_OK)
  {
    Error_Handler();
  }
}

static void MX_ADC1_Init(void)
{

  ADC_ChannelConfTypeDef sConfig = {0};

  hadc1.Instance = ADC1;
  hadc1.Init.ClockPrescaler = ADC_CLOCK_SYNC_PCLK_DIV4;
  hadc1.Init.Resolution = ADC_RESOLUTION_12B;
  hadc1.Init.ScanConvMode = ENABLE;
  hadc1.Init.ContinuousConvMode = DISABLE;
  hadc1.Init.DiscontinuousConvMode = DISABLE;
  hadc1.Init.ExternalTrigConvEdge = ADC_EXTERNALTRIGCONVEDGE_NONE;
  hadc1.Init.ExternalTrigConv = ADC_SOFTWARE_START;
  hadc1.Init.DataAlign = ADC_DATAALIGN_RIGHT;
  hadc1.Init.NbrOfConversion = 4;
  hadc1.Init.DMAContinuousRequests = DISABLE;
  hadc1.Init.EOCSelection = ADC_EOC_SINGLE_CONV;
  if (HAL_ADC_Init(&hadc1) != HAL_OK)
  {
    Error_Handler();
  }

  sConfig.Channel = ADC_CHANNEL_0;
  sConfig.Rank = 1;
  sConfig.SamplingTime = ADC_SAMPLETIME_3CYCLES;
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)
  {
    Error_Handler();
  }

  sConfig.Channel = ADC_CHANNEL_1;
  sConfig.Rank = 2;
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)
  {
    Error_Handler();
  }

  sConfig.Channel = ADC_CHANNEL_2;
  sConfig.Rank = 3;
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)
  {
    Error_Handler();
  }

  sConfig.Channel = ADC_CHANNEL_3;
  sConfig.Rank = 4;
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)
  {
    Error_Handler();
  }

}

static void MX_DMA_Init(void)
{

  __HAL_RCC_DMA2_CLK_ENABLE();

  HAL_NVIC_SetPriority(DMA2_Stream0_IRQn, 0, 0);
  HAL_NVIC_EnableIRQ(DMA2_Stream0_IRQn);

}

static void MX_GPIO_Init(void)
{
  __HAL_RCC_GPIOC_CLK_ENABLE();
  __HAL_RCC_GPIOH_CLK_ENABLE();
  __HAL_RCC_GPIOA_CLK_ENABLE();
}

void Error_Handler(void)
{
  __disable_irq();
  while (1)
  {
  }
}

void assert_failed(uint8_t *file, uint32_t line)
{
}

We will need to add to this! First, we initiate ADC reading with DMA support using:

HAL_ADC_Start_DMA(&hadc1, (uint32_t*)adcBuffer, BUFFER_SIZE)

Where adcBuffer is where the ADC results are stored and the BUFFER_SIZE is the number of ADC channels used.

#define BUFFER_SIZE 4
uint16_t adcBuffer[BUFFER_SIZE];

In our example, we disabled continuous mode so the conversion stops when HAL_ADC_Start_DMA is called and done. If you need always to do the conversion, there are two options: to put HAL_ADC_Start_DMA inside the loop or to enable continuous conversion mode.

hadc1.Init.ContinuousConvMode = ENABLE;

Next, we add a callback function that triggers every time the conversion is done.

void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc1)
{
// This function is automatically called when DMA completes a transfer

}

You can add to this function whatever you want done when the conversion completes.

So our full example code is now:

#include "main.h"

#define BUFFER_SIZE 4 
uint16_t adcBuffer[BUFFER_SIZE];

ADC_HandleTypeDef hadc1;
DMA_HandleTypeDef hdma_adc1;

void SystemClock_Config(void);
static void MX_GPIO_Init(void);
static void MX_DMA_Init(void);
static void MX_ADC1_Init(void);

int main(void)
{

  HAL_Init();

  SystemClock_Config();

  MX_GPIO_Init();
  MX_DMA_Init();
  MX_ADC1_Init();
  while (1)
  {
     HAL_ADC_Start_DMA(&hadc1, (uint32_t*)adcBuffer, BUFFER_SIZE)
  }
}

void SystemClock_Config(void)
{
  RCC_OscInitTypeDef RCC_OscInitStruct = {0};
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

  __HAL_RCC_PWR_CLK_ENABLE();
  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
  RCC_OscInitStruct.PLL.PLLM = 8;
  RCC_OscInitStruct.PLL.PLLN = 160;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
  RCC_OscInitStruct.PLL.PLLQ = 4;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }

  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5) != HAL_OK)
  {
    Error_Handler();
  }
}

static void MX_ADC1_Init(void)
{

  ADC_ChannelConfTypeDef sConfig = {0};

  hadc1.Instance = ADC1;
  hadc1.Init.ClockPrescaler = ADC_CLOCK_SYNC_PCLK_DIV4;
  hadc1.Init.Resolution = ADC_RESOLUTION_12B;
  hadc1.Init.ScanConvMode = ENABLE;
  hadc1.Init.ContinuousConvMode = DISABLE;
  hadc1.Init.DiscontinuousConvMode = DISABLE;
  hadc1.Init.ExternalTrigConvEdge = ADC_EXTERNALTRIGCONVEDGE_NONE;
  hadc1.Init.ExternalTrigConv = ADC_SOFTWARE_START;
  hadc1.Init.DataAlign = ADC_DATAALIGN_RIGHT;
  hadc1.Init.NbrOfConversion = 4;
  hadc1.Init.DMAContinuousRequests = DISABLE;
  hadc1.Init.EOCSelection = ADC_EOC_SINGLE_CONV;
  if (HAL_ADC_Init(&hadc1) != HAL_OK)
  {
    Error_Handler();
  }

  sConfig.Channel = ADC_CHANNEL_0;
  sConfig.Rank = 1;
  sConfig.SamplingTime = ADC_SAMPLETIME_3CYCLES;
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)
  {
    Error_Handler();
  }

  sConfig.Channel = ADC_CHANNEL_1;
  sConfig.Rank = 2;
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)
  {
    Error_Handler();
  }

  sConfig.Channel = ADC_CHANNEL_2;
  sConfig.Rank = 3;
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)
  {
    Error_Handler();
  }

  sConfig.Channel = ADC_CHANNEL_3;
  sConfig.Rank = 4;
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)
  {
    Error_Handler();
  }

}

static void MX_DMA_Init(void)
{

  __HAL_RCC_DMA2_CLK_ENABLE();

  HAL_NVIC_SetPriority(DMA2_Stream0_IRQn, 0, 0);
  HAL_NVIC_EnableIRQ(DMA2_Stream0_IRQn);

}

static void MX_GPIO_Init(void)
{
  __HAL_RCC_GPIOC_CLK_ENABLE();
  __HAL_RCC_GPIOH_CLK_ENABLE();
  __HAL_RCC_GPIOA_CLK_ENABLE();
}

void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc1) 
{ 
   // This function is automatically called when DMA completes a transfer 
}

void Error_Handler(void)
{
  __disable_irq();
  while (1)
  {
  }
}

void assert_failed(uint8_t *file, uint32_t line)
{
}

Summary

This tutorial outlined how to configure the STM32F407 ADC in scan mode with DMA for efficient data acquisition from multiple channels. We explored the roles of continuous and non-continuous conversion modes, discussed the benefits of normal versus circular DMA, and demonstrated how to rank ADC channels in the conversion sequence. This setup is highly effective for applications requiring real-time data processing and minimizes CPU overhead, making it ideal for embedded systems.

The post Using ADC Scan Mode with DMA in STM32F407 appeared first on Microcontroller Tutorials.

Requirements

1. STM32 microcontroller (e.g., STM32F4 Discovery, STM32F0 Nucleo board, etc.)
2. STM32CubeMX (for code generation)
3. STM32CubeIDE (or any compatible IDE like Keil, IAR, etc.)
4. LED (or the onboard LED, if your board has one)
5. Resistor (if using an external LED)
6. USB cable (for powering and programming the board)

Steps

1. Create a New STM32CubeMX Project

1. Open STM32CubeMX and click on New Project.
2. Select your microcontroller or board from the available list (e.g., STM32F407VG for STM32F4 Discovery).
3. Click Start Project.

2. Configure the PWM Output Pin

To use PWM, we need to configure one of the general-purpose timers (TIM) and assign a pin for the PWM signal output.

1. Enable the timer:
   • In the Pinout & Configuration tab, locate the Timers section.
   • Enable one of the timers capable of PWM (e.g., TIM3 or TIM2). Click the dropdown arrow and select PWM Generation CH1 (or any available channel).
2. Assign a pin for PWM:
   • Once you select a PWM channel, CubeMX will automatically assign a GPIO pin as the PWM output. For instance, if you select TIM3 CH1, it might assign PA6 as the output pin. You can confirm the pin in the Pinout view.
   • Ensure the pin is configured as PWM output.

3. Configure the Timer for PWM

Now we need to configure the timer's frequency and duty cycle.

1. Go to the Configuration tab:
   • In the Peripherals tree (on the left), expand Timers and select TIM3 (or your selected timer).
2. Set PWM frequency:

Set the Prescaler and Counter Period to achieve your desired PWM frequency. The PWM frequency is calculated using the formula:

PWM frequency = Timer clock / [(Prescaler + 1) * (Period + 1)]

• For example, if the timer clock is 84 MHz, and you want a PWM frequency of 1 kHz, you can set the prescaler to 83 and the period to 999.

1. Set the Duty Cycle:
   • The duty cycle determines the LED brightness. A duty cycle of 0% (0 in the Compare value register) will turn the LED off, and a duty cycle of 100% (equal to the period value) will turn the LED fully on. You can dynamically adjust this in your code later.
2. Enable the Timer:
   • In the same configuration window, ensure the timer is set to PWM mode and the Output Compare is enabled for the selected channel (e.g., CH1).

4. Configure the Clock

Ensure the clock configuration is correctly set. Typically, STM32CubeMX will auto-configure the clock based on the default settings, but verify that the APB1/2 timers are enabled and running at the correct frequency for your chosen timer.

5. Generate Code

1. Click on Project Manager and give your project a name.
2. Choose your preferred toolchain (e.g., STM32CubeIDE).
3. Click Generate Code.

6. Writing the Code in STM32CubeIDE

Once you generate the project, open it in STM32CubeIDE (or your chosen IDE). STM32CubeMX has already generated the initialization code, so we'll focus on adding the logic to adjust the PWM duty cycle.

1. Open the main.c file.
2. The timer and GPIO initialization should already be done in the MX_TIM3_Init() function.
3. Inside the main() function, start the PWM signal generation by adding:

HAL_TIM_PWM_Start(&htim3, TIM_CHANNEL_1);

This function starts the PWM generation on TIM3 channel 1 (which is linked to PA6 or the pin you configured).

Now, let's create a simple loop to gradually increase and decrease the LED brightness using the PWM duty cycle:

while (1)
{

    // Gradually increase brightness
    for (int duty = 0; duty < __HAL_TIM_GET_AUTORELOAD(&htim3); duty++)
    {
        __HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_1, duty); // Set the duty cycle
        HAL_Delay(10); // Small delay to see the fade effect
    }

    // Gradually decrease brightness
    for (int duty = __HAL_TIM_GET_AUTORELOAD(&htim3); duty > 0; duty--)
    {
        __HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_1, duty); // Set the duty cycle
        HAL_Delay(10); // Small delay to see the fade effect
    }
}

7. Build and Flash the Code

1. Build the project by clicking the build button (hammer icon).
2. Flash the code to your STM32 board by clicking the debug/run button (bug or play icon).

8. Testing

If everything is set up correctly, your LED should start fading in and out as the PWM duty cycle changes from 0% to 100% and back. The LED's brightness will gradually increase and then decrease, creating a fading effect.

Summary

In this tutorial, we created a project using STM32CubeMX to generate the code for PWM control. We configured a timer to generate PWM signals, wrote code to adjust the duty cycle dynamically, and successfully created a fading effect for an LED.

Key Concepts:

• PWM: Used to control the brightness of an LED by adjusting the duty cycle.
• STM32CubeMX: Simplifies peripheral configuration and code generation.
• Timers: Essential for PWM generation in STM32.

You can modify the frequency, adjust the fade speed, or control multiple LEDs using the same process.

The post Fading an LED using STM32's PWM appeared first on Microcontroller Tutorials.

What is LwIP Raw Mode?

In raw mode, LwIP uses low-level functions without an RTOS. This is perfect for small devices where you need full control of network data and don't want the overhead of an RTOS.

What You Need:

• STM32F407 microcontroller (e.g., STM32F407 Discovery board)
• STM32CubeIDE or another IDE that supports STM32
• LwIP library (this comes with the STM32Cube HAL)

Step-by-Step Setup

Step 1: Install STM32CubeIDE

Download and install STM32CubeIDE. This is an integrated development environment for STM32 microcontrollers. You will use this tool to set up your project and code for LwIP.

Step 2: Create a New Project

1. Open STM32CubeIDE.
2. Click File > New > STM32 Project.
3. Select your STM32F407 microcontroller (e.g., STM32F407VGTx) and click Next.
4. Name your project and click Finish.

Step 3: Enable Ethernet and LwIP

1. Open STM32CubeMX (inside CubeIDE) to configure your STM32.
2. Go to the Pinout & Configuration tab and enable Ethernet by clicking on the pin that supports Ethernet (PA1, PA2, PA7, etc.).
3. Under the Middleware section, enable LwIP.
4. Choose RAW API in the LwIP settings. This sets LwIP to raw mode.
5. Configure the IP settings (you can use a static IP like 192.168.0.10).
6. Click Generate Code.

Step 4: Add Ethernet Driver

The STM32F407 has a built-in Ethernet MAC (Media Access Controller). You will need an external PHY (physical layer) chip to connect to an Ethernet network, like the LAN8720.

Make sure the ETH HAL driver is enabled in STM32CubeMX. It will automatically handle Ethernet communication for you.

Step 5: Write LwIP Code

Next, we write the code that will use LwIP to send and receive data.

Initialize LwIP:

In your main main.c file, include the LwIP header:

#include "lwip.h"

In the main() function, call the LwIP initialization function:

MX_LWIP_Init();

Create a New TCP Server:

Use the raw API to create a TCP server that listens for connections. Example:struct tcp_pcb *pcb = tcp_new();

tcp_bind(pcb, IP_ADDR_ANY, 80); // Bind to port 80
pcb = tcp_listen(pcb);
tcp_accept(pcb, my_accept);

Define the my_accept function, which handles new connections.

Handle Incoming Data:

Inside the accept function, you will handle incoming data from clients. Example:

err_t my_recv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err) {
    if (p != NULL) {
        // Process data
        tcp_recved(pcb, p->tot_len);
        pbuf_free(p);
    } else {
        tcp_close(pcb);
    }
    return ERR_OK;
}

Step 6: Compile and Flash

1. Build your project by clicking the Build button.
2. Flash the program to your STM32F407 board using the Debug button.

Step 7: Test the Setup

Connect your STM32F407 to your network. Open a web browser and enter the IP address you assigned earlier (e.g., 192.168.0.10). If everything is set up correctly, your STM32 should now be responding to network requests.

Here’s an example of a simple main.c file that shows how to initialize LwIP and set up a basic TCP server using the raw API on the STM32F407. This code creates a server that listens for incoming connections on port 80 and responds to any data it receives.

#include "main.h"
#include "lwip.h"
#include "tcp.h"

/* Function prototypes */
err_t my_accept(void *arg, struct tcp_pcb *newpcb, err_t err);
err_t my_recv(void *arg, struct tcp_pcb *tpcb, struct pbuf *p, err_t err);

int main(void) {
    /* Initialize the hardware (clocks, peripherals, etc.) */
    HAL_Init();
    SystemClock_Config();  // Configure system clock
    MX_GPIO_Init();        // Initialize GPIO
    MX_LWIP_Init();        // Initialize LwIP stack

    /* Create a new TCP control block */
    struct tcp_pcb *pcb = tcp_new();
    if (pcb == NULL) {
        /* Handle error if TCP PCB creation failed */
        while (1);
    }

    /* Bind the PCB to port 80 (HTTP) */
    err_t bind_err = tcp_bind(pcb, IP_ADDR_ANY, 80);  // Bind to any IP address, port 80
    if (bind_err != ERR_OK) {
        /* Handle error if bind failed */
        tcp_close(pcb);
        while (1);
    }

    /* Put the PCB into the listening state */
    pcb = tcp_listen(pcb);
    if (pcb == NULL) {
        /* Handle error if listen failed */
        while (1);
    }

    /* Set the accept callback function */
    tcp_accept(pcb, my_accept);

    /* Infinite loop */
    while (1) {
        /* Handle LwIP tasks */
        MX_LWIP_Process();
    }
}

/* Accept callback function - called when a new connection is established */
err_t my_accept(void *arg, struct tcp_pcb *newpcb, err_t err) {
    /* Set the receive callback function for the new connection */
    tcp_recv(newpcb, my_recv);
    return ERR_OK;
}

/* Receive callback function - called when data is received */
err_t my_recv(void *arg, struct tcp_pcb *tpcb, struct pbuf *p, err_t err) {
    if (p != NULL) {
        /* Process the received data */
        char *data = (char *)p->payload;
        data[p->len] = '\0';  // Null-terminate the data
        printf("Received data: %s\n", data);  // Print received data

        /* Send a response back to the client */
        const char *response = "HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\nHello, World!";
        tcp_write(tpcb, response, strlen(response), TCP_WRITE_FLAG_COPY);

        /* Acknowledge that we've received the data */
        tcp_recved(tpcb, p->tot_len);

        /* Free the pbuf */
        pbuf_free(p);
    } else {
        /* If p is NULL, the connection was closed */
        tcp_close(tpcb);
    }

    return ERR_OK;
}
 

Troubleshooting

• No response from STM32?
  • Check the Ethernet cable and PHY chip connection.
  • Make sure the IP address is set correctly.
  • Ensure LwIP is initialized properly in the code.
• Data loss?
  • If data is not being received or sent properly, adjust the buffer sizes in LwIP settings. You can increase the size of the receive and send buffers in STM32CubeMX.

Conclusion

Setting up LwIP raw on an STM32F407 is straightforward when following these steps. By configuring Ethernet in STM32CubeMX and writing raw TCP code, you can create efficient, low-level network applications.

The post How to Set Up LwIP Raw on STM32F407 appeared first on Microcontroller Tutorials.

The STM32F4 DAC provides one or more channels that can be used to convert digital values into analog voltages of 12-bit resolution. With proper configuration, the DAC can generate precise and smooth analog waveforms.

Setting up the DAC

Enabling the DAC of the STM32F4 is easy by using STM32CubeMX.

1. Select STM32F407VET6 as the microcontroller
2. On Pinout & Configuration, select Analog > DAC then check the OUT1 Configuration checkbox.
3. In the Parameter Settings box, set the ff:
   1. Output Buffer: Enable
   2. Trigger: Timer 2 Trigger Out event
   3. Wave generation mode: Triangle wave generation
   4. Maximum Triangle Amplitude: 15
4. In Pinout View, click the PA4 pin and select DAC_OUT1

5. We also add two inputs for adjusting the frequency speed. These pins are mapped to the on-board buttons on the STM32F407 development board.

5. We also need to use the DMA controller to transfer the waveform data from memory to the DAC register for continuous output.

6. Finally, we setup the TIMER2 timer as this acts as trigger for our waveform generation.

After this, name your project and then click the "Generate Code" button on the top right. Now let's do some coding!

Generating Waveforms with MATLAB

MATLAB is a powerful tool for numerical computation and signal processing. We can leverage MATLAB's capabilities to generate waveform data and then transfer it to the STM32F4 microcontroller for DAC output. Here's a step-by-step guide:

Step 1: Generate Waveform Data in MATLAB:

In MATLAB, use built-in functions or mathematical equations to generate the waveform data for the desired waveform types (sine, triangular, or sawtooth). For instance, you can use the sin(T), sawtooth(T), or sawtooth(T, 0.5) functions to create the respective waveforms. Specify the desired duration, sample points, and DAC resolution for the waveforms.

Here's the MATLAB script for generating a sine wave:

clear; clc; % Clear The Previous Points
Ns = 128; % Set The Number of Sample Points 
RES = 12; % Set The DAC Resolution 
OFFSET = 0; % Set An Offset Value For The DAC Output 
%------------[ Calculate The Sample Points ]------------- 

T = 0:((2*pi/(Ns-1))):(2*pi); 
Y = sin(T);
Y = Y + 1;
Y = Y*((2^RES-1)-2*OFFSET)/(2+OFFSET);
Y = round(Y);
plot(T, Y);
grid
%--------------[ Print The Sample Points ]---------------

fprintf('%d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, \n', Y);

For the other waveforms, we only need to change the function. For Sawtooth:

clear; clc; % Clear The Previous Points
Ns = 128; % Set The Number of Sample Points
RES = 12; % Set The DAC Resolution
OFFSET = 0; % Set An Offset Value For The DAC Output
%------------[ Calculate The Sample Points ]-------------

T = 0:((2*pi/(Ns-1))):(2*pi);
Y = sawtooth(T);
Y = Y + 1; 
Y = Y*((2^RES-1)-2*OFFSET)/(2+OFFSET);
Y = round(Y); 
plot(T, Y);
grid
%--------------[ Print The Sample Points ]---------------

fprintf('%d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, \n', Y);

For Triangular:

clear; clc; % Clear The Previous Points
Ns = 128; % Set The Number of Sample Points
RES = 12; % Set The DAC Resolution
OFFSET = 0; % Set An Offset Value For The DAC Output
%------------[ Calculate The Sample Points ]-------------

T = 0:((2*pi/(Ns-1))):(2*pi);
Y = sawtooth(T);
Y = Y + 1; 
Y = Y*((2^RES-1)-2*OFFSET)/(2+OFFSET);
Y = round(Y); 
plot(T, Y);
grid
%--------------[ Print The Sample Points ]---------------

fprintf('%d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, \n', Y);

Step 2: Export Waveform Data from MATLAB

The MATLAB scripts above will generate the data needed to create a lookup table for the STM32 code.

For Sine:

2048, 2149, 2250, 2350, 2450, 2549, 2646, 2742, 2837, 2929, 3020, 3108, 3193, 3275, 3355, 
3431, 3504, 3574, 3639, 3701, 3759, 3812, 3861, 3906, 3946, 3982, 4013, 4039, 4060, 4076, 
4087, 4094, 4095, 4091, 4082, 4069, 4050, 4026, 3998, 3965, 3927, 3884, 3837, 3786, 3730, 
3671, 3607, 3539, 3468, 3394, 3316, 3235, 3151, 3064, 2975, 2883, 2790, 2695, 2598, 2500, 
2400, 2300, 2199, 2098, 1997, 1896, 1795, 1695, 1595, 1497, 1400, 1305, 1212, 1120, 1031, 
944, 860, 779, 701, 627, 556, 488, 424, 365, 309, 258, 211, 168, 130, 97, 
69, 45, 26, 13, 4, 0, 1, 8, 19, 35, 56, 82, 113, 149, 189, 
234, 283, 336, 394, 456, 521, 591, 664, 740, 820, 902, 987, 1075, 1166, 1258, 
1353, 1449, 1546, 1645, 1745, 1845, 1946, 2047

For Sawtooth:

0, 32, 64, 97, 129, 161, 193, 226, 258, 290, 322, 355, 387, 419, 451, 
484, 516, 548, 580, 613, 645, 677, 709, 742, 774, 806, 838, 871, 903, 935, 
967, 1000, 1032, 1064, 1096, 1129, 1161, 1193, 1225, 1258, 1290, 1322, 1354, 1386, 1419, 
1451, 1483, 1515, 1548, 1580, 1612, 1644, 1677, 1709, 1741, 1773, 1806, 1838, 1870, 1902, 
1935, 1967, 1999, 2031, 2064, 2096, 2128, 2160, 2193, 2225, 2257, 2289, 2322, 2354, 2386, 
2418, 2451, 2483, 2515, 2547, 2580, 2612, 2644, 2676, 2709, 2741, 2773, 2805, 2837, 2870, 
2902, 2934, 2966, 2999, 3031, 3063, 3095, 3128, 3160, 3192, 3224, 3257, 3289, 3321, 3353, 
3386, 3418, 3450, 3482, 3515, 3547, 3579, 3611, 3644, 3676, 3708, 3740, 3773, 3805, 3837, 
3869, 3902, 3934, 3966, 3998, 4031, 4063, 0

For Triangular:

0, 64, 129, 193, 258, 322, 387, 451, 516, 580, 645, 709, 774, 838, 903, 
967, 1032, 1096, 1161, 1225, 1290, 1354, 1419, 1483, 1548, 1612, 1677, 1741, 1806, 1870, 
1935, 1999, 2064, 2128, 2193, 2257, 2322, 2386, 2451, 2515, 2580, 2644, 2709, 2773, 2837, 
2902, 2966, 3031, 3095, 3160, 3224, 3289, 3353, 3418, 3482, 3547, 3611, 3676, 3740, 3805, 
3869, 3934, 3998, 4063, 4063, 3998, 3934, 3869, 3805, 3740, 3676, 3611, 3547, 3482, 3418, 
3353, 3289, 3224, 3160, 3095, 3031, 2966, 2902, 2837, 2773, 2709, 2644, 2580, 2515, 2451, 
2386, 2322, 2257, 2193, 2128, 2064, 1999, 1935, 1870, 1806, 1741, 1677, 1612, 1548, 1483, 
1419, 1354, 1290, 1225, 1161, 1096, 1032, 967, 903, 838, 774, 709, 645, 580, 516, 
451, 387, 322, 258, 193, 129, 64, 0

This will be the DAC levels, generated in between TIMER2 intervals, which will result in the specific waveform. The above data can be easily converted to an array in C like this:

#define NS 128

uint32_t Sine_Wave_LUT[NS] = {
2048, 2149, 2250, 2350, 2450, 2549, 2646, 2742, 2837, 2929, 3020, 3108, 3193, 3275, 3355,
3431, 3504, 3574, 3639, 3701, 3759, 3812, 3861, 3906, 3946, 3982, 4013, 4039, 4060, 4076,
4087, 4094, 4095, 4091, 4082, 4069, 4050, 4026, 3998, 3965, 3927, 3884, 3837, 3786, 3730,
3671, 3607, 3539, 3468, 3394, 3316, 3235, 3151, 3064, 2975, 2883, 2790, 2695, 2598, 2500,
2400, 2300, 2199, 2098, 1997, 1896, 1795, 1695, 1595, 1497, 1400, 1305, 1212, 1120, 1031,
944, 860, 779, 701, 627, 556, 488, 424, 365, 309, 258, 211, 168, 130, 97,
69, 45, 26, 13, 4, 0, 1, 8, 19, 35, 56, 82, 113, 149, 189,
234, 283, 336, 394, 456, 521, 591, 664, 740, 820, 902, 987, 1075, 1166, 1258,
1353, 1449, 1546, 1645, 1745, 1845, 1946, 2047
};

uint32_t Saw_Wave_LUT[NS] = {
0, 32, 64, 97, 129, 161, 193, 226, 258, 290, 322, 355, 387, 419, 451,
484, 516, 548, 580, 613, 645, 677, 709, 742, 774, 806, 838, 871, 903, 935,
967, 1000, 1032, 1064, 1096, 1129, 1161, 1193, 1225, 1258, 1290, 1322, 1354, 1386, 1419,
1451, 1483, 1515, 1548, 1580, 1612, 1644, 1677, 1709, 1741, 1773, 1806, 1838, 1870, 1902,
1935, 1967, 1999, 2031, 2064, 2096, 2128, 2160, 2193, 2225, 2257, 2289, 2322, 2354, 2386,
2418, 2451, 2483, 2515, 2547, 2580, 2612, 2644, 2676, 2709, 2741, 2773, 2805, 2837, 2870,
2902, 2934, 2966, 2999, 3031, 3063, 3095, 3128, 3160, 3192, 3224, 3257, 3289, 3321, 3353,
3386, 3418, 3450, 3482, 3515, 3547, 3579, 3611, 3644, 3676, 3708, 3740, 3773, 3805, 3837,
3869, 3902, 3934, 3966, 3998, 4031, 4063, 0
};

uint32_t Tri_Wave_LUT[NS] = {
0, 64, 129, 193, 258, 322, 387, 451, 516, 580, 645, 709, 774, 838, 903,
967, 1032, 1096, 1161, 1225, 1290, 1354, 1419, 1483, 1548, 1612, 1677, 1741, 1806, 1870,
1935, 1999, 2064, 2128, 2193, 2257, 2322, 2386, 2451, 2515, 2580, 2644, 2709, 2773, 2837,
2902, 2966, 3031, 3095, 3160, 3224, 3289, 3353, 3418, 3482, 3547, 3611, 3676, 3740, 3805,
3869, 3934, 3998, 4063, 4063, 3998, 3934, 3869, 3805, 3740, 3676, 3611, 3547, 3482, 3418,
3353, 3289, 3224, 3160, 3095, 3031, 2966, 2902, 2837, 2773, 2709, 2644, 2580, 2515, 2451,
2386, 2322, 2257, 2193, 2128, 2064, 1999, 1935, 1870, 1806, 1741, 1677, 1612, 1548, 1483,
1419, 1354, 1290, 1225, 1161, 1096, 1032, 967, 903, 838, 774, 709, 645, 580, 516,
451, 387, 322, 258, 193, 129, 64, 0
};

The full code can be seen in my repo: https://github.com/kurimawxx00/STM32F4WaveFormGen/

Step 4: Run the Application

Finally, upload and run the firmware on the STM32F407 development board. The microcontroller will receive the waveform data from MATLAB, configure the DAC and DMA, and generate the desired waveform on the DAC output pin. Press the K0 button the decrease or the K1 button to increase the frequency of the waveform. Press both K0 and K1 buttons to change waveforms.

Conclusion

By leveraging the STM32F4 DAC and MATLAB's powerful signal processing capabilities, we can generate precise and smooth waveforms like sine, triangular, and sawtooth waveforms in embedded applications. The combination of MATLAB's waveform generation capabilities and the STM32F4 DAC's accurate voltage output allows for versatile waveform generation in various applications such as audio synthesis, waveform analysis, and testing. Experiment with different waveform parameters and explore additional features of the STM32F4 DAC and MATLAB to further enhance waveform generation capabilities in your projects. Happy waveform generation!

The post Generating Sine, Triangular, and Sawtooth Waveforms using STM32F4 DAC appeared first on Microcontroller Tutorials.

This is what happens in the NodeMCU ESP8266 and ESP32. Another example, the Arduino UNO, uses an extra microcontroller just for its USB interface.

Adding another chip would entail costs in both part counts in PCB space. Thankfully, the STM32F4 microcontroller provides a neat solution.

What is CDC?

Communications Device Class (CDC) is one of many device classes specified by the USB protocol. Its primary use is for “computer networking devices akin to a network card, providing an interface for transmitting Ethernet or ATM frames onto some physical media. It is also used for modems, ISDN, fax machines, and telephony applications for performing regular voice calls.”

With CDC, a USB device acts like a normal serial port device. You can then send and receive messages serially from/to the computer. Since it’s not a “real” COM port, CDC devices are also called Virtual COM Ports.

Setting Up STM32 USB CDC

For this tutorial, I will be using the STM32F4 Black Board. This board doesn’t come with any USB-TLL converter or ST-Link, unlike the STM32 Discovery line. It does come with a miniUSB port, whose D-, and D+ pins are wired to pins PA11 and PA12.

The application will control the onboard LEDs via sending characters thru CDC. For reference, the onboard LEDs are at PA6 and PA7.

When an “x” is received, D2 lights up. When a “y” is received, D2 turns off. Alternatively, when an “a” is received, D3 lights up and when a “b” is received, D3 turns off.

It’s time to run STM32CubeMX! First up, we set the GPIO pins for the LEDs.

Make both PA6 and PA7 output pins:

To rename them, just go to System Core > GPIO and assign user labels:

Next, we make use of the 8 MHz crystal on the board. Set the PHO and PH1 pins as RCC pins.

Go to System Core > RCC and select Crystal/Ceramic Resonator as High Speed Clock source.

At this point, you can go to the Clock Configuration tab and change the input frequency to 8 MHz, HSE.

Of course, we still need to enable USB. Change pins PA11 and PA12 to their USB_OTG alternate functions.

Then go to Connectivity > USB_OTG_FS and select Device_Only mode.

Next, go to Middleware > USB_DEVICE:

On the dropdown on the right window, select Communication Device Class:

Finally, go over to Project Configuration, name your project, select a location to save it, and specify the toolchain (MDK-ARM if you’re using Keil). You may also need to change the heap size to 0x800 if you’re encountering problems whenever you’re plugging in the STM32F4 board on your computer.

Click “Generate Code” and open Keil.

Receiving Data from PC to STM32

In main.c, declare a variable that will serve as our buffer for user input. I placed mine between the Private Variables section:

Just before the while(1) loop in int main, turn off the LEDs:

Inside the while(1) loop, we insert the part where we check the serial input and control the LEDs accordingly:

We’re not done yet! Open the file usbd_cdc_if.c. This is where all the implementing functions for CDC are found.

Declare the same variable we used as buffer in main.c:

The keyword extern means it’s the same variable on main.c. This gives user_inp[] a global scope between the two files.

Locate the function CDC_Receive_FS() and add the following lines.

This function is a callback function that auto triggers whenever there is a received message thru CDC. That message is saved to the memory pointed by Buf, and its length is given by Len. All we have to do is copy that message to user_inp using memcpy. Before that, we must make sure that user_inp does not retain its previous value. This is what the first memset() does. The second memset is for clearing the Buf variable once we have transferred its contents to user_inp.

That’s about it for the code. Build and flash it to the board. As soon as you connect the board to the computer via USB, it will appear as a COM port in Device Manager:

Using a terminal application like Putty, we can now send messages to the STM32F4 Black Board from the computer.

Here's the output of this application:

Sending Data From STM32 to PC

If there’s a function for receiving data, there’s also one for transmitting:

This function accepts two parameters: the data to be sent, and its length.

You can set those parameters like this:

Also, you need to define the prototype function with extern command:

Finally, you can send messages. Here’s an example that sends a message every second:

I hope you found this tutorial on STM32 CDC USB useful. Happy coding!

The post Sending and Receiving Data over STM32 USB appeared first on Microcontroller Tutorials.

Here's a refresher on serial communication just in case you need it.

Like most microcontrollers, the STM32F103RB has dedicated serial pins. This tutorial will use the PA2 and PA3 pins which house USART2 TX and RX pins respectively. The reason behind this choice is that for the Nucleo-64 F103B, the USB port is wired directly to these pins.

In contrast, the STM32 Blue Pill, which uses an STM32F103C8, has pins PA11 and PA12 (USART1) wired to its USB port.

Assign the pins PA2 and PA3 to their USART equivalents as shown, using STM32CubeMX:

Generate the code to an MDK ARM output. If you choose to open the project, Keil V5 should start up and you have your ready-to-use code.

Here's a separate tutorial on how to use STM32CubeMX to generate code.

In main.c, you’ll notice a typedef for UART2.

UART_HandleTypeDef huart2;

This is used to initiate everything that needs to be initiated in order to use the serial port. Of course, this is also generated by STM32CubeMX:

All that is left is to call the transmit function to send messages via serial.

HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout)

The function requires the UART typedef, a char array for the message to be sent, the size of that char array, and a timeout period.

Locate the line with the infinite loop (while (1)) and insert the following:

/* USER CODE BEGIN WHILE */
while (1)
{
/* USER CODE END WHILE */

  unsigned char stringMsg[] = "Celtics 2022 Champs!\r\n";    //Data to send
  HAL_UART_Transmit(&huart2,stringMsg,sizeof(stringMsg),10);// Sending in normal mode
  HAL_Delay(1000);

/* USER CODE BEGIN 3 */
}
/* USER CODE END 3 */

This prints out the given string as long as the STM32F1 is on.

With the STM32F1 connected to the PC using the USB port, we use terminal apps like Putty to view the message:

Using printf() Function

We can further simplify printing out messages via serial by using the printf() function. For this, we need the stdio library.

Add a reference to the stdio library just below “main.h”:

Next, define a struct below the MX_GPIO_INIT function:

Below this line, create an instance of the struct and name it _stdout:

Then, define a function fputc(). This is what is required so that the UART channel is diverted to printf():

We also add a ferror function that would handle (although here it does nothing) errors in UART.

All in all, this should be what it looks like:

Now, instead of using this to transmit messages via serial port:

unsigned char stringMsg[] = "Celtics 2022 Champs!\r\n"; 
HAL_UART_Transmit(&huart2,stringMsg,sizeof(stringMsg),10);

We can now use:

printf(“Celtics 2022 Champs!\r\n”);

The whole code for this tutorial is on my repository.

The post STM32F1 Serial Port and printf() appeared first on Microcontroller Tutorials.

The board comes one of the more popular STM32F407VET Embedded IC and comes with a variety of features:

There’s a microSD slot, external flash chip, 3 user buttons, 2 user LEDs, NR24L01 socket, and easily accessible serial pins. I believe these are enough to have a good grasp of using this microcontroller.

The STM32F407VE microcontroller itself packs a punch. It has DSP and Ethernet support not to mention I2S capabilities, a 168-MHz max CPU frequency, 82 (!) GPIOs and USB (with OTG). More information about this microcontroller is in its datasheet.

Not surprisingly, much of the steps in programming this STM32F407VET board is the same as that of the STM32 Blue Pill. We will be using the STM32CubeIDE for writing code and the ST-Link Utility for uploading the program to the board.

Setting Up the Dev Environment

Install and open STM32CubeIDE. If it’s your first time opening it, you’ll need to specify the workspace directory. Tick on the checkbox below to make that workspace default and prevent this window from appearing again.

Next, select your project type. We’ll want to start a new project for now so click on Start new STM32 Project.

The next step is to select our target device. On the left panel, type in STM32F407VE in the Part Number field.

A table will appear on the right panel (see above image). Click on that and then click the Next > button.

Next, give your project a name. For our example, we’ll name it F4_Blinky.

A pop-up window will appear. Click yes to add Associated Perspective to the workspace.

At this point, STM32CubeIDE will start downloading the software packages for the STM32F407VE microcontroller.

Once downloads are finished, you will now be in the Device Configuration Tool. This is a handy tool for configuring the functions of each of the microcontroller’s pins. The tool also allows you to configure the clock for the device, among other features. For more information about this tool, read this specification sheet.

We want to write a code that flashes the two user LEDs.

The pinout diagram above shows that the user LEDs LED1 and LED2 (D2 and D3 in the board) connect to GPIOs PA6 and PA7. Hence in the Device Configuration Tool, we click on both pins and change their function to GPIO_OUTPUT.

Next, we click on System Core, then GPIO to reveal the GPIO Mode and Configuration panel. Here we can give a label to pins PA6 and PA7.

Here I gave the pins the appropriate labels:

Clicking File > Save or pressing CTRL+S will trigger another popup window:

Click Yes and a code with all the configurations will be created automatically!

After that, another window will popup. Clicking Yes to this will add an outline view of your project in the left panel:

Our IDE is now open and we're ready to code!

Writing Code for the STM32F407VE

At this point, we will edit main.c to be able to flash both LED1 and LED2.

Inside the main() function, look for an empty while(1) loop. Whatever is inside this loop is run indefinitely by the microcontroller. Thus, we insert a few lines of code for setting or clearing the user LEDs pin. Here’s how it looks:

while (1)
{
/* USER CODE END WHILE */
  HAL_GPIO_WritePin(GPIOA, LED1_Pin, GPIO_PIN_RESET);
  HAL_GPIO_WritePin(GPIOA, LED2_Pin, GPIO_PIN_SET);
  delay(500000);
  HAL_GPIO_WritePin(GPIOA, LED1_Pin, GPIO_PIN_SET);
  HAL_GPIO_WritePin(GPIOA, LED2_Pin, GPIO_PIN_RESET);
  delay(500000);
/* USER CODE BEGIN 3 */
}

HAL_GPIO_WritePin() is a built-in function for making a pin HIGH or LOW. It accepts three parameters, the first being the pin's PORT, the second is the pin's name and the third parameter is the pin's state. To make a pin LOW, the state is GPIO_PIN_RESET. Otherwise, the state is GPIO_PIN_SET.

Just like in Arduino or PIC, we'll need to configure the LED pins to be output pins. Fortunately, this is already done through the Device Configuration Tool. You'll see the configurations inside the MX_GPIO_Init() function.

Notice that we are using a delay() function. This is in fact not a built-in function and thus must be also added to the main.c file. Find the MX_GPIO_Init() function and after the closing bracket of that function, insert the following:

/* USER CODE BEGIN 4 */

void delay (int a)
{
  volatile int i,j;
  for (i=0 ; i < a ; i++) 
  { 
    j++; 
  } 
  return; 
} 

/* USER CODE END 4 */

This is a function that keeps the microcontroller busy. It uses a for-loop that counts up to the passed parameter (in our code, that value is 500000).

We also need to add a prototype of this function right with the other prototypes. The following lines should be right before the main function:

void SystemClock_Config(void);
static void MX_GPIO_Init(void);
void delay (int a);

Our code is ready for compilation! Click Project > Build All.

If there are no errors, this should be the output on the console at the bottom:

Uploading Code

A binary file is now inside the folder <Project-Name>/Debug/. Next, it’s time to load this binary file to the microcontroller.

I am using an ST-Link V2 USB dongle with its SWD pins wired to the SWD pins of the STM32F407VE board.

Also, before programming, make sure the BT0 pin is connected to ground and BT1 is wired to 3.3V. Here I am using jumpers to do just that.

In ST-Link Utility, click Target > Connect.

If the data in the memory of the microcontroller is now visible, then the connection is successful:

Next, click File > Open to load the binary file. After that, click Target > Program.

Finally, click Start to initiate the binary transfer:

If nothing went wrong, the STM32F407VE board now has a new program!

The LEDs LED1 (D2) and LED2 (D3) should now be flashing alternately.

Have any questions about this tutorial? Feel free to drop a comment below.

The post Programming the STM32F407VE Black Board appeared first on Microcontroller Tutorials.