top of page

How Real Embedded Firmware Is Actually Structured

  • Writer: Srihari Maddula
    Srihari Maddula
  • 1 day ago
  • 3 min read

Author: Srihari Maddula

Reading Time: 10-12 mins

Tags: Firmware Architecture, HAL, BSP, Clean Code, Refactoring


Spaghetti code vs. The Layered Cake. Which one are you building? (Photo by This is Engineering RAEng on Unsplash)

The "Super Loop" Nightmare

In college, your main.c file is usually a monster. It initializes the GPIOs, reads the ADC, calculates the temperature, formats a string, and sends it over UART—all in one 500-line file.

This is called Spaghetti Code. Everything is tangled. If you want to change the temperature sensor from an analog LM35 to a digital I2C sensor, you have to rip out half your code. If you want to switch from an AVR chip to an STM32, you have to rewrite everything.

Professional firmware is structured like a Layered Cake. Each layer has a specific job and only talks to the layers immediately above or below it.

1. The Foundation: Hardware Abstraction Layer (HAL)

At the very bottom, you have the code that talks to the silicon. This is the HAL.

The Job: "Set Bit 3 of Register GPIOA_ODR to 1."The Goal: To provide a clean C function like gpio_write_pin(PORT_A, PIN_3, HIGH) so the rest of the code doesn't need to know memory addresses.

Pro Tip: Most vendors (ST, Nordic, Espressif) provide a HAL. Use it, but don't let it leak upwards. Wrap it in your own "Driver Interface" if you can.

2. The Board Support Package (BSP)

This is where your specific PCB design comes in. The HAL knows how to toggle a pin. The BSP knows what that pin is connected to.

  • HAL says: "Toggle GPIO Pin 5."

  • BSP says: "Turn on the Status LED."

The BSP defines your hardware abstraction. It contains functions like:

void bsp_led_red_on(void);
float bsp_get_battery_voltage(void);
bool bsp_is_charger_connected(void);

If you re-spin the PCB and move the LED from Pin 5 to Pin 12, you only change the BSP. The rest of your application code doesn't even know the board changed.

3. The Middleware (The "Plumbing")

This is the reusable code that sits between your hardware and your application logic. It includes:

  • RTOS: FreeRTOS, Zephyr (Task scheduling).

  • File Systems: FATFS, LittleFS.

  • Communication Stacks: TCP/IP (LwIP), USB Device, BLE Stack.

  • Libraries: DSP filters, crypto libraries, JSON parsers.

This code should be hardware agnostic. A JSON parser shouldn't care if it's running on an ARM Cortex-M4 or a RISC-V core.

4. The Application Layer (The "Business Logic")

This is the top of the cake. This is what your product actually does.

"If the temperature > 50°C AND the battery is > 20%, turn on the fan and send an alert via MQTT."

The Golden Rule: The Application Layer should never, ever touch a hardware register directly. It should call the BSP or Middleware.

The Test: Can you compile your Application Layer on your PC (x86) and run it inside a simulator?

If yes, you have a clean architecture.

If no (because it tries to include stm32f4xx.h), your layers are leaking.

5. Why This Matters for Your Career

When we interview Junior Engineers at EurthTech, we ask them to design a simple "Smart Light Switch."

  • The Junior: Writes one file. "If button pressed, toggle relay."

  • The Senior: Draws a block diagram. "Here is the Button Driver. Here is the Relay Driver. Here is the Event Manager task. Here is the Wi-Fi task."

The Senior's code is 3x longer. But the Senior's code can be:

  1. Unit Tested: You can test the logic without the hardware.

  2. Ported: You can switch chips in a week.

  3. Maintained: A new team member can understand just the "Button Driver" without reading the whole codebase.

Summary: Respect the Layers

Structuring firmware is about discipline. It's about resisting the urge to take shortcuts. It takes more time to set up initially, but it saves months of debugging later.

At EurthTech, we don't write "Arduino Sketches." We architect resilient, portable, and testable firmware systems.

Recommended Resources

 
 
 

Comments


EurthTech delivers AI-powered embedded systems, IoT product engineering, and smart infrastructure solutions to transform cities, enterprises, and industries with innovation and precision.

Factory:

Plot No: 41,
ALEAP Industrial Estate, Suramapalli,
Vijayawada,

India - 521212.

  • Linkedin
  • Twitter
  • Youtube
  • Facebook
  • Instagram

 

© 2025 by Eurth Techtronics Pvt Ltd.

 

Development Center:

2nd Floor, Krishna towers, 100 Feet Rd, Madhapur, Hyderabad, Telangana 500081

Menu

|

Accesibility Statement

bottom of page