Alan's Ramblings - Solaris category

A Makefile for Arduino Sketches

Fri, 04 Jun 2010 15:19:00 GMT

When I started tinkering with Arduinos I started out with the standard Arduino IDE. It's great for getting started quickly but for more complex work, such as those involving libraries shared between Sketches, it quickly becomes limiting. What I wanted was to continue using the standard Arduino libraries but to switch to a more capable IDE. I already use NetBeans so I wanted to try to use that if possible. The first step was to come up with a way of building Arduino Sketches from outside the Arduino IDE. The Arduino distribution includes a number of old, deprecated Makefiles, but nothing that was really usable. I therefore set to and wrote my own. I've followed the standard layout we use at work, with a 'master' Makefile that contains most of the logic, which is then included into a per-project Makefile that sets up the required configuration for the rules in the master Makefile. It is available here. An example project Makefile looks like this:

BOARD = atmega328
PORT = /dev/term/0
LIB_DIRS = ../Common/Task ../Common/VirtualWire
include ../Makefile.master

Some notes about how to use the Makefile:

At the moment the Makefile is pretty Solaris-specific, because I haven't had the time to get it all going under a Linux VM, although the required changes are simple. Patches are welcome :-)

You'll need the standard Arduino environment installed first, either version 0018 or 0019.

You must use gmake as your make implementation - not usually a problem as it comes included in the Arduino environment.

The valid values for BOARD are those found in the standard boards.txt file, that file is parsed to extract the relevant values for the Makefile. PORT is the path of the USB port that the Arduino is attached to. LIB_DIRS is a list of directories containing any libraries that you want to use.

The following targets are provided in the Makefile:
- all - build everything (default).
- clean - remove all generated files.
- upload - build everything and upload to the board.
- monitor - run the serial monitor.
- upload_monitor - build everything, upload to the board and run the serial monitor.

You don't need to explicitly list the various .c, .cpp and .pde files that make up your application, the makefile assumes that any such files it finds in the various source directories are all to be compiled.

The processing of the Sketch (.pde) files is very simplistic, much more so than the processing done by the Arduino IDE. There's talk on the Arduino development list of splitting the Sketch-to-C++ processing out into a separate library so it can be reused, but it hasn't happened yet. I've actually stopped using .pde files and now just write my own main.cpp, it's simple enough not to be any sort of an inconvenience to do so.

The output is all created in the build subdirectory of the Sketch's directory. That means it doesn't interfere with anything if you still want to be able to use the standard Arduino environment.

Unlike the Arduino IDE which rebuilds everything every time, the Makefile only builds files that have changed. One caveat: if you change the board type in the Makefile, be sure to run make clean; make afterwards to rebuild everything correctly.

The Makefile builds three archive libraries in the build directory:
- libarduino.a - this contains the object code of the standard Arduino run-time libraries.
- liblibrary.a - this contains the object code of any libraries you specified in the LIB_DIRS Makefile variable.
- libsketch.a - this contains the object code of the files that comprise your Sketch.
The use of archive libraries allows the linker to only include object files that provide referenced symbols, which will result in smaller executables if you use libraries that contain code that you don't actually use in your Sketch.

I tried offering the Makefile to the Arduino developers but they seem a little, ummm... reluctant to take contributions in areas outside of their immediate goals. I understand they want to concentrate their efforts on their priorities, but if they want to grow the pool of people developing the Arduino platform (as opposed to growing the community developing on the platform) they are going to have to change their approach. It's not just me that has had this experience, the changes for the Solaris Arduino port also haven't made their way back in.

I'll write a followup post on how I've used the Makefile to enable me to use NetBeans as my Arduino development environment, including all the nice features such as code completion, pre-compilation error checking and syntax highlighting, so please check back for more!

Stephen, I wonder if you recognise this?

Sat, 22 May 2010 18:39:00 GMT

I was reminiscing with Stephen about work yesterday, It's very faded after much use, but I wonder if he'll recognise the hat :-)

Arduino on OpenSolaris

Sat, 12 Dec 2009 01:09:00 GMT

Ed Plese has kindly provided OpenSolaris x86 binaries for the Arduino development environment. This includes all the necessary dependencies such as avr-gcc. and will work on OpenSolaris x86 build snv_113 onwards. The tarball is hosted on the Sun Download Centre, see the page at OpenSolaris.org for more details and links to the downloads.

Thanks to Ed for doing the work necessary to make this available for the OpenSolaris community.

Upgrading from Nevada to OpenSolaris the easy way

Wed, 21 Oct 2009 11:26:00 GMT

The OpenSolaris installer is simple and quick to use but it has one significant drawback - it gives you no control of how your disk is laid out. I needed to upgrade my Toshiba R500 laptop from Nevada to OpenSolaris and I had the disk set up with 3 VTOC slices - 2 ZFS pools, one for the root pool and one for a data pool - home dirs, installed software and so on. The final slice is a raw swap device. A straightforward install would have overwritten the entire disk, so I wanted to find a way of installing without clobbering everything. Ed Pilatowicz outlined some time back how you could do a hand-crafted OpenSolaris install to work around this, but I wanted to see if there was an easier way of achieving the same result with a more recent build of OpenSolaris.

My first attempt was to use the OpenSolaris 2009.06 livecd to install OpenSolaris onto a 8Gb USB stick so I could boot off that and have a poke around. That was fairly straightforward, but when I tried importing the existing root pool from the disk I hit a problem - the Nevada build I was running was onnv_124, but 2009.06 was based on 111b and the ZFS format has been rev'd since then so the pool wouldn't import. I then tried to update my USB image to build 125, but the stick wasn't big enough for the 125 BE and the 'pkg image-update' failed. Drat.

Third try was to pull a build 125 livecd image from the internal repo, boot off that and do a fresh install onto the USB stick. As before that worked fine so I rebooted off the USB stick. When I originally installed Nevada I had renamed the root pool from 'rpool' to 'solaris', so I typed 'zpool import solaris' and my existing boot pool on the drive appeared - looking good so far. Next thing to try was 'beadm list', and not only did my OpenSolaris BE show up, but the Nevada BEs on the drive also appeared. Ok, so far so good.

Now I needed to try to get an OpenSolaris BE onto the disk root pool. Worst case I could just blow away the existing root pool on the drive and create an OpenSolaris BE in that, but I wanted to see if I could preserve the existing Nevada BEs if possible. As Nevada and OpenSolaris are very similar and as I was using Nevada 124 and OpenSolaris 125 I figured there was a reasonable chance that if I could just get an OpenSolaris BE into the existing root pool I'd be able to get it into the grub config so I could boot it, even if that meant some hand-editing of menu.lst.

The easiest way to get an OpenSolaris BE onto the disk was to use 'beadm create'. Normally that creates the new BE on the same volume as the source BE, but there's a '-p' flag that allows you to specify an alternate pool to do the install into, which in my case was the existing 'solaris' pool on my disk - so, 'beadm create -p solaris on_125'. That seemed to work OK, so with everything appropriately crossed I typed 'beadm activate on_125' and rebooted. When Grub appeared, my new OpenSolaris BE was listed along with my existing Nevada ones, and both the OpenSolaris and Nevada BEs work just fine. Huzzah!

So, to summarise, here are the steps:

Make sure you are running a recent Nevada release
Obtain an OpenSolaris LiveCD image that is close to or the same as your Nevada release
Install OpenSolaris onto a spare disk - a 8Gb or larger USB memory stick or a USB disk will do fine
Boot into the OpenSolaris image
Import your existing root zpool - see below why this many not be as easy for you as it was for me
Create a new OpenSolaris BE on the imported pool with 'beadm' using the '-p' flag to specify the imported pool
Activate the new BE
Reboot, and you should see your existing Nevada BEs along with the OpenSolaris one which will be booted by default

Some caveats - this is clearly unsupported, don't be surprised if it doesn't work with a different mix of OpenSolaris and Nevada builds and don't blame me if it fries your machine. Also, this isn't a true upgrade in that you end up with a new OpenSolaris install and you'll have to manually migrate the necessary config from your Nevada BE into the OpenSolaris one - but at least you'll still have your Nevada BE :-) The final thing is I definitely got lucky - When I originally installed I'd renamed my Nevada root pool from 'rpool' to 'solaris'. That meant I could import it without it conflicting with the name of the root pool on the USB stick. If I hadn't done so I'd have to have imported it using the pool identifier and a new name. That would almost certainly have invalidated the contents of the menu.lst on that drive, so unless beadm fixed it up for me I'd have had to do some surgery to fix it up. If you try this yourself and figure out what's needed, please drop me a comment to let me know what you did :-)

The new opensolaris.org user management webapp moves into the light

Fri, 28 Sep 2007 15:48:25 GMT

As outlined here I've been working away on providing the infrastructure needed to break up the current monolithic J2EE application used to host opensolaris.org. I've just released the source code of the existing portal, a large J2EE application. As detailed in the restructuring document, the intention is to split the functionality of the current webapp into smaller, more manageable parts. As I was releasing the portal code, I thought it was a good time to move my development repository outside as well. Accordingly, you can browse the source at:

http://src.opensolaris.org/source/xref/website/auth/trunk/

and the source can be accessed via anonymous SVN at:

svn+ssh://anon@opensolaris.org/svn/website/auth

It is *very* rudimentary and is *far* from being finished. What I've put on opensolaris.org is just a snapshot of my development workspace as of today. However the database schema is available, along with a small set of dummy data which is used to populate the Derby database currently used by the prototype webapp.If you have any questions, I encourage you to subscribe to the website-discuss mailing list and ask them there.