Interrupt (Memfault)

For Cortex-M embedded topics, memfault's blog is simply one of the best out there. Consistently great posts even though they are written by a bunch of different authors. I go back to https://interrupt.memfault.com/blog/cortex-m-fault-debug all the time when debugging hard faults on different systems. Even if you regularly write embedded code for Cortex-M MCUs, scroll through their list of posts and you'll find several that will teach you something new and useful.

It’s primarily about the number of hours. At Pebble, we’d be able to get a pretty good gauge on battery life with about 10-20 devices and about 24 hours worth of data. We recorded the battery’s percentage drop over the course of each hour, averaged all samples together, and then used that to estimate how long the battery charge would last. This strategy is covered here: https://interrupt.memfault.com/blog/device-heartbeat-metrics#battery-l… Of course it’s better with thousands of devices, but we were always surprised how accurate it was (as long as we had a few Android users in the office - it reliably got worse battery life due to worse Bluetooth performance)

I like the monthly round up of articles here. https://interrupt.memfault.com/

This whole website is really great; it has been a fantastic resource for me. https://interrupt.memfault.com/blog/cortex-m-fault-debug in particular was really great.

In theory, Rust can completely replace C for AVR development. Based on what shepmaster said, certain Rust features may not work yet. I'm also a Rust newbie. This article is a great intro to Rust for microcontrollers (but it's for ARM Cortex): https://interrupt.memfault.com/blog/zero-to-main-rust-1

> Async Rust (by default) can allocate memory For bare-metal Rust firmware, you would always use no-std, which excludes a default allocator. I understand from what you're saying that the principal difference between embassy-rs and what you'd expect from an RTOS is the choice of scheduling; as far as I can see, embassy-rs'es cooperative scheduler is even defended as highly intended. The advantage of cooperative scheduling is that you don't need threads and context switching, since every yield gives control to the next task. And, as you say, the downside is that you can't reason about when yielding happens, so you can only hope that tasks yield often. > interrupt executor [...] essentially ties each task to a dedicated interrupt, and AFAICT requires that all high-priority work must happen in interrupt context. Hmm, that seems bad. And how so is RTIC disqualified? It seems not classically preemptive. https://rtic.rs/2/book/en/#rtic---the-past-current-and-future https://interrupt.memfault.com/blog/embedded-async-rust#cooperative-vs… https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown

Direct link: https://interrupt.memfault.com/blog/eoss-recap#engineering-secure-ssh-… > Colin (Garmin) goes through the challenges for enabling SSH access to devices in production. Passwords and secret keys are not great solutions: if you share one across all your devices then a leak would be catastrophic. And a leak is hard to protect against because the engineers need the keys with them when doing maintenance work. So instead, he recommends using certificates to create keys that are only valid for one hour or one day. The device SSH daemon validates that the engineer key has been signed by the proper certificate, and that we are still within the correct validity period. This way, the only real secret (the private key used to sign the keys) can be stored in a very safe storage, engineers are only granted access for a few hours (so an ex-employee will not have access anymore).

Here are some that I've been following why working on my newsletter (https://weeklyrobotics.com/). These will be mostly robotics oriented, and some of them might be inactive: * [Robots&Chisel](http://www.robotandchisel.com/blog/) - a blog by Michael Ferguson, he did a very nice series of posts on restoring a UBR-1 robot and implementing ROS-2 on it * [Mike Isted](https://mikeisted.wordpress.com/) - at one point Mike was writing quite many blog posts on making drones, including some offboard control and autonomy * [The Interrupt](https://interrupt.memfault.com/) - in-depth blog about embedded programming. Really like their monthly "What we've been reading..." series * [Electron Dust](https://www.electrondust.com/) - inactive, but a really cool series of blog post on making a ball bouncing robot * [Casey Handmer blog](https://caseyhandmer.wordpress.com/) - some very in-depth articles related to space * [Modicum of Fun](https://jpieper.com/) - a blog post of Josh Pieper, who makes mjbots open-source motor controller Other: * [Julia's Drawings](https://drawings.jvns.ca/) - neat presentation of various technical concepts in programming. Unfortunately it's not active anymore.

Blogs * https://www.cnx-software.com * https://hackaday.com * https://interrupt.memfault.com/blog/

Linux Coredumps (Part 2) － Shrinking the Core : https://interrupt.memfault.com/blog/linux-coredumps-part-2 Linux Coredumps (Part 3) － On Device Unwinding : https://interrupt.memfault.com/blog/linux-coredumps-part-3

> If I understand correctly, when an initializer is provided the padding bits are set to 0. https://interrupt.memfault.com/blog/c-struct-padding-initialization looks at this (albeit a bit outdated; clang 13 and GCC 11) and claims to see undefined values even when initializers are given, at higher optimization levels > Additionally, setting the whole chunk of memory to 0 w/ memset would work. This seems to be the only thing that can be relied on to work (… sadly) An alternate answer is: don't treat structs as chunks of bytes when the chunk crosses padding (i.e. create functions to hash specific structs) Another alternate answer: remove the padding and add "_pad12[34]" members instead. But then you need to figure out where you actually have padding, which is architecture dependent…

Embedded is a PIA, its not web development and shouldn't be treated as such. Printf isn't re-entrant, and they are calling it from multiple threads. There are solutions with trade offs: https://interrupt.memfault.com/blog/printf-on-embedded Everything in embedded is a tradeoff of space, performance, or cost. If you come at it as web development with IO you are going to have a very bad time.

this look at hw/sw breakpoints for arm stuff.. the int3 is a exception provided by the architecture, which coders leverage. so hence its not available on arm, but there's other breakpoint / debug functionality since arm devs also need to debug stuff :> happy hacking! https://interrupt.memfault.com/blog/cortex-m-breakpoints

It depends on what you call "ordinary Rust", I guess. You can use an allocator on embedded, but likely won't want to. There are static types that provide the same APIs as the allocating data structures you'd miss[1]. Granted, you're not gonna be able to take any random crate that isn't designed for such an environment, but that's a different problem, and there's a fledging ecosystem of no_std crates out there. Despite all those caveats, you can still write very high level code in embedded Rust, even async/await state machines![2] 1: https://docs.rust-embedded.org/book/collections/index.html 2: https://interrupt.memfault.com/blog/embedded-async-rust

I quit my job before I got to deploy this, but RAUC looked like it would handle this for Yocto: https://github.com/rauc/rauc https://github.com/rauc/meta-rauc For microcontrollers, Memfault had a good article: https://interrupt.memfault.com/blog/device-firmware-update-cookbook

The advantage is ease of use, semihosting is rather slow and has a big impact on system behaviour, as it uses a breakpoint and r0 to transfer a datapoint. It is definitely slower than SWO or RTT, which transfers data over SWD. You can find a detailed description here https://interrupt.memfault.com/blog/arm-semihosting

You're probably looking for something like this. Newlib is the libc in play here. Not exactly what you're asking for, but adjacent at least. https://interrupt.memfault.com/blog/memcpy-newlib-nano

Adding to other replies https://mcuoneclipse.com/2021/05/31/finding-memory-bugs-with-google-ad… https://interrupt.memfault.com/blog/ubsan-trap I've tested the UBSan, it worked with some limitations but helped me catch some old hidden bugs.

Also see the "From Zero to main()" series: https://interrupt.memfault.com/blog/zero-to-main-1

This would have been really useful for me about a year ago :). (although https://interrupt.memfault.com/blog/how-to-write-linker-scripts-for-fi… is pretty good too)). One thing I see not mentioned here is setting up a section specifically for debug functions you don't want to be dropped by the linker (functions you never call, except when abusing gdb as a repl for debugging).

This is part of the spec for ARM MCUs: the vector table starts at 0x0, and the first two words in it are the initial stack pointer and the entrypoint. We go into this in details (with references) in our earlier post: https://interrupt.memfault.com/blog/zero-to-main-1

GDB is happy to deal with separate debug info files from the executable code - and has been approximately "always", as far as I'm aware. But it's not particularly common / well-understood how to actually achieve it. Some info here on how to configure GDB to use it: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Separate-Debug-… The old-school way appears to be to extract the debug information from the binaries after compilation, then strip the binaries. As described here: https://stackoverflow.com/questions/866721/how-to-generate-gcc-debug-s… The new way is to use gcc's ability to generate split DWARF directly: https://interrupt.memfault.com/blog/dealing-with-large-symbol-files#sp… This will work with debuginfod but you don't have to have that running to use these - you can just supply the symbol directory when you want to debug.

Working with / compiling from source code (portable/non-portable): cosmopolitan libc[0] Each language kinda has own tricks,java[3], rust[4] From [1] : " A comparison of dietlibc, uclibc, musl, and glibc, by the author of musl: http://www.etalabs.net/compare_libcs.html " How to make smaller C and C++ binaries[7] Removing unused code[5] / Exploiting function similarity for code size reduction[6] ------- [0] : a) https://justine.lol/cosmopolitan/ b) size tricks : https://justine.lol/sizetricks/ [1] : Dietlibc - a libc optimized for small size : https://news.ycombinator.com/item?id=21291893 [2] : https://interrupt.memfault.com/blog/dealing-with-large-symbol-files [3] : java : https://www.graalvm.org/latest/reference-manual/native-image/guides/op… [4] minimizing rust : https://github.com/johnthagen/min-sized-rust [5] : https://tetzank.github.io/posts/removing-unused-code/ [6] : https://dl.acm.org/doi/10.1145/2666357.2597811 [7] : how to make smaller c and c++ binaries : https://news.ycombinator.com/item?id=35853625