Engineer Thursday - An Introduction to Ino Toolkit
SparkFun Engineer Chris Taylor guides you through developing with the Ino Toolkit.
When developing embedded electronics, many people have their favorite Integrated Development Environment (IDE). Some people like Eclipse, some people like Programmer's Notepad, some people like the Arduino IDE, etc. These environments are useful because they give the developer an easy-to-understand interface for programming and automate a lot of the common tasks a developer has to do. They're useful for compiling, debugging, and all the "overhead" stuff that a developer must do. Lots of people work well with these tools. I am not one of these people.
When I started embedded development, I was running Gentoo Linux on my PC, developing on an LPC2138 ARM7 platform. All of the project files were written by hand. The Makefile was written by hand. The toolchain was compiled on the machine by hand. The source files were edited in a terminal with vi. These "overhead" things took time, but if something went wrong with the build, I knew exactly what each support file looked like. I knew my build inside and out. I really liked the amount of control I had over every detail of the development.
With Arduino, it often feels like you're locked into the IDE. Sure, you could hack the IDE code to do your specifications, but what if you want to develop old-school-style with a terminal and command-line control? Enter Ino toolkit.
Arduino Development in the Terminal
The Ino project is a set of command line tools for working with Arduino in the terminal. It does most of what the Arduino IDE does, but on the command line. Your hands never have to leave the keyboard, which, if you're like me, makes development much more enjoyable and gives you that warm and cuddly "nerd-cred" feeling. Unfortunately, the toolkit is currently only available on Linux and OS X, but they're always looking for Windows developers for help with the project (hint hint).
Ino toolkit implements the important bits of the Arduino IDE, and has some functionality that the Arduino IDE does not. Here's a quick rundown of the commands:
build Builds firmware from the current directory project
clean Removes intermediate compliation files completely
init Setup a new project in the current directory
list-models List supported Arduino board models
preproc Transform a sketch file into valid C++ source
serial Open a serial monitor (uses picocom)
upload Upload build firmware to the device
Each command has a list of flags that set things like baud rate, error reporting, etc. All the normal actions you would perform in the Arduino IDE are now performed with commands.
$ ino build -m mega2560
$ ino upload -m mega2560 -p /dev/ttyACM1
$ ino serial -p /dev/ttyACM1
This gives you more capability in some ways, but also has some drawbacks.
Pros of Ino Toolkit:
Ability to upload code without recompiling
Ability to generate valid C++ source from Arduino sketches
Work entirely from the terminal
Verbose error reporting and programming process reporting
Cons of Ino Toolkit:
No drop-downs, all examples and folders must be accessed through the terminal
Converting existing projects to work with Ino toolkit is more involved
Installing Ino Toolkit
To install Ino Toolkit, visit their website to download the installer packages. Currently, the packages must be compiled on your machine, but if you're using Ubuntu, I've written up a handy installer script that should take care of the dependencies and setup for you. If you have git already installed on your machine, you can uncomment the last few lines of the script and it will download and setup the package for you. Enjoy!
Awesome. This is pretty much exactly what I've wanted since I first cracked open the Arduino IDE. I mean, it's a fine little shim for the things it bundles up, but it's kind of a ball of sadness as editors go.
Same here, I've 'learned' vim and love it. I realize I can write sketches in vim and use the Arduino ide to upload, but that always seemed a bit of a kludge.
I haven't used this enough to see if it's worth it, but I'm happy to give it a fair shot...
(and I agree about the ball of sadness!)
Thanks. Nothing against the Arduino IDE, but this will feel more like home. Now if someone will just make a shield that can upload a sketch from a stack of punchcards.
That's why I stopped using Linux in 2006. I was tired of doing everything "by hand". My Dad used to poke fun at me because I'd spend more time getting things to work than I did actually "doing anything". He'd ask me, "Don't you think there's something fundamentally wrong with the OS when you have to spend 3 days trying to get your machine to play an .mp3 or a DVD?" I switched to the Mac, and like they say, it "just works".
I want the tools to work for me. That way I can spend less time tinkering and getting things to play nice and more time "doing stuff".
And what's the big deal about recompiling? What machine's do you guys use that it's such an issue? Doesn't it take seconds to recompile? It does on my machine anyway.
I think you aren't the target group for the toolkit. Use the IDE, by all means.
On the other hand, the command line tools are extremely useful when you actually want to automate something - such as rebuilding of the project for several different types of boards your have in production, each may need different settings, etc. With an IDE that is an extremely tedious and error-prone process. Using a short script that calls these tools you can automate all of the above, minimizing the errors and manual work required.
And re recompiling - the need to recompile to program the target is perhaps not a big deal when writing code for an Arduino, where a typical sketch has few hundreds of lines tops. Try that for an ARM project sometime - even a simple "hello world!" type project needs several files, lots of settings, some libraries linked in, correct linker script etc. Also the code size tends to be a lot bigger, because those chips have a lot more memory and can handle much more than the puny ATMegas. The constant recompilation would be a major waste of time and pain in the neck in such case - that's why scripts, Makefiles (CMake/Jam/SCons/...) were invented.
Don't pan stuff only because you don't need it/don't understand its purpose.
Jan
OK, just trying to understand why someone would see "not recompiling" as a perk. Even my iOS projects that use hundreds and hundreds of sources files and are a good 60M only take about 20 seconds (if that) to compile.
That's because your makefile is doing its job, and only recompiling the things that have been touched since the last compile. You're doing it right. We're trying to bring that to everything.
Hang on a sec. In one sentence you say that you want to spend less time fooling around with stuff, and in the next you say "well, except for THIS extra step - that one's just fine". I'm not trying to pick a fight or anything like that, but your statements seem inconsistent to me.
As far as the big deal goes, you just get into a rhythm, you know? You're going and going and going - and then you gotta wait. Speed bumps bug me. But I think everybody gets that this is going to come down to a personal preference. I like having the control at times, but I also like simplicity. So I'm firmly planted on the fence.
You misunderstood. I don't want to spend 3 days tweaking and tinkering to get the OS and IDE to play nice together. That's 3 days that I could be working on the project and/or the code.
Case in point with Linux, (granted I'm talking about what it was like in 2006 when I gave it up) but more often than not, you'd have to install dozens and dozens of binaries in order to do something simple like play an mp3. If you couldn't find an rpm for your flavor of linux, you'd have to compile it from scratch. But you'd need X binary first, but for X to work, you needed Y, for Y you needed Z. The next thing you know, you've installed 15 binaries in order to do something trivial like burn a DVD. I'm sure Linux has come a long way since 2006, but I'd rather not spend so much time getting things to work, and spent more time working on the actual content of my project.
I've found with the Mac, that everything just works and I don't have to mess around compiling binaries and doing things from the command line. That's all I'm saying.
[Here is the Standard Moderator Note that this needs to not decay into the Standard Operating System Flamewar or we'll hide comments. Thanks in advance, everyone.]
But that's the only way to once and for all prove which is best. I haven't even seen all CAPS yet.
You mean something like this?
It's probably not really a flamewar until you get at least one vitriolic or deeply overthought argument-provoking response to this.
I fired up a DOS for the first time in years the other day to run some QBasic I'd written in the late 90s. It was oddly exhilarating, at least until the guilt for never having finished programs I started writing in the 9th grade set in all over again.
Perhaps off topic, but as you brought up QB... If you crave 'QB for Win' (like I did), run over and buy yourself a copy of PowerBasic Console Compiler. The IDE is rather 'a dozen years ago', so I write the code in UltraEdit (a must have) and compile with PBCC.
Huh. My interest is pretty much in pure nostalgia territory these days, and I haven't written code on Windows systems in 10 years at least, but it's cool to see they're still supporting PowerBasic.
There's nothing like the kick you get out of firing up an ancient computer and almost feeling it's operating system ticking over.
I use a Mac mini. I compile and program my AVR's from the Atmel IDE in Windows XP inside VMWare, then I design my 3D parts in Sketchup in OS X, code the final parts in my own PHP program via TextWrangler in OS X, my PHP program converts those parts into RML-1 codes, I save the resulting files to a CompactFlash card, then I copy the files from CompactFlash to the hard drive of my old ThinkPad 760XL which is running Windows 98SE and then finally I send those files to my Modela MDX-3 via an MS-DOS shell via the "copy file.rml lpt1" command.
It just works!
Choice is a good thing. Without it, there would be lots of unhappy people. The fact of the matter is that the Arduino IDE tools don't "work" for many (including me). I put together my own set of Makefiles so that I could build and upload from the CLI -- this workflow has increased my productivity as I'm now able to use an editor/environment that I am extremely proficient with (vim/make) instead of the clunky Arduino IDE. Others might be more happy using Eclipse or Visual Studio (Arduino integration exists for both, btw). Full disclosure: I use Windows 7, Mac OS X (MBP, Mini), and Debian (workstation, server) and I have developed for all three platforms (as well as Java). They all have their advantages and disadvantages and I accepted that long ago. There's no need for fanboyism.
Linux has only gotten better since 2006. With Ubuntu, Linux Mint, and to lesser extent Debian everythng now seems to work right out of the box. I haven't had to fool with config scripts or look for third party libraries in a Loooong time. (The only recent exception was trying to get Skype or Eaglecad running from the download sites. In those cases the issue was trying to run a 32 bit app on a 64 bit version of the OS. Eagle has since fixed the issue on their end, M$ now owns Skype so who knows?)
You can install "ia32-libs" onto your 64-bit linux system to run 32-bit applications. I wish it was included by default.
Nice! Just one thing: "the toolkit is currently only available on Linux and iOS" -- I think that should be OSX, not iOS.
Thanks - fixed!
That's "OS X", not "OSX".
Better make that "OS X". ;-)
I think I'm gonna go with OS'X. :)
If we're going to be pedantic, it's GNU/Linux, not that anyone cares :p
BSD and NeXTSTEP are not GNU/Linux, not that anyone cares. :p
Aaaaaahhhhh!!! :p
You can also use Ino with LOA (Linux on Android) as I describe in this lunch-and-learn presentation.
http://www.jeffboody.net/sparkfun-lunch-and-learn-20130124.pdf
Thanks, I've been looking to automate things. I use MATLAB/Octave and Python to program experiments and communicate with external devices, would be great to write and compile everything in one IDE.
While I appreciate the fact that this is available for those who need/want to use it, I don't feel like I have to just to enhance my “nerd-cred”. I started programming back on punch cards and went all through the command line tools up to the current IDE's. I have no intention of giving up what has been gained with the modern environments. As I said, this is a great option for those who want to go that route.
At the very least it will enable you to more easily use the "modern environment" of your choice. One of my biggest peeves about embedded software is every product line has its own supported IDE. Command line tools are the glue that binds disparate environments together, whether you use them directly or via a script called by pressing an IDE's build button.
I go back and forth on this, personally. Ino Toolkit adds some functionality that is notably lacking in the Arduino IDE- the ability to reprogram without recompiling, for instance, and (easier) access to intermediate stages of the code between the Arduino environment's concatenation and the actual compilation process.
What I don't like about command line stuff is that it tends to become very specialist. For instance, I'm quick-draw on command line git, but that doesn't get me anywhere with any other version control system. And knowing my avrdude syntax is completely useless if I want to start working with PIC or ARM.
This is pretty awesome for people trying to develop Arduino code in places where GUIs might not be too practical (like on a server, or Raspberry Pi)
This seems like it would be more useful in a production setting where you would need to program a large amount of arduinos with the same code. I'm sure that since it is a command line interface it could be used as part of a shell script to do so at the push of a button. Otherwise its usefulness is limited for most people.
Wouldn't it be possible to connect dozens of Arduinos in parallel to program them all at once? Even if you have to lower the clock speed of the ISP/HVSP it would still be faster than physically connecting, programming and disconnecting the units one by one.
You could program them in parallel, but not verify them in parallel. From a production standpoint, proper verification is more important than throughput.
How about a special setup that could go through dozens of them by letting the hardware talk to them one by one via their select pins?
You're right, with various amounts of hacking on the programmer hardware and avrdude you could likely get it working. Our production ninja Pete cooked up a broadside programmer a while back, check out his interesting tutorial on the subject.
Awesome! This is just what I needed for some Github integration I was planning on.