This is is so far by far the best series about embedded programming on STM32. I'm using a "blue pill" and there are many things that need to be adjusted for it to work - The series allows enough information to allow me to figure out the correct values to use on a blue pill (a bit guessing here and there, but that's the best way to learn). I really like the explanations of how the values are figured out. I was looking for something like this as I'm too annoyed at the normal CubeIDE's amount of dead code and million comments that make it annoying to navigate and understand Thank you!

really love this series. help me recall what i learned in school with better and more detailed real development

Huge Respect for you from INDIA , such Indepth explanation i never seen before so ,i am thankful to you for bringing and sharing your knowledge and experience to all of us to electronics and Embedded community ,looking forward for your next series in BARE METAL SERIES 😊

Excellent way of teaching.

brilliant, thanks ever so much for sharing your knowledge.

Hi, really enjoying the series (I'm beyond this one but I think my comment is more appropriate on this vid) I would be really interested in some more in-depth tutorials on timers. Specifically I'd like to understand how to set up a GPIO as a frequency or pulse counter. It might also be interesting to have something on driving addressable LEDs. Just a thought, keep up the great work.

wooo keep it up, this is great content :)

CORRECTION REQUEST. I like your project! I am currently catching up by binge watching. And this is a CORRECTION REQUEST to make it even better. First: I like to hear this content from your perspective. Most of what you show is repetition for me, but I know it mostly from datasheet and sometimes tedious googeling, therefore getting it feed by you with a spoon is very comfortable :-). Second, the correction: your diagram of the pwm signals should always start with the Pulse (HI). Especially when you show the 'stair' diagram. because the threshold value is proportional to the (positive) pulse width. In your diagram, it is proportional to the pause width.

Your QOI series were amazing. Will you also look into the QOA for audio? The specification is just around the corner!

@LowByteProductions

Жыл бұрын

Thanks Dimitri. I've only followed the QOA spec a little but it's definitely exciting. When it's finalised I'd definitely be interested in taking a crack at it.

PWM is what gives modern day computers their unicorn vomit :) As well as being able to control the fans in a case.

Thanks for the video. A question: If we're setting TIM2 at 1000 khz - that means, the pin PA5 receives a signal (which lasts for a certain time - duty cycle) at 1000 khz intervals. But in main, we're incrementing the duty cycle by 1% at 10 khz interval, which reaches 100% at 1000 khz (100 loop iteration * 10 khz). Since TIM2 drives pin PA5 only at 1000 khz intervals, does the increment of 1% in the main_loop have any effect? We should expect to see just a normal led on & off at 100% duty cycle right? But in the video, we could indeed see a gradient led output, but can't understand the code. What's wrong with the understanding? Maybe the next video clears things up

j link > stlink

Int stands for internal or at least it does in most contexts and i highly doubt it stands for integer

the best channel on youtube!

quick question: how do we make the "64-bit time" "thread-safe"? or is there any way we can guarantee the value we get is intact? My thought is to keep reading the value three times: 1. upper 32 bits, 2. lower 32bits, 3. upper 32 bits again. If the value read from step 3 and 1 are not same, read again. but it may stuck in the loop forever

@LowByteProductions

10 ай бұрын

The safest way is to mask interrupts before reading or writing the ticks value

@bowenliu6911

10 ай бұрын

a follow up question: what if we need to read a 64bit register would on a 32bit system? do we need to disable all the interrupts? @@LowByteProductions

Hoping for AVR assembly project tutorials.

@LowByteProductions

9 ай бұрын

You never know 😁

Core locked up: I am using a STM32 Discovery board with a F407 chip. I am able to flash the code onto the MCU but it is not being executed. Earlier it was working fine with systick but when i powered it on yesterday, the blue led (which i configured to blink) was not blinking. I was using st-flash on CLI for this. I installed STM32CubeProgrammer, which after flashing the code, tells me that the core is locked up. Can someone please guide me on what to do? Edit: i tried flashing the same code onto a nucleo board with f411re and the core immediately locked up as well.

@LowByteProductions

Ай бұрын

Did you change the makefile to reflect that you're using a different chip? You'll also need to change the linkerscripts to reflect the memory layout of these chips.

@harinayan7879

Ай бұрын

@@LowByteProductions no sir I didn't make any changes in the make file or the linker scripts. I am using a stm32f407 processor so I assumed I need not make any changes. This was working all right upto systick and was working as intended. Later for some reason it didn't work. Also, I am using stlink-tools to flash from the cli. I tried using the STMCubeIDE on windows and this works fine. However this has STM's implementation of HAL and it is on windows not Linux so I don't want to use the IDE. It was working earlier and all of a sudden stopped working. What changes do I have to make in the linker and the makefile sir?

@harinayan7879

Ай бұрын

@@LowByteProductions okay so I tried something. In Linux, I cloned the libopencm3 examples repo and built a blink project. I tried to flash this code onto the processor, flash was successful but didn't execute as core locked up. Then I tried uploading the code using stm cube progmmer, which also locked the core. Then, I mailed myself this file and then in windows, I used the cubeprogrammer to flash the same code onto the processor, which again resulted in a lockout. Then I wrote the same code using stm32 HAL in their official IDE, and it worked. So here are my assumptions and my guess as to what might be the issue: 1) libopemcm3 works for F4 processor 2) this problem is clearly not dependent on the OS as the issue persisits on Linux and windows. 3) It is independent of the flashing tools (stlink-tools) or the the official programmer. 4) HW works as there is no issue running the stm32's official HAL. 5) on Linux, the project is built and the .binary and .elf is made So my guess is that this is mostly a compiler on Linux issue. If I am wrong please correct me and let me know how to proceed sir.

@harinayan7879

Ай бұрын

@@LowByteProductions I fixed it sir. I had installed a software used for programming FPGAs. The software Targeted a ARM cortex processor on the FPGA board and used C as the programming language. When I installed it, it also installed a C compiler for ARM processor on this board that has the exact same name as the one I installed at the beginning of your series here (arm-none-eabi-gcc). Now the problem was that the path to this compiler was put ahead of the /usr/bin in the environment variables. Consequently, when the make file in my project built the project, it used the ARM compiler of the FPGA rather than the ARM complier I installed for the STM32. The executables generated now were for the ARM chip on the FPGA, and when I uploaded it onto the STM32, it incorrectly initialised the clock and other peripherals, causing the core lock up. To fix this I simply changed the path to the complier in the makefile so that it has the path to the correct compiler for the STM32 and everything works properly now.

@LowByteProductions

Ай бұрын

Awesome, glad you got it sorted!