next topic »

[on:]

Could the Arduino IDE be used on command-line mode?

Code:

arduino example.pde [parameters]

with parameters like build, build and upload, target board, port selection, ...

[Reply #1 on:]

Hold down the shift key when you press the upload icon. All the commands used to compile and link and upload the sketch will be shown. It's not a trivial task to get all the arguments right for all the board types.

[Reply #2 on:]

Thanks for the tip

[Reply #3 on:]

Hold down the shift key when you press the upload icon. All the commands used to compile and link and upload the sketch will be shown. It's not a trivial task to get all the arguments right for all the board types.

I haven't thought about it much or looked into it - but this would seem to be a prime candidate to split this out from the Java IDE into a make file; then, if you wanted to use the Java IDE, the command line, or your own IDE (or anything else), it wouldn't be much of an issue.

[Reply #4 on:]

maybe this is informative - http://www.arduino.cc/playground/OpenBSD/CLI -

[Reply #5 on:]

this would seem to be a prime candidate to split this out from the Java IDE into a make file;

Yes, indeed.  This idea has been brought up over and over again.  It has been consistently rejected by the Arduino Team.

The reason cited has usually been the necessity of including (and maintaining) more binary tools in the distribution.  Currently there are 2: the avr toolchain and avrdude.  Not only would the make binary need to be included, but so would something that can do the preprocessing step.  Make can not do it alone.  Some other parsing tool besides make (eg, perl) would also need to be in the distribution.

Reimplementing the preprocessing step without java is really the thorny issue.  All the .pde files are concatenated together.  Then a regex-based parser finds the functions and adds prototypes, and adds an include.  It also discovers which libraries are used, based on the includes the user wrote.  This information from parsing must be fed back into the build process to create the correct dependencies and include paths.

Numerous makefiles have been created to mimic the Arduino build.  Most of the makefiles have not been maintained well as Arduino has changed its build process.  But none, at least that I've seen, completely reproduce the exact Arduino build with preprocessing.  Faithfully reproducing the exact build process is not so simple.  It can be done.  Maybe it has, but I just haven't seen it?

But regardless, the Arduino Team has said very clearly, many times, that Arduino will not switch to using make for its build process.

[Reply #6 on:]

Thank you for all interesting comments.

My idea is to use a more sophisticated editor —e.g. syntax check, function parameter tip, code completion, object structure visualisation— and then ask Arduino to compile and/or upload the whole project —main sketch and related libraries.

I don't want to re-do the job Arduino does nicely nor go into Makefile specifics.

So, either an external IDE sends a command-line to Arduino or Arduino offers an option to be more closely integrated with an external IDE.

[Reply #7 on:]

We'd be open to the idea of supporting command-line arguments to the editor that would do the compilation and upload, though.  See the issue here: http://code.google.com/p/arduino/issues/detail?id=124

[Reply #8 on:]

My idea is to use a more sophisticated editor —e.g. syntax check, function parameter tip, code completion, object structure visualisation— and then ask Arduino to compile and/or upload the whole project —main sketch and related libraries.

The current "use external editor" preference item actually works pretty well as a compromise, considering its simplicity.  It prevents you from editing the Arduino IDE source panel(s), and re-reads any changed file when you click the "verify" or "upload" buttons, essentially changing the IDE into a button-click compiler.  I use this "frequently" when I want editing functionality beyond that provided by the IDE...

(this is not to say that having a non-windowed "compile" command line wouldn't be a good thing, or wouldn't be possible.  EAGLE is an example of a program that does this; double-clicking EAGLE fires up the GUI.   Entering "EAGLE <switches> <commands> <files>"  from a command line or shell script does a bunch of processing and exits...  It even works that way on multiple platforms.  Though there's a special exe for windows that bysteps some corner cases.)

[Reply #9 on:]

Hi all,

did you checked http://inotool.org/ for this purpose (open source, MIT license)?
I use it when I don't need Arduino IDE.

[Reply #10 on:]

Bonsoir zhuk,

Thank you for the link. I did try it one month ago but gave it a second look.

Some parameters are to be adjusted for a OS X environment.

Let's see!

[Reply #11 on:]

Reimplementing the preprocessing step without java is really the thorny issue.  All the .pde files are concatenated together.  Then a regex-based parser finds the functions and adds prototypes, and adds an include.  It also discovers which libraries are used, based on the includes the user wrote.  This information from parsing must be fed back into the build process to create the correct dependencies and include paths.

Numerous makefiles have been created to mimic the Arduino build.  Most of the makefiles have not been maintained well as Arduino has changed its build process.  But none, at least that I've seen, completely reproduce the exact Arduino build with preprocessing.  Faithfully reproducing the exact build process is not so simple.  It can be done.  Maybe it has, but I just haven't seen it?

This is absolutely all true...  Still, some things are more important than others.  I use command-line build tools almost exclusively now, just checking stuff in the IDE before sharing with people I know use the IDE.  Here's what I have found:

* Concatenating PDE's is not really needed.  I have a makefile rule that appends the right include to the top, makes a CPP file, and feeds it into the build like any CPP.  Works flawlessly.
* Adds prototypes.  Yup.  It's pretty easy to get in the habit of declaring function prototypes.  It's not that hard.  Super-handy for total new people to not have to do this, but by the time you're outgrowing the IDE, people should be able to handle this IMO.
* Finds the right libraries.  Also true, but also easy to work around.  Libraries used in a sketch don't change that often, and so yeah you have to go into your makefile to add them.

[Reply #12 on:]

I agree, maniacbug.  I'm not sure that it necessarily makes sense for the non-IDE build processes to do all the pre-processing.  If someone wants to use standard Makefiles, etc. maybe it makes sense to use standard .cpp files and syntax too, with the Arduino libraries and board.

[Reply #13 on:]

Hi!

I posted two issues on the repository for ino:

• repertories to be adapted for OS X
• readiness for other platforms —as Arduino Due or chipKIT.

[Reply #14 on:]

I agree, maniacbug.  I'm not sure that it necessarily makes sense for the non-IDE build processes to do all the pre-processing.  If someone wants to use standard Makefiles, etc. maybe it makes sense to use standard .cpp files and syntax too, with the Arduino libraries and board.

I think that the "IDE" really should be thought more of a tool that either runs
as a full fledged IDE in a GUI mode or a non GUI mode can do all the same stuff
as the GUI mode through command line options.

So I believe that when the IDE executable is called form the command line in non-GUI mode,
that it will have to do everything the same
otherwise you will not be able to build everything that is out there, "as is".
And if you can't build everything from the command line that you can build with the GUI IDE, what is the point?

Much of the problem is that the existing code, libraries and even the core code are "decaying" into "Arduino-ized" code
rather than standard C/C++ code because they are being built after the IDE massages things.
As such, the only way to build the code is to do all the same pre-processing that the current IDE does to ensure
that the code can be built.


My preference would to be simply have the IDE executable be able to take command line arguments which
includes options like -o to specify the output file names.
That way, a real Makefile sitting on top can create .ino to .o rules and use IDE in non GUI mode to do the build
for that module.

There also needs to be a way set/over-ride compiler and linker options so that more sophisticated
users can do things like use source level debugging.

One of the more painful things in the current IDE is the way include paths are handled.
The way things are currently done it makes it difficult for one library to be able to directly use another
library.
There are some simple alternate ways of doing things to easily clean this up in a transparent
and yet backward compatible way.

But in order to do these kinds of things, the Arduino team needs to be more open to ideas, outside
their own core development team.
There are folks out there with literally decades of realtime embedded development experience who
really do understand what it takes to build real products and could offer the core
team ready-to-go solutions, if the Arduino core team were simply more open to outside
input.

--- bill