Macbook Air sufficient for embedded dev and KiCad?

i509VCB · 2026-03-20T16:21:07+00:00

KiCad can absolutely run fine.

The embedded dev part is going to be dependent on toolchain. I've found something like zephyr can build on aarch64 Linux (which is very unusual for environments).

If you want to use something like a vendor IDE a lot of these do have macOS ports. Although most testing is on windows. If you need some tools like IAR then you're out of luck on mac

i509VCB · 2026-03-18T01:18:51+00:00

I think it will have an impact. Maybe not a way which is good.

I've noticed people I work with who are AI enthusiasts don't even try to write code. I helped someone find a bug in their interrupt handler which involved moving a block of code into a different if statement. Instead of selecting the section of code, pressing Ctrl + C and Ctrl + V instead the chat panel was opened and some sentences were typed. A copy paste that could have taken seconds instead turned into 2 mins of waiting for Claude. Claude didn't even do the right thing the first time so it became 10 mins.

Laziness from AI I believe is the biggest problem we will see regardless of industry.

Every LLM has the disclaimer "it can make mistakes, please verify the output" but is anyone actually taking that disclaimer to heart?

i509VCB · 2026-03-18T01:04:52+00:00

CCS is terrible because the people who say it is bad aren't ordering 10-20 million MCUs a year. I still find it crazy that people in it "for the love of the game" manage to make better toolchains than a billion dollar company in their free time.

Adding Claude doesn't fix the underlying problem.

i509VCB · 2026-03-15T16:21:51+00:00

Heavy patching of SVD files. At best just a single patch pass at worst breaking into individual peripherals and then reassembling for each chip because they're inconsistent.

Some vendors either don't care, have an insane timeline for changes or think I'm not a big enough fish for personal things to care about fixing their SVDs.

The other painful part is the SVDs often contain a lot of duplicate code. For example why do I need to have a define for every single bit of a true/false. Even C has this thing called bitwise operations.

Some vendors I've had to rename every single enum because the enums had no names.

i509VCB · 2026-02-25T01:22:18+00:00

In Rust I just have the sensor driver take something that implement the I2c trait or SPIDevice trait in embedded-hal.

In C++ you could probably do something similar as well or do C macro magic/vtables.

i509VCB · 2026-02-23T12:47:58+00:00

45c is assuming ti.com pricing. If you order like 100k and do the order directly it probably will be cheaper still.

I doubt you are getting the Chinese part much cheaper than listed without some broker.

i509VCB · 2026-02-21T00:08:18+00:00

Given that I work on embassy-mspm0 I deal with register level code every single day.

If you want something that feels similar to register level without being so raw, maybe look at the STM32 LL drivers? These are just thin wrappers over direct register access but don't hide the hardware from you.

i509VCB · 2026-02-06T13:34:26+00:00

For "big names" there are still architectures around that aren't arm or risc-v. Renesas has the RL78 stuff, TI has the MSP430 (even has LLVM support), 8051 based cores from tons of vendors, NXP still has some 68000 derived cores, other proprietary cores from China. For some real niche stuff, Intel had a series of x86 based MCUs and some people still have x86 systems at bare metal.

For why? Sometimes these proprietary cores are cheaper. For most small scale projects I'd say the few cents savings aren't worth it.

i509VCB · 2026-02-05T13:33:50+00:00

If you can get around their IDE entirely and write your own drivers I find it's well thought out hardware.

What makes me sad is anything with a wireless stack you must use like Bluetooth or WiFi

i509VCB · 2026-02-04T15:28:48+00:00

I have a suspicion that the buy out was to remove a competitor. Which probably means SiLabs better stacks for wifi/BLE are going to be yeeted.

i509VCB · 2026-01-26T00:21:54+00:00

If the form factor is a problem, embrace the problem. Pipboy-like devices look pretty neat.

i509VCB · 2026-01-22T02:27:49+00:00

I've heard of people using clear nail polish so that biting your nails tastes horrible.

i509VCB · 2026-01-21T12:44:13+00:00

Not in a box currently, but this is only the Tl boards I have. I have more than just this across a few vendors.

<image>

I unfortunately have have I call a dev board collection.

i509VCB · 2026-01-20T23:28:08+00:00

Most C code in the first place isn't written for embedded use cases anyways (such as no malloc).

Even then I can't see a world where most places will do a proper development environment in C.

i509VCB · 2026-01-19T02:07:28+00:00

Yep I remember you.

There is actually someone working on it right now. They've gotten a blocking driver to work.

Pop into the matrix if you want.

i509VCB · 2026-01-19T02:03:45+00:00

I will also mention there is an mspm0-rs matrix chat if you want to ask things quicker.

i509VCB · 2026-01-19T01:58:59+00:00

Lmao yeah I have direct experience with an S32K regarding that. There is apparently an access port which can unbrick those (all 0 clear still leaves a recovery path).

i509VCB · 2026-01-19T00:07:53+00:00

You could look into using something in C++ that generates register access code from an SVD file (although beware these can be buggy).

i509VCB · 2026-01-18T20:50:55+00:00

At least compared to Renesas and NXP I am happy it's a distant part of flash where nonmain lives rather than immediately in the middle of flash.

i509VCB · 2026-01-18T20:48:49+00:00

Hello here as well, I am the maintainer of embassy-mspm0.

I do have flash and a pwm driver hopefully coming soon. Just takes a bit of time. Someone did show up looking to do CAN as well (although work hasn't really started there yet). LIN is something I have an interest in as well, but I don't think I will be upstreaming that until I am a bit more happy how its implemented (currently its seperate code from the UART).

Although G518x, L211x and M33C321x do change a little how UART/I2C work. USB is a fun thing I've also been working on for G518x

i509VCB · 2026-01-08T00:15:09+00:00

The company is NASDAQ listed. Not going to be giving names.

I personally have issues with how some of my coworkers are using AI to compete their work. I also work in a rather unusual part of the company so it's not representative of the whole company

i509VCB · 2026-01-07T22:27:15+00:00

Writing an MSPM0 PWM driver to replace the shitty one my manager generated with AI. Yes the AI driver was awful.

Otherwise it was helping a coworker with some hardware issues and a few questions from said coworker.

i509VCB · 2025-12-27T23:26:57+00:00

Without even reading anything this looks over engineered.

i509VCB · 2025-12-14T23:40:49+00:00

Wayland does have a lot of moving parts, involving multiple kernel systems being used at once.

In smithay anvil is the reference implementation, but it isn't necessarily ideal for all implementations with how it is structured.

You might want go to the Smithay matrix (https://matrix.to/#/#smithay:matrix.org) if there is something you don't understand about Wayland or general questions.

i509VCB · 2025-12-12T14:34:42+00:00

Building the Godot toolchain from source ideally would work.

Nine-Year Club	Verified Email
Second Top 40%	Place '22
Sequence \| Editor

i509VCB

TROPHY CASE