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

1–10 of 20 posts

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

#3

Post by prudhvis »

sansnomme wrote: post #2

What does this line of code mean? *(volatile uint32_t *)0x40021018 = 0x00000004; Why is a pointer being created and dereferenced at the same time?

Thats memory mapped IO. Registers, and control registers are mapped onto certain regions of memory on ARM Coretx-M processors.

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

#5

Post by chli »

sansnomme wrote: post #2

What does this line of code mean? *(volatile uint32_t *)0x40021018 = 0x00000004; Why is a pointer being created and dereferenced at the same time?

It's how you access memory mapped registers in C. It's writing the value 0x04 at that address using a 32-bit memory write. There is a peripheral register at that location.

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

#6

Post by ahaferburg »

sansnomme wrote: post #2

What does this line of code mean? *(volatile uint32_t *)0x40021018 = 0x00000004; Why is a pointer being created and dereferenced at the same time?

You could split up the definition of the pointer and the dereferencing+assignment:

  volatile uint32_t* p = (volatile uint32_t *)0x40021018;
  *p = 0x00000004;

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

#7

Post by sgtnoodle »

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 volatile to make the counter variable "ISR safe".

Embedded code is a lot of fun, but if you want to safely work on the "really fun" stuff it's important to maintain a high level of quality and correctness for fundamental but lame utility functions like this. Otherwise you could literally build a ticking time bomb!

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

#8

Post by hexo »

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.

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

#10

Post by JoshMcguigan »

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 motor outputs into a serial transmit port just to do some "println debugging".

Not sure if OP is here, but I'd be interested in hearing about which debug options are easily exposed on that board. Can you use the port you are flashing the drone with as a standard serial port after your code is loaded? Looking forward to the future post about SWD that is introduced at the end of this post as well.

[0]: https://www.joshmcguigan.com/blog/betafpv-drone-flight-contr...

[1]: https://www.joshmcguigan.com/blog/betafpv-drone-flight-contr...

Post reply on HN