I’m a sufficiently advanced programmer, and I still use the Arduino IDE rather than anything else for my electronics projects (though mostly non-Arduino boards these days)
My VSCode setup is already crowded with Development tools for other platforms and the Arduino IDE reliably works, with the libraries. I’ve been using the 2.0 beta for awhile And it is really nice. I’m pleased it’s made it out of beta.
I'm the exact opposite.
I find the Arduino ide totally unusable. It takes forever to start up. Every operation is slow.
It can take over ten seconds to open a small file and display it on an top of the line 12th gen Intel laptop
It literally recompiles all code on every verify or upload (because "we don't want lots of machine objects littering hard disks")
So on any of the mbed based boards compiles are like a minute or two for anything. On platformio and other compatible ways, it is instant.
So even for basic messing around I don't use the Arduino ide because it makes it not fun
I had something similar, I thought Arduino IDE was crazy slow, but then switched laptops and it was crazy fast. Not that the new laptop was more expensive or a lot newer, just different.
I blame windows stuff I guess, it's definitely not just CPU power
How can C++ compilation be slow if Arduino doesn't even use templates and the final binary is to fit in 32kb of ROM? If anything, recompiling all cpp files instead of individual object files with a link step shouldn't even have a noticeable speed difference
Yeah I don't even have a build system for my embedded C++ projects targeting 32-128K flash systems.
A main.cpp that includes all other .cpp files and a build.bat that recompile everything, it's always been instant.
And I do use a some amount of template and constexpr for peripheral setup code (computing all the constant values for GPIO config registers with a nice "DSL" of sort for example).
I have a significant C++20 app on zephyr (an RTOS), and it compiles to 65k on zephyr on an ARM board, and, with stripped/lto/etc to about 300k on ARM desktop (debug binaries are much larger, so it's not that). The only difference in code between the two (impressively for zephyr, IMHO) is some small GPIO/device abstractions to account for zephyr vs linux[1]. None of those take up any meaningful amount of code.
It all compiles nearly instantly.
So you can have large apps that work fine in that space and time.
I haven't debugged the differences in compile options, etc. I suspect it is related to constant data handling differences (they both have the same RTTI, exceptions settings. They both use the same GCC version). But IMHO there can be very wide variation in the size of literally the same code.
In the case of arduino, they don't provide you anything that could be used to flamegraph it, but i suspect it's just recompiling a significant part of mbed each time or something.
The non-Mbed based ones are faster to compile for sure.
[1] The one thing Zephyr does not yet support is std::thread/std::mutex, but it's really easy to make it work in your app because the build system functions properly, so i did and sent them patches as an example. They are working on proper support in the toolchain. Just need to rebuild it with some different config flags and twiddle a few files. MBed fully supports std::thread/etc if i remember right.
From my experience about 7 years ago, it was 10-100x faster under Linux (minutes compared to seconds), even though the Windows machine was way more powerful. Maybe file accesses are slowed down by something like an antivirus?
It's horrible. After futzing with it for a year or two for trivial test rig and automation stuff I switched to avr-gcc and avr-libc toolchains and just used vim and makefiles now.
Unfortunately yes. I ran a workshop with a group of students learning about digital electronics. They all installed the IDE and it was pretty much unusable except for on the faster laptops. The RP2040 was particularly bad, but the Mega*8 was a bit better. The problem seemed to be continual project indexing and no caching. It was also very difficult to see progress so often you'd hit upload and wait for tens of seconds before figuring out if anything had compiled or uploaded.
This is absolutely an Arduino problem. avr-gcc for a small program often compiles faster than the time it takes to upload with avrdude. And the IDE uses both underneath. Or compared to Atmel Studio, which is surprisingly not bad.
Lots of people swear by PlatformIO on VSCode, and that's totally fine. But if you're the kind of programmer that just wants "notepad, but with an 'upload' button" the Arduino IDE is hard to beat.
I like Arduino IDE as kind of a living reminder of "how the other half lives". I'm sitting here with Tinygo and my J-Link pushing several revisions of my code per minute (not to mention fucking goroutines and channels on an ARM M0 core), and other people are fiddling for hours trying to get Arduino IDE to compile code for 45 minutes only to be told COM69 is no longer connected (because Windows decided that it's now COM123).
I really think that professional software engineers are trolling "normal people" with stuff like this. Oh, you want to be a programmer? Jump through these 8 million flaming hoops suspended over man-eating sharks, and you'll see just how hard it is to make an LED blink. After failing, you will dedicate a new national holiday to our sacrifices; we do this for a living and you should be grateful that literal human garbage like you are even allowed to THINK about monitoring the water level of your potted plants. But behind the scenes, we don't do this for a living. When we press TAB, our IDE knows exactly which level to indent the text too. When we want to reflash our microcontroller, it does a diff of the last binary we pushed and updates only the 3 flash cells that actually changed and updates it in microseconds. When we want the documentation for some library function, it pops up in a web browser hovering above our cursor. Our life is nothing like this. We just use our skills to give you tools to make you think programming sucks.
I definitely agree. Arduino was good back in 2009 when professional alternatives were expensive and complicated, but it basically didn't change at all until now. And they've only really fixed the IDE. The rest of it is still terrible. Awful API, badly written libraries, everything done over an (emulated!) serial port.
It's like the legal system where emails are converted to fax when sent and then back to email when received.
That said, I think Mbed should have eaten Arduino's lunch but they kept making loads of different terrible build systems, and there are still a load of old boards available that need firmware updates to work properly. I have a couple of K22F's that have been bricked just by plugging them into a Windows machine. Never happened with Arduino.
So yeah, Arduino have sat still at the "it's rubbish but it works pretty reliably" stage while Mbed has failed to get beyond "it's great... when it works".
Because having thirty billion integrations and automations, toggles and etc that a new user may mess up is overwhelming for a newcomer. Arduino IDE serves great as a plug-and-play introduction to microcontrollers, allowing people to learn what they're doing before figuring out what the billions of automation tools are and how to tame them. It's the same reason python still has IDLE, it's just notepad with a run button, because it's all you need when you first start getting to grips with everything.
I don't think syntax highlighting and autocomplete and live error squiggles and tooltip help make things harder for beginners. The optimum beginner experience definitely isn't Eclipse, but it also definitely isn't Notepad!
VSCode is kind of bloated + really bad if you like to exclusively use keyboard control rather than "mouse sometimes", as things lose focus easily when notifications and other things gets focus and then it doesn't drop focus back where you were.
Not every tool is for everyone, and that's fine :)
Interesting I found platform.io and a like a Makefile approach so I can continue using vim… but it’s a little frustrating when the esp32 s3 came out and support lagged behind… maybe I should use the more native approach for these or maybe just use the IDE… I just can’t bring myself to learn a user interface that will not be the same in 10 years… vim and bash have not really changed in 20 years …
Yeah, I'm the same way. I battle build systems, cross compilers and version control all day for work. I have specific company owned laptops set up for all that. When I just want to mess around with a microcontroller, I fire up the Arduino IDE, and use Google drive for versioning...
I do have set up different workspaces for different development tasks where only the necessary plugins are activated. If I do embedded development I open my platformio.workspace, if I'm doing Java I have a workspace and if I'm doing JS/Frontend stuff I have a workspace as well as for LaTeX. It really works well and isn't really difficult (although I'm not really sure that workspaces should be used for this)
Having lost several hours once trying to set up Arduino.mk properly, I would strongly recommend not using anything suggested there and opting for a Makefile calling arduino-cli and normal c++-mode, alongside arduino-language-server.
In case it wasn't clear the first time: I would not even do that. Write a makefile, use your regular M-x recompile etc. bindings. Configure `make install` to upload it, so e.g `projectile-install-project` does the right thing.
The more you treat "Arduino project" differently from any other project, the less sense it makes to be using Emacs instead of the Arduino IDE.
Yes, arduino-cli is very nice. You get the convenience of arduino ecosystem (prebuilt cross-compilers, board files, libraries), without the downsides of using full blown IDE.
This is an aside, but Arduino has saved my butt during the chip shortage. It's often possible to port code from one chip platform to another with relative impunity. I've ported mundane apps to lower performance chips, to free up the fancy boards when new boards become unavailable. Also, sharing code across platforms has resulted in a much larger developer community.
Nothings perfect, sometimes you need chip specific functions, but I have so far been pretty lucky.
Yes! This is exactly why I continue to use Arduino for both personal and "work" (various non-industrial one-off widgets), despite having been literally laughed out of the room by embedded software and hardware engineers for even suggesting it.
Like for one project as a student, we had to make a dozen or so units of a custom data logging thingy. The plan was to use STM boards, but I suggested using Arduino software/libs because all the hardware was supported and we didn't really need anything STM-specific. Eyes were rolled, something to the extent of "Arduino is for amateurs and children" was said, so I volunteered to work on the server side instead and let them have their fun with STM32 HAL. They ended up having to interface with most things manually because libs just don't exist or aren't publicly available. Half a year later, they needed to set up a more of these units, but it was in the middle of the supply chain issues and basically no affordable STM boards were in stock. Meanwhile, the local electronics store had more than a hundred Arduinos in the warehouse. My screenshot and winking emoji were not appreciated in the team chat. The new generation now uses various Arduino (Atmel) and ESP boards with software now fully written on top of the Arduino stack with only one or two board-specific sections in the code.
I've never regretted choosing the tools that were intended for hobbyists and kiddies. They laughed at me for using Python. Of course there are good reasons for choosing the grown-up tools, but also bad reasons, and the bad reasons translate directly into costs in time and effort, lack of adaptability, and so forth. These things are normalized by the structure of the organization, but remain painfully visible to the astute observer on the sidelines. And to the users.
Amen. I've been doing embedded since forever and am continually stunned how engineers shun simple, open source tools for complicated expensive ones with no value add.
For work, I had to program on a industrial Atmel board. I was baffled by the crappy librairies Atmel provived with the board. Stuff like the I2C lib was broken and I had to patch some code that was checking interrupts flags and such.
I spent days to do something I could have done in days at home, and the board was still unstable.
That's why companies with non-critical sytems don't bother with 'industrial' developement boards, when it's cheaper to buy Arduino compatible boards. Oh, and the documentation and knowledge available online is gold, when compared to the crappy docs from a big tech firm,
Work stuff, but in an R&D environment where nothing goes into large scale production. If something threatens to be useful, it gets handed over to the dev team. The devs are actually very good engineers, but they do use the traditional methods. Moving across platforms is a headache -- perhaps the biggest problem is that the contract shops also have their own chosen platforms, so it's hard to outsource even minor work when a little bit of extra capacity is needed. Every platform is an island.
I always felt the Arduino IDE was lacking some features I would consider "basic" for any IDE. I'm glad to see they seem to be putting a lot more work into it lately. I think these features will improve usability tremendously.
When I was doing a lot more Arduino programming ~5 years ago I ended up using Visual Studio with some pretty good extensions. The Arduino "IDE" really felt more like a basic text editor with an upload button at the time.
Is anyone else terrified that Microsoft is slowly taking over the entire development stack? I love the new Microsoft, but I'm generally worried about what tomorrow's Microsoft could look like.
I have a particularly hard time forgetting "Linux is a cancer."
The new new Microsoft is the old Microsoft. They're already attempting to extinguish open source VSCode (much more "open core" nowadays). However most of the cool projects based on "VScode"are actually based on its open core which Microsoft won't be able to take it away.
In my first years as design student I spent quite some time programming in the Arduino IDE because it worked pretty much out of the box plug-n-play.
Happy to see an integrated rich serial data plotter. One of my tricks used to be to do a: Serial.print(inputVal * 100 * "-") to get a basic visual 'chart' stream going to test sensor inputs and the like.
It's been a while but I made a plotter for a client several years ago kluged a simple rs232 client that fed data to gnuplot as a plotter and they could also do some basic signal filters I put in the client. Gnuplot is good for quicky jobs where you want to graph things, even real time. Along the lines of what's going on here https://funprojects.blog/2020/09/10/gnuplot-realtime-plots-i...
Maybe it depends on your preferences. As someone who enjoys "suckless" tools on Linux, it makes me happy when I can avoid VS Code, however, many embedded projects out there just default to Platform IO. A simpler Arduino IDE is an advantage for me. With a more capable Arduino IDE, maybe there will be less VS Code dependence.
>The new IDE is based on the Eclipse Theia framework, which is an open source project based on the same architecture as VS Code (language server protocol, extensions, debugger).
You can use PlatformIO from the command line, so it should work with any editor in principle. (It’s written in Python.) The main thing missing would be the glue code to tell the editor which directories to find header files.
I think this is more targeted at beginners or at hardware/electronics people that have little software experience. In those cases vscode + platform.io is probably more daunting than a simple arduino editor with a button to flash your code to the chip.
I feel like the complexity is being oversold a bit here, I agree Arduino is very beginner friendly, but PlatformIO is very much a "Click and Play" development experience
For an absolute beginner PlatformIO is off the beaten path so I'd say skip it to start, but if you have any familiarity with traditional IDEs, PlatformIO is probably 90% as beginner friendly while being more of a traditional development environment.
2.0 being based on Monaco will help bridge the gap, but it's clear that they're still going for a very pared down experience in the Arduino IDE. Other comments comparing it to Notepad are about right... it's very easy to get into Notepad but can be limiting once you get past the initial hump
I'm using PlatformIO now, but in my experience the installation experience is hit and miss, due to lack of feedback while downloading and installing things. It just hangs, and you don't know if it failed.
A workaround is to not follow their suggestion to install from the VS Code plugin and install the command line tools instead.
Yeah but everything is a couple clicks away in the arduino library and you don't have to understand much about how the libraries and such work together (say for making a make/cmake file). Also the IDE sort of silos you off from mixing up projects and such as it just launches a new instance for anything "new". It's great for beginners but the lack of control probably drives most software developers crazy and they opt for platform io or jsut command line tools. It's nothing like notepad. Notepad doesn't let you include libraries, upload, have a build in serial and plotter, etc. For playing around it's fine. I've seen some fairly nice hobby projects done exclusively in it.
If you can't install vscode and platform.io tools you're gonna have a really rough time with even basic aruduino programming. There are probably a dozen good videos on it on youtube. I don't knwo anyone who just sits down at a terminal and doesn't look up at tutorial or whatnot on what they want to do.
For one it's a single install, so you don't need to install VSCode, add the extension, restart, make some changes in the project config .ini... This is a huge deal for hobbyists who are often not computer power users or even fully computer-literate (often children who are just learning this stuff).
Otherwise, you can do anything Arduino 2 can do with VSCode+PIO, it'll just take some setup.
If you’re comfortable using platform.io, probably not, you’re not the target audience for the Arduino IDE, which I think is much more focused on people who are just picking up electronics and embedded development.
It's simpler, so if you only want a really quick program, like something you can knock out in 5 minutes, the Arduino IDE is faster to get going. But that's the only advantage I have found.
Well, there's an Arduino FPGA board : the MKR Vidor 4000[0]
However I'm not sure how much people use it and if it really has the simplicity that Arduino brought to tinkering with microcontrollers. I read and hear a lot that the FPGA dev tooling is usually not really great to use and very vendor-specific, but it's something I haven't tinkered with yet so I don't really know much !
> Well, there's an Arduino FPGA board : the MKR Vidor 4000
It's an Arduino with an FPGA on it, yes. But the FPGA is practically a hood ornament: there is no support whatsoever for building gateware in the Arduino IDE, only for using a set of prebuilt demonstration bitstreams, and what little documentation Arduino has provided on using the FPGA (e.g. https://docs.arduino.cc/tutorials/mkr-vidor-4000/vidor-quart...) is extremely vague and is missing a lot of critical information.
(Additionally, some of the product specifications for the board are highly misleading -- for example, some pages refer to the edge connector as "mini PCI Express" and suggest that it can be used "to creat [sic] your own PCI interfaces", but the FPGA on the board does not support PCIe.)
You're much better off with a dedicated FPGA development board. Arduino hasn't brought anything useful to the table here.
Thanks for bringing more details into light ! As I've said I don't know much about the space and sadly suspected that it wouldn't be great, but not to this degree. It's a bit sad and it's not the "easy solution" that would have made it an easy choice for me if I were to tinker with FPGAs.
Not that you have an answer, but it makes me wonder what is the target audience for this board ?
In what way? The hard part of using FPGAs is all the computer engineering background necessary to design and debug circuits. The janky IDEs are really the least of the hobbyist's problems and cheap student/hobbyist boards (e.g. Digilent Arty series) have been available for years.
i think what you mean here is, we need a better IDE for the fpga world.
building a simple hardware dev board is a straightforward exercise.
building an IDE that lets a novice do anything useful on an fpga, outside of a very basic state machine, is an entirely different problem in both scope and structure.
The vast majority of HDL blocks you'd need to make such a thing more useful than a $4 microcontroller are closed source, nontrivial to build, and require careful thought in terms of integrating them into a workable system, not to mention very specific and application dependent PHYs: Things like HDMI, ethernet, USB, etc.
I think what most people would prefer is a fast general purpose CPU with pluggable, low-latency memory mapped peripherals without the hassle of having to know linux systems programming to make it work.
> building a simple hardware dev board is a straightforward exercise.
I would argue that you can make your own microcontroller dev board easily enough too. An RP2040 or similar, a USB programmer, some kind of voltage converter, etc.
The joy that Arduino bright to microprocessors was that it was a device that was useful for a lot of projects straight out of the box, accessible to those with only high school knowledge of circuits or programming.
We need sane open source fpga tool chains that can generalize building bitstreams for multiple vendor fpga's. As it stands the idea of programming them isn't that hard (well, to me), it's the damn tooling that is an ugly vendor created and maintained barrier to entry.
I want a gcc or LLVM like compiler ecosystem that can handle multiple vendor backends and language front ends so we can use vhdl, verilog or a new hdl in a project. Let me write portable modularized logic files that let me abstract the underlying hardware so I can target different vendors and devices. Decouple layout and let the community create as many textual or graphical layout tools as needed. Then let me write a makefile to handle the build process. I don't want to worry about switching gigabytes of tooling so I can move from a Xilinx to Lattice or Microchip FPGA or SoC. These tools will be a boon to devs using those awesome FPGA SoC's as you can self-host the toolchain on the SoC itself.
I did a bunch of fpga self learning around 2012 and spent a lot of time fighting with getting ISE to run on Linux. I then tried Altera and then fought with fought with Quartus (though from memory I think it was easier to setup). Then ISE was replaced by vivaldo and I felt discouraged by having to adopt a new IDE contraption with more licensing woes. Then my hard drive died and I've never bothered with wrestling fpgas since. The two fpga boards, a Digilent Nexus 3 and Terasic de0 nano collect dust. I gave up because the tools sucked and i wasnt using them to make money.
One of the difficulties of open sourcing bitstream generation of an FPGA is not the fabric itself, but all of the other IPs on the chip. Things like PCIe, Ethernet, memory controllers, SerDes and whatnot are often licensed from external vendors who don't want their register maps out in the open. Some FPGA vendors give you a simulation model, but I'm pretty sure you have to sign an NDA.
Also IPs sometimes have errata in them that need to be worked around. With an FPGA, you can usually fix it in soft logic, but vendors don't like giving that out either.
For some smaller FPGAs without complex IPs, they are starting to open up their bitstream generation algorithms. Though bitstream generation is pretty trivial compared to synthesis and place & route.
I found the open-soruce toolchain to be a good first step into that direction, that is, not having to jump through hoops to get the vendor toolchain to work.
It's only a first step though. Still needed: an Arduino-like IDE where you can click-and-run your design; examples that match the board you are using; examples to use peripherals(1) without having to resort to vendor IP blackboxes.
We're also eternally stuck with HDLs that are either crappy, niche-only, or add loads of complexity -- but I'm not really sure how bad this is for a beginner. Getting Verilog syntax right is probably only half bad if you have good IDE support.
(1) talking to an SDRAM is easy, getting DDR3 timing right on an ECP5 isn't. A simple "this is how you do it" example would be priceless, not being stuck between blackboxes from Lattice and Migen exception stacktraces.
Rather than Arduino, something by the raspberry pi foundation might hit the spot and make this sort of thing ubiquitous. Perhaps call it the "Raspberry Phi"?
It's not dumb you're just a little ignorant of the advantages of having dedicated hardware for an FPGA but it reminds me of "would you download a car?" :) . You can emulate an FPGA on the arduino (a really small fpga) but it would be so slow that it would be useless. Imagine simulating a Video Card on your PC, it can be done, but it would be 1000-100000x (more?) slower than the actual GPU.
You can emulate anything on a microcontroller if you're determined enough. It just won't run as fast as you might want.
You could certainly use a microcontroller to implement arbitrary digital (or even analog) logic within a circuit. You'll be limited by the CPU speed. The trick is to avoid interrupts, and spin the CPU in a tight poll loop instead. An Arduino Uno's MCU can run an instruction perhaps every 150ns on average. You could implement some simple logic that runs upwards of 1Mhz. If you use a cortex-m CPU, you could do fairly complex logic at several Mhz.
That's a silly way to use an MCU, though. You're supposed to use the peripherals to offload enough complexity from the CPU that you have plenty of cycles to implement your application logic in a straightforward, maintainable way.
> You can emulate anything on a microcontroller if you're determined enough. It just won't run as fast as you might want.
You can absolutely compile Verilog to C using Verilator and run it on a microcontroller. The performance is abysmal, and it completely misses the point of using HDL, but it does work. :)
I think it is possible since you could load an sketch that emulates a fpga. Nevertheless it would surely be inconvenient. Probably performance would be sub-par.
That’s true but I think that’s not the only reason. Programming an FPGA isn’t as simple as writing and deploying compiled code, you have to write in a hardware specification language.
Actually you can get the same experience with an FPGA if you pay for the FPGA development tools, maybe what you’re asking for is a low cost version of Quartus or similar tools. I would like it if that existed but I fear FPGA makers deliberately want to keep their tooling expensive and hard-to-learn to promote lock-in.
Yosys and nextpnr exists and work pretty well for a lot of use cases. Only some FPGAs and vendors are supported but the experience is literally light years ahead of vendor tooling.
I was going to reply that maybe they wanted a light application to develop for Arduino, but...
"The new IDE is based on the Eclipse Theia framework, which is an open source project based on the same architecture as VS Code (language server protocol, extensions, debugger). The front-end is written in TypeScript, while most of the backend is written in Golang."
A VSCode plugin doesn't mean being lighter, the Java tooling from Red-Hat/Microsoft basically runs Eclipse headless, at which point I rather keep using Eclipse anyway.
[PlatformIO](https://platformio.org) has taken care of that so thoroughly for them, maybe they only think their IDE is worthwhile for people who don't want to use VS Code?
I struggle with VSCode because of the visual clutter. I know that I can set it up to my preferences, but haven't figured out how to make all the extra stuff go away. Also, IDE's seem to have an insatiable appetite for "improving" the UI elements rather than using standard elements from each platform, like scroll bars. I still can't use the scroll bars in VSCode or Spyder on a touch screen.
But with that said, PlatformIO is super impressive.
This tracks. I recall being surprised by the behavior of the Cmd+W keyboard shortcut in the new IDE that closed the window rather than the tab[1]. Keeping it simple seemed to be the main factor driving the way UX choices were made.
This is used extensively in classrooms. Providing this standalone editor that "just works" is more appealing in such scenarios than asking students to use vscode with extensions
> If your eyes are feeling the strain you can quickly change settings and switch to Dark Mode ... our design team has reworked the entire Dark Theme to make it more consistent, beautiful and easy on the eye.
If your eyes are feeling strained/sore, stop using your computer for a while.
If reading black/dark text on a white/light background is regularly causing you discomfort, consider improving the lighting around your display. Ideally, get regular sleep and go outside (in the sun) every day.
Light text on a dark background ("dark mode") takes more work to focus on because more dilated pupils let more light in. Your eye muscles doing work causes eye strain.
I'm never going to use an Electron app, so rest in peace Arduino IDE. To upload sketches to my ESP8266, I solely used the Arduino IDE. I use Notepad2-zufuliu completely to code. If only there was a quicker method of compiling and uploading sketches that didn't require the Arduino IDE.
Yes. I've had both installed while 2.0 was in beta, and can confirm that the portable installation mode that a sibling comment mentioned does keep the two separate.
My VSCode setup is already crowded with Development tools for other platforms and the Arduino IDE reliably works, with the libraries. I’ve been using the 2.0 beta for awhile And it is really nice. I’m pleased it’s made it out of beta.