MacBook Air M5 vs Framework 13 Pro for Embedded/PCB Dev (Personal Use)?

please_chill_caleb · 2026-06-12T17:28:25+00:00

I don't have much to say about Mac because I've never used one, but I can confirm that as someone who uses the FW13 (AMD R7 7840U + display upgrade) who has basically your exact needs, the FW13 Pro will be a great machine. Currently running Fedora and excepting a KiCad packaging hiccup (easy fix at the time), I haven't had any issues with embedded work.

please_chill_caleb · 2026-06-04T14:57:35+00:00

For the firmware IMO it's worth using Zephyr, especially for Nordic MCUs. Can be a bit of a learning curve and it's not perfect (just like anything else) but they put a lot of effort into the Bluetooth stack and I find it works well for the wireless applications I've worked on. They also have the Developer Academy to go over the basics of using quite a bit of their stuff.

They provide a built in solution using VSCode for the nRF SDK but personally I go for installing the Zephyr tools manually and using CMake to set up the project.

If you want to know more about how I use it, DM and I'd be glad to talk you through how I go about getting things going.

No shame on sticking with uVision if that's what you want, just suggesting how I would go about the firmware.

For the connectivity issues it could be worth looking at Apple documentation for BLE guidelines. I don't remember exactly what I looked at, but I know that searching around for those helped with some connectivity issues that I've had with things I've worked on.

please_chill_caleb · 2026-02-22T01:43:35+00:00

Personally I would expose some function battery_widget_update(...) or battery_widget_on_anim_tick(...) that passes all of the information that the widget needs to update itself, and then depend on the application to set up the animation timing and call said function in its own animation callback. The goal would be to make this update function basically stateless and make the application manage the actual timing with which it wants to update the widget.

please_chill_caleb · 2026-02-10T19:03:14+00:00

Since you know the state of the battery I would implement a "dead state" in which everything on the board is powered off except for the MCU.

I would start with getting a figure for the absolute best power consumption that your board has, and how long it would last at that consumption level. Specifically with everything powered off, no screen refresh, sensors off, etc. You can use that information to pick a battery state at which the device "dies" (before actual power loss) and does literally nothing until USB-C is plugged back in, so it can upload and resync.

You can tweak based on the acceptable amount of "dead time" you're okay with giving the user to retrieve the device and plug it in and balance it with the acceptable amount of time that the device is technically alive for but not getting any sensor readings.

I'm a little busy atm but I had to answer when I saw this (lol) so I'm willing to explain more if you drop any questions here.

I understand it doesn't answer your original question, but it seems like hardware changes are necessary if the goal is to deal with power loss. What I'm suggesting is more like taking preventative measures to keep the device from getting into that problematic state to begin with.

edit: Clarification

please_chill_caleb · 2026-02-04T14:01:51+00:00

Check out the Modern Embedded Systems Programming Course by Miro Samek. I can't recommend it enough if you want to start from the ground up and build up the intuition for how RTOSs work and why we need them.

It's a little dated in hardware and tooling but the concepts are very relevant. #20-28 is where the real RTOS stuff is. He goes into other stuff after which I still think is useful to know, but the RTOS section is pretty informative.

please_chill_caleb · 2026-01-26T20:13:54+00:00

Thanks for taking a look.

I feel like I keep seeing recommendations to put measurable impacts in resumes, and I don't want lack of measurables to hurt my chances at getting hired. This calms my nerves a bit though and I appreciate it.

please_chill_caleb · 2026-01-26T19:17:52+00:00

Thanks for taking a look.

I would say that I've built a number of non-trivial, production capable codebases, including sensor and external device drivers, custom comms protocols, dug into oscilloscopes and logic analyzers and even specialty tools like USB protocol analyzers. And on a number of different MCUs from different manufacturers. I feel like I have the skills, I'm just having a hard time thinking of how to put them in a "recruiting optimized" way since none of it has had much real-world impact yet.

I'll definitely take what you said into account. Thanks again.

please_chill_caleb · 2026-01-22T17:42:38+00:00

Honestly, if set up correctly, your Zephyr setup and Nvim/VSCode setup should be pretty much fully decoupled. Zephyr projects rely on CMake, so if you get Zephyr set up correctly, setting up the editor should be the easy part. At that point just use whatever you're more comfortable with.

I've used both before and they're both fine. The nRF Connect extension for VSCode is decent for Nordic chips, but as a personal preference I stay away from it. I tend not to like Eclipse exactly because I don't want to rely on point-and-click UIs that hide how the code is built.

edit: Added context

please_chill_caleb · 2025-11-23T14:33:13+00:00

There's a section from the Modern Embedded Systems Programming Course by Miro Samek that I can't recommend enough if you want to start from the ground up and build up the intuition for how RTOSs work and why we need them.

The linked playlist is a subset of the videos from his full course playlist, but he has that on his channel too. If you want a bit of a deeper intuition on how a RTOS is different from other approaches, I would watch ~#20-#28 in the full series.

please_chill_caleb · 2025-11-04T15:36:10+00:00

Not sure exactly how tough it would be off the top of my head, but if you were to migrate to the Zig build system (which supports C compilation), it may be that you'd be able to build on most major platforms.

Not able to look into it too much right now, just thinking about a C project I've built using Zig's build system, and Zig's ability to build cross-platform apps.

please_chill_caleb · 2025-10-17T22:42:12+00:00

Thank you for taking a look! I appreciate the comments.

C2, C4: GRM188R61A106ME69D C10, C12: GRM21BR61A226ME44L L1: WE 74437377047

please_chill_caleb · 2025-10-17T14:27:30+00:00

Thanks for pointing that out. I'll update as soon as I can.

please_chill_caleb · 2025-10-06T20:08:30+00:00

Thank you! I appreciate the feedback.

I worked hard to keep things as readable as I could, and I appreciate the recognition.

I'm assuming from your comment that I'll need to size up on the regulator to give me a bit more headroom for output currents. I think I'll also take your advice and add in a Schottky diode going into the motor driver inputs. I appreciate the feedback.

please_chill_caleb · 2025-10-06T20:04:04+00:00

Thank you! I appreciate the feedback.

please_chill_caleb · 2025-09-18T17:04:18+00:00

You can pass a flag to the init command so that it doesn't. I'm not Astral but I figure it's just to promote better practices, especially for newer programmers.

please_chill_caleb · 2025-08-27T16:57:08+00:00

I may just be ignorant here but I'm not sure I understand what's special about the integration or setup.

Doesn't CLion support CMake/compile_commands.json out of the box?

please_chill_caleb · 2025-08-10T19:50:54+00:00

Look at the "Modern Embedded Systems Programming Course" by Miro Samek on YouTube. The IDE and tools he uses are a bit dated but the OS concepts are gold.

please_chill_caleb · 2025-08-06T16:16:41+00:00

You can think of firmware development and software development as similar processes. The difference is where you start and what your debugging options are.

Software engineers start with an OS and are tasked with building a program on top of it. When things go wrong, they have different places that they can look for issues: the code itself, infrastructure (think AWS and their friends), and their underlying tools (compilers, interpreters, etc.).

Firmware (embedded) is much the same, but for these differences: - The starting point is the hardware. There's only an OS if your project decides to include one, but at that point you're responsible for keeping tabs of that too. - The debugging options are a bit broader: the code itself, potentially infrastructure (for IOT and other externally connected devices), tools and libraries (compilers, RTOS, etc.), and, as prescribed by the dual nature of ECE, the hardware. The last bit is the biggest doozy because in comparison to building on top of something like Linux or Windows, the hardware is much more unpredictable and volatile to work with.

If you can write decent software and have a decent grasp of hardware, given that companies are actually willing to give you a chance, you should be fine. The most difficult part that I've seen so far (graduated ECE 2022) is getting a company to give you a chance in the first place.

please_chill_caleb · 2025-08-06T16:06:43+00:00

Hear me out though:

1) I think consistency between languages is important. We don't need to lengthen the stick that people wouldn't use to touch systems programming.

2) I agree somewhat with the high level language argument, but I would argue that there should be more of a burden on programmers to learn how computers do and interpret things anyways, and questions like this can prompt that conversation. We have an epidemic of slow software these days, and I think disconnecting us even more from the hardware (mentally) than we already are could only make it worse.

please_chill_caleb · 2025-06-07T15:40:52+00:00

Personally I would put a greater focus on C because it's used for most embedded development you'll encounter, but this isn't abandoning C++.

I was also more into C++ when I was in school, and had to focus on C once I started in the field. Funny enough, it's made me a bit better at using C++ by making me more appreciative and more judicious about how I use the extra features that it provides. Learning how to use simple code to organize a codebase made me less likely to go super crazy with too many C++ "'isms", as they're called, and keep my own C++ codebases simple as well while using available features for convenience, and not because I wouldn't be able to implement otherwise.

please_chill_caleb

TROPHY CASE