As someone else said in the previous thread when it was announced: it's about the software first. Qualcomm likely doesn't get this and likely never will
Writing traditional MCU software without an RTOS always sucked for a multitude of reasons. Vendor lockin, expensive specialty compilers, and so on
Arduino showed that it could be done differently with some not too expensive abstractions. Sure it is looked down on by traditional embedded engineers but the productivity gains and accessibility was hard to argue against
ESP didn't (only) grow huge because the hardware was cheap and available. The integration in the Arduino ecosystem was done brilliantly. It truly felt like a natural citizen in between usual Arduino code
What do you mean "vendor lock in"? Developers become accustomed to a particular SDK, and it is hard to move to new silicon because you need to relearn where the peripherals differ. If that's what you mean, I don't consider that lock-in, just inertia, but by your definition the Arduino SDK is "vendor lock in" (for all but the most trivial code it is portable). ESP32 integration with Arduino's ecosystem is severely limited to just a handful of APIs, and you need to use the ESP32 function calls if you want to do anything sophisticated (and idf.py). The Arduino API is too topical. I know from experience. Zephyr blows away Arduino, it has portable stacks, security, update, wifi/ble, etc...
Also, near everyone is offering GCC/LLVM/IAR/ARMCC (except for Synopsys ARC and Renesas RX).
Zephyr is a baby project. From the embedded devs I know they have only started seriously considering Zephyr in the last 2-3 years for commercial projects.
And you may call it inertia sure, but in the mid 2000's everyone was doing their own hardware abstraction. You had to get books and stuff because documentation sucked. MCU vendors seemingly made a point of making especially stuff like ADCs and timers very hard to abstract away between vendors.
Back then you had a choice of GCC/IAR/KEIL/CCS/Codwarrior and probably more. Each worse and less standards-compliant than the next, except for GCC/avr-gcc as was the key enabler of Arduino
All that text to say: The situation was different, and Arduino showed that there's a wider unmet demand for custom embedded stuff and that people will sacrifice a bit of performance for something that's easy to develop
"People will sacrifice a bit of performance" was also enabled by all the MCU advances.
Those bytes of memory really mattered when 512B was all the RAM you'll ever get. Nowadays, you can buy a RTOS capable 32-bit MCU for $0.20. Why count bytes when you can just... not?
The amount of memory used defines the size of the state space of the system — with exponential growth in the number of representable states. The amount of testing needed to have confidence in the behavior of a system grows (and I’d state based on experience, but without proof, grows faster than logarithmically) with the size of the state space. Building smaller, simpler systems is still the key to being able to realistically test and define behavior at high confidence levels, regardless of the price of a bit.
Most white box appliance makers use zephyr, so do some popular Wifi camera systems, and every major embedded SOC/MCU maker supports it. If that's a baby project, why don't you tell me what a "mature" project is?
Can't say, and you're not obliged to believe me. The vendors are just the companies supporting it. Companies that use it aren't going to announce it. Think about it: if it is just vendors on the site that would mean nobody is using it.
Zephyr is basically "let's have the nice things from Linux on small MCUs" and it sucks. Yes, it is numbers of magnitude better than vendor-specific not-quite-RTOS crap. It blows away Arduino because Arduino is an educational environment just a step above Scratch. Zephyr still sucks. And there is no hope of fixing it because it doesn't suck because the authors did a bad job. They did a fantastic job and it still sucks because the approach fundamentally doesn't work.
Zephyr loves to reuse Linux tooling but it simply doesn't fit. Kconfig silently disabling options because of missing dependencies sucks. No, I'm not using menuconfig, thank you very much, navigating a million of menus is the last thing I need. DTS to C macros abomination sucks. Tons of CMake scripts scattered over every directory suck.
The build in-drivers? What is implemented and tested directly by SoC vendors works, the rest is unusable for anything but example project. Want to use an external SPI flash? Too bad the driver doesn't implement any power management, program it all yourself or accept a constant 12mA draw (fine for many projects, absolutely unacceptable for some). Want to read this I2C sensor once an hour? Too bad, the build-in driver can only poll it constantly in a dedicated thread, just write one yourself. Not like that's a big job, but the build-in driver would be infinitely more useful if it just defined the register map in a header.
And worse yet, Zephyr doesn't do anything to actually solve the silicon lock-in problem, because it's not something that can be solved by new abstractions. Peripheral interconnect, interval timers and basically any peripheral that isn't I2C or UART is simply impossible to abstract over in a useful way. There is no common denominator like there is on desktop.
IMHO, FreeRTOS is a much better system simply because it doesn't tries to be a HAL. It switches between threads and that's it. And HAL for MCUs is simply a pipedream. If you can afford a HAL, go with Linux on a SoC large enough for that.
Nothing you've said is wrong, but I strongly disagree that it sucks.
The DTS error messages are awful, but having declarative configs with compile time validation is amazing once you've figured out what the errors actually mean. Writing drivers is just something you accept for board bringup, so that's basically a non-issue for me.
West's main problem is that it's just a weird little custom tool, not that it's annoying in itself. It's a large improvement over most other
embedded build systems, especially the config tools offered by TI and NXP.
And in exchange for those things you get an extremely capable RTOS with a decent shell, good features, and one of the best RTOS networking stacks out there. When you want to rev the layout 2, 3, 4 times or even make a new board entirely, it's straightforward to reuse all the effort in your initial bringup. A FreeRTOS system is much less reusable and has proportionally more schedule risk.
I guess that's depends on the application. What I had was a series of wireless DAQ devices with a common application core but different sets of sensors (and hence drivers). Some are as simple as "read and I2C value and put in into uplink queue" and that's where I often made the mistake to assume I could rely on stock drivers. Other are fully driven from the MCU's analog guts. Once the application core was there on one board I quickly found myself spending 50% of my time fighting against DTS.
FreeRTOS is much less reusable, but that means you are confidently pessimistic about schedule risk. That's an RTOS and that's it. The rest is on you and you know it. With Zephyr you get tons of support infrastructure, but you also risk finding that it doesn't fit too late in the process. E.g. the flash chip power management issue was quite bad - we ended up dropping the features that required an external flash altogether.
Then again, Zephyr is the best we have got, but I feel it's due to the Zephyr team's dedication to details - and in spite, not thanks to, the general approach.
The thing with Zephyr drivers is: sometimes you need to do something very special and exact to the hardware, and sometimes you just want to use it in the most generic and braindead way possible.
>> Zephyr loves to reuse Linux tooling but it simply doesn't fit.
What? It has its own tooling.
>> What is implemented and tested directly by SoC vendors works,
Yes, that's the point.
>> And HAL for MCUs is simply a pipedream.
Huh? What does this even mean?
>> Want to read this I2C sensor once an hour? Too bad, the build-in driver can only poll it constantly in a dedicated thread
That's literally how it an RTOS works. I'm baffled by your complaint. It sounds like you just don't understand embedded programming.
>> There is no common denominator like there is on desktop.
Ah ok, there we go: found the problem. If you expect linux, then of course you'll miss all of the embedded patterns that Zephyr solves cross-platform.
Their HAL works, their stacks work, the portability is incredibly smooth compared to other vendors. I just disagree with everything you've said in my experience using it, and working with companies that use it.
It uses KConfig (which is Linux specific-tool) and devicetree (which has origins in OpenFirmware but is nowadays maintained by Linux). And these are over-complicated overkill for MCUs. KConfig is oriented towards generating a nice-looking menu interface for kernel builders to pick and match from a set of well-tested configurations, it provides no debug aid for "where the option I enabled but didn't got into the build actually got rejected". DTS originally works as boot-time configuration format, which is silly for a MCU so Zephyr process it into a set of C macros. Not a bad idea in itself, but the error messages are as cryptic as it gets - and sometimes stuff get silently disabled because of a missing dependency with no build warning.
> Huh? What does this even mean?
You cannot have a portable interface for timers, comparators, peripheral interconnect, programmable logic - all the MCU goodies.
> That's literally how it an RTOS works.
You don't allocate a separate thread stack for something you do once an hour - not unless it's a high-criticality task. You don't constantly poll a sensor that consumes 10mA on a device that has 10µA idle consumption budget. Zephyr does have the facility to do this the right way: workqueues (which is also a ripoff of Linux workqueues nee bottom halves). But most stock device drivers (or the network stack for that matter) don't play well with these, I guess because of the bulky callback-driven interface.
>If you expect linux
I don't expect Linux. That's my point - you can't have Linux on embedded so why even bother with all the abstractions? Why bother with DTS and Kconfig when you still end with a set of header files to debug - except now they are also auto-generated unreadable mess?
> portability is incredibly smooth compared to other vendors
Oh, kconifg is great. Do you think arduino is better? lolno. Check out NXP or STM's solution, and kconfig makes way more sense. Again, my opinion.
>> You don't allocate a separate thread stack for something you do once an hour - not unless it's a high-criticality task. You don't constantly poll a sensor that consumes 10mA on a device that has 10µA idle consumption budget.
I know. But you said you were TRYING to do that. You invent a scenario then you explain why it is wrong.
I don't like to argue for the sake of arguing. Peace out.
Before I clicked I expected a single SoC with a hybrid architecture (powerful cores to run Linux, MCU cores for real time control). This is a board with two physically separate chips. They put an MCU next to the quad-core application chip.
It will be interesting to see how they make this arrangement approachable for Arduino’s audience which generally expects ease of use to be a high priority.
> It will be interesting to see how they make this arrangement approachable for Arduino’s audience which generally expects ease of use to be a high priority.
Would not be surprised to see both approaches to developing only for one of the two systems: programming the MCU and deploying some ready-made stuff to the big Qualcomm chip, like a stacking a shield on top of the Uno only that the shield is software-defined (providing some compute service), and running some ready-made interface abstraction on the MCU, running everything individually programmed on the powerful Linux chip. Likely within some form of JVM or a Python runtime, or node.
> It will be interesting to see how they make this arrangement approachable for Arduino’s audience which generally expects ease of use to be a high priority.
If history is any indication: they won't. See the previous Arduino Linux + MCU systems like Arduino Yún and Tian, for example, or the FPGA-based Arduino MKR Vidor - Arduino's approach has generally been to throw hardware over the wall with a bit of example code and hope the community can come up with a use for it.
I saw this the other day. I’m not sure exactly what the concerns are, nor why Qualcomm deserves any shade. I don’t know much about Qualcomm, but at least on the face of it, they’re keeping Arduino alive and infusing a lot of cash and expanding the platform, and they’re also keeping the board designs fully open source. It seems reasonable (and probably necessary in today’s world) to have terms on the cloud services. Arduino’s website itself was never open source, the chips they’ve always used aren’t open source. And it was Arduino’s decision to sell to Qualcomm, right? Why should the cloud services be open source?
> I’m not sure exactly what the concerns are, nor why Qualcomm deserves any shade.
Yeah, the missing subtext here is the opinions of the folks who have worked with Qualcomm’s (software) org and products professionally. They’re… not beloved.
Arduino has four layers, only two were ever truly open:
1 Hardware reference designs (sort of open by intent)
2 Core software (open-source licensing)
3 Services and “happy path” tooling (not open)
4 Brand and governance (never open)
Qualcomm’s move is about owning layer 4 and using it to grow layer 3, while keeping layers 1 and 2 open enough to preserve credibility and community adoption.
That makes sense to me. Adafruit’s complaint relates to layer 3, right? Is Qualcomm changing the openness of layers 1 & 2 in meaningful ways that affect makers & hobbyists? And I guess layer 1 is PCB design, not [MC]PU design, right? Is that what you mean by ‘sort of’?
I expect it to have much less community support, but it ships with better hardware, has more hardware compatibility (with Pi peripherals) - and much better documentation availability, because Texas Instruments actually puts TRMs up online.
I bought one of these to play with when it was announced, but with all the drama I’ve been hesitant to invest any time with it. Anyone make anything interesting?
It's kind of hard to use. I considered putting it to use for a project, but, no official camera sensor boards, not even a Pi camera adapter yet, and the official ISP tuning guides are NDA'd, because, Qualcomm. Would have rolled my own sensor board otherwise.
Very silly. They make a board that screams "for robotics", market it "for AI", and then neglect the cameras.
It would be worthwhile still if this had LTE on board, but it doesn't.
This can be hard to explain to both engineers and laypeople because there's Arduino, then there's Arduino, and then there's Arduino...
For instance, "Arduino" could mean the Arduino branded boards, and the cloud based development stack.
On the other hand, "Arduino" has become almost a generic term for any microcontroller board that happens to support the (open source) Arduino API. As in: "Just throw an Arduino in there."
For instance I've got several ongoing projects using third party boards such as Teensy, where my entire relationship to Arduino is represented by a single line of code:
We get that, but when some elements of the stack have incredibly onerous terms added to them, the 2nd order and 3rd order Arduinos become license untenable particularly for low-level developers working with minimal docs
Am including a few different articles on this because viewpoint diversity is good for this issue
My expectation (well, maybe my hope) is that the Arduino community will diverge from the Arduino business and become self sustaining.
Arguably, the cloud based development environment may have been a good idea, especially since a lot of students are stuck with locked down Chromebooks that can't install the toolchain locally. And I lack the expertise to speculate about this, but it would seem to me that if an entire Python toolchain can run in a web app (e.g., Jupyter Lite), then maybe an embedded dev environment could be make to work in a similar way.
As someone else said in the previous thread when it was announced: it's about the software first. Qualcomm likely doesn't get this and likely never will
Writing traditional MCU software without an RTOS always sucked for a multitude of reasons. Vendor lockin, expensive specialty compilers, and so on
Arduino showed that it could be done differently with some not too expensive abstractions. Sure it is looked down on by traditional embedded engineers but the productivity gains and accessibility was hard to argue against
ESP didn't (only) grow huge because the hardware was cheap and available. The integration in the Arduino ecosystem was done brilliantly. It truly felt like a natural citizen in between usual Arduino code
What do you mean "vendor lock in"? Developers become accustomed to a particular SDK, and it is hard to move to new silicon because you need to relearn where the peripherals differ. If that's what you mean, I don't consider that lock-in, just inertia, but by your definition the Arduino SDK is "vendor lock in" (for all but the most trivial code it is portable). ESP32 integration with Arduino's ecosystem is severely limited to just a handful of APIs, and you need to use the ESP32 function calls if you want to do anything sophisticated (and idf.py). The Arduino API is too topical. I know from experience. Zephyr blows away Arduino, it has portable stacks, security, update, wifi/ble, etc...
Also, near everyone is offering GCC/LLVM/IAR/ARMCC (except for Synopsys ARC and Renesas RX).
Zephyr is a baby project. From the embedded devs I know they have only started seriously considering Zephyr in the last 2-3 years for commercial projects.
And you may call it inertia sure, but in the mid 2000's everyone was doing their own hardware abstraction. You had to get books and stuff because documentation sucked. MCU vendors seemingly made a point of making especially stuff like ADCs and timers very hard to abstract away between vendors.
Back then you had a choice of GCC/IAR/KEIL/CCS/Codwarrior and probably more. Each worse and less standards-compliant than the next, except for GCC/avr-gcc as was the key enabler of Arduino
All that text to say: The situation was different, and Arduino showed that there's a wider unmet demand for custom embedded stuff and that people will sacrifice a bit of performance for something that's easy to develop
"People will sacrifice a bit of performance" was also enabled by all the MCU advances.
Those bytes of memory really mattered when 512B was all the RAM you'll ever get. Nowadays, you can buy a RTOS capable 32-bit MCU for $0.20. Why count bytes when you can just... not?
> Why count bytes when you can just... not?
The amount of memory used defines the size of the state space of the system — with exponential growth in the number of representable states. The amount of testing needed to have confidence in the behavior of a system grows (and I’d state based on experience, but without proof, grows faster than logarithmically) with the size of the state space. Building smaller, simpler systems is still the key to being able to realistically test and define behavior at high confidence levels, regardless of the price of a bit.
I fail to think of many cases where such an approach would be warranted at all.
>> Zephyr is a baby project
Most white box appliance makers use zephyr, so do some popular Wifi camera systems, and every major embedded SOC/MCU maker supports it. If that's a baby project, why don't you tell me what a "mature" project is?
> Most white box appliance makers use zephyr
Most? Like who? Looking at Zephyr's member page it's just chip vendors
Can't say, and you're not obliged to believe me. The vendors are just the companies supporting it. Companies that use it aren't going to announce it. Think about it: if it is just vendors on the site that would mean nobody is using it.
> Zephyr blows away Arduino
Zephyr is basically "let's have the nice things from Linux on small MCUs" and it sucks. Yes, it is numbers of magnitude better than vendor-specific not-quite-RTOS crap. It blows away Arduino because Arduino is an educational environment just a step above Scratch. Zephyr still sucks. And there is no hope of fixing it because it doesn't suck because the authors did a bad job. They did a fantastic job and it still sucks because the approach fundamentally doesn't work.
Zephyr loves to reuse Linux tooling but it simply doesn't fit. Kconfig silently disabling options because of missing dependencies sucks. No, I'm not using menuconfig, thank you very much, navigating a million of menus is the last thing I need. DTS to C macros abomination sucks. Tons of CMake scripts scattered over every directory suck.
The build in-drivers? What is implemented and tested directly by SoC vendors works, the rest is unusable for anything but example project. Want to use an external SPI flash? Too bad the driver doesn't implement any power management, program it all yourself or accept a constant 12mA draw (fine for many projects, absolutely unacceptable for some). Want to read this I2C sensor once an hour? Too bad, the build-in driver can only poll it constantly in a dedicated thread, just write one yourself. Not like that's a big job, but the build-in driver would be infinitely more useful if it just defined the register map in a header.
And worse yet, Zephyr doesn't do anything to actually solve the silicon lock-in problem, because it's not something that can be solved by new abstractions. Peripheral interconnect, interval timers and basically any peripheral that isn't I2C or UART is simply impossible to abstract over in a useful way. There is no common denominator like there is on desktop.
IMHO, FreeRTOS is a much better system simply because it doesn't tries to be a HAL. It switches between threads and that's it. And HAL for MCUs is simply a pipedream. If you can afford a HAL, go with Linux on a SoC large enough for that.
Nothing you've said is wrong, but I strongly disagree that it sucks.
The DTS error messages are awful, but having declarative configs with compile time validation is amazing once you've figured out what the errors actually mean. Writing drivers is just something you accept for board bringup, so that's basically a non-issue for me.
West's main problem is that it's just a weird little custom tool, not that it's annoying in itself. It's a large improvement over most other embedded build systems, especially the config tools offered by TI and NXP.
And in exchange for those things you get an extremely capable RTOS with a decent shell, good features, and one of the best RTOS networking stacks out there. When you want to rev the layout 2, 3, 4 times or even make a new board entirely, it's straightforward to reuse all the effort in your initial bringup. A FreeRTOS system is much less reusable and has proportionally more schedule risk.
I guess that's depends on the application. What I had was a series of wireless DAQ devices with a common application core but different sets of sensors (and hence drivers). Some are as simple as "read and I2C value and put in into uplink queue" and that's where I often made the mistake to assume I could rely on stock drivers. Other are fully driven from the MCU's analog guts. Once the application core was there on one board I quickly found myself spending 50% of my time fighting against DTS.
FreeRTOS is much less reusable, but that means you are confidently pessimistic about schedule risk. That's an RTOS and that's it. The rest is on you and you know it. With Zephyr you get tons of support infrastructure, but you also risk finding that it doesn't fit too late in the process. E.g. the flash chip power management issue was quite bad - we ended up dropping the features that required an external flash altogether.
Then again, Zephyr is the best we have got, but I feel it's due to the Zephyr team's dedication to details - and in spite, not thanks to, the general approach.
The thing with Zephyr drivers is: sometimes you need to do something very special and exact to the hardware, and sometimes you just want to use it in the most generic and braindead way possible.
Zephyr's HAL streamlines the latter. Very nice.
>> Zephyr loves to reuse Linux tooling but it simply doesn't fit.
What? It has its own tooling.
>> What is implemented and tested directly by SoC vendors works,
Yes, that's the point.
>> And HAL for MCUs is simply a pipedream.
Huh? What does this even mean?
>> Want to read this I2C sensor once an hour? Too bad, the build-in driver can only poll it constantly in a dedicated thread
That's literally how it an RTOS works. I'm baffled by your complaint. It sounds like you just don't understand embedded programming.
>> There is no common denominator like there is on desktop.
Ah ok, there we go: found the problem. If you expect linux, then of course you'll miss all of the embedded patterns that Zephyr solves cross-platform.
Their HAL works, their stacks work, the portability is incredibly smooth compared to other vendors. I just disagree with everything you've said in my experience using it, and working with companies that use it.
> What? It has its own tooling.
It uses KConfig (which is Linux specific-tool) and devicetree (which has origins in OpenFirmware but is nowadays maintained by Linux). And these are over-complicated overkill for MCUs. KConfig is oriented towards generating a nice-looking menu interface for kernel builders to pick and match from a set of well-tested configurations, it provides no debug aid for "where the option I enabled but didn't got into the build actually got rejected". DTS originally works as boot-time configuration format, which is silly for a MCU so Zephyr process it into a set of C macros. Not a bad idea in itself, but the error messages are as cryptic as it gets - and sometimes stuff get silently disabled because of a missing dependency with no build warning.
> Huh? What does this even mean?
You cannot have a portable interface for timers, comparators, peripheral interconnect, programmable logic - all the MCU goodies.
> That's literally how it an RTOS works.
You don't allocate a separate thread stack for something you do once an hour - not unless it's a high-criticality task. You don't constantly poll a sensor that consumes 10mA on a device that has 10µA idle consumption budget. Zephyr does have the facility to do this the right way: workqueues (which is also a ripoff of Linux workqueues nee bottom halves). But most stock device drivers (or the network stack for that matter) don't play well with these, I guess because of the bulky callback-driven interface.
>If you expect linux
I don't expect Linux. That's my point - you can't have Linux on embedded so why even bother with all the abstractions? Why bother with DTS and Kconfig when you still end with a set of header files to debug - except now they are also auto-generated unreadable mess?
> portability is incredibly smooth compared to other vendors
That's an extremely low bar.
Oh, kconifg is great. Do you think arduino is better? lolno. Check out NXP or STM's solution, and kconfig makes way more sense. Again, my opinion.
>> You don't allocate a separate thread stack for something you do once an hour - not unless it's a high-criticality task. You don't constantly poll a sensor that consumes 10mA on a device that has 10µA idle consumption budget.
I know. But you said you were TRYING to do that. You invent a scenario then you explain why it is wrong.
I don't like to argue for the sake of arguing. Peace out.
Before I clicked I expected a single SoC with a hybrid architecture (powerful cores to run Linux, MCU cores for real time control). This is a board with two physically separate chips. They put an MCU next to the quad-core application chip.
It will be interesting to see how they make this arrangement approachable for Arduino’s audience which generally expects ease of use to be a high priority.
> It will be interesting to see how they make this arrangement approachable for Arduino’s audience which generally expects ease of use to be a high priority.
Would not be surprised to see both approaches to developing only for one of the two systems: programming the MCU and deploying some ready-made stuff to the big Qualcomm chip, like a stacking a shield on top of the Uno only that the shield is software-defined (providing some compute service), and running some ready-made interface abstraction on the MCU, running everything individually programmed on the powerful Linux chip. Likely within some form of JVM or a Python runtime, or node.
> It will be interesting to see how they make this arrangement approachable for Arduino’s audience which generally expects ease of use to be a high priority.
If history is any indication: they won't. See the previous Arduino Linux + MCU systems like Arduino Yún and Tian, for example, or the FPGA-based Arduino MKR Vidor - Arduino's approach has generally been to throw hardware over the wall with a bit of example code and hope the community can come up with a use for it.
Nice try, Qualcomm.
Some context for people who haven't been following recent the recent Qualcomm/Arduino developments: https://arstechnica.com/gadgets/2025/11/arduinos-new-terms-o...
I saw this the other day. I’m not sure exactly what the concerns are, nor why Qualcomm deserves any shade. I don’t know much about Qualcomm, but at least on the face of it, they’re keeping Arduino alive and infusing a lot of cash and expanding the platform, and they’re also keeping the board designs fully open source. It seems reasonable (and probably necessary in today’s world) to have terms on the cloud services. Arduino’s website itself was never open source, the chips they’ve always used aren’t open source. And it was Arduino’s decision to sell to Qualcomm, right? Why should the cloud services be open source?
> I’m not sure exactly what the concerns are, nor why Qualcomm deserves any shade.
Yeah, the missing subtext here is the opinions of the folks who have worked with Qualcomm’s (software) org and products professionally. They’re… not beloved.
Arduino has four layers, only two were ever truly open:
1 Hardware reference designs (sort of open by intent)
2 Core software (open-source licensing)
3 Services and “happy path” tooling (not open)
4 Brand and governance (never open)
Qualcomm’s move is about owning layer 4 and using it to grow layer 3, while keeping layers 1 and 2 open enough to preserve credibility and community adoption.
That makes sense to me. Adafruit’s complaint relates to layer 3, right? Is Qualcomm changing the openness of layers 1 & 2 in meaningful ways that affect makers & hobbyists? And I guess layer 1 is PCB design, not [MC]PU design, right? Is that what you mean by ‘sort of’?
Qualcomm trying to kill what makes Arduino so successful and then wonders why no one is hyped about it.
How would it stack up against BeagleBoard BeagleY-Ai, save for the lack of drama?
BeagleY-Ai is probably a better board overall.
I expect it to have much less community support, but it ships with better hardware, has more hardware compatibility (with Pi peripherals) - and much better documentation availability, because Texas Instruments actually puts TRMs up online.
I bought one of these to play with when it was announced, but with all the drama I’ve been hesitant to invest any time with it. Anyone make anything interesting?
If you already bought it dont let the drama waste your money. You just buy different next time if you feel they no longer meet your expectations.
It's kind of hard to use. I considered putting it to use for a project, but, no official camera sensor boards, not even a Pi camera adapter yet, and the official ISP tuning guides are NDA'd, because, Qualcomm. Would have rolled my own sensor board otherwise.
Very silly. They make a board that screams "for robotics", market it "for AI", and then neglect the cameras.
It would be worthwhile still if this had LTE on board, but it doesn't.
> the official ISP tuning guides are NDA'd
Oof.
At least some of the promotion images on the site seem AI-generated: The image next to "Single-board computer" features a very wonky keyboard.
What do you mean? I see nothing wrong with the keyboard.
Well, there are three keys labeled "A," to start with...
Aimed at AAA studios.
I somehow expect HPC systems to look different
Let’s see where they are in a few years.
Why would we want to use anything Arduino after all those horrible QCOM licensing changes?
Am asking because an OSS project asked me the same thing when I mentioned possibly using an Arduino platform for something related to their project.
This can be hard to explain to both engineers and laypeople because there's Arduino, then there's Arduino, and then there's Arduino...
For instance, "Arduino" could mean the Arduino branded boards, and the cloud based development stack.
On the other hand, "Arduino" has become almost a generic term for any microcontroller board that happens to support the (open source) Arduino API. As in: "Just throw an Arduino in there."
For instance I've got several ongoing projects using third party boards such as Teensy, where my entire relationship to Arduino is represented by a single line of code:
We get that, but when some elements of the stack have incredibly onerous terms added to them, the 2nd order and 3rd order Arduinos become license untenable particularly for low-level developers working with minimal docs
Am including a few different articles on this because viewpoint diversity is good for this issue
https://www.molecularist.com/2025/11/did-qualcomm-kill-ardui...
https://arstechnica.com/gadgets/2025/11/arduinos-new-terms-o...
https://itsfoss.com/news/enshittification-of-arduino-begins/
My expectation (well, maybe my hope) is that the Arduino community will diverge from the Arduino business and become self sustaining.
Arguably, the cloud based development environment may have been a good idea, especially since a lot of students are stuck with locked down Chromebooks that can't install the toolchain locally. And I lack the expertise to speculate about this, but it would seem to me that if an entire Python toolchain can run in a web app (e.g., Jupyter Lite), then maybe an embedded dev environment could be make to work in a similar way.