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).
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.
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?
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 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.
It would be worthwhile still if this had LTE on board, but it doesn't.
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
Also, near everyone is offering GCC/LLVM/IAR/ARMCC (except for Synopsys ARC and Renesas RX).
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.
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.
It would be worthwhile still if this had LTE on board, but it doesn't.
Oof.