I doubt Qualcomm will be able to pressure there rules to the market. They do not own the cpu and making a arduino like board is very easy nowerdays. The have not even the power over the bootloader or the compiler. Library’s are either standard c/c++ or open source. People also do not like the arduino ide because the days of easy setup and run are gone and a real way of debug is needed in most projects. China board makers will never obey any rules and marketplaces like alibaba will still sell clones. Perhaps the ai at Qualcomm told them to buy arduino because it is in a suicide mission. Please excuse my bad English, no native speaker
> People also do not like the arduino ide because the days of easy setup and run are gone and a real way of debug is needed in most projects.
A surprising amount of embedded SoCs target the Arduino IDE either as the main IDE, or one of the main ones. And for those the setup is still pretty easy for non technical users - "Download IDE, paste this into the boardmanager, compile the sketch, upload". That's the main reason I'm still using the Arduino IDE for stuff I publish and expect less technical people to use.
The problem with the IDE is that it doesn't offer a gradual path to more advanced usage. You're pretty much stuck with a single file main project. You can split off functionality into libraries, but the way library resolving works is way worse compared to "proper" build systems. There are projects to provide makefiles for Arduino projects, but it's a bit of a pain to set up - I use that for CI on some of my stuff, but it clearly is on the other end of difficulty scale.
And of course the editor is horrible - but thanks to file watching and automatic reloads that isn't much of an issue nowadasy.
But targeting the Arduino IDE only means to have a GCC version to compile and some upload program and then set a bunch of variables in platform.txt . It doesn't actually make it any harder to not use the Arduino IDE.
> The problem with the IDE is that it doesn't offer a gradual path to more advanced usage. You're pretty much stuck with a single file main project. You can split off functionality into libraries, but the way library resolving works is way worse compared to "proper" build systems. There are projects to provide makefiles for Arduino projects, but it's a bit of a pain to set up - I use that for CI on some of my stuff, but it clearly is on the other end of difficulty scale.
It actually isn't all that hard. I recently did exactly that and it took like a week, most of which was spent on understanding what the Arduino IDE does with strace. Initially I assumed the Arduino IDE does way more stuff then it actually does. The makefile projects are too complicated, because they try to abstract over the installation and project. Instead I used Autotools which is way easier and simpler. It also breaks less, because these makefile projects tend to hardcode paths.
To save others the work: All you need to do is populate CPPFLAGS, CFLAGS, LDFLAGS, ... with the information from platform.txt and boards.txt . Then tell your build system to use the cross-compiler toolchain from your OS. Take care to only use the exact uploader program version that the Arduino IDE also uses, I have been burned by using the latest version, which bricked my board (i.e. you can't upload anything to fix it and need to use a second board to reflash the bootloader). This information is in the package_index.json file. Granted this is annoying to work with using fulltext search, you would have a much saner experience actually using the JSON format, but it still works and I am lazy.
> You're pretty much stuck with a single file main project.
You can have multiple files just fine, this is actually the reason why the Arduino IDE defaults to having this project directory. The Arduino IDE just assumes all files below that are things to compile. You need to remember to not name the other files with *.ino, but *.cpp, *.c and *.h, otherwise you end up with multiple main functions. An *.ino file is just a *.cpp file that gets preprocessed with a main function template.
> And of course the editor is horrible
You can tell the Arduino IDE to use another editor, which is what I did when I used it.
So basically, Arduino IDE acts as the client side of the tether to compile and flash firmware to the target device.
This seems like an ideal component for the OSS community to handle and rally around. Then anyone can use the IDE of their choice, the compile-flash manager handles the rest.
Prototyping platforms have tiny markets, but lead to downstream sales. Many a company were brought down by more developer-friendly platforms ignoring the "tiny" userbase of people who want to do unconventional things.
Most IC vendors provide free samples and support because of this. That's a market size of close to zero -- electronic engineers -- but leads to a market size of "massive." I can get an application engineer to visit my office for free to help me develop if I want.
Arguably, iPhone and Android won by supporting the tiny market of developers, who went on to build an ecosystem of applications, some long-tail, and some unexpected successes.
And arguably, x86 won for the same reason.
Atmel had shipped 500 million AVR flash microcontrollers, due in large part to the ecosystem created by Arduino.
Balmer said "Developers! developers! developers!" Visual Studio was not a major revenue driver for Microsoft; what was developed in it was.
> Prototyping platforms have tiny markets, but lead to downstream sales. Many a company were brought down by more developer-friendly platforms ignoring the "tiny" userbase of people who want to do unconventional things.
Qualcomm doesn't even make small/cheap MCUs so they aren't going to win over that market by buying Arduino. Their first board post-acquisition is a mashup of a Linux SBC with an MCU devkit, and while the Linux SOC is from QCOM, the MCU is from ST Micro.
>Atmel had shipped 500 million AVR flash microcontrollers, due in large part to the ecosystem created by Arduino.
How do you know the 500 million sales is due to the Arduino ecosystem?
I used to work in embedded for 10+ years and in the 4 companies I worked at so far, none of the products ever featured AVR microcontrollers. The microcontroller of choice for production was always based on the feature/cost ratio for each application, never on the "is it part of the Arduino ecosystem?" question.
Tinkering with Arduino at home, and building products for mass production, have widely different considerations.
If they sold 500 million microcontrollers and your workplaces never bought any, then your experience doesn't tell us anything about why the people that did buy them, bought them.
All of the products that i've been involved with that included AVR microcontrollers are from before the Arduino platform existed. The STMicro ARM M3 chips are more capable and cheaper then the 8-bit AVRs; The Arduino IDE never factored into the decision, even at the height of its popularity.
FWIW: I've used Arduinos, but never with their IDE.
AVR was super-developer-friendly well before the Arduino. It replaced the PIC for a lot of hobbyist projects.
To the points in the thread, on major product development, these things don't matter. On the long tail of smaller products, as well as on unexpected successes, they do.
That is the downside. you can prototype with one chip and when the concept works switch. I've worked with many projects over the years where that was done. Sometimes an intern proved it works with arduino - which wat cheap enough to buy without needing supply management, but then we did the project with 'good code' on our internal controllers. Othertimes we bought a competitor andiagain first thing switched them to our controllers. (Our controllers are designed for harsh environments which means millions of dollars spent designing the case and connectors)
