July 22, 2025 • 17 mins
Welcome back to Build, Create & Learn — A Maker’s Journey! In this episode, I’m taking you along on my early adventures with embedded programming using the STM32 microcontroller.
From that first blinking LED to the moment I finally got sensor data from the BME280, it’s been a ride full of bugs, head-scratching errors, and small wins that felt huge.
I’ll walk you through:
- How I got started with STM32 and why I chose it
- The common mistakes that slowed me down
- Wiring up and reading from the BME280 sensor
- What I’ve learned (and what I still don’t understand)
If you’re curious about embedded development or just enjoy the learning journey behind the scenes, this one’s for you. Whether you’re a beginner or someone looking back at their first “blinky” project, I hope you find something relatable in the process.
Check out the companion blog post for links, images, and the source code: herndlbauer.com
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Hey everyone and welcome back to Build, Create and Learn and Make Us Journey.
I’m your host Stefan and I’m really excited to dive into Episode 2 with you today.
If you tuned in for the first episode you know we started things off by talking about the why behind the podcast and the project that got my gears turning, building a custom FPB drone telemetry system.
(00:24):
It’s all about these flight stats, speed, altitude and position, transmitting down in real time because let’s be honest for a data hungry maker like me, flying without that information feels like leaving half the story untold.
Before we jump into the nitty gritty of microcontrollers I’ve got a couple of quick updates from my maker life.
(00:45):
First off, a new arrival in my workshop.
My new 3D printer just landed and trust me it’s already got my mind spinning with ideas for what we could build next.
Maybe even some custom enclosures for the telemetry system down the line or perhaps even some functional parts for the drone itself.
It’s a whole new dimension of possibilities and I’m really excited to share more about my latest movement into 3D printing on my blog soon.
(01:10):
Also being diving into the world of remote desktop for CAD work, trying to optimize my design workflows and there are some fascinating possibilities there.
Imagine being able to design complex parts on the go and send them straight to your 3D printer back home.
But today we’re really getting our hands dirty with the heart of our FPV telemetry project tackling the STM32 microcontroller.
(01:33):
This is where the rubber meets the road, where the theoretical becomes tangible and where the real learning begins.
Part 1.
Setting up the development environment.
The first steps.
So the very first thing on this embedded journey was getting the STM32 cube IDE installed on my Mac.
(01:54):
Honestly for a major development environment it was surprisingly straightforward.
A quick heads up for everyone else diving in though.
You need to register an account with STM to download it.
It’s a small quick step but definitely good to know beforehand so you’re not caught off guard.
Once you’re in you immediately notice the difference from something like Arduino IDE.
(02:15):
It feels more professional, more robust with a lot more options.
When you start a new project you have a couple of powerful ways to select your chip.
You can pick just the raw microcontroller which gives you the maximum control or this is the pro tip I quickly learned and would highly recommend for beginners.
You can select the specific development board directly.
(02:35):
Choosing the board has a huge benefit.
All the onboard components like LEDs and buttons are often already pre-configured for you.
Correctly assigned to the microcontroller pins.
For my nuclear board I could immediately see the LEDs properly assigned in the configuration.
It saves a significant amount of initial guess working and head scratching trying to figure out which physical pin maps to which software register.
(02:58):
For a project type I recommend going with the MQube MX Auto Generation.
Especially for beginners it makes it so much easier to use the microcontroller correctly right off the gate.
It handles a lot of the initial setup for you so you can focus on your application logic rather than getting bogged down into low level configurations.
Part 2.
(03:22):
Dive into the debugging and the printf pitfall.
My very first task once the IDE was set up was simple.
Test the printer functionality.
I just wanted to make absolutely sure that the board could be programmed and compiled properly so that I could get the debug message back to my computer.
So I added the standard library and a simple printer command to my main function.
(03:44):
Sounds easy enough right?
But then a little moment of anxiety.
When I connected the board for the very first time a message popped up.
"STM link debugger needs to be updated".
Now I’ll admit I needed a moment to think.
You know that feeling you just started out, you’re super excited and you really don’t want to break the new component on day one.
(04:04):
That thought of accidentally corrupting the firmware or damaging the chip just by trying to update it was definitely there.
But I thought deep breathed remind myself that these updates are usually routine, proceeded with it, flashing the debugger to the newest version and thankfully it went smoothly.
No hiccups.
Poo.
Crisis averted before it even began.
(04:26):
So debugger updated, code compiled, loaded onto the chip.
I’m staring at my trace console eagerly waiting for my first message and nothing.
Absolute silence.
Oh no, what happened I thought?
I followed the learning material exactly.
I didn’t do anything different.
The immediate reaction is always that I’ve done something fundamentally wrong.
(04:47):
I carefully rechecked my code line by line comparing it to the example, inspecting every character and then I saw it.
A tiny problem.
I had used single quotes for the print-dev statement.
In TypeScript and Python, which I’ve been working a lot in the recent years, that difference is completely irrelevant.
Single or double quotes it doesn’t matter.
But C is notoriously strict about these details.
(05:10):
One tiny change to double quotes, recombining and reloading.
And there it was, my first successful message in the tracing console.
Yes.
This relief was absolutely real.
A small victory that felt disproportionately large after this brief moment of panic.
It’s the little moments of our coming unexpected hurdles that makes the makers’ journey so rewarding.
(05:31):
On three, my learning process and the blinky milestone.
This experience with the print-dev bug really highlighted my learning process and how I approach new technical challenges.
For quick starts and getting something like the blinky app up and running, YouTube videos are fantastic.
You are visually following along, get a quick overview and see immediately results.
(05:55):
They are great for the initial spark and getting the feeds wet.
But to go deeper to really understand why things work the way they do, how memory addresses are structured and how to find the right ones for the job, I’ve been heavily relying on a Udemy course.
Mastering, microcontrollers and better driver development.
This course dives into the nitty gritty details that YouTube tutorials often close over.
(06:18):
It’s about understanding the foundational principles.
Using the hardware abstraction layer simplifies a lot the tedious memory fiddling and direct register manipulation.
I firmly believe it’s worth understanding how it works at least once before relying solely on the abstraction.
It gives you a deeper appreciation of what the hardware abstraction layer is doing for you and helps you troubleshoot when things inevitably go wrong.
(06:42):
This deep dive into the fundamentals is what really helped me navigate data sheets and find the necessary information, turning what initially looked like an impenetratable wall of text into something that I could actually learn from.
I can totally recommend this course.
It’s incredibly well made, clear and comprehensive.
As for the Blinky app itself, after a print dev debugging saga, it was fairly straightforward.
(07:06):
Just two lines of code in the main function to toggle an onboard LED on and off.
No big surprise, no dramatic revelation, but seeing the LED light up exactly as configured, blinking away in the perfect rhythm was pretty satisfying.
It’s the hello world of an embedded system and it always feels good to get the first successful interaction with the hardware.
(07:27):
Part 4 Connecting the First Sensor, the BME 280 Journey With the Blinky app out of the way, the next big step was connecting our first sensor.
I had my breakout board ready and my STM32 was up and running.
But before I could even connect it, there was the small but significant hurdle, soldering the pins onto the breakout board.
(07:51):
It’s common practice for these tiny breakout boards to ship without the pin headers attached.
It reduces the shipping footprint and gives you more options for how you want to mount them.
But honestly, for me this was a new situation.
In the past, all the sensors and breakout boards I’ve bought had the pins pre-attached.
Now, the soldering itself wasn’t the issue.
I know how to do this well enough.
(08:13):
My only open question was which way do these pins go?
Do they point up or down?
After watching a quick YouTube video, it was obvious.
Sometimes you just need to see it once and then it’s clear.
A little visual guidance goes a long way.
Oh, a little make-up tip for soldering this.
I actually 3D printed a breadboard replica.
It’s perfect for holding the pin straight up while you solder and it meant I wouldn’t accidentally damage one of my actual breadboards with heat or stray solder.
(08:41):
Though after doing it, I’m still a little unsure if I put it in the right direction.
Because now the sensor itself points up, but the labels are at the bottom.
It works, so I’m rolling with it for now.
So, pins soldered, board ready, next big question, how to connect them properly?
My BME1280 environmental sensor breakout board has the following pins.
(09:04):
VCC, ground, SCL, SDA, CSB and SDO.
I logged into the BME280 datasheet and the first thing I learned was that sensor supports two different data protocols.
I2C and SPI.
For beginners, I2C is generally recommended because it uses fewer pins and it’s often simpler to get started with.
(09:26):
So that’s the path I took.
I spent some time learning about the I2C protocol, understanding how to transmit data between devices and the concept of master and slave devices.
For wiring it up to the STM32, I also needed two pull-up resistors between 3.3V and the clock and the data lines.
The datasheet recommends 4700 ohm resistors but the closers I had on hand were 5100 ohm ones.
(09:53):
Close enough I thought that should be fine for the first test.
It’s often about making it work with what you have in the makers world.
I watched several videos but most of them covered Arduino and ESP32 setups and they often used premade libraries that were directly helpful for my STM project.
It was a bit frustrating, feeling like it was constantly hitting dead ends for my specific setup.
(10:17):
But then I got lucky.
I found a tutorial that used STM32 blue pill board with the exact same sensor, although with a slightly different break-up board.
Crucially this developer also provided a very sophisticated driver for this sensor and a detailed explanation of the code he wrote.
It was a lifesaver.
I used his code files and imported him to my project.
(10:38):
The first thing I needed to adjust was linking it to the right chip header file from my nuclear support but after a first build everything looked good.
Now the moment of truth.
I integrated this driver into my main program, followed the tutorial on how to setup and configure the sensor, creating a new debug configuration and started the program in debug mode.
(10:59):
I looked at the live expressions just like the developers in the video did but for me it only showed zero values.
Absolute zeros.
This couldn’t be right.
I double checked the wiring, tracing every connection and then it hit me.
I understood a potential conflict.
I was using the pin diagram from the mbed.com platform for my nucleus board, which is a great resource but it turned out that the SCL and SDA ports on my specific board were swapped compared to the pin diagram.
(11:28):
So I gave it a try and switched the two cables from PC9 and PC8.
And then hooray!
A so live data values appearing on the screen.
Temperature, pressure, humidity.
It was truly a fascinating moment.
Seeing these numbers, real world data populating on my debug console.
After all the setup and troubleshooting was incredibly satisfying.
(11:50):
I know I didn’t drive the entire driver myself and there are definitely many parts of the code I don’t fully understand yet but it works and that makes me incredibly happy.
It’s a testament to the power of open source contributions and building on the work of others.
Since I primarily interested in altitude values instead of raw pressure data, I definitely wanted to add this myself.
(12:11):
I looked up the calculation for converting the measured pressure to sea level heights, a quick bit of research into esmeric models and after a few minutes of coding, I also had my desired altitude values.
It felt great to add my little piece of logic to the system.
I know I’ve only briefly touched on all the capabilities of this one sensor and its configuration but as a first step I’m really happy with the results.
(12:36):
This first test was also configured for indoor measurements so far drone flights outside, I definitely have to tweak the sampling configuration settings to account for dynamic changes in environment.
Part 5 Conclusion and what’s next?
So this episode has been all about these critical first steps getting our development environment set up, wrestling with debuggers, appreciating data sheets and celebrating the simple joy of a blinking LED.
(13:04):
And then the big win, getting your first real world data from the BME 280 sensor, even after a little pin swapping adventure and a quick 3D printing detour.
It’s a powerful reminder that Makers Journey is full of these small aha moments, tiny frustrations that led to big lessons and simple victories that fuel the motivation.
It’s about learning, adapting and most importantly not being afraid to stumble and figure things out along the way.
(13:30):
That’s where the real growth happens.
Next time the goal is to get some useful GPS coordinates.
That’s going to be a whole new challenge dealing with different data formats, understanding satellite signals and ensuring accuracy for the drone telemetry.
It’s about the big pieces of the puzzle and I’m excited to share this ups and downs of the process with you.
If you enjoyed this honest look on the early stage of an embedded project, please subscribe to Build, Create and Learner Makers Journey wherever you get this podcast.
(13:58):
Drop me a message, connect on social media or leave a comment on the blog post in the episode.
I would love to hear about your debugging nightmares, your stories on what makes these communities so vibrant.
Let’s keep building, creating and learning together.
Hey everyone and welcome back to Build, Create and Learn and Make Us Journey.
I’m your host Stefan and I’m really excited to dive into Episode 2 with you today.
If you tuned in for the first episode you know we started things off by talking about the why behind the podcast and the project that got my gears turning, building a custom FPB drone telemetry system.
(00:24):
It’s all about these flight stats, speed, altitude and position, transmitting down in real time because let’s be honest for a data hungry maker like me, flying without that information feels like leaving half the story untold.
Before we jump into the nitty gritty of microcontrollers I’ve got a couple of quick updates from my maker life.
(00:45):
First off, a new arrival in my workshop.
My new 3D printer just landed and trust me it’s already got my mind spinning with ideas for what we could build next.
Maybe even some custom enclosures for the telemetry system down the line or perhaps even some functional parts for the drone itself.
It’s a whole new dimension of possibilities and I’m really excited to share more about my latest movement into 3D printing on my blog soon.
(01:10):
Also being diving into the world of remote desktop for CAD work, trying to optimize my design workflows and there are some fascinating possibilities there.
Imagine being able to design complex parts on the go and send them straight to your 3D printer back home.
But today we’re really getting our hands dirty with the heart of our FPV telemetry project tackling the STM32 microcontroller.
(01:33):
This is where the rubber meets the road, where the theoretical becomes tangible and where the real learning begins.
Part 1.
Setting up the development environment.
The first steps.
So the very first thing on this embedded journey was getting the STM32 cube IDE installed on my Mac.
(01:54):
Honestly for a major development environment it was surprisingly straightforward.
A quick heads up for everyone else diving in though.
You need to register an account with STM to download it.
It’s a small quick step but definitely good to know beforehand so you’re not caught off guard.
Once you’re in you immediately notice the difference from something like Arduino IDE.
(02:15):
It feels more professional, more robust with a lot more options.
When you start a new project you have a couple of powerful ways to select your chip.
You can pick just the raw microcontroller which gives you the maximum control or this is the pro tip I quickly learned and would highly recommend for beginners.
You can select the specific development board directly.
(02:35):
Choosing the board has a huge benefit.
All the onboard components like LEDs and buttons are often already pre-configured for you.
Correctly assigned to the microcontroller pins.
For my nuclear board I could immediately see the LEDs properly assigned in the configuration.
It saves a significant amount of initial guess working and head scratching trying to figure out which physical pin maps to which software register.
(02:58):
For a project type I recommend going with the MQube MX Auto Generation.
Especially for beginners it makes it so much easier to use the microcontroller correctly right off the gate.
It handles a lot of the initial setup for you so you can focus on your application logic rather than getting bogged down into low level configurations.
Part 2.
(03:22):
Dive into the debugging and the printf pitfall.
My very first task once the IDE was set up was simple.
Test the printer functionality.
I just wanted to make absolutely sure that the board could be programmed and compiled properly so that I could get the debug message back to my computer.
So I added the standard library and a simple printer command to my main function.
(03:44):
Sounds easy enough right?
But then a little moment of anxiety.
When I connected the board for the very first time a message popped up.
"STM link debugger needs to be updated".
Now I’ll admit I needed a moment to think.
You know that feeling you just started out, you’re super excited and you really don’t want to break the new component on day one.
(04:04):
That thought of accidentally corrupting the firmware or damaging the chip just by trying to update it was definitely there.
But I thought deep breathed remind myself that these updates are usually routine, proceeded with it, flashing the debugger to the newest version and thankfully it went smoothly.
No hiccups.
Poo.
Crisis averted before it even began.
(04:26):
So debugger updated, code compiled, loaded onto the chip.
I’m staring at my trace console eagerly waiting for my first message and nothing.
Absolute silence.
Oh no, what happened I thought?
I followed the learning material exactly.
I didn’t do anything different.
The immediate reaction is always that I’ve done something fundamentally wrong.
(04:47):
I carefully rechecked my code line by line comparing it to the example, inspecting every character and then I saw it.
A tiny problem.
I had used single quotes for the print-dev statement.
In TypeScript and Python, which I’ve been working a lot in the recent years, that difference is completely irrelevant.
Single or double quotes it doesn’t matter.
But C is notoriously strict about these details.
(05:10):
One tiny change to double quotes, recombining and reloading.
And there it was, my first successful message in the tracing console.
Yes.
This relief was absolutely real.
A small victory that felt disproportionately large after this brief moment of panic.
It’s the little moments of our coming unexpected hurdles that makes the makers’ journey so rewarding.
(05:31):
On three, my learning process and the blinky milestone.
This experience with the print-dev bug really highlighted my learning process and how I approach new technical challenges.
For quick starts and getting something like the blinky app up and running, YouTube videos are fantastic.
You are visually following along, get a quick overview and see immediately results.
(05:55):
They are great for the initial spark and getting the feeds wet.
But to go deeper to really understand why things work the way they do, how memory addresses are structured and how to find the right ones for the job, I’ve been heavily relying on a Udemy course.
Mastering, microcontrollers and better driver development.
This course dives into the nitty gritty details that YouTube tutorials often close over.
(06:18):
It’s about understanding the foundational principles.
Using the hardware abstraction layer simplifies a lot the tedious memory fiddling and direct register manipulation.
I firmly believe it’s worth understanding how it works at least once before relying solely on the abstraction.
It gives you a deeper appreciation of what the hardware abstraction layer is doing for you and helps you troubleshoot when things inevitably go wrong.
(06:42):
This deep dive into the fundamentals is what really helped me navigate data sheets and find the necessary information, turning what initially looked like an impenetratable wall of text into something that I could actually learn from.
I can totally recommend this course.
It’s incredibly well made, clear and comprehensive.
As for the Blinky app itself, after a print dev debugging saga, it was fairly straightforward.
(07:06):
Just two lines of code in the main function to toggle an onboard LED on and off.
No big surprise, no dramatic revelation, but seeing the LED light up exactly as configured, blinking away in the perfect rhythm was pretty satisfying.
It’s the hello world of an embedded system and it always feels good to get the first successful interaction with the hardware.
(07:27):
Part 4 Connecting the First Sensor, the BME 280 Journey With the Blinky app out of the way, the next big step was connecting our first sensor.
I had my breakout board ready and my STM32 was up and running.
But before I could even connect it, there was the small but significant hurdle, soldering the pins onto the breakout board.
(07:51):
It’s common practice for these tiny breakout boards to ship without the pin headers attached.
It reduces the shipping footprint and gives you more options for how you want to mount them.
But honestly, for me this was a new situation.
In the past, all the sensors and breakout boards I’ve bought had the pins pre-attached.
Now, the soldering itself wasn’t the issue.
I know how to do this well enough.
(08:13):
My only open question was which way do these pins go?
Do they point up or down?
After watching a quick YouTube video, it was obvious.
Sometimes you just need to see it once and then it’s clear.
A little visual guidance goes a long way.
Oh, a little make-up tip for soldering this.
I actually 3D printed a breadboard replica.
It’s perfect for holding the pin straight up while you solder and it meant I wouldn’t accidentally damage one of my actual breadboards with heat or stray solder.
(08:41):
Though after doing it, I’m still a little unsure if I put it in the right direction.
Because now the sensor itself points up, but the labels are at the bottom.
It works, so I’m rolling with it for now.
So, pins soldered, board ready, next big question, how to connect them properly?
My BME1280 environmental sensor breakout board has the following pins.
(09:04):
VCC, ground, SCL, SDA, CSB and SDO.
I logged into the BME280 datasheet and the first thing I learned was that sensor supports two different data protocols.
I2C and SPI.
For beginners, I2C is generally recommended because it uses fewer pins and it’s often simpler to get started with.
(09:26):
So that’s the path I took.
I spent some time learning about the I2C protocol, understanding how to transmit data between devices and the concept of master and slave devices.
For wiring it up to the STM32, I also needed two pull-up resistors between 3.3V and the clock and the data lines.
The datasheet recommends 4700 ohm resistors but the closers I had on hand were 5100 ohm ones.
(09:53):
Close enough I thought that should be fine for the first test.
It’s often about making it work with what you have in the makers world.
I watched several videos but most of them covered Arduino and ESP32 setups and they often used premade libraries that were directly helpful for my STM project.
It was a bit frustrating, feeling like it was constantly hitting dead ends for my specific setup.
(10:17):
But then I got lucky.
I found a tutorial that used STM32 blue pill board with the exact same sensor, although with a slightly different break-up board.
Crucially this developer also provided a very sophisticated driver for this sensor and a detailed explanation of the code he wrote.
It was a lifesaver.
I used his code files and imported him to my project.
(10:38):
The first thing I needed to adjust was linking it to the right chip header file from my nuclear support but after a first build everything looked good.
Now the moment of truth.
I integrated this driver into my main program, followed the tutorial on how to setup and configure the sensor, creating a new debug configuration and started the program in debug mode.
(10:59):
I looked at the live expressions just like the developers in the video did but for me it only showed zero values.
Absolute zeros.
This couldn’t be right.
I double checked the wiring, tracing every connection and then it hit me.
I understood a potential conflict.
I was using the pin diagram from the mbed.com platform for my nucleus board, which is a great resource but it turned out that the SCL and SDA ports on my specific board were swapped compared to the pin diagram.
(11:28):
So I gave it a try and switched the two cables from PC9 and PC8.
And then hooray!
A so live data values appearing on the screen.
Temperature, pressure, humidity.
It was truly a fascinating moment.
Seeing these numbers, real world data populating on my debug console.
After all the setup and troubleshooting was incredibly satisfying.
(11:50):
I know I didn’t drive the entire driver myself and there are definitely many parts of the code I don’t fully understand yet but it works and that makes me incredibly happy.
It’s a testament to the power of open source contributions and building on the work of others.
Since I primarily interested in altitude values instead of raw pressure data, I definitely wanted to add this myself.
(12:11):
I looked up the calculation for converting the measured pressure to sea level heights, a quick bit of research into esmeric models and after a few minutes of coding, I also had my desired altitude values.
It felt great to add my little piece of logic to the system.
I know I’ve only briefly touched on all the capabilities of this one sensor and its configuration but as a first step I’m really happy with the results.
(12:36):
This first test was also configured for indoor measurements so far drone flights outside, I definitely have to tweak the sampling configuration settings to account for dynamic changes in environment.
Part 5 Conclusion and what’s next?
So this episode has been all about these critical first steps getting our development environment set up, wrestling with debuggers, appreciating data sheets and celebrating the simple joy of a blinking LED.
(13:04):
And then the big win, getting your first real world data from the BME 280 sensor, even after a little pin swapping adventure and a quick 3D printing detour.
It’s a powerful reminder that Makers Journey is full of these small aha moments, tiny frustrations that led to big lessons and simple victories that fuel the motivation.
It’s about learning, adapting and most importantly not being afraid to stumble and figure things out along the way.
(13:30):
That’s where the real growth happens.
Next time the goal is to get some useful GPS coordinates.
That’s going to be a whole new challenge dealing with different data formats, understanding satellite signals and ensuring accuracy for the drone telemetry.
It’s about the big pieces of the puzzle and I’m excited to share this ups and downs of the process with you.
If you enjoyed this honest look on the early stage of an embedded project, please subscribe to Build, Create and Learner Makers Journey wherever you get this podcast.
(13:58):
Drop me a message, connect on social media or leave a comment on the blog post in the episode.
I would love to hear about your debugging nightmares, your stories on what makes these communities so vibrant.
Let’s keep building, creating and learning together.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
My Favorite Murder with Karen Kilgariff and Georgia Hardstark
My Favorite Murder is a true crime comedy podcast hosted by Karen Kilgariff and Georgia Hardstark. Each week, Karen and Georgia share compelling true crimes and hometown stories from friends and listeners. Since MFM launched in January of 2016, Karen and Georgia have shared their lifelong interest in true crime and have covered stories of infamous serial killers like the Night Stalker, mysterious cold cases, captivating cults, incredible survivor stories and important events from history like the Tulsa race massacre of 1921. My Favorite Murder is part of the Exactly Right podcast network that provides a platform for bold, creative voices to bring to life provocative, entertaining and relatable stories for audiences everywhere. The Exactly Right roster of podcasts covers a variety of topics including historic true crime, comedic interviews and news, science, pop culture and more. Podcasts on the network include Buried Bones with Kate Winkler Dawson and Paul Holes, That's Messed Up: An SVU Podcast, This Podcast Will Kill You, Bananas and more.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.