The "watch out for compilers eliminating your code" idea at 00:32:00 was an "aha!" moment for me. Last week I was scratching my head for hours trying to figure out why my basic blinky app wasn't blinking. Inserting the `nop` and setting `i` to `volatile` did the trick for me. That little piece of subtle but crucial info has convinced me to watch more of the series. Great work.
Thanks for the Video, looks great. By any chance could you do a video about how you have configured VSCode? Would be nice to better understand those settings rather than copy. Thanks!
Sometimes.... some GPIOs and perhaps UART0 might be on by default. I need to check lpc1769 (my favorite cortex m3) but i seem to remember some peripherals being on by default. Its a good idea to turn 'em on, even if they're already on, no harm twiddling those bits, but its a good idea.
The video is from a year ago already, but I felt like it should be mentioned. You can speed up the process of make compiling anything, by using --jobs use flag. The jobs value should be equal to half of your ram but not more than the amount of cpu threads for best optimization. So for example I have 16GB of ram and 12 thread processor, so I run make -j8 and it should compile 8 times faster.
Looking forward to the series. I am thinking of tipping my toes into bare metal development by follwong along but use QEMU instead of a development board. Are there any significant advantages using real hardware?
Sounds like a great plan! If the emulation is good enough, and you have some way to simulate the "outside world" (LEDs, GPIOs, etc), then I don't see any major disadvantages to using something like QEMU. I personally enjoy having the physical hardware in front of me, hooking up the oscilloscope etc but that's a personal preference
Well, i was thinking. I might start explaining the state system of WHAT you're programming before 7:05. Mention what drive your program, maybe some event driven basics. in that infinite loop, i might suggest the WFI (wait for interrupt processor instruction...).
Glad to find you made this series, just what I was looking for, I watched one of your other series a while back and it was good (was it uefi?). Unlike some other commenters, I'm glad you didn't waste a bunch of time setting up basic development tools that are already extremely well-covered elsewhere. It's unfortunate you feel the need to digress to explain C syntax or electronics basic, but what I do I know, I just find it boring since nobody should be at this point in doing what you're showing without knowing already or how to lookup. You're one of my favourite TH-cam teachers.
I explained this in episode 0 of the series, but I'll sum it up here. "Bare metal" is a fairly broad term that can mean everything from "code with zero dependencies that performs only raw register accesses" to "code that runs without a standard library, RTOS, or operating system like linux". On that spectrum, this series is somewhere in the middle. There's no RTOS or standard library usage, and although libopencm3 is an external library that is used, it is itself an extremely low level library that performs one or a handful of raw register accesses per function call. Additionally, I make it a very large part of the series to actually follow all of the important function calls in libopencm3 all the way down to the raw register level, and explain them in depth.
I definitely think this qualifies as bare metal programming. You start out with an STM32 development board that does nothing, and write all the software that's needed to make it do something. The "prebuilt functions" are just libopencm3, which is only a level or two of abstraction from the true bare metal code. IMO it's actually really powerful to be able to think about the bare metal tasks in conceptual terms such as "set up the clock for GPIO port A". And then when I really need to see the true bare metal code it's not hard to follow the libopencm3 C files to the true end. I just started the series but I think I'm going to be able to get a lot farther thanks to this level of abstraction.
@@LowByteProductions if possible can you please create tutorial on how to blink LED using raw register accesses, custom linker script, startup code and makefile? No RTOS, no standard library, no HAL, no CMSIS & no libopencm3.
The latest version of libopencm3 has been slightly modified. The preprocessor directive should be #include In case of future changes, just look at the include folder directory structure of libopencm3
Hmmm you shouldn't have to do this if you have the chip properly defined in the makefile. Take a look at github.com/libopencm3/libopencm3/blob/master/include/libopencm3/stm32/rcc.h, which would be #include If you have STM32F4 properly defined in the makefile, it automatically includes the file you mentioned.
Thank you so much. Questions re setup - is this windows, wsl or stand alone linux? ST-Link drivers links on github are for windows but vscode config paths on this tutorial show Linux. Would Windows + wsl 2 (with arm compiler and make) + vscode work for flashing via ST-Link? Cheers.
Hey Igor 👋 I believe the setup will work both on windows and Linux for st-link, but I haven't tested it myself. Scott, who submitted the patch, is using Windows with no wsl layer.
It's definitely not perfect! One of the things that I'm enjoying the most with this series is using libopencm3 instead of the STM32 Cube tools and STs HAL. Its a breath of fresh air!
I really don't like the official HAL, so this quick look at open-cm was kinda interesting. I always use `goto` and a label instead of `while` for my main loops... just to be "edgy" ;)
libopencm3 won't compile on window. Error with the nvic.h linker line 63: from the make file. Did anyone have a work around this since the include Header file is dynamic link
I really enjoy this series! I decided to try to follow along with my own STM32 board. I did everything that was required in the README on github. I even "scrolled" back to the initial commit. I had a lot of trouble installing gcc and make for some reason on windows. After a couple hours arguning with chatgpt I got it to work. My questions are now: 1) How did you come up with all those files that you already had at the start of this video? 2) What do I have to do to use my own STM32, because I have a different one (STM32L432KC)? 3) In 'c_cpp_properties.json' i changed the compilerPath to my path as vscode threw me an warning (current: "/program files (x86)/Arm GNU Toolchain arm-none-eabi/12.2 mpacbti-rel1/bin/arm-none-eabi-gcc"). Is that correct? 4) vscode is presenting 5 errors in 'firmware.c': identifier 'rcc_hsi_configs', 'RCC_CLOCK_3V3_84MHZ', 'RCC_GPIOA', 2x 'uint32_t' are undefined". Does this happen because I use a different controller or am I missing libraries? Shouldn't a uint32_t be defined out of the box, I mean.. it's just another type? 5) How do I program the mcu using the on-board stlink? Drivers are already installed. Asking more about the steps I have to do in vscode. I recognise those are questions that might require some time to awnser properly so a pointer* to a good resource is also very much appreciated.
I installed the repository but am getting this error ffor the app: # Build the main application firmware cd app make $ make src/bootloader.S: Assembler messages: src/bootloader.S:3: Error: file not found: ../bootloader/bootloader.bin make: *** [Makefile:171: src/bootloader.o] Error 1
Hi, same problem here! You might have already solved it yourself, but here’s what I did: Under the `bare-metal-series` folder, first `cd bootloader` and run `make`. Then, navigate to the `app` folder and run `make` again. This worked for me.
Experienced Asm developer writing first simple C program: "Ha! I understand every line, it's so simple and convenient" Experienced Asm developer rage quits after not being able to set up a toolchain for 3 days and writes program in binary Linux users: *troll face*
Setting up tooling is pain, I totally agree. You can trade convenience for insanity if you're willing to step over to something like Docker, but it's not for everyone. Can I ask why just installing the arm gcc tools didn't work? Or was this make related? Are you using Windows, mac, or Linux?
I guess youtube did delete my reply for some reason :( So in short, I had set everything on Windows + MinGW, couldn't get debug to start, discarded all, installed on Linux in vm, debug still won't start. After troubleshooting it turned out gdb only works with python 3.8. I still don't understand why, at least got it running. And massive thank you for the series! Love your detailed explanation. Not having a "magical intermediate" is the best way to go
i am facing issue with running make on the firmware.c file. I get the error make: *** No rule to make target 'firmware.elf', needed by 'elf'. Stop. Someone please help.
@@LowByteProductions yes sir. I cloned it as is, didn't alter any of the makefiles and only removed the additional files and folders to replicate the folder structure that you had in the blinky video. Also the file is named firmware.c in my directory as well. and on the current commit.
Well the makefiles changed a fair bit throughout the series, so it makes sense that it might not work outright. You'll find it easier I think to check out the commit associated with the first episode instead, and try to get that running. From there you'll be able to follow along with the seri3s making your own changes 🙂
@@LowByteProductions This solution worked sir. Thank you. But now i am facing a different issue in the PWM video related to a core lockup. How may i proceed from here?
If the main function will never return, why not just make it a void function? void main(), then you don't need to include the return statement at all 🤷♂
You configured the type of the pin but not level. While it doesn't matter for this example, in the real world, not initializing the pin level, you can cause problems later on. You can put the device driven by the pin into a funny/undefined state which can be hard to identify. Best to set pin level if it's going to be and output and if it's an input, set the initial level with the pullup/pulldown function. Even better is an external resistor as this ensures desired level as the system powers up. I had a SPI device that would partially clock data into itself. Later writes to the chip were all shifted making quite the problem.
Its a pity you have decided not to provide more information on how to set up our environment to match yours. What OS are you using? It has been an exercise in frustration trying to get libopencm3 make, VSCode and git to work as smoothly as you show, and totally detracts from the value of your course.
i like the bare metal idea but.... you have a list of needed installs that doesn't include the environment your showing or how to get where you are. This makes it harder to follow you. Please consider adding an episode or a link detailing these crucial first steps, showing how to set up the system you are running so we all start on the same page.
It's a fair point, but also a decision that I made consciously not to try to show getting to this environment. At the end of the day, there are 3 major operating systems, and even those 3 are fractured into various versions, distros, releases etc. There is simply a combinatorial problem here, and no matter how hard I try to cover every possible case, someone will come with a particular flavour that I haven't, and will want answers. Unfortunately I just don't have the time to support all of that, so getting the tools installed is left to the viewer. Fortunately though, the readme of the project does include all the things you need to get going, as well as an editor configuration for vscode that covers debugging for a jlink and st-link. Please give those materials a look first. If you can't get up and running I'm happy to try help in the discord server
@@LowByteProductionsWhile I agree of the plethora of target systems, I'm just talking about your system. If it's linux Windows, MacOS, doesn't matter. Just document your system setup. Going down the rabit hole of setting up Make, installing GCC etc really detracts from the goal of programming the micro.
When I run make I get the following errors. Seems the Makefile isn't finding something. make[1]: arm-none-eabi-gcc: No such file or directory make[1]: *** [../Makefile.include:41: can.o] Error 127 Failure building: lib/efm32/ezr32wg: code: 2 Failure building: lib/efm32/g: code: 2 Failure building: lib/efm32/gg: code: 2
@@LowByteProductions Thanks. I installed Arm GNU Toolchain to the root of Msys2 and used this path. export PATH="$PATH:/Arm GNU Toolchain arm-none-eabi/bin/" cd libopencm3 make ...
Hi! I've set up my c_cpp_properties doc, and everything else seems right (I'm doing this on windows btw), but I get libopencm3/stm32/rcc.h: No such file or directory when I try and compile, any idea why? I've been scratching my head over this for ages, if I do this from the command line though, I do seem to get further arm-none-eabi-gcc -I ./libopencm3/include -D STM32F4 firmware.c But it's weird vscode throws this error, any pointers?
process_begin: CreateProcess(NULL, printf " GENHDR stm32/f0 ;", ...) failed. make (e=2): The system cannot find the file specified. make: *** [Makefile:63: include/libopencm3/stm32/f0/nvic.h] Error 2 Any Idea to deal with this ERROR !
Hey, I'm trying to compile libopencm3 and getting the following error, tried to solve it, searched google, no luck. maybe you can asssist: PS C:\Users\Arie\Desktop\Embedded Dev Courses\Low Bite Productions\bare-metal-series\libopencm3> make process_begin: CreateProcess(NULL, printf " GENHDR stm32/f0 ;", ...) failed. make (e=2): The system cannot find the file specified. make: *** [Makefile:63: include/libopencm3/stm32/f0/nvic.h] Error 2
Episode 0: th-cam.com/video/uQQsDWLRDuI/w-d-xo.html
The "watch out for compilers eliminating your code" idea at 00:32:00 was an "aha!" moment for me. Last week I was scratching my head for hours trying to figure out why my basic blinky app wasn't blinking. Inserting the `nop` and setting `i` to `volatile` did the trick for me. That little piece of subtle but crucial info has convinced me to watch more of the series. Great work.
Thank you. I really love how you guide the audience through the code and what it does. Awesome
Good to see some STM32 content, I'm used to the HAL library so this was very nice to see!
Thank you very much for this series, can't wait to get to the bootloader.
Thank you so much. I am just starting to learn the STM32 a couple of days ago and this is a fantastic tutorial!
You're welcome!
Oh, these are meta skills. You will find most of this applicable to a wide variety of different micros. Cheers!
Thanks for the Video, looks great. By any chance could you do a video about how you have configured VSCode? Would be nice to better understand those settings rather than copy. Thanks!
Sometimes.... some GPIOs and perhaps UART0 might be on by default. I need to check lpc1769 (my favorite cortex m3) but i seem to remember some peripherals being on by default. Its a good idea to turn 'em on, even if they're already on, no harm twiddling those bits, but its a good idea.
Wtf i'm just frustrated and unable to setup the environment , could you please make a video please
The video is from a year ago already, but I felt like it should be mentioned. You can speed up the process of make compiling anything, by using --jobs use flag.
The jobs value should be equal to half of your ram but not more than the amount of cpu threads for best optimization.
So for example I have 16GB of ram and 12 thread processor, so I run make -j8 and it should compile 8 times faster.
on ubunto wsl 2 i had run
sudo apt-get install gcc-arm-none-eabi
arm-none-eabi-gcc --version
Looking forward to the series. I am thinking of tipping my toes into bare metal development by follwong along but use QEMU instead of a development board. Are there any significant advantages using real hardware?
Sounds like a great plan! If the emulation is good enough, and you have some way to simulate the "outside world" (LEDs, GPIOs, etc), then I don't see any major disadvantages to using something like QEMU. I personally enjoy having the physical hardware in front of me, hooking up the oscilloscope etc but that's a personal preference
hello! glad to see you again)
Wonderful! Subscribed.
Hi, can you please share how to customize the vscode like yours? I really like the terminal and theme.
Well, i was thinking. I might start explaining the state system of WHAT you're programming before 7:05. Mention what drive your program, maybe some event driven basics. in that infinite loop, i might suggest the WFI (wait for interrupt processor instruction...).
On second thought... if it's NOT complex... And just a dumb blinky, then WFI is too much.
Glad to find you made this series, just what I was looking for, I watched one of your other series a while back and it was good (was it uefi?).
Unlike some other commenters, I'm glad you didn't waste a bunch of time setting up basic development tools that are already extremely well-covered elsewhere. It's unfortunate you feel the need to digress to explain C syntax or electronics basic, but what I do I know, I just find it boring since nobody should be at this point in doing what you're showing without knowing already or how to lookup.
You're one of my favourite TH-cam teachers.
I want to program stm8s103f3 chip using stm8s207k nucleo board..i am looking for how to do it.. if anyone can help
how this is bare metal programming when using all the prebuilt functions?
I explained this in episode 0 of the series, but I'll sum it up here. "Bare metal" is a fairly broad term that can mean everything from "code with zero dependencies that performs only raw register accesses" to "code that runs without a standard library, RTOS, or operating system like linux". On that spectrum, this series is somewhere in the middle. There's no RTOS or standard library usage, and although libopencm3 is an external library that is used, it is itself an extremely low level library that performs one or a handful of raw register accesses per function call. Additionally, I make it a very large part of the series to actually follow all of the important function calls in libopencm3 all the way down to the raw register level, and explain them in depth.
I definitely think this qualifies as bare metal programming. You start out with an STM32 development board that does nothing, and write all the software that's needed to make it do something. The "prebuilt functions" are just libopencm3, which is only a level or two of abstraction from the true bare metal code. IMO it's actually really powerful to be able to think about the bare metal tasks in conceptual terms such as "set up the clock for GPIO port A". And then when I really need to see the true bare metal code it's not hard to follow the libopencm3 C files to the true end. I just started the series but I think I'm going to be able to get a lot farther thanks to this level of abstraction.
@@LowByteProductions if possible can you please create tutorial on how to blink LED using raw register accesses, custom linker script, startup code and makefile? No RTOS, no standard library, no HAL, no CMSIS & no libopencm3.
Based on your file explorer.. are you going to be doing an EFM32 tutorial as well?
The latest version of libopencm3 has been slightly modified. The preprocessor directive should be #include
In case of future changes, just look at the include folder directory structure of libopencm3
Hmmm you shouldn't have to do this if you have the chip properly defined in the makefile. Take a look at github.com/libopencm3/libopencm3/blob/master/include/libopencm3/stm32/rcc.h, which would be #include
If you have STM32F4 properly defined in the makefile, it automatically includes the file you mentioned.
@@LowByteProductions, Yes, you are correct. I modified my makefile. Thanks.
Thank you so much. Questions re setup - is this windows, wsl or stand alone linux? ST-Link drivers links on github are for windows but vscode config paths on this tutorial show Linux. Would Windows + wsl 2 (with arm compiler and make) + vscode work for flashing via ST-Link? Cheers.
Hey Igor 👋 I believe the setup will work both on windows and Linux for st-link, but I haven't tested it myself. Scott, who submitted the patch, is using Windows with no wsl layer.
What is incorrect in integrated ST-LINK on the NUCLEO board, instead plug J-link by special adapter?
There's nothing wrong with the ST-Link, I just prefer using a J-Link. There are vscode configurations for st-link in the repository.
You can also reprogram them to be a black magic probe, which is what I've done with mine.
Nice :) I have a Nucleo laying around :)
STM Cube and the environment is a nightmare tho 🤣
It's definitely not perfect! One of the things that I'm enjoying the most with this series is using libopencm3 instead of the STM32 Cube tools and STs HAL. Its a breath of fresh air!
I really don't like the official HAL, so this quick look at open-cm was kinda interesting.
I always use `goto` and a label instead of `while` for my main loops... just to be "edgy" ;)
When it's a while(true) loop, it will generate the exact same code, so why not haha
libopencm3 won't compile on window. Error with the nvic.h linker line 63: from the make file. Did anyone have a work around this since the include Header file is dynamic link
getting same ERROR
Hello, what VS Code theme do you use? :D
I really enjoy this series! I decided to try to follow along with my own STM32 board.
I did everything that was required in the README on github. I even "scrolled" back to the initial commit.
I had a lot of trouble installing gcc and make for some reason on windows. After a couple hours arguning with chatgpt I got it to work.
My questions are now:
1) How did you come up with all those files that you already had at the start of this video?
2) What do I have to do to use my own STM32, because I have a different one (STM32L432KC)?
3) In 'c_cpp_properties.json' i changed the compilerPath to my path as vscode threw me an warning (current: "/program files (x86)/Arm GNU Toolchain arm-none-eabi/12.2 mpacbti-rel1/bin/arm-none-eabi-gcc"). Is that correct?
4) vscode is presenting 5 errors in 'firmware.c': identifier 'rcc_hsi_configs', 'RCC_CLOCK_3V3_84MHZ', 'RCC_GPIOA', 2x 'uint32_t' are undefined". Does this happen because I use a different controller or am I missing libraries? Shouldn't a uint32_t be defined out of the box, I mean.. it's just another type?
5) How do I program the mcu using the on-board stlink? Drivers are already installed. Asking more about the steps I have to do in vscode.
I recognise those are questions that might require some time to awnser properly so a pointer* to a good resource is also very much appreciated.
Got great help on discord!
I have a bluepill board, can the code adapt to it?
Why not *void* main (void), since there is not even anywhere to the return value to go to?
It's possible!
You got VS Code IntelliSense working with Linux, GCC and libopencm3?
Yep. The .vscode directory in the repository contains all the configuration you need
I installed the repository but am getting this error ffor the app:
# Build the main application firmware
cd app
make
$ make
src/bootloader.S: Assembler messages:
src/bootloader.S:3: Error: file not found: ../bootloader/bootloader.bin
make: *** [Makefile:171: src/bootloader.o] Error 1
Hi, same problem here! You might have already solved it yourself, but here’s what I did:
Under the `bare-metal-series` folder, first `cd bootloader` and run `make`. Then, navigate to the `app` folder and run `make` again.
This worked for me.
Experienced Asm developer writing first simple C program: "Ha! I understand every line, it's so simple and convenient"
Experienced Asm developer rage quits after not being able to set up a toolchain for 3 days and writes program in binary
Linux users: *troll face*
Setting up tooling is pain, I totally agree. You can trade convenience for insanity if you're willing to step over to something like Docker, but it's not for everyone.
Can I ask why just installing the arm gcc tools didn't work? Or was this make related? Are you using Windows, mac, or Linux?
I guess youtube did delete my reply for some reason :( So in short, I had set everything on Windows + MinGW, couldn't get debug to start, discarded all, installed on Linux in vm, debug still won't start. After troubleshooting it turned out gdb only works with python 3.8. I still don't understand why, at least got it running.
And massive thank you for the series! Love your detailed explanation. Not having a "magical intermediate" is the best way to go
i am facing issue with running make on the firmware.c file. I get the error make: *** No rule to make target 'firmware.elf', needed by 'elf'. Stop. Someone please help.
Did you clone the repository? Are you on the right commit for this episode?
@@LowByteProductions yes sir. I cloned it as is, didn't alter any of the makefiles and only removed the additional files and folders to replicate the folder structure that you had in the blinky video. Also the file is named firmware.c in my directory as well. and on the current commit.
Well the makefiles changed a fair bit throughout the series, so it makes sense that it might not work outright. You'll find it easier I think to check out the commit associated with the first episode instead, and try to get that running. From there you'll be able to follow along with the seri3s making your own changes 🙂
@@LowByteProductions thank you sir i will try that.
@@LowByteProductions This solution worked sir. Thank you. But now i am facing a different issue in the PWM video related to a core lockup. How may i proceed from here?
If the main function will never return, why not just make it a void function? void main(), then you don't need to include the return statement at all 🤷♂
Where can I get the initial repository without any code to start following the series ?
Or I am supposed to go back to the first commit?
Yeah the easiest way is to step through the commits. You can use `git log --oneline` to get the hashes of each episode, and `git checkout `
@@LowByteProductions Thanks
You configured the type of the pin but not level. While it doesn't matter for this example, in the real world, not initializing the pin level, you can cause problems later on. You can put the device driven by the pin into a funny/undefined state which can be hard to identify. Best to set pin level if it's going to be and output and if it's an input, set the initial level with the pullup/pulldown function. Even better is an external resistor as this ensures desired level as the system powers up. I had a SPI device that would partially clock data into itself. Later writes to the chip were all shifted making quite the problem.
When can we expect the next video 🙂
Next week
Does anyone know if this will work for an stm32f401?
This is an stm32f401, so yes 😄
@@LowByteProductions Then apologies for my dumb question, i missed it in the intro, but see it's even mentioned in the description.. Thank you!
No worries, there are no dumb questions! Enjoy the series and let me know if you have any more
Its a pity you have decided not to provide more information on how to set up our environment to match yours. What OS are you using? It has been an exercise in frustration trying to get libopencm3 make, VSCode and git to work as smoothly as you show, and totally detracts from the value of your course.
It's not a course, it's a TH-cam video.
Totally agreeing with you were you able to set it up could you please help
2:12 makefile
i like the bare metal idea but.... you have a list of needed installs that doesn't include the environment your showing or how to get where you are. This makes it harder to follow you. Please consider adding an episode or a link detailing these crucial first steps, showing how to set up the system you are running so we all start on the same page.
It's a fair point, but also a decision that I made consciously not to try to show getting to this environment. At the end of the day, there are 3 major operating systems, and even those 3 are fractured into various versions, distros, releases etc. There is simply a combinatorial problem here, and no matter how hard I try to cover every possible case, someone will come with a particular flavour that I haven't, and will want answers. Unfortunately I just don't have the time to support all of that, so getting the tools installed is left to the viewer. Fortunately though, the readme of the project does include all the things you need to get going, as well as an editor configuration for vscode that covers debugging for a jlink and st-link. Please give those materials a look first. If you can't get up and running I'm happy to try help in the discord server
@@LowByteProductionsWhile I agree of the plethora of target systems, I'm just talking about your system. If it's linux Windows, MacOS, doesn't matter. Just document your system setup. Going down the rabit hole of setting up Make, installing GCC etc really detracts from the goal of programming the micro.
Anyone give vscode settings for ST LINK
It's in the Repo, check the description
Thanks I noticed it.@@LowByteProductions
it could be better if you use vi editor then vs code
Use whatever editor you feel comfortable with 👍
When I run make I get the following errors. Seems the Makefile isn't finding something.
make[1]: arm-none-eabi-gcc: No such file or directory
make[1]: *** [../Makefile.include:41: can.o] Error 127
Failure building: lib/efm32/ezr32wg: code: 2
Failure building: lib/efm32/g: code: 2
Failure building: lib/efm32/gg: code: 2
Seems like the arm gcc tool chain is not properly set up. If you have installed it, make sure it's in your path.
@@LowByteProductions Thanks. I installed Arm GNU Toolchain to the root of Msys2 and used this path.
export PATH="$PATH:/Arm GNU Toolchain arm-none-eabi/bin/"
cd libopencm3
make
...
Hi! I've set up my c_cpp_properties doc, and everything else seems right (I'm doing this on windows btw), but I get
libopencm3/stm32/rcc.h: No such file or directory
when I try and compile, any idea why? I've been scratching my head over this for ages, if I do this from the command line though, I do seem to get further
arm-none-eabi-gcc -I ./libopencm3/include -D STM32F4 firmware.c
But it's weird vscode throws this error, any pointers?
process_begin: CreateProcess(NULL, printf " GENHDR stm32/f0
;", ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [Makefile:63: include/libopencm3/stm32/f0/nvic.h] Error 2
Any Idea to deal with this ERROR !
If you're building on windows, you probably need to convert the line endings
Hey,
I'm trying to compile libopencm3 and getting the following error, tried to solve it, searched google, no luck. maybe you can asssist:
PS C:\Users\Arie\Desktop\Embedded Dev Courses\Low Bite Productions\bare-metal-series\libopencm3> make
process_begin: CreateProcess(NULL, printf " GENHDR stm32/f0
;", ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [Makefile:63: include/libopencm3/stm32/f0/nvic.h] Error 2
Have the same exact problem idk why. I have all the tools installed what I believe is correctly.
Did you manage to solve this? I get the same error.