BUG Labs works hard to make the process of writing embedded software easy. You can write a program using the Dragonfly SDK and send it to a BUG on the network. No messing with JTAG cables, writing to SD cards and rebooting, or even using scp. BUG has got your back! But what's really going on behind the scenes?
The process works like this:
- Find BUGs on the network.
- Create an application JAR file.
- Remove the old instance of the app from the selected BUG if one already exists.
- Send the JAR file to the selected BUG.
You should first understand how Dragonfly finds BUGs on the network. This is done using Zeroconf's service discovery mechanism. If you are running Linux and have the avahi package installed, you can get a list of the BUGs on your network using this command from the command line:
avahi-browse _bugdevice._tcp This will print a a list of all of the devices that advertise the _bugdevice._tcp service. It should look like this:
+ eth0 IPv4 tergbug _bugdevice._tcp local
+ eth0 IPv4 desenna-bug _bugdevice._tcp local
+ eth0 IPv4 aturley-bug20 _bugdevice._tcp local
+ eth0 IPv4 motherbug _bugdevice._tcp local
+ eth0 IPv4 bug20-2 _bugdevice._tcp localThese devices show up in Dragonfly's "My BUGs" panel.
When you tell Dragonfly to send an application to a BUG, it creates a JAR file for the application. A JAR file is an archive file that contains all of the application's classes and resources. BUG JAR files also contain the source code and Eclipse configuration files for the project. You can see the JAR file by looking in your Eclipse workspace after you have told the SDK to send the app to a BUG (and since the JAR file is created at the beginning of the request, you do not have to actually send the application to see it). For example, I have an app called ButtonPusher, and the JAR file is located at workspace/.metadata/.plugins/com.buglabs.dragonfly.ui/ButtonPusher.jar, where workspace is my Eclipse workspace.
Once the JAR file has been created and the destination BUG has been selected, a series of HTTP requests are made to the BUG to determine whether or not an app is already installed. The point of access for these requests is http://<BUGADDRESS>/program, where <BUGADDRESS> is the address of your BUG on the network. You can use this URL to get information about the bundles that are installed on the BUG. If you point your browser at the URL you will see an XML reprsentation of this information. You can add bundles by sending an HTTP POST request to http://<BUGADDRESS>/program/PROGRAMNAME, where PROGRAMNAME is the name of the name of the bundle, from the Bundle-Name property in the app's manifest. The data in the HTTP request should be the actual JAR file for the app. For example, if I wanted to send the ButtonPusher app that I mentioned earlier, I could use curl and do this:
curl --http1.0 --request POST --upload-file workspace/.metadata/.plugins/com.buglabs.dragonfly.ui/ButtonPusher.jar http://<BUGADDRESS>/program/ButtonPusherSimilarly, sending an HTTP DELETE request to http://<BUGADDRESS>/program/PROGRAMNAME will delete the app. Using curl I can do this:
curl --request DELETE http://<BUGADDRESS>/program/ButtonPusherAs a final trick, you can retrieve the app's JAR file using an HTTP GET request. But in this case you need to use the program id that is listed when you send a request to http://<BUGADDRESS>/program. For example, ButtonPusher's program id was 42, then it's JAR file could be retrieved like this:
Why is this useful? Well, maybe you just like knowing how things work. But you could also use this information to build your own system for loading apps without using Dragonfly. You could write a bulk app loader that loads an app to all connected BUGs. Or ou could write a small program that downloads apps from BUGnet and loads them onto a BUG. Have fun, and use your imagination.