Is M1 Macbook pro a good choice if I want to use Rust to do embedded development?

Alright, I missed that, however now they do have a site with macOS binaries, which you can access from elsewhere too, you don't need to go through blog posts that you find questionable. I do agree that specifically M1 Macs aren't well-supported yet, though.

1 Like

How many USB ports does it have? In Embedded dev is used a lot of them

2 type-c s on regular m1 however you can always use a hub

This is the link you were looking for: Arm GNU Toolchain

So, in my day job I'm working on a Rust project that is deployed to both X86 and Arm based embedded hosts. And by night (on those rare occasions I get the time) I'm working on AVR embedded Rust projects.

I would say there are two reasons I would recommend against the M1 laptop - and, for avoidance of doubt, I'm writing this from my M1 Macbook Air :slight_smile: - if it is going to be your only development machine. If you also have another desktop X86 based machine you can offload tasks to when needed, the M1 makes an awesome client machine, that's how I use it.

The reasons against:

  1. Docker is a mess on the M1 at the moment. Performance is terrible, and it is buggy as hell, with containers randomly crashing. I can get rustc in a docker container to reliably crash with SIGSEGV - Invalid Memory Access without even trying. Now you don't need Docker for simple cross compiling, and Rust is great for simple cross compiling, but as soon as you find yourself needing to link in native libraries that are only available on the destination platform etc. suddenly you'll discover that Docker makes things so, so much easier, so I think for 'soft' embedded (e.g. Arm) Docker is far from overkill, it's a lifesaver.

  2. For 'harder' embedded (e.g. AVR microcontrollers) - well, Rust isn't a great choice for that right now anyway, but if you're doing it anyway and taking the risk, you will nevertheless discover that an awful lot of the tooling you need to deal with proprietary programmers, ICEs, debuggers etc. is only available for Linux or in egregious cases Windows, and the ability to spin up a VM running one of those OSes is a lifesaver. The M1 makes your life a lot harder here.

I love my Macbook Air dearly, and have no regrets - but that's because I have access to other machines that I can offload to when I run into something the M1 isn't good for. If I was going to use it as my only machine though, right now, for embedded - well, I just wouldn't.

3 Likes

Thanks, yes, M1 is still not fully ready for programmers. Maybe revisit M2 or later~lol

On topic: I've heard great things about the M1, but embedded Rust builds just fine on my $400 Lenovo IdeaPad 330s-15ARR Ryzen 5 2500U. My current project is targeting STM32F727ZI.

I believe the correct toolchain for STM32Fxxx is thumbv7em-none-eabihf. The "hf" suffix is for hard float, i.e. FPU support.

I jumped on the Apple hardware wagon back in 2011 with a 17" Macbook Pro core i7 quad -- top of the line at the time -- paid about $2700 retail. It was fabulous until the GPU melted its solder balls. I migrated to a refurb 15" MBP to keep going, but NEVER AGAIN.

Prior to and since then, my platform of choice was and is Linux. If embedded tools happen to require Windows, then I either dual boot or use VMware.

You should try Multipass, it allows you to use any version of Ubuntu from the command line and mount your folders from your laptop. Works for me on my x86 macbook pro, will be trying the m1 version in a few days...

I have a first-generation M1 MacBook Air. Depending on what I'm doing, it's anywhere from 75-150% as fast as my similar-age 300W Linux workstation, and has a charger only rated to 30W, which still blows my mind. (Granted, most of the workstation's power consumption is in its GPU, but still.)

I do some "hard" embedded work, mainly targeting 65xx/ARM/RISC-V. I also do "softer" cross-compilation quite a bit. I've never used Docker for anything in my life (let alone cross-compiling). For me, for everything but 65xx, crosstool-ng is an essential tool for cross development. It takes care of all the issues relating to building a specific toolchain for a specific target, including linker, debugger, libraries. With its help, my Rust cross-development experience has been a breeze.

...so the fact that crosstool-ng doesn't seem to be working on ARM macOS at the moment is a big obstacle for me. D:

(also, my stomach for technical issues might be greater than the norm, since historically my cross-compilation pipeline has included Linux-to-macOS...)

If you are going to work on a large code base and your work involves compiling for different targets and/or a bit more complex build processes, you may feel significant drop in performance. In some of these scenarios, it's likely that under the hood Apple Rosetta 2 has been hired to address a compatibility issue but as a side effect it may slow down the system.
My most down moment with M1 was when a dockerized code builder failed and the developers of that project didn't even bother to try to fix it for M1!
Comparing to the last year's Intel Core i9 based macbook pro, it feels slower to me which is a shame. However as it is with Apple products, you'd still enjoy the design and interactions and it is improved over the previous models.

But one is a laptop which is portable and stays cool. Other sits on a desk with big power unit.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.