fra

14 ms·

151.
by fra 7y ago
Edit: I see the msn link was chosen because of no paywall. I wonder if there is a way we can give a h/t to the LATimes as well for the fantastic reporting though. It would be nice to point at the source, rather than a repost on msn.com
152.
by fra 7y ago
One thing I didn’t mention in the article: we built a full emulated version of the watch at Pebble with QEMU and used it for the majority of our automated testing. We even allowed 3rd party devs to build apps against it. Today, I think we’d
153.
Cortex-M MCU Emulation with Renode(interrupt.memfault.com)
4 points by fra 7y ago|1 comments
154.
Tracking Firmware Code Size(interrupt.memfault.com)
10 points by fra 7y ago|3 comments
155.
by fra 7y ago
While CMake & Bazel are gaining in popularity, Make is still the de-facto standard for firmware projects. It certainly is miles better than some of the XML-based, GUI-first build systems IDEs bundled with Keil or IAR.
156.
A Shallow Dive into GNU Make(interrupt.memfault.com)
10 points by fra 7y ago|3 comments
157.
by fra 7y ago
You’re right, if it reproduces at your desk you’ve got some good tools at your disposal. Collecting enough state to fix them from a customer report is tricky, I would say.
158.
by fra 7y ago
Watchdogs are one of the more frustrating types of issues to debug. Chris's overview of how to implement them properly, and investigate resets is an amazing resource I wish I had earlier in my career.
159.
A Practical Guide to Watchdogs for Embedded Systems(interrupt.memfault.com)
104 points by fra 7y ago|29 comments
160.
by fra 7y ago
Many of us are homeowners. Speaking for myself, I simply believe affordable housing for all is more important than my property value.
161.
by fra 7y ago
Thanks! We've been writing all the content we wish had existed when we started out as embedded software engineers. It's fantastic to hear from folks who enjoy reading it as much as we do writing it.
162.
by fra 7y ago
They're all roughly equivalent. I would choose a cost effective one and move on. One thing to watch out for: i2c is not designed for long wires, so you may have signal integrity issues beyond a 1-2 feet. You'll want to switch to d
163.
by fra 7y ago
Cool! I've never seen this before.
164.
by fra 7y ago
Thanks for the kind words! I was up late last night writing this up, it's encouraging to see folks enjoy it.
165.
by fra 7y ago
No reason why you need to reset them individually ;-).
166.
by fra 7y ago
I've worked on server hardware with dozens of devices on a bus :-). Making sure addresses were programmable was a must indeed.
167.
by fra 7y ago
For what it's worth, here is a good doc on I2C resets: https://www.analog.com/media/en/technical-documentation/appl...
168.
by fra 7y ago
> No way to safely bring the bus back to idle from mid-transaction. [...] No safe, universal way to bring the bus from tristate, or low, to pulled-up. These are great points, and I'll add a note about them in the article. Thanks! &g
169.
by fra 7y ago
I think I2C and SPI have very different use cases. Over I2C, you can interact with 127 devices with just 2 pins. To do the same with SPI, you'd need 130 (4 + an additional CS for every device on the bus). You may think of the extra pin
170.
by fra 7y ago
Yes! I considered adding a bit about i2s, but since the article is already clocking at ~2500 words I thought I'd leave it to another time. I2S is everywhere in audio.
171.
I2C in a Nutshell(interrupt.memfault.com)
375 points by fra 7y ago|107 comments
172.
by fra 7y ago
I think one can both be excited about Rust and acknowledge that for most projects C is still the way to go. The libraries, communities, compilers, vendor support, ...etc. is much more mature on the C side of things and will remain that way
173.
by fra 7y ago
Ah, you're right! fixed.
174.
by fra 7y ago
Check out Tock: https://www.tockos.org/ . As far as I know it's the most complete effort out there.
175.
by fra 7y ago
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://inte
176.
From Zero to Main(): Bare Metal Rust(interrupt.memfault.com)
293 points by fra 7y ago|84 comments
177.
Reproducible Firmware Builds(interrupt.memfault.com)
4 points by fra 7y ago|0 comments
178.
by fra 7y ago
If there's anyone from the embedded community who's taking a stab at fixing rust for that use case, it's James. He's one of the three members of the Rust Embedded Working Group ( https://github.com/rust-em
179.
by fra 7y ago
He's super responsive on twitter: https://twitter.com/bitshiftmask
180.
How to Debug a HardFault on ARM Cortex-M(interrupt.memfault.com)
1 points by fra 7y ago|0 comments

More ›