Shiny Object Syndrome
I was supposed to talk more about lwos last time, but I got distracted talking about the Arudino and how I both like and dislike it at the same time. I was going to talk more about lwos this time, but a shiny object appeared and so I want to say just one more thing regarding the Arduino build process.
I know it isn't for everyone, but I still am just as satisfied with my favorite editor (emacs, and yes, I do know vi, I just prefer emacs) and a command line. Not to knock Eclipse, but it is sort of like a Swiss army knife with 125 blades. It does everything, weights 10kg, and there are always a few blades in it that you are totally sure what they do. Powerful, but not always convenient.
On the other hand, if Eclipse could manage the build process then why couldn't I with a makefile? I have learned when I have an idea like that not to rush into developing it right away. A quick search on Google often finds someone has beat me to the punch, and this was no exception. Even if you don't care about using the command line, most tools will manage an external Makefile for you and, besides, reading it can explain a lot about the Arduinio build process.
Here is the page I found and it apparently is a modified version of another Makefile. I picked up the modified version since it handles libraries. However, that file is at version 0.3 and the original file is at 0.4 (a quick diff looks like some autodetection for Leonardo-style boards and a few extra compiler options).
The file needs a few variables you can set up in your .profile, .bashrc, or just in a script you source to your shell. Here's my source script:
#remember to . source this file export ARDUINODIR=~/Embedded/Arduino/arduino-1.0.2 export BOARD=atmega328 export SERIALDEV=/dev/ttyUSB0
Of course, you need to adjust this as you see fit. The first variable is the path to your Arduino install. The second is the board type (you can do a make boards
command to find the right entry or dump the boards.txt file in your Arduino installation if you don't want to fire up the IDE. The makefile will guess your serial port, but I set the final variable to tell it where to look anyway.
The build worked perfectly (of course, I already had the prerequisite avr-gcc and avrdude installed). The default make
command builds your program and the upload target sends it to the actual hardware.
Since many programs use the serial port for debugging, the makefile has a target for "monitor" that starts the GNU Screen utility on your selected serial port. Screen
actually lets you set the baud rate as an argument, but the makefile doesn't do that and I frequently run at different baud rates for one reason or another. I was tempted to replace screen
with byobu
(if you use screen
, look up byobu
and try it). However, I really wanted to just launch a normal terminal so I decided to change the monitor section to use picocom
and allow a selection of a baud rate. You can either specify the ARDUINO_MONITOR_SPEED
variable in your environment or the makefile will prompt you for the speed from a short list of common baud rates. I cleaned up a few items related to guessing the baud rate as well.
You can download the entire file online but here's the main part I changed:
# screen $(SERIALDEV) # Assume the environment set a baud rate # if not, do a select. Either way # wind up with the baudrate in BAUDTEMP and # kick off picocom with no hardware handshaking @BAUDTEMP=$$ARDUINO_MONITOR_SPEED ; \ test ! -z "$(ARDUINO_MONITOR_SPEED)" || { \ echo Select baudrate: ; \ select BAUD in 300 1200 9600 19200 57600 115200 ; \ do ARDUINO_MONITOR_SPEED=$$BAUD ; \ BAUDTEMP=$$BAUD ; \ break ; \ done; } ; \ picocom -b $$BAUDTEMP -fn $(SERIALDEV)
The only tricky part is using $$
in the makefile to ensure the script sees a variable reference and not the expansion of that variable by make
(which happens before you select the baud rate). If you aren't familiar with picocom
(you have to install it, of course) use Control+A Control+Q to exit. If you are used to the Arduino monitor resetting your board when it connects (which is true with some hardware variants), be aware that picocom
probably won't do that. I prefer to control the reset myself, anyway.
In addition to a makefile, I found a few other interesting links. First, there is a large list of alternatives to the Arduino IDE. The list includes information on using Atmel Studio, the command line, Visual Studio, and KDevelop. In addition, there are articles about using Minbloq (think Android App Inventor or >>>) or AVR-Ada. So there are options.
If Eclipse is too heavy for you, you don't like the command line, but the stock IDE is too simplistic, you might consider MariaMole (which is, apparently, a Brazilian dessert). Oh yeah, be sure you are running Windows for this one, although other versions are in the works.
In the cross-platform camp, I'm not sure how practical it is, but there is a totally online IDE for Arduino. You do have to install a plugin, but the website can compile and upload your sketches. It wasn't clear to me how to use libraries, but I didn't spend much time on it either.
Another interesting but only mildly-related link I found was something I've often thought would be fun to write: an Arduino simulator. Sadly, also a Windows program but it does seem to run under Wine.
Ok I'm done with my Arduino rants for awhile. More on lwos next time. I promise. Assuming I don't see another shiny object.