Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Quadcopter Programming Part 2: Using the CMSIS Library and First Takeoff

timakro.de

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Quadcopter Programming Part 2: Using the CMSIS Library and First Takeoff

#11

Post by myself248 »

sgtnoodle wrote: post #7

The article's Delay function unfortunately has a rollover bug. If the counter rolls over in the middle of a delay, the delay will return early. It's a nefarious bug because it only occurs every 50 days, and only if the program is delaying. Also, while it's probably ok in this usage since it's a 32-bit cpu, it would be better to use atomic access intrinsics or a critical section and memory barriers rather than volatil…

Not saying this isn't a real bug (it definitely is!), but most quadcopters aren't powered on for 50 minutes at a time, let alone 50 days. Unlikely to make anything actually fall out of the sky.

Re: Quadcopter Programming Part 2: Using the CMSIS Library and First Takeoff

#12

Post by timakro »

JoshMcguigan wrote: post #10

I found quadcopters to be a great way to get into embedded development. There are a couple posts on my blog [0] [1] related to getting Rust running on a quadcopter controller, although I never actually got my code controlling the drone in flight. The lesson I learned was that if I was going to do it again I'd definitely choose a board with an exposed debugger port, as I spent a lot of time repurposing one of the moto…

SWD is purposefully exposed on that board and instead of flashing via the bootloader I got flashing with gdb via SWD with the `load` command working. I just use a male header with some jumper wires for the connection. It seems stable enough. Some pictures of the debug port here:

https://files.timakro.de/IMG_20191201_142259.jpg

https://files.timakro.de/IMG_20191201_142246.jpg

Re: Quadcopter Programming Part 2: Using the CMSIS Library and First Takeoff

#13

Post by roland35 »

prudhvis wrote: post #4

I thought, the Peripheral library is deprecated for STM32. Is there any reason to use it besides the STM32 CUBE framework?. Because, the later seems to support more STM32 product lines.

Stm32 cube mx is the newest version of the framework, but the old peripheral driver library is a bit simpler and easier to use! It is more low level and a light layer over the hardware.

The new cube library can be more complex.

Re: Quadcopter Programming Part 2: Using the CMSIS Library and First Takeoff

#14

Post by leggomylibro »

hexo wrote: post #8

CMSIS is the most bizarre API i've ever seen. This kind of mixing ALLCAPS_WithUnderscores_AndCamelCase is like criminal. Also _Min_Heap_Size. And that is the reason i would never use it and i've always looked for alternatives. Now i've ended up using Ivory/Tower eDSL framework where just about everything is equally complicated - as building a spaceshuttle.

On the bright side, the core CMSIS headers should work with all ARM Cortex-M cores, so you don't get locked into one vendor's HAL to do things like setup interrupts or interact with registers that are common to ARM cores. It also has something approaching first-party support with a permissive license.

I think that the ALLCAPS parts come from acronyms in most cases. Like, NVIC = Nested Vector Interrupt Controller. The naming can get a little bit confusing, but it seems fairly consistent.

Re: Quadcopter Programming Part 2: Using the CMSIS Library and First Takeoff

#15

Post by leggomylibro »

roland35 wrote: post #13
prudhvis wrote: post #4

I thought, the Peripheral library is deprecated for STM32. Is there any reason to use it besides the STM32 CUBE framework?. Because, the later seems to support more STM32 product lines.

Stm32 cube mx is the newest version of the framework, but the old peripheral driver library is a bit simpler and easier to use! It is more low level and a light layer over the hardware. The new cube library can be more complex.

The new cube libraries do include two abstraction layers, though. I agree that the "HAL" libraries can be very confusing because they try to do everything for you with endlessly nesting functions and macros, but the "LL" (Low-Level) ones are closer to the old peripheral driver libraries.

Re: Quadcopter Programming Part 2: Using the CMSIS Library and First Takeoff

#16

Post by roland35 »

sgtnoodle wrote: post #7

The article's Delay function unfortunately has a rollover bug. If the counter rolls over in the middle of a delay, the delay will return early. It's a nefarious bug because it only occurs every 50 days, and only if the program is delaying. Also, while it's probably ok in this usage since it's a 32-bit cpu, it would be better to use atomic access intrinsics or a critical section and memory barriers rather than volatil…

This is a good point, although the author notes in the article that the battery will only last a few minutes you never know if this code might get copied into a different project!

What I would do in this particular case is make a note of the limitations in the function block comment. There are always trade-offs in embedded code so I think it is fair to say that yes this code does not handle rollover, FYI.

Re: Quadcopter Programming Part 2: Using the CMSIS Library and First Takeoff

#17

Post by emilfihlman »

sgtnoodle wrote: post #7

The article's Delay function unfortunately has a rollover bug. If the counter rolls over in the middle of a delay, the delay will return early. It's a nefarious bug because it only occurs every 50 days, and only if the program is delaying. Also, while it's probably ok in this usage since it's a 32-bit cpu, it would be better to use atomic access intrinsics or a critical section and memory barriers rather than volatil…

>Also, while it's probably ok in this usage since it's a 32-bit cpu, it would be better to use atomic access intrinsics or a critical section and memory barriers rather than volatile to make the counter variable "ISR safe".

The dislike for volatile coming from people in higher systems is pretty tiring and unwarranted.

Volatile is a perfectly fine tool on low level mcus.

Re: Quadcopter Programming Part 2: Using the CMSIS Library and First Takeoff

#19

Post by fhars »

emilfihlman wrote: post #17
sgtnoodle wrote: post #7

The article's Delay function unfortunately has a rollover bug. If the counter rolls over in the middle of a delay, the delay will return early. It's a nefarious bug because it only occurs every 50 days, and only if the program is delaying. Also, while it's probably ok in this usage since it's a 32-bit cpu, it would be better to use atomic access intrinsics or a critical section and memory barriers rather than volatil…

>Also, while it's probably ok in this usage since it's a 32-bit cpu, it would be better to use atomic access intrinsics or a critical section and memory barriers rather than volatile to make the counter variable "ISR safe". The dislike for volatile coming from people in higher systems is pretty tiring and unwarranted. Volatile is a perfectly fine tool on low level mcus.

No, it is not, it will just work most of the time in low level MCUs because compilers support this abuse for lack of clearly better options. C and C++ have no support whatsoever for dealing with interrupts: volatile does not introduce any memory fences, atomics are for sharing data between threads which you do not have in many embedded systems, and sig_atomic_t is only defined for situations where you have a posix-like runtime environment. So sharing data between an ISR and the main program is undefined in C, and the compilers are free to compile „volatile“ the way most people expect, but the language does not guarantee that it works.

It can be argued that the only kind of variable that can be shared safely between an ISR and the rest of the code is a volatile sig_atomic_t, but that is an argument from analogy and not from first principles, as the C abstract machine has no concept of ISR. The same goes for the argument that you should use atomic intrinsics, plausible, but still just an analogy.

(Just in case anyone was wondering if C as a language is close to the metal: no, it is not.)

Post reply on HN