I am a newbie, thank you very much!
I am not an embedded developer but I am a rust developer who happens to use m1 and do a bunch of cross-compilation to x86 android and Linux as well as aarch64 android and ios.
My experience so far is pretty positive. The main point is to check the toolchain availability. So I guess in order to answer your question you need to check the target toolchains availability for the arm64 macOS host.
I'm sure plenty of people use laptops, but a laptop will never be as good as a high-core desktop. (You can technically get laptops with chips like 3950Xs, but in laptops they don't have enough cooling to run them at full power, so it's a waste -- they end up running in low-power 65W instead of "TDP" 105W, or more realistically I run it at about 200W at peak.)
1 Like
the thing with m1 is that it does not get hot. It is super-efficient. its like magic I was a desktop Linux user until m1 came along. Its truly unrealistic I have never seen anything like this before.
1 Like
That's great, but it tops out at 10 CPU cores, according to the website -- but that's 8 "performance cores" and 2 "efficiency cores". And I don't think it has hyperthreading? So being efficient is great, but if you're in a place where you can just plug it in and afford the extra power, 16C32T will give you faster parallelizable builds than the M1 chip.
EDIT: Since someone said benchmarks below, MacPro 3950X has 21890 for the multicore clang and MacBookPro M1 Max has 12335 for multicore clang. M1 is a good chip, but it's not magic.
2 Likes
please do check m1 max chip also there are plenty of benchmarks on internet
My MacBook Pro M1 is faster than any PC or laptop I have ever owned. It also runs on batteries far longer than any of my previous laptops. Oh, and it's smaller and lighter. That is close enough to magic for me 
If nothing else I would be loath to give up all that for the sake of a mere doubling of so in compilation speed.
Speaking of which, the Rust compiler is renowned for being on the slow side. However as one usually only does a cargo check rather than a full build when riffing on code that is hardly a concern.
So the remaining question is: Is there a compiler that runs on the M1 and generates code for the required embedded target?
So LarkyRust, what embedded targets do you have?
1 Like
Thanks. I am thinking about STM32F4 series dev board~
docker is awful experience on Mac.
I suggest to switch to a better OS once Linux is safely ported onto m1
Or just use cross-compilation tools without docker
1 Like
As far as I can tell you need a compiler for thumbv7m-none-eabi for the STM32 F4.
Have a look here: GitHub - aholzbaur/rust-stm32f4-disco-blinky: Small project example to be used as template for embedded software in Rust on the STM32F429-Discovery board.
Installing that Rust compiler for ARM does at least run on my Mac M1.
Thanks ZiCog, for testing this for me!
That might be premature. I only did:
$ rustup target add thumbv7m-none-eabi
$ rustc src/main.rs --target=thumbv7m-none-eabi
and found it did actually run. I have no idea what code it produces or manage to build a program.
I'd love to hear how you get on as I have an STM32 F4 board stashed away some place. And a Mac M1 of course !
For a laptop form factor, the M1 CPU is excellent and probably the best you can get.
However, macOS is not a good OS for this. Embedded development requires a lot of cross-compilation, and this tends to require Linux or at least Docker. Docker for Mac is clunky and slow, and Docker for M1 Macs is even worse.
2 Likes
In my experience cross compiling from anywhere to anywhere can be a pain to get working, although I also feel it can be easier from a Linux host.
Rather than blow MacOS away I would press an old Linux PC into use for builds and edit the code remotely.
No idea about Docker. Sounds like overkill for this to me.
I'd bee interested to see if Rust can be cross compiled from the Mac to embedded ARM. At least the compiler runs so it must be worth a shot.
The problem of cross-compiling from macOS host is that Rust only supports creation of object files (static libraries). This is usually woefully inadequate, and you will need:
- a cross-linker,
- target's system libraries, at very least a libc,
- and most likely a working C cross-compiler.
Rust/rustup can't do any of these, and macOS doesn't have packages for these things, so you're left to fend for yourself. It's a problem that's theoretically solvable — "just" build a cross GCC for your target, and "just" install an appropriate sysroot for the target platform. But it's a rabbit hole of chasing other people's incomplete docs, half-finished projects, dodgy unofficial Homebrew formulas for outdated software, and then landing on an inflexible black-box Docker image by some random person on GitHub.
1 Like
While that is indeed a pain, I don't think it's needed in the case of the more popular targets. In particular, there's a full, pre-built GNU toolchain (and an updated version here) suitable for OP's dev board among others.
Indeed. Over the years I have had to deal with that rabbit hole quite a few times. All those issues targeting Power, ARM, RISC V from Linux hosts!
Is it really so much harder from MacOS?
On Debian the stuff you need is there, you just need to know how to enable it (dpkg --add-architecture + crossbuild-essential + installing a few packages with an :$arch suffix).
On macOS Apple provides tools to cross-compile to other Apple devices, but everything else is missing, and you're left with DIY solutions.
Using random stranger's blog post from 2013 with a broken link to the old Homebrew repo is on par with my experience. The ARM site is much more useful, but they don't have compilers built for M1 host yet.
I don't see of what significance the identity of the author is. The Launchpad link in the blog post points to a site that is an official ARM project maintained by ARM employees and is definitely not broken (GNU Arm Embedded Toolchain in Launchpad). It moved in the meantime, so newer versions are on the other site that they themselves link to. But that happens – I do not consider clicking one more link to be a significant hardship, nor a reason to lose trust in the project.
1 Like
But Launchpad is for Ubuntu, not macOS. This is exactly the problem I'm talking about: macOS is second-class here.
1 Like