New Arduino IDE 2.0

Anyone tried this yet?

1 Like

No. But its about time they actually overhauled that old thing. I am pretty sure I will not switch from VSCode to it.

1 Like

Apparently it runs on Eclipse Theia, which is a fork of VSCode, so it’s probably far better than the original.

That said, I doubt I’ll switch either. I like being able to do Arduboy, Lua and Haskell development all in the same editor.

I’m gonna give it a spin soon. Sounds like Paul over at Teensy was or is a developer on it, all the teensyduino stuff is built in along with a bunch of other improvements and fixes he has been on them about for a long time.

1 Like

I’m keen to know whether @Mr.Blinky’s packages are compatible…?

It looks like the whole board/ port selection thing is the same and @Mr.Blinky’s boards and all work perfectly.

Still really basic …

•  You cannot see files in sub-directories.
•  When compiling, you cannot click on an error in the log to jump to that location.

Still has this annoying ‘feature’:

1 Like

Definitely sticking to VSCode then!

The stupid thing is that the software they forked (Eclipse Theia) can definitely do folders (the UI is a lot like VSCode), so that’s something they would have had to intentionally remove.

Sadly that’s to do with the preprocessor (or should I say the “prepreprocessor”?), not the IDE. Though I’d love it if they either scrapped that rule or allowed to to be overriden (e.g. with some kind of project file or something).

VSCode … which simply invokes the Arduino runtime / compiler can handle it. So why the restriction?

1 Like

Thanks for testing.

1 Like

I had to double-check that. Sure enough you’re right.

Well, VSCode gets around it because it uses a ‘project file’ (i.e. .vscode/arduino.json), so theoretically the Arduino IDE could do the same.

At the very least that implies it’s not a prepreprocessor problem, it genuinely is an IDE ‘decision’ (read: issue).

I’m half tempted to raise an issue on the GitHub, but I think it would get ignored or closed.

Too Bad it’s only availabe on 64-bit platforms. So it’s not usable on lots of older hardware :confused:

Good to know!

Because Arduino is, and always has been, for “makers” not “programmers”. For people who want to blink lights, read buttons and sensors, control motors, etc. with a only basic understanding of programming. Arduino is intentionally kept simple and restrictive so these types of individuals aren’t as likely to “shoot themselves in the foot”. This is the reason for the preprocessor, restrictive file placement and naming, and a tendency for simple C style programming (other than class members).

It may not seem like a good thing if you’re an experienced programmer or are using it to learn programming, not just to quickly create software to control your hardware project, but that’s the way it is based on its intent and will likely continue with that in mind.

To be honest, if that were their goal I think they would have been better off with something like Pascal. Or BASIC even.

If nothing else, the use of keywords over symbols would probably be easier to digest, and I think they’d be able to do away with predeclarations without needing a preprocessor.

Not if you want to allow easy direct access to hardware and want to be able to use manufacturer provided code snippets and/or libraries.

Plus, using C++ makes it easier to switch to something like VSCode for anyone who outgrows Arduino, and still have easy access to hardware.

1 Like

This is exactly the path I’ve followed; as have countless others.
Arduino is a gateway to harder coding :wink:

Pascal has pointers, as do some variants of BASIC, e.g. QB64, so using memory-mapped IO ought to be possible.

Things that require compiler extensions would be more difficult (e.g. progmem), but not impossible.

Code snippets would need translating, but libraries could be used providing they were C libraries because practically every language under the sun supports linking to C languages via some kind of foreign function interface.

I expect VSCode already has highlighting support for Pascal and BASIC.
(I already use it for Lua and Haskell.)

I don’t know which part you’re trying to draw attention, but one thing I did notice:

One of the authors (Massimo)
developed in 2003 a simple micro-controller platform
called “Programma 2003” based on a PIC chip and the
open source language Jal.

And according to Wikipedia:

JAL (Just Another Language) is a Pascal-like programming language and compiler that generates executable code for PIC microcontrollers.

So a move to Pascal wouldn’t have been too far removed from what was already being used.

The main reason JAL got dumped was because it lacked important features and was too niche.
If GNU Pascal had existed that far back, it would have been a viable option.

Lol I thought it would be obvious there would be no Arduboy without Arduino. The only reason I was able to get into microcontrollers was because I could plug in a USB and it “just worked”. All of the more advanced features and things that often require configuration, setup, or knowledge to progress are what kept me and other developers from doing these kinds of things.

Not being able to use sub folders and requiring folder names to match the ino is pretty dumb though!

I agree … I understand most of the other things they are trying to achieve but these are not going to confuse the average beginner. I guess though if they have multiple .ino files, the IDE would need to allow you to select the ‘main’ one - the same way VSCode does.

Guess they wanted to use all of the readily available libraries without this effort? Why pick a language where you have to use pointers and the like to even get started?

Allowing sub-folders might not confuse the average beginner but they likely aren’t necessary either. For a simple “maker” type hardware control project that Arduino was intended for, there shouldn’t be much need for sub-folders. One or a few .ino files is all the majority of these type of projects should need. Even stuff that a “real” programmer would put in .h files could go in .ino files and thus would eliminate the need to #include local .h files. Plus, there would be extra complexity in the IDE (possibly causing confusion) to provide the ability to create, manage and move files between sub-folders.

If a project gets large and complicated enough for the developer to require sub-folders, then it’s probably time for that developer to consider switching to VSCode or PlatformIO or some other “programmers” IDE capable of integrating with and/or compiling and uploading Arduino compatible binaries.

The type of Arduboy games that use sub-folders to help with organisation are substantially more sophisticated than a typical Arduino project.