I'm a long time user of the Arduino IDE for third party boards such as the Teensy. Recently I've switched to Platformio for coding. So I should be satisfied with never needing Arduino's cloud service.
But Adafruit points out a problem, which is that the cloud service is the only available option for students using school-issued Chromebooks. I can confirm that a school-issued Chromebook is likely to be set up to lock out access to any programming tools. We wouldn't want children to learn coding after all, right?
I think relying on a corporation to preserve our freedom to code is a bit too optimistic.
Chromebooks and iPads are both completely unsuitable for digital education in my opinion. They can be decent tools for education using digital resources, but that is something different.
To "force" someone to develop on a Chromebook is like giving someone a bicycle to become a race car driver.
That said, I usually flashed my arduinos and used bare metal C. Ironically I think it makes many things easier to learn and understand, provided you have a programming device.
What does a "digital education" look like, specifically?
Having spent several years teaching kids to code everything from games to lightbulbs on Chromebooks, I can confirm that there are certainly difficulties - but they're tradeoffs. I could spend my time coming up with a way to work through the platform restrictions, or I could spend my time maintaining a motley crew of devices and configurations. Having done it both ways, they both have different pain points.
You really can't compare a Chromebook with an iPad. On a Chromebook that I bought and that I fully own I can enable the Linux system and install whatever I want on it (it runs in a VM and it is a full Linux system). The iPad is artificially crippled for programming by Apple.
School IT departments are unlikely to allow this. Even if they don't have technical restrictions, they'll have policies that prohibit it (at least my kids' school district would).
School-issued devices are generally intended to be similar to devices a corporation would provision for non-technical workers.
Honest question, if you buy (just a hypothetical, I assume most parents can't afford to buy one) a Chromebook for your kid that will be used in school, do you have to lock it down or can you enable the Linux system (assuming that you want to do that and that your kid is interested in learning to program).
I think an old PC would be more useful then a chromebook to a kid interested in learning to program; also it avoids dealing with a School District IT Department, which have to defend themselves from all kinds of attack from annoying kids and parents, so are probably more technologically conservative then the average IT worker.
So my advice would be: Don't bother trying to provision a chrome-book to connect to some school network. Use a school-issued chromebook for school stuff (if that's what they issue...), use a normal PC for extracurricular learning.
For the record: my kids are in elementary school, and are issued lenovo laptops running windows. They are locked down to the point where they might as well be chromebooks; kids have unprivileged accounts and are allowed to run very few programs. This is as it should be; those computers are for a very specific purpose, and are not general purpose toys.
> a School District IT Department, which have to defend themselves from all kinds of attack from annoying kids
Indeed, when I was in school, the WiFi networks were very poorly secured, so it was easy for annoying kids to get their own computers onto school networks if other students were using school-issued laptops around them. Annoying!
Schools typically don't allow BYOD policies because of support costs and equitability between students. Assuming a school district even did allow this, they would only allow the student to use a managed Chrome profile and the school's device policy would lock out the Linux VM option and everything else that might become an in-class distraction.
If a kid wants to learn how to program, they're going to have to bring their own separate computer and it will be treated about the same as bringing their smartphone to class, i.e. not allowed except during very specific times, there would be concerns about liability of damage or theft from other students, and they probably wouldn't allow it on the school networks.
Most larger school systems (if they allowed it at all) would end up "locking" the device as if it were one of theirs for the duration, just like some companies allow you to bring your own laptop or phone, but it becomes "as if it were theirs" while it is managed.
Support costs, mainly.
A small school that does its own IT is more likely to be flexible.
Your personally owned Chromebook isn’t comparable to a school issued Chromebook at all. They’re more locked down and useless than a stock iPad. Kids cannot install Linux on them.
You commented in context of digital education. The point is that your argument of Chromebooks comparing better to iPads doesn't apply in this situation. In fact they're often worse because schools deploy the cheapest, lowest common denominator Chromebooks with slow CPUs, horrible screen resolutions, inadequate RAM and terrible battery life. Kids hate them. The fact that good and uncrippled Chromebooks exists doesn't help them at all. A 5 year old iPad is likely a better experience and a more capable OS and device than a new Chromebook issued to students this fall, but the warranty and repair costs for schools dealing with careless kids don't add up to less so they get the cheaper option.
> On a Chromebook that I bought and that I fully own I can enable the Linux system and install whatever I want on it (it runs in a VM and it is a full Linux system).
Do you really own it ? Can you install linux or BSD _instead_ of ChromeOS ?
Yes[1], depending on the chromebook / chrometablet it will have varying levels of support for even swapping the firmware and running standard linux/BSD. Sometimes you will need to open up the laptop for a jumper/screw to adjust for enabling firmware flashing. Others its just turning on dev mode first.
Even then an ipad is not good. An Ipad is good for digital art and thats it. For the same money you can buy a computer capable of 3d modeling, digital art and a drawing tablet buy some paint brushes and clay to do real life art.
Apple has long provided tools for teaching kids how to code. Including lessons targeted at kids in middle schools.
> young coders are asked to assist these characters achieving simple goals by coding simple instructions. As challenges become more difficult, more complex algorithms are required to solve them and new concepts are introduced.
Your work Chromebook is completely incomparable to a school issued Chromebook. It's doubtful that your employer locks you out of literally everything that would allow you to develop software on-device. See my other comments in this thread.
People of HN-age are assuming that school Chromebooks are anything like the Apple-IIe or other computers they had "in the computer lab". Those machines had a "purpose" - but they were wide open for investigation by those who wanted to.
They're not. They're locked down as hard as they can be.
> It's doubtful that your employer locks you out of literally everything that would allow you to develop software on-device.
In strongly regulated industries, it is not unusual that you are indeed strongly locked out of this, and you need to create special requests to get access to the specific functionalities (as an exception) that you need for developing software on-device.
Right, many people have to treat their local computer as a thin-client and do everything through a WebEx session or similar means, which makes the local device irrelevant. Or if you're regulated but have to be specifically exempted and allowed to work in a way that schools would never permit, then in that case you'd not be arguing in good faith that kids are able to learn to code and develop on a Chromebook since they can't.
> Or if you're regulated but have to be specifically exempted and allowed to work in a way that schools would never permit, then in that case you'd not be arguing in good faith that kids are able to learn to code and develop on a Chromebook since they can't.
No, I just wanted to show that your claim
> It's doubtful that your employer locks you out of literally everything that would allow you to develop software on-device. See my other comments in this thread.
simply does not hold in practice.
--
Addendum: Additionally, from my school experience, rather the attempts to circumvent "abitrary" restrictions on the computers which were set up by the school made you a good coder. :-)
I recently had a great time developing on ESP-32 directly in VSCode/Cursor and using the Arduino CLI. I believe very similar in concept to Platformio. I've always hated being limited to the Arduino IDE.
> We wouldn't want children to learn coding after all, right?
Why aren't we teaching kids vibe coding? I've been told that is the future after all, and junior devs will never be needed ever again. All they need a webpage interface to an LLM to provide data and customer demographics for AI companies.
Because typically we don’t leap to teach kids things that are speculative.
We in the industry might see AI progressing to where cube vibe coding is just as real as using spreadsheets rather than paper ledger books, but it is years out, and teaching kids on v0.1 tools would just be frustrating for teachers while likely teaching kids all the wrong things.
My kids are absolutely learning how to use AI: every syllabus has guidelines for when AI usage is acceptable (it's not a blanket prohibition against), and they talk about both the pragmatic and ethical implications of it.
A school lesson where the teacher babbles about wishy-washy AI topics needs a lot less preparations by the teacher than a school lesson where he teaches scientifically sophisticated topics.
Technically any recent Chromebook can run Linux in a VM if enabled from settings. Now, I don't know if most schools forbid this, but since it is running in a VM it is safe to use for sure.
The reason people use Chromebooks is because they want to minimally manage the devices. The Chromebooks being locked down is ENTIRELY the point of using them in the first place...That and because Google.
Ever since I got involved with Espressif's ESP32/ESP8266 chips, I haven't even thought about arduinos, except to download the UI, but you don't even need to do that with the right VSCode extensions to make your life better.
Last time I used Arduino was probably the late 2000s, as a kid/teenager,student their prices always felt too high to me, so I moved to "compatibles" or "clones" for a while.
Once ESP8266 and ESP32 came along (with a detour thanks to Raspberry Pi coming along in the 2010s), there was really no need nor desire to use Arduino anymore and like you I forget about them.
Maybe they have a place in education, and maybe in industrial applications, but outside of that, I wouldn't even consider Arduino anymore.
PlatformIO by the way is excellent, and I've used it for all ESP8266/ESP32 development in VSCode for some time now, though increasingly I just use ESPHome, as my desire to program microcontrollers at a low level wanes and my desire to simply achieve the task quickly grows.
As a hacker and tinkerer I hate ESPHome. Yes it's super cool to have a turnkey "I want these sensors, give me firmware" but all of the code is hidden away and you can't easily modify or add to it.
If I want to run custom logic, I have to bundle a custom component into the esphome thing. Not bad I guess but I still don't like the lack of control
Arduino’s sweet spot was always in education and learning.
I think most people should graduate into PlatformIO or vendor tools if they’ve used Arduino to learn basics.
I think it’s great that the Arduino ecosystem became so large and capable, but it had the side effect of leading many beginners into thinking that Arduino was synonymous with microcontroller.
I even took a contract once updating a company’s internal tooling because their first contractor tried to do it all with Arduino. The same scenario happens with Raspberry Pi in the world of Linux embedded systems development.
Are there good ESP32-based starter kits with manual books which a kid can learn from? I was looking for an Arduino-like kit as a Christmas gift, and it seems that Arduino kits are unbeatable. The starter kit is available in 10 languages and comes with a project booklet. All ESP32-based products seem to be better suited for more advanced users and seem to have a steeper learning curve.
I use a combination of Adafruit Ampy to copy files, esptool to reflash, picocom for the REPL, and VSCode. Some of those might be redundant and it did take a bit to figure out the syntax. But once that’s determined it’s cake, and all saved in my CLI history. I just Ctrl+R and bring it back.
What do you think of PlatformIo on these chips compared to the official ESP IDF?
Personally, I am not convinced we should (continue) conflating the IDE with the build+flash tools; the former should be associated with the programming language and developer preferences, and the latter with the MCU being programmed.
I use the command line tool arduino-cli (with plain Makefile) to compile and upload the code (obviously usable in any editor). It has also a --verbose mode to show exactly what is getting executed.
But I heard a lot about platformio, so I am wondering what is its benefits (beside the integration in vscode; as an emacs user vscode is not working for me)
I think platformio's selling point is multiple target boards via ts config. That and you can use an actual editor instead of the arduino "IDE", although I'm not a fan of vscode anymore either.
I also think they have some testing features built in, though i never delved too deep.
I switched to platformio in vscode (and command line) a few months ago after using arduino ide for over a decade.
Can’t recommend it enough. Faster startup. Repeatable builds. The abilty to save your image and then flash on many devices. Build time parameters. Also allows access to some functionality that is not possible using arduino build process due to how arduino compiles and processes sketches.
The raspberry pico is much nicer to work with, if you're looking for an alternative. It has dual core if you need it, and the fun little IO coprocessors if you want to get really low level. The pico2 even has a risc-v mode
The process of getting a binary onto the board is just dragging a file, and on linux at least you can script it with picotool
+1, if only for the documentation. If you haven’t, skim through it: https://pip.raspberrypi.com/documents/RP-008373-DS-2-rp2350-... it’s truly unlike any reference manual I’ve ever read. I will happily pay a few extra cents at modest volumes for a chance to get the detailed technical details and opinions from the design team.
Flashing can be easy, sure. Compiling that binary, including library management, is not, unless you’re using something like micropython. CMake is not hobbyist/student-friendly as an introductory system. (Arduino isn’t either, but platformio with Arduino framework IS! RPi refuses to support platformio sadly)
Arduino took over for 3 reasons: a thoughtful and relatively low cost (at the time) development board that included easy one-click flashing, a dead-simple cross-platform packaging of the avr-gcc toolchain, and a simple HAL that enabled libraries to flourish.
Only the first item, and a bit of the second), is really outdated at this point (with clones and ESP32 taking over the predominant hardware) but the framework is still extremely prominent and active even if many don’t realize it. ESPHome for example still will generally use the Arduino HAL/Framework enabling a wide library ecosystem, even though it’s using platformio under the hood for the toolchain.
Even folks who “don’t use Arduino any more” and use platformio instead are often still leveraging the HAL for library support, myself included. Advanced users might be using raw esp-idf but the esp-idf HAL has had a number of breaking API changes over the years that make library support more annoying unless you truly need advanced features or more performance.
The flipside of this is that the RP2xxx has rather poor hard IP, and the PIO is not quite powerful enough to make up for it.
They are great for basic hobbyist projects, but they just can't compare to something like an STM32 for more complicated applications.
They are a pleasure to work with and I think that they are great MCUs, but every time I try to use them for nontrivial applications I end up being disappointed.
To give a very basic example: its times can't do input capture. This means you have no easy way to do high-accuracy pulse time measurement. Compare the two datasheets, and the STM33's timers literally have orders of magnitude more features.
Only having two UARTs can be limiting - and PIO is a no-go if you want offloaded parity checking and flow control. The PIO doesn't have an easy external clock input. No CAN or Ethernet makes usage in larger systems tricky. There's no USB Type-C comms support. Its ADC is anemic (only 4 channels, with 36 io pins?). There are no analog comparators. It doesn't have capacitive touch sensing. There's no EEPROM.
None of them are direct dealbreakers and you can work around most of them using external hardware - but why would you want to do so if you could also grab a MCU which has it fully integrated already?
That is exactly the problem: you need to use PIO to constantly read the pins, and analyze the bitstream in software. At high speeds this takes up a substantial fraction of your compute resources, and it makes any kind of sleep impossible.
On a STM32 you can just set up the timer and forget about it until you get a "hey, we saw a pulse at cycle 1234" interrupt. The two are not the same.
My argument wasn't "this is completely impossible", but "this is needlessly complicated".
Agreed; RP2040 doesn’t have true timer input-capture like STM32 (no CNT->CCR latch on edge). That criticism is fair.
What Pico/RP2040 projects do instead is use a PIO state machine clocked from the system clock to deterministically timestamp edges (often DMA’d out). It avoids ISR latency and gives cycle-accurate edge timing relative to the MCU clock. It’s not a built-in capture peripheral, but it achieves the same practical result.
If you want a drop-in hardware capture block with filtering and prescalers, STM32 is the better choice. RP2040 trades fixed peripherals for a programmable timing fabric.
Can you give an example of a chip with software-defined IO coprocessors that is 1/4 the price? The pricing I’m getting on the RP2350 is 0.6EUR per chip.
When I’ve compared to other dual-core SoCs with programmable IO, like NXP with FlexIO (~€11) or ESP32 chips with RMT (~€1) they are much more expensive than the RP2350.. is there a selection of programmable IO chips I’m missing?
That's the thing: with proper dedicated peripherals you don't need the software-defined coprocessors.
Sure, they are great if you want to implement some obscure-yet-simple protocol, but in practice everyone is using the same handful of protocols everywhere.
Considering its limitations, betting on the PIO for crucial functionality is a huge risk for a company. If Raspberry Pi doesn't provide a well-tested library implementing the protocol I want (and I don't think they do this yet), I wouldn't want to bet on it.
I think they are an absolutely amazing concept in theory, but in practice it is mostly a disappointment for anything other than high-speed data output.
In Cortex M33 land $15 will get you an entire NXP (or STM) dev board. An MCX-A156 will set you back about $5 which is about on par with an STM32H5. You can go cheaper than that in the MCX-A lineup if you need to. For what I'm working on the H5 is more than enough so I've not dug too deep into what NXP's FlexIO gives you in comparison. Plus STM's documentation is far more accessible than NXP's.
Now the old SAM3 chip in the Arudino Due is a different beast. Atmel restarted production and priced it at $9/ea. For 9k. Ouch. You can get knockoff Dues on Aliexpress for $10.
Edit: I'm only looking at single core MCUs here. The MCX-A and H5 lineups are single-core Cortex M33 MCUs. The SAM3 is a single core Cortex M3. The RP units are dual core M33. If the RP peripherals meet your needs I agree that's a great value (I'm seeing pricing of $1+ here).
Edit2: For dual core NXP is showing the i.MX RT700 at around $7.
That's true in general, but people do use these hobbyist boards as an alternative to a manufacturer dev board when prototyping an actual product.
It's reasonably common in the home automation space. A fair few low volume (but still commercial nevertheless) products are built around ESP32 chips now because they started with ESPHome or NodeMCU. The biggest energy provider in the UK (Octopus) even have a smart meter interface built on the ESP32.
To "yes, and..." you, the whole RP2040 microcontroller line is great and I would encourage folks to support the smaller maker/OSHW companies on Tindie[1] who use it.
I believe you need 5v to run the regular $4 pi pico board. The chip only requires 3.2v though so maybe it’s not a hard requirement? There are probably other lighter weight RP2040 boards but I don’t think months or years-long low power usage was an intended goal— it’s $4 (still!) with 40 GPIO pins and PIO and it runs micropython for people scared of/chafed by C— it’s a prototyping/hobby tool.
Pi Pico has a lower power mode that sleeps when not in use that draws well under 5v, but you the programmer have to activate it. I think it is called “lightsleep” but may be wrong.
The STM32L011 in no way requires the arduino IDE; your code would likely compile with GCC just fine. The pico would probably work if you redesigned your project, but your hardware very likely doesn't need to change, just the software you're using.
>It has dual core if you need it, and the fun little IO coprocessors
I think you're missing the point of what made arduino so popular. It's not the HW itself, it's that you can plug in whatever display, sensor or motor driver out there, and there's ready made templates in the IDE that gets you running immediately, without you having to know anything about how the HW or SW works under the hood.
The lack of dual cores or "fun IO coprocessor" whatever fun is in that context, was never an issue for the arduino.
There's a virtually unlimited number microcontrollers and boards out there for tinkering or production, that are more powerful and have more features, but they all have a higher technical barrier to entry than the standard Arduino out of the box.
I don't wanna have to read datasheets and erratas just to learn how to use a second core, deal with shared memory between cores, or how to configure the GPIO of the "fun IO coprocessor" just to get a LED blinking to work. That's not what fun is to a lot of people. Fun is getting the motor spinning until my coffee finishes brewing and that's where the Arduino ecosystem USP was versus other more powerful platforms.
> I don't wanna have to read datasheets and erratas
I recently started programming Arduino for profit and you need to do exactly that, because the libraries range from somewhat buggy to completely broken. They so often just write into random other registers and if it works it is only do to the chip already working without any configuration and the library not breaking things too badly.
This is from a child comment that is dead, but I still wanted to answer:
> szundi
> If you go mainstream with your requirements, you don’t step on these though
Absolutely not. I am talking about things like the example in the README, which actually doesn't do anything, because they forgot the shift to make it write into the right field. Or they added "support" in 2012 for the only chip which is still sold, but forgot to update the register addresses, so now you have code for a newer chip, which uses the register addresses of the old chip. This does not work with either chip. And this is all with the libraries "officially" "provided" by Arduino.
The RP2xxx also comes with excellent documentation and libraries. If anything, with the drag-n-drop flashing it is even easier to work with than an Arduino.
From a practical end user perspective, being able to buy a device, and download and install binaries onto it to make it perform a specific purpose by plugging it in and dragging the file over, is considerably easier than installing an IDE, and downloading compiling and installing from source.
> Are they more in number and easier to use than the Arduino libraries?
It's not either/or, beyond what's in the native SDK RP2 boards also benefit from the Arduino ecosystem via the excellent and well maintained https://github.com/earlephilhower/arduino-pico
> Are they more in number and easier to use than the Arduino libraries?
I haven't done a direct comparison, but considering that the hobbyist ecosystem (which is the main source of those libs) is shifting over, it is just a matter of time.
> Why do you think the Arduino is more difficult than "drag-n-drop flashing" by comparison?
Because you need to install an IDE and mess around with things like serial drivers - and it gets a lot more complicated if you ever have to flash a bootloader. It's not hard, but it's definitely not as trivial as the RP2xxx's drag-n-drop.
Seems fine. There's a Qualcomm SaaS platform you don't need that they have the boilerplate no-hacking clause on. And Arduinos are the same as always. Considering the EFF and Arduino positions in favour, both of whom have done a lot for open-source stuff, I really can't be bothered that Adafruit is trying to drum up some marketing content.
My first Arduino was something like 15 years ago as well, a Duemilanove. I suspect my parents still have it. I'm not saying nothing can change over time, but there's always one controversy after another online these days in software communities and I think rather than trust the latest mob I'm going to trust the guy who's been serving me well for more than a decade. These openness purity tests are really not for me.
Same story on this side and same feelings. It doesn't matter to the mob, the perception is all. Who cares that there's a website which is not open source, you don't buy an arduino for the website. You buy it because it's cheap and easy to use. Otherwise everyone would still be flashing atmel 8s
>there's always one controversy after another online these days in software communities and I think rather than trust the latest mob I'm going to trust the guy who's been serving me well for more than a decade. These openness purity tests are really not for me.
Thanks you! Sad that HN gets ideologically captured in the same mob behavior instead of thinking logically and practically.
>The logical thinking is: are they going to make me dependent on some cloud service to develop for Arduino?
The logic to me is "how can they do that?". You don't need a cloud service to program a microcontroller and they can't force that upon you even if they'd want to since the arduino board is not an iPhone.
Yep, it's fine to not consider future versions when you do say hobby projects, but I worked on a commercial Arduino based project that's supposed to run on top of poles on solar. For that I very much care if they plan to make it cloud dependent... and I don't assume sanity on part of management.
This article doesn’t really explain how the new Arduino stuff works, which makes it harder to judge the impact of these new licenses. I’m used to flashing microcontroller boards over USB, originally from the Arduino IDE, more recently with PlatformIO. I’ve bought boards that have WiFi, but it wasn’t an essential part of the development environment.
I did a bit of searching and found some sketchy documentation that just leaves me with more questions. It sounds like Arduino’s new web editor programs boards wirelessly somehow? Does it assume the board has WiFi? What is this new, networked system? What Internet protocols does it use? How do you pair it with the web editor?
Wait, does the IDE no longer work with cloud/account?/etc.?
I have a old Arduino UNO R3, would be a really disappointing if I could no longer play around with it by just downloading the IDE and connecting the cables.
"- All-in-one toolbox: Arduino UNO Q combines the powerful Qualcomm® Dragonwing™ QRB2210 microprocessor (MPU) with a real-time STM32U585 microcontroller (MCU) – no matter what you’re building, it’s your new go-to tool!
- AI in a blink: unlock AI-powered vision and sound solutions that react to their environment."
Okay, so if you want to use a microprocessor that isn't targetted by an open-source compiler and assembler, you're going to have to use proprietary stuff.
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.
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)
Was going to quote this exact line. Yes, what was open stays open, but unmaintained, then development/updates/patches are moved to the close(r) alternative until the hassle of running the open old one isn't worth the effort anymore and the need of updated/debugged libraries or board definitions forces the users to migrate.
I wonder how doable would be a fork of the whole shebang with the online downloadable content hosted somewhere.
It's a bit odd that most of this article is various claims from one of Arduino's competitors being taken at face value, especially when the EFF spokesperson generally seems to think the new terms broadly make sense, albeit with some criticisms.
It sounds like Adafruit are just trying to sow some outrage here.
Adafruit makes a ton Arduino libraries, and sells boards and starter kits. They also make their own stuff, and sell things from their other "competitors." I got my first arduino from them over 19 years ago.
Their real competitor is sparkfun, but I never heard them say anything to put them down.
Historically neither of them made any microcontrollers. Arduino shipped Atmel and Raspberry Pi chips. Adafruit has boards with a variety of microcontrollers from various brands on them.
This is different now that Arduino is Qualcomm-owned and ships Qualcomm silicon, of course.
They also sell feather and a bunch of other vaguely similar stuff and have their own "maker" ecosystem (think CircuitPython). I like Adafruit, but they are in many senses competitors to Arduino.
I understand adafruit's take at it. But I guess they are simply plain wrong when saying 'incompatible', at least from a pure license perspective for the HW/firmware.
As other pointed out, companies like Google demonstrate, how open source can be used in a rather aggressive commercial strategy. However, I think the good news is that that the open hardware stuff is not rocket science and maintenance hell at this point (without the new Qualcomm bits). I guess it is now for others to step up and make the ecosystem resilient. That is IMHO the power of open source in case it works.
Adafruit is pretty clearly the front-runner these days in the educational/hobbyist market, Arduino (and even SparkFun) have fallen by the wayside. My only gripe is the focus on micropython these days, it can introduce a barrier later in the learning process when you eventually need to leave the nicely organized sandbox. They still support the “Arduino” C++ libraries, but uPy is the default.
Adafruit actually focus on CircuitPython which is a fork of Micro Python but takes some of the complexity of Micro Python away. I don't personally like coding in C++ as I started my career with Perl then PHP and Javascript. Writing Python in my own choice of text editor instead of the Arduino IDE is much more my style.
A couple of weeks ago, I bought a 'sensor kit' from Amazon for my son to use with his Raspberry Pi. It includes some input devices (e.g. button, moisture sensor) and output devices (e.g. LED) that can be plugged onto breadboard.
In my experience LLMs can code C++ for the Arduino framework pretty well these days. The mistakes they make, like wrong pin numbers, are pretty language agnostic.
I never use Arduino or Arduino IDE anyway; it's incredibly laggy for me, and I hate having these things in the cloud. I mainly use Pico and VS Code now.
There is a version of Thonny[1] designed for use with the Pico that is great for education. Raspberry Pi have some good resources on getting started[2].
If your target audience is school kids, you really can't go past the micro:bit and Makecode[3].
The Micro:bit Educational Foundation also make a web-based Python Editor at https://python.microbit.org which is designed to be a supportive introduction to text-based coding and physical computing with no installation, friendly error messages and device simulation
I am endlessly thankful for the Arduino project as it was one of the major gateways to programming for me, but at the same time, I bought an Arduino R4 and have barely even used it. ESP32, Raspberry Pi, and even 8 bit Atmel chips get way more attention from me. I'm guessing that Renesas chip on the R4 won't be getting too much attention anymore.
I feel like Arduino has lost its unique place in all but mindshare 5+ years ago. What I would recommend as a default:
- Wi-Fi: Esp Risc-V (C3 etc)
- BLE without Wi-Fi (Or ANTD): Nordic. Also a good choice in general for simple devices
- General-purpose, including high-performance, low-power, and high I/O: Stm32
Use whichever IDE is suitable for the language you're programming in. (Jetbrains, Zed, VsCode etc). Use the specialty IDEs like Cube for viewing pinouts and configuring hardware as a reference.
If using rust, probe-rs + cargo is a "just works" CLI workflow to compile, flash, and debug.
As an aside, I have never seen a decent license for user generated content. Either they expose the platform to serious liability, or they come across as incredibly predatory.
In this context, the license is for using the Arduino Studio application. This is hosted by Arduino, and therefore needs to take user input, save it and work with it. As I understand it, this puts them in a complex situation: they don't own the code you've written (obviously), but they do need to do things with it like compile it and run it (when you press the button in the IDE). They're also hosting the code and therefore partly legally responsible for it.
At the very least, you need some sort of user agreement to specify the things you can do with their content, otherwise you can't really do it because it's their content and you're not allowed to mess with it by default. (Like you said, code is copyrighted by default.) You also need to specify the things that are necessary by law because you are hosting that code and therefore in part responsible for it. You also don't want to make the user sign a new agreement every other week if you add some new feature that they need to agree to use, because the cost of all those legal documents is prohibitive, and it's also very bad UX.
Added to this the fact that lawyers are naturally very conservative as a profession (generally only doing things that have been proven successful, rather than avoiding things that have been proven unsuccessful), and it's easy to see why these sorts of agreements tend to be more expansive than they perhaps need to be, in order to ensure the company is fully protected.
Is this actually true? Doesn't the action of directing someone to compile this code, mean they are allowed to compile this code? Of course they are not allowed to do anything else, but this is what I want as a user. I think it is more, that the vendors want to push the user to grant them more rights than what would be strictly necessary for them to do they job they "sell".
This is what's been explained to me before. The problem is that lawyers don't necessarily work on the basis of "if it seems reasonable that the user allowed this, then this is allowed". Their goal is to make a contract that, if they need to go to court, will make their job as easy as possible. So it's not enough to say "obviously the user pressed the 'compile' button and we needed to do all this stuff to make that happen, here's all my technical experts who agree", instead they would rather say "paragraph 3 subsection 12 clearly allows this behaviour and the user has agreed to it".
It's also, as I understand it, the reason why law has so much of an emphasis on seemingly magic phrases that you copy and repeat in all sorts of different places. These are phrases that have already been tested and have a meaning that has been made clear in a court of law, so if you need to go to court to defend them, you can pull up the existing case law on the subject and rely on that, rather than having to analyse exactly what the new wording means. Hence why these T&C documents tend to have a lot of fairly standard phrases that don't obviously mean what you expect them to mean.
Allow the user to license the content that they generate. I can write a novel with Microsoft Word, and Microsoft has no claim over it -- why should any IDE tools be different?
Hobbyists don’t get full exposure to this, but the reality is that the embedded space is still very much a binary blob landscape. Even relatively popular SDKs like Expressif and Nordic’s are full of weird proprietary stuff, and it just gets worse as you go into beefier hardware (Rockchip, I’m looking at you).
But yeah, Arduino is in a weird place right now. I knew people there (kind of lost track), quite liked their IDE and how accessible it made a lot of things, but the recent turn on events is just… weird.
That has been a long way coming. Only a couple of months ago I was looking at alternatives and "Arduino compatible" products. The reason being simply that so many "for fun projects" are built with it and I wondered what good alternatives there are.
I kind of drifted off. So curious about what people here think is the best "Arduino when it still was open source" contender. Preferably something Arduino compatible because of the sheer amount of projects already out there.
That said I've heard a fair bit about Adafruit criticism as well, but that's more on the company level and no personal experience there.
T&C's preventing reverse engineering of an online platform seems to have no real business value. Serious hackers will ignore the T&C's, whilst serious competitors will not need to do any reverse engineering to build an online compiler.
These days I don't think Arduinos are meaningfully more accessible than, say, an ESP8266 or ESP32. If I was starting a new hobby project today I'd choose the latter.
That's only if you're using the Arduino IDE though, and it's so commonplace that instructions are widespread. Many are using MicroPython/CircuitPython which are independent from Arduino.
The first esp8266 I bought was as a dedicated wifi chip for an arduino (or something) project. I discovered after getting it, that it came with a 'free' MCU (that was default flashed with a UART/AT-command firmware to allow other MCUs to get wifi)
Arduino was always a terrible pseudo-language/IDE, taught bad workmanship, and had problems with fast chip io handling etc.
However, it was a "standard" boot-loader, had consistent documentation, and a wide community of users. It encouraged people of all skill levels to play with chips, and that was great.
These days a full Linux SoC is often cheaper than most mcu. The age of the Arduino board will just end a little quicker now. Generally, irritating a planet of bored computer engineers does not end well for a business. =3
The problem space a full Linux SoC solves is very different from the problem an MCU solves. (Imagine a lot of real time io, interacting with a lot of peripherals etc....)
What's eating Arduino's lunch is the various mcus: risc v, stm32, esp32 etc...
Arduino was the first (and then, the only) simple microcontroller, that you could give to someone, even a child, give them a 5 page tutorial, and they'd be able to blink leds, capture a button press, a potentiometer input and display the results via leds or 7 segment displays. Every other microcontroller needed a special board to program it, you needed a thick book to program it, take care of registers, use some weird windows-only ide and usually none of that was free... arduino was just different, one board, one cable, free software and good documentation.
Of course, an ecosystem has grown around that, so you could attach pretty much any popular device (sensor, display, input device,...) to it, and the library was already made for you to simply use it in your project.
But now, years later? There are many such controllers, from esp8266/esp32 to rpi pico, with additional features (wifi included) on better boards (displays, buttons, interfaces,...), for even less money.
Yes, the original arduino was important.. but if it vanishes overnight, very few people would notice.
>Adafruit’s Torrone had also said Arduino’s new documents “introduce an irrevocable, perpetual license over anything users upload.”
Yea that's gonna be a hard pass for me. Thank goodness for the Pi Pico which means I'll never have to use Arduino ever again. On a side note, the new Arduino IDE based on Monaco looked nice but made development so painful I just stopped. I had to keep disconnecting and reconnecting devices all the time to upload sketches when before with the old IDE that was never an issue. Everything Arduino feels like a regression.
IMO too many people come to the conclusion that Qualcomm will in some way screw up the Arduino takeover at the expense of the community.
And I think these people are right, but that is not necessary a bad thing.
There is just about no reason a giant like Qualcomm would take over something like Arduino for any other purpose but to acquire resources (talent, customers, community, processes, documentation, ...) they can use to teach themselves how to become more open, to what degree they even want to and to have a trusted platform they can take their initial steps in and will get feedback from.
And the reality is, that someone with little experience will screw up badly, several times. I mean, look at the current state of the major silicon IP holders, the only reason they dont ship brain-chips with their NDAs that explode the moment you mention the wrong part number infornt of a competitor is because the NDAs for the documentation on how to install the brain-chips would get them stuck in recursion hell.
And just as little experience Qualcomm has at making open source a successful business strategy, Arduino has just as little experience at being a corporate Godzilla trying to carefully pet the egg they just adopted. And let's be real: Open source projects OWE it to their community to be financially successful, because it's that financial success that guarantees that the project CAN STAY open and wont force its core maintainers into choosing between their commitment to their community and a fulfilling lifestyle, although for someone like Qualcomm this success can probably be something else but financial in nature (acquiring talent, their products becoming a preferred choice, schools teaching students using Qualcomm products, whatever).
Both Arduino and Qualcomm will end up outside of their domain and it'd be surprising if this would not result in major mistakes being made.
.
Qualcomm has to evaluate whether their new talent at Arduino is doing a good job and are suddenly looking at a giant dumpster fire, wondering what could have possibly caused this since their lawyers aren't even half-done sticking on the "by Qualcomm" labels yet.
Right now, instead of trying to pressure Qualcomm into making commitments they do not understand, the community should try to adopt the role of a stakeholder, who prioritizes a long and healthy relationship with a currently struggling contractor over getting the desired product at a reasonable timeline.
The community needs to make a cold day in hell happen, calm down, get together and formalize what they think they liked about Arduino up until now, the fundamental requirements that need to be retained or even developed and what would be nice to have.
Is this another one of those opensource project gone wrong, that when they lose the user base because of this gray(blackish) i would say) “new terms” they apologise and try to come back… often too late?
After Qualcomm bought them? Who could have seen this coming? Hang on while I get back to arguing with my MSP that I really would prefer ProxMox over HyperV to replace VMWare.
I did some evaluating on this option and there's definitely complexity to bear in mind: Proxmox has worse support for my storage and backup solutions, and if the MSP you are working with has a ton of experience on Hyper-V migrations and limited Proxmox experience, the support you get will lack.
I will say I'd eventually love to have my day job environment on Proxmox but it isn't quite ready to be there today. No shade to anyone who is able to be there by any means, but I think it's fair to say hypervisors aren't something you want to choose on vibes alone.
We need to get off of VMWare as the min license for us is now $15k pre year… from $3k. But the MSP knows the support for ProxMox isn’t there, and they have SLA contracts to uphold.
I’m going to have to HyperV which I expect to have the same issues as VMWare soon enough/someday.
IMHO the key thing is to build your ability to switch. VMware did this because nobody has plans to switch their hypervisor. Learn to.
If you go to Hyper-V this year, leave yourself the flexibility to move away from it in a couple years. Choose backup solutions and storage solutions which enable flexibility.
We back up VM’s with Veeam, but we don’t back up the content outside of the VM presence if that makes any sense.
They’re effectively telling me we go to hypervisor this year before Feb for VMWare billing reasons. And my hope is that by the time I get tired of HyperV, or we need to move that a solution exists to convert to next.
It’s either that, or they’re trying to sell me on scale computing VM’s and their hardware.
Veeam is a good start because they already support a bunch of hypervisors and are working on more. But for example, Veeam can't yet do replication with Proxmox, but it can with VMware and Hyper-V.
For hardware, I'd avoid going in on hypervisor platforms that need you to buy their specific hardware. Your standard Dell, HP, Lenovo servers can run almost anything, but if you buy a hyperconverged system you are going to get yourself locked in.
A big lesson I learned is: Make sure to divide up your storage pools enough! There's no easy way to gradually migrate if your storage array is one big VMware VMFS file system.
There is a lot of shade being thrown against Adafruit in this discussion thread which is disappointing.
It is disappointing because it distracts from the discussion around Open Source and Arduino as a long term educational tool. Regardless if that shade is in good faith or not, it distracts from the conversation we should be having.
So this citation, is basically fake news and FUD.
The *now* part is false and this hide the fact that the "platform" is only the SaaS.
> Phillip Torrone had warned [...] Arduino’s users were now “explicitly forbidden from reverse engineering or even attempting to understand how the platform works unless Arduino gives permission.”
I’ve never heard of this, and it feels like if true this is the type of thing that would be covered. Do you have any links to references that support this claim?
The doxxing listed here is saying a person's first name? I think? Maybe former name? This is hard to follow. It's so deep in arguing about arguing that I can't tell if he's a 1/10 problem or a 9/10 problem.
I probably missed some of the cross links but this is a mess.
Can you elaborate on "harassing trans people"? From these links at best I can guess at one of them being trans but I can't tell if that's related to the argument; who else is on that list?
This adds a little more context, but it still seems to be a complete nothingburger. It also looks like the user was harassing adafruit for not condemning the use of AI.
But Adafruit points out a problem, which is that the cloud service is the only available option for students using school-issued Chromebooks. I can confirm that a school-issued Chromebook is likely to be set up to lock out access to any programming tools. We wouldn't want children to learn coding after all, right?
I think relying on a corporation to preserve our freedom to code is a bit too optimistic.
To "force" someone to develop on a Chromebook is like giving someone a bicycle to become a race car driver.
That said, I usually flashed my arduinos and used bare metal C. Ironically I think it makes many things easier to learn and understand, provided you have a programming device.
Having spent several years teaching kids to code everything from games to lightbulbs on Chromebooks, I can confirm that there are certainly difficulties - but they're tradeoffs. I could spend my time coming up with a way to work through the platform restrictions, or I could spend my time maintaining a motley crew of devices and configurations. Having done it both ways, they both have different pain points.
More recently, kids can have a ton of fun programming STM32, making DACs, audio gear, robots, etc.
School-issued devices are generally intended to be similar to devices a corporation would provision for non-technical workers.
So my advice would be: Don't bother trying to provision a chrome-book to connect to some school network. Use a school-issued chromebook for school stuff (if that's what they issue...), use a normal PC for extracurricular learning.
For the record: my kids are in elementary school, and are issued lenovo laptops running windows. They are locked down to the point where they might as well be chromebooks; kids have unprivileged accounts and are allowed to run very few programs. This is as it should be; those computers are for a very specific purpose, and are not general purpose toys.
Indeed, when I was in school, the WiFi networks were very poorly secured, so it was easy for annoying kids to get their own computers onto school networks if other students were using school-issued laptops around them. Annoying!
If a kid wants to learn how to program, they're going to have to bring their own separate computer and it will be treated about the same as bringing their smartphone to class, i.e. not allowed except during very specific times, there would be concerns about liability of damage or theft from other students, and they probably wouldn't allow it on the school networks.
Support costs, mainly.
A small school that does its own IT is more likely to be flexible.
Do you really own it ? Can you install linux or BSD _instead_ of ChromeOS ?
[1]https://docs.mrchromebox.tech/docs/supported-devices.html
To answer your questions, it depends. On some Chromebook models you can wipe ChromeOS and install Linux.
If you mean computer science then yes you are correct.
> young coders are asked to assist these characters achieving simple goals by coding simple instructions. As challenges become more difficult, more complex algorithms are required to solve them and new concepts are introduced.
https://en.wikipedia.org/wiki/Swift_Playgrounds
Lol, I use a Chromebook for development at work
They're not. They're locked down as hard as they can be.
In strongly regulated industries, it is not unusual that you are indeed strongly locked out of this, and you need to create special requests to get access to the specific functionalities (as an exception) that you need for developing software on-device.
No, I just wanted to show that your claim
> It's doubtful that your employer locks you out of literally everything that would allow you to develop software on-device. See my other comments in this thread.
simply does not hold in practice.
--
Addendum: Additionally, from my school experience, rather the attempts to circumvent "abitrary" restrictions on the computers which were set up by the school made you a good coder. :-)
Why aren't we teaching kids vibe coding? I've been told that is the future after all, and junior devs will never be needed ever again. All they need a webpage interface to an LLM to provide data and customer demographics for AI companies.
We in the industry might see AI progressing to where cube vibe coding is just as real as using spreadsheets rather than paper ledger books, but it is years out, and teaching kids on v0.1 tools would just be frustrating for teachers while likely teaching kids all the wrong things.
I do keep meaning to try this though - https://platformio.org/
Once ESP8266 and ESP32 came along (with a detour thanks to Raspberry Pi coming along in the 2010s), there was really no need nor desire to use Arduino anymore and like you I forget about them.
Maybe they have a place in education, and maybe in industrial applications, but outside of that, I wouldn't even consider Arduino anymore.
PlatformIO by the way is excellent, and I've used it for all ESP8266/ESP32 development in VSCode for some time now, though increasingly I just use ESPHome, as my desire to program microcontrollers at a low level wanes and my desire to simply achieve the task quickly grows.
If I want to run custom logic, I have to bundle a custom component into the esphome thing. Not bad I guess but I still don't like the lack of control
I think most people should graduate into PlatformIO or vendor tools if they’ve used Arduino to learn basics.
I think it’s great that the Arduino ecosystem became so large and capable, but it had the side effect of leading many beginners into thinking that Arduino was synonymous with microcontroller.
I even took a contract once updating a company’s internal tooling because their first contractor tried to do it all with Arduino. The same scenario happens with Raspberry Pi in the world of Linux embedded systems development.
Personally, I am not convinced we should (continue) conflating the IDE with the build+flash tools; the former should be associated with the programming language and developer preferences, and the latter with the MCU being programmed.
PIO + esp-IDF is the only way I write ESP firmware.
I also think they have some testing features built in, though i never delved too deep.
Can’t recommend it enough. Faster startup. Repeatable builds. The abilty to save your image and then flash on many devices. Build time parameters. Also allows access to some functionality that is not possible using arduino build process due to how arduino compiles and processes sketches.
The process of getting a binary onto the board is just dragging a file, and on linux at least you can script it with picotool
Arduino took over for 3 reasons: a thoughtful and relatively low cost (at the time) development board that included easy one-click flashing, a dead-simple cross-platform packaging of the avr-gcc toolchain, and a simple HAL that enabled libraries to flourish.
Only the first item, and a bit of the second), is really outdated at this point (with clones and ESP32 taking over the predominant hardware) but the framework is still extremely prominent and active even if many don’t realize it. ESPHome for example still will generally use the Arduino HAL/Framework enabling a wide library ecosystem, even though it’s using platformio under the hood for the toolchain.
Even folks who “don’t use Arduino any more” and use platformio instead are often still leveraging the HAL for library support, myself included. Advanced users might be using raw esp-idf but the esp-idf HAL has had a number of breaking API changes over the years that make library support more annoying unless you truly need advanced features or more performance.
They are great for basic hobbyist projects, but they just can't compare to something like an STM32 for more complicated applications.
They are a pleasure to work with and I think that they are great MCUs, but every time I try to use them for nontrivial applications I end up being disappointed.
> nontrivial applications
Out of curiosity, where do you find that you’re hitting the limits of what it can handle?
Only having two UARTs can be limiting - and PIO is a no-go if you want offloaded parity checking and flow control. The PIO doesn't have an easy external clock input. No CAN or Ethernet makes usage in larger systems tricky. There's no USB Type-C comms support. Its ADC is anemic (only 4 channels, with 36 io pins?). There are no analog comparators. It doesn't have capacitive touch sensing. There's no EEPROM.
None of them are direct dealbreakers and you can work around most of them using external hardware - but why would you want to do so if you could also grab a MCU which has it fully integrated already?
is 2.5ns (https://github.com/gusmanb/logicanalyzer) to 3.3ns (https://github.com/schlae/pico-dram-tester) resolution not enough for you?
On a STM32 you can just set up the timer and forget about it until you get a "hey, we saw a pulse at cycle 1234" interrupt. The two are not the same.
My argument wasn't "this is completely impossible", but "this is needlessly complicated".
What Pico/RP2040 projects do instead is use a PIO state machine clocked from the system clock to deterministically timestamp edges (often DMA’d out). It avoids ISR latency and gives cycle-accurate edge timing relative to the MCU clock. It’s not a built-in capture peripheral, but it achieves the same practical result.
If you want a drop-in hardware capture block with filtering and prescalers, STM32 is the better choice. RP2040 trades fixed peripherals for a programmable timing fabric.
There are similar chips at a quarter of the price.
Obviously for hobbyist stuff, $1 doesn't really matter.
When I’ve compared to other dual-core SoCs with programmable IO, like NXP with FlexIO (~€11) or ESP32 chips with RMT (~€1) they are much more expensive than the RP2350.. is there a selection of programmable IO chips I’m missing?
Sure, they are great if you want to implement some obscure-yet-simple protocol, but in practice everyone is using the same handful of protocols everywhere.
Considering its limitations, betting on the PIO for crucial functionality is a huge risk for a company. If Raspberry Pi doesn't provide a well-tested library implementing the protocol I want (and I don't think they do this yet), I wouldn't want to bet on it.
I think they are an absolutely amazing concept in theory, but in practice it is mostly a disappointment for anything other than high-speed data output.
Now the old SAM3 chip in the Arudino Due is a different beast. Atmel restarted production and priced it at $9/ea. For 9k. Ouch. You can get knockoff Dues on Aliexpress for $10.
Edit: I'm only looking at single core MCUs here. The MCX-A and H5 lineups are single-core Cortex M33 MCUs. The SAM3 is a single core Cortex M3. The RP units are dual core M33. If the RP peripherals meet your needs I agree that's a great value (I'm seeing pricing of $1+ here).
Edit2: For dual core NXP is showing the i.MX RT700 at around $7.
It's reasonably common in the home automation space. A fair few low volume (but still commercial nevertheless) products are built around ESP32 chips now because they started with ESPHome or NodeMCU. The biggest energy provider in the UK (Octopus) even have a smart meter interface built on the ESP32.
[1] https://www.tindie.com/search/?q=rp2040
I'm asking because used Arduino ide to program STM32L011 and it would run for months or even years.
I think you're missing the point of what made arduino so popular. It's not the HW itself, it's that you can plug in whatever display, sensor or motor driver out there, and there's ready made templates in the IDE that gets you running immediately, without you having to know anything about how the HW or SW works under the hood.
The lack of dual cores or "fun IO coprocessor" whatever fun is in that context, was never an issue for the arduino.
There's a virtually unlimited number microcontrollers and boards out there for tinkering or production, that are more powerful and have more features, but they all have a higher technical barrier to entry than the standard Arduino out of the box.
I don't wanna have to read datasheets and erratas just to learn how to use a second core, deal with shared memory between cores, or how to configure the GPIO of the "fun IO coprocessor" just to get a LED blinking to work. That's not what fun is to a lot of people. Fun is getting the motor spinning until my coffee finishes brewing and that's where the Arduino ecosystem USP was versus other more powerful platforms.
I recently started programming Arduino for profit and you need to do exactly that, because the libraries range from somewhat buggy to completely broken. They so often just write into random other registers and if it works it is only do to the chip already working without any configuration and the library not breaking things too badly.
> szundi
> If you go mainstream with your requirements, you don’t step on these though
Absolutely not. I am talking about things like the example in the README, which actually doesn't do anything, because they forgot the shift to make it write into the right field. Or they added "support" in 2012 for the only chip which is still sold, but forgot to update the register addresses, so now you have code for a newer chip, which uses the register addresses of the old chip. This does not work with either chip. And this is all with the libraries "officially" "provided" by Arduino.
Are they more in number and easier to use than the Arduino libraries?
>If anything, with the drag-n-drop flashing it is even easier to work with than an Arduino.
Why do you think the Arduino is more difficult than "drag-n-drop flashing" by comparison? Do you think one click is more difficult?
Look at how Ben Eater built and set up the SIDKPico to serve as a SID audio chip in his 8 bit breadboard computer here: https://www.youtube.com/watch?v=nooPmXxO6K0
It's not either/or, beyond what's in the native SDK RP2 boards also benefit from the Arduino ecosystem via the excellent and well maintained https://github.com/earlephilhower/arduino-pico
I haven't done a direct comparison, but considering that the hobbyist ecosystem (which is the main source of those libs) is shifting over, it is just a matter of time.
> Why do you think the Arduino is more difficult than "drag-n-drop flashing" by comparison?
Because you need to install an IDE and mess around with things like serial drivers - and it gets a lot more complicated if you ever have to flash a bootloader. It's not hard, but it's definitely not as trivial as the RP2xxx's drag-n-drop.
Even easier if you setup debugging using another pico, debug probe or even a Pi (not sure if this works on the 5)
This was evident to me when their original post "yada yada yada'd" over the details to make things in the agreement sound sinister.
Thanks you! Sad that HN gets ideologically captured in the same mob behavior instead of thinking logically and practically.
Don't know what Adafruit has a problem with, but the above is my problem.
The logic to me is "how can they do that?". You don't need a cloud service to program a microcontroller and they can't force that upon you even if they'd want to since the arduino board is not an iPhone.
License future important libraries only for use via their cloud toolchain?
Stop contributing support to non-cloud toolchain and/or intentionally break it?
Slip more restrictive licensing into new easy to use features (like a vision service) that taint combined products?
Never underestimate a company's ability to pay lawyers to restrict freedom.
Me too.
Due to the Qualcomm issue, or something else? I'm working for a small company, so we will likely just ignore it.
I did a bit of searching and found some sketchy documentation that just leaves me with more questions. It sounds like Arduino’s new web editor programs boards wirelessly somehow? Does it assume the board has WiFi? What is this new, networked system? What Internet protocols does it use? How do you pair it with the web editor?
I have a old Arduino UNO R3, would be a really disappointing if I could no longer play around with it by just downloading the IDE and connecting the cables.
It doesn't need to do anything with "the cloud".
https://store.arduino.cc/products/uno-q
"- All-in-one toolbox: Arduino UNO Q combines the powerful Qualcomm® Dragonwing™ QRB2210 microprocessor (MPU) with a real-time STM32U585 microcontroller (MCU) – no matter what you’re building, it’s your new go-to tool! - AI in a blink: unlock AI-powered vision and sound solutions that react to their environment."
You can just not buy their product.
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.
> 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.
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.
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.
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.
Now contemplate open Android and Google Play Services.
Or even that they forbid to use different clients for YouTube
Ineffectively, thank God
It sounds like Adafruit are just trying to sow some outrage here.
Their real competitor is sparkfun, but I never heard them say anything to put them down.
> Chief microcontroller rival Adafruit
Implying that Adafruit makes their own competing microcontrollers, which sure would have been news to me.
Edit: sees sibling posted at the same time. Well that would explain it.
This is different now that Arduino is Qualcomm-owned and ships Qualcomm silicon, of course.
As other pointed out, companies like Google demonstrate, how open source can be used in a rather aggressive commercial strategy. However, I think the good news is that that the open hardware stuff is not rocket science and maintenance hell at this point (without the new Qualcomm bits). I guess it is now for others to step up and make the ecosystem resilient. That is IMHO the power of open source in case it works.
The setup instructions included something to do with CircuitPython. I had not heard of it before then: https://github.com/sunfounder/universal-maker-sensor-kit/blo...
They are PCB brands. The microcontrollers are made by the usual manufacturers like ST, Renesas, Infineon...
But of course Arduino historically also didn't make the Atmel or Pico chips, so I can sort of see what they were going for.
If your target audience is school kids, you really can't go past the micro:bit and Makecode[3].
1. https://thonny.org
2. https://projects.raspberrypi.org/en/projects/getting-started...
3. https://makecode.microbit.org
If using rust, probe-rs + cargo is a "just works" CLI workflow to compile, flash, and debug.
Code is copyright without any licensing. The hardware is not licensed, I don't sign a license or agree to one when buying a car or microwave.
You can find edge cases, but the point is no licensing is actually required.
At the very least, you need some sort of user agreement to specify the things you can do with their content, otherwise you can't really do it because it's their content and you're not allowed to mess with it by default. (Like you said, code is copyrighted by default.) You also need to specify the things that are necessary by law because you are hosting that code and therefore in part responsible for it. You also don't want to make the user sign a new agreement every other week if you add some new feature that they need to agree to use, because the cost of all those legal documents is prohibitive, and it's also very bad UX.
Added to this the fact that lawyers are naturally very conservative as a profession (generally only doing things that have been proven successful, rather than avoiding things that have been proven unsuccessful), and it's easy to see why these sorts of agreements tend to be more expansive than they perhaps need to be, in order to ensure the company is fully protected.
It's also, as I understand it, the reason why law has so much of an emphasis on seemingly magic phrases that you copy and repeat in all sorts of different places. These are phrases that have already been tested and have a meaning that has been made clear in a court of law, so if you need to go to court to defend them, you can pull up the existing case law on the subject and rely on that, rather than having to analyse exactly what the new wording means. Hence why these T&C documents tend to have a lot of fairly standard phrases that don't obviously mean what you expect them to mean.
But yeah, Arduino is in a weird place right now. I knew people there (kind of lost track), quite liked their IDE and how accessible it made a lot of things, but the recent turn on events is just… weird.
Everything else is top notch open.
But for low power sensor stuff the ESP32 is far away from being my favorite anyway. That's almost all-in Nordic for me.
I kind of drifted off. So curious about what people here think is the best "Arduino when it still was open source" contender. Preferably something Arduino compatible because of the sheer amount of projects already out there.
That said I've heard a fair bit about Adafruit criticism as well, but that's more on the company level and no personal experience there.
(Disclosure: I know the Adafruit founder, but haven't discussed this matter with her.)
Why do you think it isn't?
T&C's preventing reverse engineering of an online platform seems to have no real business value. Serious hackers will ignore the T&C's, whilst serious competitors will not need to do any reverse engineering to build an online compiler.
We need an arduino fork.
There are also 10c RISCV cores available that people are starting to use
I don't think it "saves" it particularly though
Maybe it should all have been free software all the time.
However, it was a "standard" boot-loader, had consistent documentation, and a wide community of users. It encouraged people of all skill levels to play with chips, and that was great.
These days a full Linux SoC is often cheaper than most mcu. The age of the Arduino board will just end a little quicker now. Generally, irritating a planet of bored computer engineers does not end well for a business. =3
What's eating Arduino's lunch is the various mcus: risc v, stm32, esp32 etc...
Of course, an ecosystem has grown around that, so you could attach pretty much any popular device (sensor, display, input device,...) to it, and the library was already made for you to simply use it in your project.
But now, years later? There are many such controllers, from esp8266/esp32 to rpi pico, with additional features (wifi included) on better boards (displays, buttons, interfaces,...), for even less money.
Yes, the original arduino was important.. but if it vanishes overnight, very few people would notice.
Yea that's gonna be a hard pass for me. Thank goodness for the Pi Pico which means I'll never have to use Arduino ever again. On a side note, the new Arduino IDE based on Monaco looked nice but made development so painful I just stopped. I had to keep disconnecting and reconnecting devices all the time to upload sketches when before with the old IDE that was never an issue. Everything Arduino feels like a regression.
And I think these people are right, but that is not necessary a bad thing.
There is just about no reason a giant like Qualcomm would take over something like Arduino for any other purpose but to acquire resources (talent, customers, community, processes, documentation, ...) they can use to teach themselves how to become more open, to what degree they even want to and to have a trusted platform they can take their initial steps in and will get feedback from.
And the reality is, that someone with little experience will screw up badly, several times. I mean, look at the current state of the major silicon IP holders, the only reason they dont ship brain-chips with their NDAs that explode the moment you mention the wrong part number infornt of a competitor is because the NDAs for the documentation on how to install the brain-chips would get them stuck in recursion hell.
And just as little experience Qualcomm has at making open source a successful business strategy, Arduino has just as little experience at being a corporate Godzilla trying to carefully pet the egg they just adopted. And let's be real: Open source projects OWE it to their community to be financially successful, because it's that financial success that guarantees that the project CAN STAY open and wont force its core maintainers into choosing between their commitment to their community and a fulfilling lifestyle, although for someone like Qualcomm this success can probably be something else but financial in nature (acquiring talent, their products becoming a preferred choice, schools teaching students using Qualcomm products, whatever).
Both Arduino and Qualcomm will end up outside of their domain and it'd be surprising if this would not result in major mistakes being made.
.
Qualcomm has to evaluate whether their new talent at Arduino is doing a good job and are suddenly looking at a giant dumpster fire, wondering what could have possibly caused this since their lawyers aren't even half-done sticking on the "by Qualcomm" labels yet.
Right now, instead of trying to pressure Qualcomm into making commitments they do not understand, the community should try to adopt the role of a stakeholder, who prioritizes a long and healthy relationship with a currently struggling contractor over getting the desired product at a reasonable timeline.
The community needs to make a cold day in hell happen, calm down, get together and formalize what they think they liked about Arduino up until now, the fundamental requirements that need to be retained or even developed and what would be nice to have.
I will say I'd eventually love to have my day job environment on Proxmox but it isn't quite ready to be there today. No shade to anyone who is able to be there by any means, but I think it's fair to say hypervisors aren't something you want to choose on vibes alone.
We need to get off of VMWare as the min license for us is now $15k pre year… from $3k. But the MSP knows the support for ProxMox isn’t there, and they have SLA contracts to uphold.
I’m going to have to HyperV which I expect to have the same issues as VMWare soon enough/someday.
If you go to Hyper-V this year, leave yourself the flexibility to move away from it in a couple years. Choose backup solutions and storage solutions which enable flexibility.
We back up VM’s with Veeam, but we don’t back up the content outside of the VM presence if that makes any sense.
They’re effectively telling me we go to hypervisor this year before Feb for VMWare billing reasons. And my hope is that by the time I get tired of HyperV, or we need to move that a solution exists to convert to next.
It’s either that, or they’re trying to sell me on scale computing VM’s and their hardware.
For hardware, I'd avoid going in on hypervisor platforms that need you to buy their specific hardware. Your standard Dell, HP, Lenovo servers can run almost anything, but if you buy a hyperconverged system you are going to get yourself locked in.
A big lesson I learned is: Make sure to divide up your storage pools enough! There's no easy way to gradually migrate if your storage array is one big VMware VMFS file system.
It is disappointing because it distracts from the discussion around Open Source and Arduino as a long term educational tool. Regardless if that shade is in good faith or not, it distracts from the conversation we should be having.
Running a proprietary SaaS doesn't really show commitment to open source.
And btw, the "reverse engineering" close was already here too. You can check the archive.org of Jan 2025, months before the Qualcomm acquisition.
https://web.archive.org/web/20250120145427/https://www.ardui...
So this citation, is basically fake news and FUD. The *now* part is false and this hide the fact that the "platform" is only the SaaS.
> Phillip Torrone had warned [...] Arduino’s users were now “explicitly forbidden from reverse engineering or even attempting to understand how the platform works unless Arduino gives permission.”
They released their first closed source "pro" boards in 2021
https://blog.adafruit.com/2023/07/12/when-open-becomes-opaqu...
Unfortunately, it’s not isolated.
https://chaos.social/@North/115605819126197877
I probably missed some of the cross links but this is a mess.
Can you elaborate on "harassing trans people"? From these links at best I can guess at one of them being trans but I can't tell if that's related to the argument; who else is on that list?
This adds a little more context, but it still seems to be a complete nothingburger. It also looks like the user was harassing adafruit for not condemning the use of AI.
https://digipres.club/@discatte/115601133682447929
Conform conform conform.
You are either really bad at detecting humour or you actually agree with me but hate it being pointed out.