nRF Connect / VS Code broken for M1 Mac users

[Scott]

There are at least several show-stopper level issues with your nRF Connect SDK and VS Code for M1 Mac users

First not supporting the native VS Code app is annoying and forces us to use a much slower non-native Intel based build

Second - even after installing that, I'm stuck forever in nRF Connect for Desktop on « Checking if VS Code and dependencies are installed »

Third after going around that and installing directly in VS Code [ which incidentally seems to kind of work in the M1 based VS Code ] I get a lot of «

[west]: warning: templates not found in /usr/local/Cellar/git/2.32.0_1/share/git-core/ » warnings

Fourth - just with the basic hello_world sample app, compilation fails because zephyr.h and sys/printk.h are not found

Fifth - spaces and other perfectly valid characters in filenames/directory names are not allowed 

I definitely / strongly prefer this to the SEGGER studio requirement ( which is annoying because of the licensing hoop and just because I don't want to use or mandate our developers use a specific IDE ) but there are a lot of issues that desperately need to be addressed before this is viable in production for anyone who doesn't have a lot of time and resources to burn getting things to work

[Shahar]

A month later and this is still an issue.

This is starting to become ridiculus.

M1 macs been out since November 10, 2020. We're mid 2022 now (almost 18 months).

[Scott]

This is even worse than you think because Apple released an M1 Developers Transition Kit in late June 2020 so closer to two years ago.

I get that it's annoying to deal with the differences in hardware but this is just neglect

[Shahar]

Add to the list:

- Bugs in nRF5 SDK which been in existence for ages and you simply patch it yourself based on posts in the dev zone (Bootloader for nRF52832AB, softblink for P1 GPIOs, FreeRTOS nRF52832 FPU bugs, FreeRTOS out of date, just to name a few…)

- nRF5 SDK in complete neglect. Samples still uses nrf_drv. Still no proper examples for SAADC v2. Latest SES compatibility broken. Just to name a few.

- nrfutil unusable on M1 unless you build pc-BLE-driver v5 bindings manually

- pc-BLE-driver v6 node.js/python non-existent.

[Scott]

I do get that software is hard and that it's much more fun to work on new stuff than to maintain or ruggedise/polish the old stuff, but that's so essential especially when people are relying on it for their products

[Shahar]

We rant and rant ... but I don't think Nordic really cares about us ...

90% of their end users are windows based.

But Apple Silicon Macs are taking over, at some point I hope there will be a tipping point.

[Scott]

Apple Silicon is great but unfortunately I can't imagine that Apple will magically get massive market share especially among engineers who have weird longstanding biases against Macs and macOS - especially given that there is a bit of a bootstrap problem. Even Apple doesn't use Macs to design their hardware because all of the best CAD tools are PC / workstation based, and they have their own chips and internal tools and toolchains for software development so we're stuck with hoping that companies like Nordic will put in the effort to take care of niche customers and although you and I think we're using the best hardware, I get why they'd make a business decision to neglect us and leave us floundering

[Sigurd Hellesvik]

Hi Scott and Sahar

I have queried our developer who will be able to give an good answer on our M1 Mac support status.

However, he is out of office today. I will let you know what our status on the issue is as soon as I hear from him. Hopefully tomorrow or Monday.

Regards,
Sigurd Hellesvik

[Shahar]

I somewhat disagree with the assesment that macOS is not gaining a massive market share.

I see more and more of the "new blood" of embedded developers (embedded is a much broaded term this days than it used to be) actually prefering the Apple Silicon computers.

It gives them mobility, at least 8 hours of work without the need to hookup a PS and super fast build times.
And there's no real reason not to go this route this days when many of the big players gives fully workinng Apple Silicton or macOS solution which works like STM32, Segger, platformIO (early adopter!), MicroChip, NXP, etc. (Silicon Labs was also late to the party on this btw)

just got to compare Zephyr on Windows x64 to Zephyr on macOS Apple Silicon (as Zephyr does supports the M1 stuff, its mostly the Nordic issue) - it's massive. Even Intel based macs are faster, the whole "tons of small files with lots of directories" has always been the achiles heel of NTFS. Look at git and how much work is done on microsoft end to improve the git for windows (like caching and stuff).

So I do believe Apple Siicon and ARM based Windows is going to become a bigger and bigger market. ARM based Windows PC will break so much stuff ... which going to hurt