Now that I have the Embeetle set up on my Fedora 33 LXDE, it is time to get tinkering with the code.
First I had problems setting all the tools in the Embeetle, then the Arduino project conversion failed, but after reading some error texts I tried installing the Arduino IDE in “parallel” to Embeetle and suddenly the conversion and all the tools worked fine. So to clarify, is the Arduino IDE required for Embeetle’s Arduino project conversion to work? And does all the “AVR-tools” come with the Arduino IDE, since I have this vague memory of not finding the “avr-tools” via Embeetle’s tool installs (could be false memory, so I want to confirm this)?
Now to the main question. Perhaps like so many people, who have found the boundaries of Arduino IDE, I too would like to get more control on my AVR (made few minor projects with Microchip Studio, but didn’t like it). And now if I just convert my tooLongCode.ino to Embeetle project, the converter kindly adds the Arduino.h and related libraries, as it is supposed to. Now, the main purpose of me finding a new IDE (Embeetle) was to try and get rid of the Arduino libraries, if any way possible.
After so much ranting: How to create a bare bones project that still works on Arduino UNO? Is it even possible to do without the Arduino.h or is the only way to mutilate the Arduino source? Though as promised Embeetle already excludes most of the Arduino libraries as I’m not using them in the code.
By bare bones I mean something like this
int counter = 0;
I do realize that this is Arduino specific question and may not be completely within the interest of you people, if this is the case, please answer in general on how to create a bare bone project that still compiles. Now with empty project I get some null errors, propably as there is no files (beside my test.c) in the project
This is clearly a mistake from our side. I thank you for bringing this to our attention!
This confirms my diagnosis. After you installed the Arduino IDE, it installed the AVR Toolchain on your PC, and added it to your PATH environment variable. Then you restarted Embeetle, and the beetle found the AVR Toolchain on your path. Problem solved.
You can check if this diagnosis is correct by navigating to the Home Window > Toolbox tab. Please click on the AVR Toolchain to see its details. It would be great if you could send a screenshot - just so I know if my diagnosis was correct
Absolutely not. Thanks to your feedback, we can make sure that Embeetle will show a warning (including a download offer) to users who have no AVR Toolchain installed yet and try to use our Arduino sketch importer.
Exactly - that’s why we’re here for you. I can’t resist the temptation to bring our comic to your attention: Embeetle IDE
Agreed, same feeling here. Even though it’s better than Eclipse, Microchip Studio still feels too bloated.
Our Arduino importer works in several steps:
First the importer simply compiles your sketch file with the native Arduino build system. This “native Arduino build system” is a tool created by Arduino itself: arduino-cli.exe. We include it in the Embeetle installation (Arduino is open source) such that our users don’t need to have the Arduino IDE. This tool performs all sorts of magic on your sketch file to transform it into a valid .cpp file. Then it determines what libraries are needed to be compiled and linked with that .cpp file, such that the final binary can be created.
Long story short: what happens here is exactly the same as what happens when you click the build button in an Arduino IDE.
When the previous step is finished, our importer parses the build output. This way it figures out what .c, .h and .cpp files are involved in the build, as well as the linkerscript.
After listing all the relevant source files, our importer creates a new folder - your project folder - and copies them all into it.
Because you told the importer which Arduino board you have, it has now all the needed information to create a makefile, and a dashboard.mk file for your project. You can read some more info about these files here: Embeetle IDE . In short, dashboard.mk is a file that contains all the needed compiler flags. It gets imported into the makefile, such that GNU Make passes the right flags to each source file during compilation.
If the four steps described above work out well, you end up with a project that is completely makefile-based! You no longer depend on the magic tricks from the Arduino IDE to compile your project. I believe that is exactly what you wanted.
3. Arduino libraries
Unfortunately, you still have some Arduino libraries in the imported project. The best we can achieve is making them easily accessible and editable. That’s something you cannot do in the Arduino IDE (unless you sneak around in temporary folders deep down your file system, but that’s terrible to say the least).
Throwing away all these Arduino libraries to replace them with new code, is certainly possible. Some people try that. We are in contact with Mr. Lars Potter, who is undertaking such an effort:
His goal is to replace bloated HALs (Hardware Abstraction Layers) with minimalistic, bare bones HALs. It’s an initiative we applaud and support in every way we can (eg. we offered him our server to host his website). However, we cannot spend much of our own time on this effort, as the creation of Embeetle IDE itself is taking all of our time and energy.
4. Final note
As a final note, I’d like to ask you a favor. If you decide to throw away the Arduino libraries and you replace them with your own, minimalistic bare bones code, please think about us. We are always on the lookout for sample projects to add to our “New Project Wizard”:
You certainly did answer all my questions in perfect detail, thanks!
Pleasure was all mine
And here is the screenshot from my Fedora 33 LXDE (about the updates available notification, I have tried making the installation via update page few times and it seems to finish, but afterwards the old version is still there. But that’s perhaps an another topic for another day ):
It might be that my situation doesn’t fit perfectly to your diagnosis since the location of the toolchain is in the beetle directory. Perhaps it just wasn’t too clear at the start for me to what tools to select for AVR development or just couldn’t find it at first and installed it before Arduino IDE. When you combine the confusion and the beetle not showing the notification of missing tool, perhaps we are at the source of the problem. Although I did have trouble making the install work and had to try few times to get all right. (not sure if this link works but here goes: (IDE not starting in Fedora 33 LXDE - #7 by ygramoel)
I shall certainly keep this in mind when I finally feel comfortable with “real C-coding”, although I have still lot to learn as I’m still in the middle of reading one of the so called “Bible of C-coding” books.
I did read the comics and the one you linked was one of the best ones - “Mario quickly finds out there’s dark magic involved” It was so hilarious that I had to link it to few of my friends.
Looking at your screenshot, it seems like the AVR Toolchain is indeed downloaded by Embeetle at some point. Nevertheless, your initial post made me realize that our Arduino importer lacks a warning message for missing tools. That’s very valuable information - we can spare many future users a lot of headaches. Thank you!
Some day I’d like to add a tutorial on our website for embedded C and C++ coding. But that’ll be for the far, far future. The development of Embeetle itself consumes all my time.
By the way, we’re currently implementing a great improvement. You heard about PlatformIO? We’re working towards a full integration of PlatformIO into Embeetle. Our goal is to have it ready by next Embedded World conference in Germany. Maybe you can meet us there
Yikes, that’s unfortunate! My colleague @matkuki just tried on Lubuntu 20.04, but it works fine on that system. My other colleague @ygramoel can try on his Fedora bootstick, maybe tomorrow. However, could you please try it again and take a screenshot of what you see? Or maybe you can even try the following:
Please start Embeetle from a terminal. For example:
Ok, this is starting to be embarrassing I ran the embeetle from console as I always do, but with the --debug added and guess what, the updater started fine and the beetle version is now 0.2.28.
I know that I tried making the update several times before, failing every time. This time seemed different to my previous attempts, because last time (if I remember correctly) the embeetle opened the “beetle-console” and ran some scripts, but just halted at some point. This time it did the same thing, but instead of halting, it opened the “beetle-update” GUI and continued with the update.
My plan was to run the updater once to see it would fail and then try the screencasting, but… "beetle used demo effect… demo effect was super effective
Here are some errors from the console, I can’t get the first ones since the console “log” was quickly overrun with the “external progbar overflow” error:
ERROR: The external progbar has a value too high!
val = 136
max = 135
ERROR: Attempt to apply a value on a non-existing progbar in the ConsoleWidget()!
ERROR: functions.urlretrieve_beetle() gave wrong
numbers to the reporthook:
- blocknum = 1
- bs = 8192
- size = 1675
That would really attract some Arduino coders to “beetles embrace” as well.
Actually I used the PlatformIO (or some version of it) with VScode to “port” (in lack of better word) a minimal version of Marlin firmware for my extra old (with extra little memory) 3D printer GEN6 controller card. But in general I have no idea what the Platform IO is
Meeting you people in Embedded World conference in Germany, would certainly be a quest worthy of a seasoned adventurer
This means the “beetle updater” tool somehow failed to start in your previous attempts. I have no idea why. I’ll see with my colleagues what we can do. Thank you very much for your efforts to report all these things
Don’t worry about the demo-effect. You have the latest version now, so that’s great
We’ll be happy to meet you there as well. From which country are you?
As the problem can’t be repeated it’s gonna be hard to find the real culprit. Perhaps mute the “The external progbar has a value too high!” error so next time the debug wont be overflowing. If the update problem happens again, I’ll let you know.
Finland! Are you people from different countries and only united via Internet?
So I got the beetle-update done, made a test program and it compiles fine, but now I’m having trouble with the flashing. The flashing is done with the avrdude and I have used it on Windows a few times, but now on the linux and Embeetle it’s not too clear where to set the serial port settings for the avrdude. So as expected I got an following error:
/home/vncuser/Documents/arduino_skeleton$ /home/vncuser/embeetle/beetle_tools/linux/gnu_make_4.2.1_64b/make flash -C build -f ../config/makefile TOOLPREFIX=/home/vncuser/embeetle/beetle_tools/linux/gnu_avr_toolchain_7.3.0_64b/bin/avr- COM=/dev/ttyS0
make: Entering directory '/home/vncuser/Documents/arduino_skeleton/build'
# __ **************
# / /_ * make flash *
# /_ / **************
# Operating system:
# Source folder: /home/vncuser/Documents/arduino_skeleton/source
# Build folder: /home/vncuser/Documents/arduino_skeleton/build
/home/vncuser/embeetle/beetle_tools/linux/gnu_avr_toolchain_7.3.0_64b/bin/avrdude -C "/home/vncuser/embeetle/beetle_tools/linux/gnu_avr_toolchain_7.3.0_64b/etc/avrdude.conf" \
avrdude: Version 6.3-20210108
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/home/vncuser/embeetle/beetle_tools/linux/gnu_avr_toolchain_7.3.0_64b/etc/avrdude.conf"
User configuration file is "/home/vncuser/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyS0
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: ser_open(): can't open device "/dev/ttyS0": Permission denied
avrdude done. Thank you.
make: *** [../config/dashboard.mk:161: flash] Error 1
make: Leaving directory '/home/vncuser/Documents/arduino_skeleton/build'
/home/vncuser/embeetle/beetle_tools/linux/gnu_make_4.2.1_64b/make: exit code '2'
The error quite likely is caused by wrong serial port name, but how should I set it correctly in the beetle? Via the makefile? From the dashboard.mk I can find the command that is run to initialize the flash, but the file says that it might be automatically changed by the beetle. Or should I just create the file /home/vncuser/.avrduderc, and set the port settings there? The port that should be used is ttyUSB0 instead of ttys0.
The way to set the COM-port in Embeetle is through the Dashboard:
When you select the right COM-port there, Embeetle will feed that as a parameter in the GNU make call. So there is no need to change anything in dashboard.mk.
You are not the only user having this issue. We noticed that most people don’t find this COM-Port setting in the Dashboard. That’s why we’re planning to duplicate this setting in the Toolbar at the top, right next to the Flash button. Your question just confirmed that this is a good decision
By the way,
Please drop me a message on my phone after you post a question here:
+32 (0)496 90 75 44