Yes, Galileo, is a Linux device that emulates Arduino.
There are several methods for connecting to the Galileo Linux console:
You can manipulate the pins via Linux:
Or you can manipulate the pins via this Python library:
The only limitation is that it can be difficult to build a Linux image with all the stuff that you want. But that process is getting better all the time.
While I agree the Arduino IDE is lame, Intel has created some really helpful code to go along with it. Go ahead and download the Intel Arduino IDE (https://communities.intel.com/docs/DOC-22226) and look inside the directory. Intel wrote C++ libraries for performing common tasks like GPIO, I2C and SPI. Their function calls just match common Arduino ones. However, these libraries are normal C++ user-mode libraries. I haven't tried them outside of the IDE but I see no reason why it cannot be done.
> I would be happy even to see Blink written in c++, running in Linux
Just a reminder that an Arduino Sketch is a C++ program. The only difference with a "real" C++ program is:
a) Arduino provides the main() function for you. It basically does just this:
b) Arduino does a bit of preprocessing so that you (nominally) don't have to declare functions before you use them.
c) Arduino provides the "Arduino-y" functions like digitalWrite and pinMode. But the source code for all that is provided. If you really want to build a script/makefile that builds and uploads an Arduino sketch without having to load the IDE, the best way to start is turn on "Verbose compilation and upload" in the IDE (File/Preferences) and watch what it does. (I did this for a Sanguino board I built.)
The Galileo is very open. Maybe it will be clearer when your board arrives and you can experiment. The Galileo IO is handled by Linux drivers, these are all open source. They follow the normal Linux driver models for these kinds of IO devices. These drivers are accessible from user-mode applications (e.g. C, C++). While there aren't libraries specifically designed to access them outside of the guise of Arduino, that doesn't matter because the Intel-provided libraries true C++ libraries.
I also have a BeagleBone Black. From my experience, Galileo is just as open as bb.It isn't as easy to do advanced things with though. It clearly isn't a polished product from the software perspective. It is quite workable and I and happy to have it. I think the work being done to get Debian booting on it will go a long way.
OK, I ported all the Arduino headers and .cpp files over to the Linux side, and I have a version of blink that compiles clean.
I use a command like "g++ -c -o blink.o blink.cpp -I ../arduino". All well and good - this picks up all my headers.
Linking, however can not find any of the standard library functions like memcpy, strcpy, tolower, and toupper.
This is on a link statement like: "ld blink.o ../arduino/wiring.a". (I stuffed all the Arduino .o files into wiring.a for testing)
I need some help with the g++ and ld magic incantations... All standard Linux stuff.
I think the Galileo build process links using g++ on this line--the second-to-last one that you see when you do a Ctrl-R "verify" build:
[bin]/i586-poky-linux-uclibc-g++ -m32 -march=i586 --sysroot=[tools]/i586-poky-linux-uclibc -Os -Wl,--gc-sections -march=i586 -o [tmp]/sketch_feb23a.cpp.elf [tmp]\sketch_feb23a.cpp.o [tmp]/core.a -L[tmp] -lm -lpthread
(I've replaced certain very verbose directories with [...] for readability.)
Thanks Mikal, but that does not help me with this current problem. At this point, I can compile and link clean. The build line I am using is:
g++ blink.cpp ../arduino/galileo.a -I ../arduino -pthread
Another point of interest is that the executable is 101,539 bytes. Not bad for a program that just flashes an LED. And this is the minimal set of required object modules.
I used galileo_fab_d for my variant library.
Getting further. main.cpp has a bit of pathogical behavior. It expects exactly two parameters - tty0 and tty1.
I can't just dump main.cpp, because it calls init(). Init is in variant.cpp - and it also expects those two parameters. I can't dump that, because it would skip calls to pwmInit and pinInit which are in wiring_analog.cpp and wiring_digital.cpp
Executing "./a.out tty0 tty1" gets a lot further - it does not exit.
/tmp contains two trace files - log.txt and log_er.txt. Log.txt confirms successful initialization. log_er.txt shows one per second error messages saying pin 13 is out of range. Getting closer!
Last update on this post - blink.cpp is running - and the led is flashing, once per second. PinInit was never beintg called, because the serial ports were not initializing successfully. Most of this was fixed with "./a.out ttyS1 ttyS1". I really don't like the interdependence between serial ports specified on the command line and digital pins.
I will probably start a new post called "Steps to run blink under Linux". With the structure in place, running any sketch under Linux should be easy.
Message was edited by: Robert Mitchell