Cilia/Cilia-SunSPOT Developping a new application
Here is some help showing how to develop a new application on a Java SunSPOT using the Cilia framework.
- 1 Introduction
- 2 Application Architecture
- 3 Adapters
- 4 An Adaptative Application
- 5 Constraints
- 6 A Flexible Code
- 7 Tricks
- 8 One complete example : Fire Detection and Environment measures
First, if you haven't made it before, you should make the Cilia-SunSPOT Hello World tutorial. This first tutorial helps you making one simple application on a SunSPOT using the framework Cilia.
Second, this may sound obvious, but when you develop an application for a SunSPOT using the framework Cilia, you are developping a Cilia application. Therefore most of the principles and concepts from Cilia stay unchanged : mediators, processors, schedulers, dispatchers, adapters, ... (see the Cilia overview).
Finally, major questions about building such an application will be : is it possible ? what are the machine's constraints about this application?
For any questions on the SunSPOT possibilities and characteristics, see on the SunSPOT's site. If it is possible on a SunSPOT, then it is possible on a SunSPOT using the framework Cilia.
An application's architecture is similar to the architecture of an application deployed on OSGi, however the files are not in the same type, and are not named the same way :
- The dscilia file, which corresponds to the chain descriptor, is replaced by a file Midlet.java, which describes the chain in Java.
- The metadata.xml file, which corresponds to the mediators description, is replaced by several files Mediator.java (like TimeMediator.java or BufferMediator.java), each one describing the content of one component.
- An extra file, Main.java calls the Midlet.java file, following the SunSPOT specification.
- The processor, scheduler, and dispatcher files stay unchanged.
You need to describe the same points like in an application which is deployed on OSGi ; the only difference is that you describe it completely in Java, and therefore structure it in a different way. An example of this architecture is given in the complete example.
In Cilia, adapters play a special role. They are placed at the limits of the chain mediation, when the framework Cilia loses the control on the data flow.
In the SunSPOT devices, they are particularly important, because an embedded system's purpose is an action on the environment : radio messages, visual messages, actuators,... However, they are not necessary : as any function of the device is directly available, you can call for a SunSPOT's functionality inside a mediator. Therefore, you should have a conceptual use of adapters : when the goal is to make an action on the environment, or with the environment.
Some adapters have already been developped for the complete example, they can (and they should) be reused as much as possible.
Here is a diagram showing the existing architecture for Cilia-SunSPOT, followed by a little description of each adapter.
Emission adapters :
- LED Adapter : send a message to this adapter to turn one led on or off. For instance, if you send a message containing setOn RED 0, you will turn on the first led on the left of your device, in red. If you send a message containing setOff 7, you will turn off the last led of your device. The available colors are : CHARTREUSE, CYAN, GREEN, MAGENTA, MAUVE, ORANGE,PUCE, RED, TURQUOISE, WHITE, YELLOW, and BLUE.
- Write Memory Adapter : send a message to this adapter with a byte as content, and it will store this byte array in memory.
- Send Radio Message (To Desktop/To SPOT) Adapter : send a message with a String in order to broadcast this String to the desktop if it is reachable/to any SunSPOT device that is listening.
- Period Adapter : send a message to this adapter with an integer value if you want to change the value of the sample period (in milliseconds) of the SPOT.
- Radio Power Adapter : send a message to this adapter with an integer value if you want to change the radio power : 0 for sending messages by radio as strong as possible, -31 for sending messages by radio as weak as possible.
Reception adapters :
- Heat Adapter : this adapter sends periodically a message with the value of the heat sensor.
- Light Adapter : this adapter sends periodically a message with the value of the light sensor.
- Listen To Radio Adapter: whenever it receives a radio message from the environment, this adapter receives this message and communicates it to the mediation chain.
- Time Adapter: this adapter sends periodically a message with the value of the device's clock.
Other adapters :
- Read Memory Adapter : this message sends all the data that have been stored in memory when it receives an empty message.
An Adaptative Application
One big interest of using Cilia for developping an application on SunSPOT devices is that it is easier to build highly adaptative applications.
Indeed, as you build your application as a mediation chain, the adaptation relies on messages that you send when some conditions are combined. Therefore, you can focus on how to detect these conditions, and what to send when these conditions are detected.
In the complete example of an application, we used the possibilities of adaptation : the application decides if it wants to send a radio message or not, if it wants to set one led on or off, etc., depending on what we wanted in such conditions. For instance, our application doesn't send message when there is no fire and no one tries to contact this device. If it receives a radio message, it will send another radio message, with a content depending on the first message's content. But if the application detects a fire, then it will send directly an alarm message.
Moreover, you can regulate your application characteristics depending on the conditions. For instance, in our example, in case of a detected fire, the application sends radio messages with more power, and the sampling period is reduced, in order to send messages more frequently. When the fire seems to have been put out, the application comes back to a behaviour that saves more energy : the power of communications is reduced, and the sampling period is increased.
In our example, we use the period and radio power adapters to regulate our characteristics. There is obviously many ways to perform it if you develop your own application with more specific constraints.
These adaptative possibilities allow you to design an application that can decide what to do, and how to do it, in order to have a flexible behaviour depending on the environment and the external conditions. Using the SunSPOT memory, you can also build an application that waits for complex conditions and performs complex reactions, following whatever you may want.
SunSPOT devices work with Squawk, which is a Java Virtual Machine designed for embedded systems. Compared to another Java Virtual Machine, it offers almost the same compilation environment, but with much attention to the size it takes in memory, in order to minimize its impact on the system, and to use as much of the system's performances on the applications.
This means that some functionalities that were possible in Java are no longer possible when using Squawk : Squawk is CLDC 1.1-compatible, as it is said in the project description (where you can also find more publications about Squawk, see here).
The main parts of Java which have disappeared that you should know are :
- The reflection part : the only reflective function that we found possible to use on Squawk is Class.forName().newInstance().
- Some usual Java data types : for instance, Vector, Collection and Hashtable are available, but very few other ones.
In order to find if a Java implementation would work on Squawk, a good solution is to use your IDE with good parameters of compilation and build path : see at the end of this section in order to set it up. If the method or class that you want to use is not recognized, it means that this is not implemented in Squawk.
When we met problems of implementating a functionality that was not supported by Squawk, we chose between :
- Replacing the implementation we wanted by another, with simpler methods or classes
- Getting the sources of the implementation we needed, and rewrite it explicitly
- Giving up this part of the application, because it would be too heavy for the code or the performances to make it another way
A Flexible Code
Even if Squawk brings some constraints in the development, deploying an application based on Cilia on OSGi or on a SunSPOT device brings very few difference.
Moreover, if an application can be compiled on Squawk, and therefore be deployed on a SunSPOT, it can also be deployed on OSGi (the only restriction is about hardware : you can't call functions that are specific to SunSPOT devices, like setting one led on, sending a radio message, etc...).
Therefore, it is possible to develop the code of the application, and only then to choose where to deploy it : OSGi, SunSPOT, or another platform if Cilia is deployable inside.
This gives possibility to begin developpment sooner, and to analyze performance, before to choose how to split an application between OSGi and devices. Moreover, this could allow a simulation of the global application, before the deployment, without spending extra time for the developpment of the simulation : the code of the simulation can be reused in the application. For instance, we developped our application on OSGi in a first time, and reused the final code for building the application on a SunSPOT device.
These points make the design and the developpment of an application more flexible, in a domain in which delays or mistakes have a very important cost.
Here are some useful tricks about developping an application on SunSPOT using Cilia.
A first simulation of your application
In the complete example, we developped a little package, CiliaSpotDebugProject, which allows a first simlation of the application outside the device.
The idea is that the application code looks for a boolean indicating if it runs in debug mode or in the device. If it is in debug mode, then the application doesn't call for the hardware, and gives a poor simulation of it (for instance, it always gives the same temperature, or it receives one radio message after 3 seconds, etc...).
This way, you can get a first idea of what happens in your application before deploying it on the device.
If you want to use this package, and you developp other adapters, or mediators using the device's hardware (led, memory, radio protocol, etc...), you must follow the example of code in some adapters (HeatAdapter for instance) in order to make a correct code. If you don't, the project won't be able to run, as it will call for hardware that is not present.
Seeing traces while the application is working inside the SunSPOT
Another stage of testing your program can be to run the code inside the SunSPOT device, but with traces that are printed on the screen.
You should use the ant command ant run in order to perform this test.
This test restricts the possibilities, as your device is necessarily connected to your personal computer, but it allows you to follow precisely what happens inside the device.
Once this test is passed, you can simply unplug the device and reset it if you want to run it in normal conditions.
If you want to rewrite components, because you need a minor change in their behaviour, or if you want to suggest new components in the cilia-sunspot libraries, they are placed in cilia-sunspot-components, and in cilia-minimal-compendium, which are available here.
cilia-sunspot-components contains the adapters, and classes that are specific to SunSPOT platform (like Machine.java, containing the hardware methods) ; cilia-minimal-compendium contains the usual schedulers, processors and dispatchers, in a version compatible with Squawk.
Compiling the Cilia-SunSPOT libraries
If you want to modify the Cilia-SunSPOT libraries, you may appreciate a compilation script, that simplifies the compilation of the different packages, and places the compiled jars in your SDK library repository.
This script is script.sh, available here.
If you want to add extra packages to these libraries, you can follow what was explained in this section, and change script.sh in order to add one package, following what was made for the others.
You should also add the packages that are in the SDK library to the classpath in your IDE, so that your IDE and your device always have the same version of the code.
One complete example : Fire Detection and Environment measures
The complete example is an application which measures periodically the environment (heat and light, with the clock time of the sample), and records these measures. Following different criteria (day time : too hot ; night time : too hot or too much light), it can detect fire. In case of fire, it sends radio messages of alarm, and sets one led on in red. If there is no fire, the led is set on in green, and no radio messages are sent.
The example also includes an application on a basestation, which sends periodically messages to SunSPOT devices, in order to get their measures. If a SunSPOT device get one of these messages, it sends all its measures in radio messages, and the basestation application prints it on the screen.
If a SunSPOT device receives a message of fire from another device, it sends this message back once, and sets one led in orange. If a basestation application receives a message of fire, it prints it on the screen.
If a SunSPOT device detects no fire any more, it sends a message "No more fire", which can be received by another device (which sets off the orange led) or by the basestation application (which prints it on the screen).
The complete example is available here.
The repository Emulation contains different emulations of the application. The repository HeatCiliaDesktop contains the basestation application. The repository HeatCiliaSpot contains the device application. The jar files are the libraries which were used to compile this application.
A demonstration video is coming soon...