You are viewing a static version of the site. Enable JavaScript to benefit from the
full functionality of this site and enable such things as forum posting.
Arduino CLI
matt:
I have been playing with arduino-cli recently, and I've been somewhat impressed.
With my experience of that, and a desire to maybe incorporate the ESP-IDF into UECIDE I am considering something radical...
Rip out all UECIDE's compilation and board management completely, and just use it as a wrapper to arduino-cli - or the compilation system of your choice.
It would be a massive change, and I'd appreciate the thoughts of others that use UECIDE.
It would mean:
UECIDE's aggressive caching would go
The plugin manager would vanish / radically change
You'd not be able to install just the boards you need
You would finally get 100% compatibility without those pesky compilation errors
Have instant access to all the Arduino cores and boards without me having to manually port them
Have more than just Arduino (such as ESP-IDF)
So UECIDE would become little more than an editor that is geared towards editing Arduino code.
Thoughts? Comments?
MathiasWilhelm:
Salut Matt,
I like UECIDE because I can select the boards I use and the compilation works much faster than with the arduino IDE. If UECIDE becomes just another editor, I can stick with the ones out there like Atom or PlatoformIO. I also rpofited a lot of your fast support in case of any problems. I woudl regret if UECIDE evolves into a frontend of the Arduino IDE.
Ciao, Mathias
matt:
I could do with finding some way of integrating arduino-cli into UECIDE. My problem is that there are so many Arduino-like cores around now, and supporting them all is not really practical. By integrating arduino-cli I then get instant support for all the cores that Arduino has without needing to do any work.
I keep getting requests along the lines of "Can you add such-and-such a board?", which usually means a good few weeks of back-and-forth trying to port the Arduino core files to UECIDE.
I also want to have some way of integrating the ESP-IDF, which uses a python-based script system to both configure and build a project.
The hardest thing about using arduino-cli is selecting the board options. There's no way of finding out what the options are without examining the boards.txt file. My thinking is that UECIDE will do that for you and present the options for you to select. I'm considering moving to a "create project..." style where you can have "Arduino CLI project", "ESP-IDF Project", "Generic Makefile Project", "Native UECIDE Project" etc (where the latter is what you have now).
That system would then move things like the board / core / compiler / board options away from the menus and into a "project configuration" panel / dialog to more closely tie the settings with the project, and make them more specific to the type of project you've chosen.
matt:
Maybe I should create uecide-cli - a native tool for compiling really fast from the command line. Completely separate the IDE from the compilation - then it's just one of many plugable compilation systems. That would be good, and remove a lot of the complexity from the IDE. The IDE becomes an editor with a selection of native back-ends (arduino-cli, uecide-cli, idf.py, etc). It also means you can more easily use your own preferred editor with the UECIDE compilation and board management. And it would be faster too without Java being involved...
Now there's a thought...
ullix:
My 5 cents:
Getting full Arduino compatibility certainly does have value! And I can imagine that saving time for you sounds enticing. However, this does seem to come at a price for some users.
Of value to me is the left side of the uecide window with sources, libs, output and more. Seeing the status of the libs - great. Likewise the bottom window with Status etc. Overall, much better structure in uecide than in arduino.
Fast compilation with libs being precompiled is very much enjoyed!
The uecide editor is horrible. I use Geany in parallel. Any changes made there are detected by uecide. I use the uecide editor basically only to let me show the errors, and then edit them in Geany. But quickly editing in uecide anyway, and forgetting to explicitely save, and I may loose the corrections next time I use Geany, and I am surely loosing any bookmarks I defined in Geany for that file. So, using a 2nd editor is bad, but better than the uecide editor alone!
Getting rid of Java? Ooooh, please! In the last few months I believe I had to kill uecide like 100 times! During the same time the number of kills for all other programs combined: None! If you want my blessing for that, you sure have it!!!
The serial monitor: a nuisance having to close it during uploads, and then one may not be fast enough to open it for seeing the execution start. I first put a delay into the code, and nervously watched the compilation. Now I use my own serial monitor (programmed in Python) to monitor output via Serial2. Arduino does that part much better (though there I am missing the 'Pulse line' command).
Perhaps bottom line: full compatibility may be the most valuable part.
matt:
> Getting rid of Java? Ooooh, please! In the last few months I believe I had to kill uecide like 100 times! During the same time the number of kills for all other programs combined: None! If you want my blessing for that, you sure have it!!!
Java is like Marmite. Great when spread thinly but a whole spoonful makes you gag. I am still considering moving all the compilation and library management to a native program (probably C++) but the actual IDE will still be Java for ease of cross-platform GUI.
For the native C++ program I will of course want to keep the aggressive caching that arduino-cli lacks, and may have discrete "steps" available (uecide-cli --compile-libraries for example) for better feedback to the IDE. The one thing that is hardest with arduino-cli is working out what the options for a board are - something that is especially critical for ESP32 and ESP8266, both of which have comparatively huge numbers of options. UECIDE is going to have to natively know about those options and how to set them.
ullix:
You've got to be genuinely British to be using Marmite to explain a software problem ;-)
Since you are considering C++, why not have a look into Qt as toolkit?
matt:
I have looked at Qt before, and I'm not a fan. I have struggled to get it to do even the most basic of things like a vertical split that can resize.
matt:
In some strange way I have kind of come to like the Swing model in Java. The actual underlying implementation of it is maybe not so good, but the way it works is quite nice. What gets my goat (and I have a lot of goat to get) is that there is no standardisation in the API. It's like different bits have been bolted on at different times by different people with no underlying plan. Mind, the same can be said about the whole of the Java language. Nice idea, bad implementation. It does have the advantage though that you don't have to write any real native code, it's 100% cross platform - compile once, bundle many times. Not like C++ / Qt where you have to write loads of native code and guard it all with #ifdefs to get the right code compiled for the right platform. Especially when it comes to compiling for Windows. Java takes all that pain away from you (and replaces it with other pain, true...).
matt:
And no, I won't use Python! :P
ullix:
> On Thu Oct 15 2020 matt wrote:
>
> And no, I won't use Python! :P
Too bad, really. I could show you how to do a vertical split ...
matt:
The only vertical split I wish to do in Python is directly down through the head of the original author ;)
ullix:
We can cooperate on this, but I will chose the author of Java!
matt:
Can't say as I blame you. But at least Java feels closer to C++. Python is too close to COBOL(locks) for my liking...
