Software

From Joon's Homepage (joonahn)

Jump to: navigation, search

Contents

[edit] My Library

The following are software libraries or modules developed by myself. I will be glad if someone finds one of them useful to him/her. You can feel free to modify it, but please leave my name as an original creator. Most of modules has their names started with Ja, which stands for Joon Ahn my name.


[edit] For TinyOS

What is TinyOS?
TinyOS is an open source component-based operating system and platform targeting wireless sensor networks (WSNs). TinyOS is an embedded operating system written in the nesC programming language as a set of cooperating tasks and processes. It is intended to be incorporated into smartdust. TinyOS is developed by a consortium led by the University of California, Berkeley in co-operation with Intel Research. (quoted from Wikipedia)
Look also its official homepage.
  • Following modules are for TinyOS 2.x (tested under beta2).
  • All the following modules are following most of the coding standards of tinyos-2.x (TEP 3).

[edit] JaFloodC

  • Description:
    This is the implementation of best-effort controlled flooding. If you use this for Tmote-sky'es, a flood packet will be sent out with TTL=254 and power=2 when you push the user button on a mote.
    • Features
      • Best-effort flooding: A node which receives a flooding packet forwards it only one time.
      • Delayed flooding: A node which receives a flooding packet forwards it after a ramdomly decided time; the miminum delay time is MIN_DELAY_TIME_4_FLOODING, delay time is slotted with interval SIZE_DELAY_SLOT_4_FLOODING, and the maximum number of slots is MAX_DELAY_SLOT_4_FLOODING. The reason of delayed flooding is to decrease the flooding packet collision. If we don't do the delayed flooding, neighbor nodes get the packet at almost same time, and forward it at almost same time because of the same software and hardware, and so there will be a high probabilty of collision.
      • Supports multiple floods: Each node can remember recent MAX_NUM_FLOODS number of floods, and does not forward them more than once so long as it remembers.
      • Supports a command: Each flood can carry one command (descripted by 'op') that a receiving node should do only once.
      • Adjustable transmitting power: Each flood packet has its designated transmitting power from 0 to 31 for Tmotes. For instance, two nodes should be placed a few inches away to communicate each other with high probability with the power of one.
    • Flooding packet format:
typedef struct FloodPktStruct {
	nx_uint16_t	id;			// JA: flood id		--	zero means dummy
	nx_uint16_t src;			// NOTICE: number of floods to do experiments when op is FLOOD_OP_BEGIN_EXPERIMENT
	nx_uint16_t dest;
	nx_uint8_t top;			// type of packet
	nx_uint8_t op;			// operation
	nx_uint8_t ttl;
	nx_uint8_t power;		// trasmitting power for this packet
} FloodPktStruct;
  • 'top' (Type of Packet) List:
enum {
   START_FLOOD = 24,
   FORWARD_FLOOD = 25
};
  • 'op' (Operation) List:
enum operations {
	FLOOD_OP_NOP = 0,			// no operation
	FLOOD_OP_SYNC_LOG = 1,			// make log synchoronized 
	FLOOD_OP_ERASE_LOG = 2,			// erase the entire log
	FLOOD_OP_BEGIN_EXPERIMENT = 3	// start the designated experiment. 
		// Currently, this operation is only applied to START_FLOOD.
};
  • Using Interfaces:
    • JaUserButton: For detecting user button signal.
    • Packet
    • CC2420Packet as PowerPacket: In order to control the transmitting power.
    • SplitControl as CommControl: A communication module (e.g. ActiveMessageC) should be connected.
    • Receive as CommReceive
    • AMSend as CommSend
    • LogWrite: For logging. The followin events are logged; receiving the first of flood packets with same flood id, fowarding a flood packet. The log format is as follows;
typedef struct __logdata_t {
	nx_uint32_t		time;   // time when the event occurred
	nx_uint16_t		id;     // flood id
	nx_uint16_t		src;    // 'src' of the corresponding flood packet
	nx_uint16_t		dest;   // 'dest' of the corr. flood packet
	nx_uint8_t		top;	// type of packet
	nx_uint8_t		op;	// operation
	nx_uint8_t		power;  // transmitting power of the corr. flood packet
	nx_uint8_t		commType;	// communication type; 'R' for received, 'T' for transmitted
	nx_uint8_t		ttl;    // TTL value of the corr. packet.
} logdata_t;
  • How to use: Just connect all the wires properly.

MainDefs.h (header file), FloodDataStruct.h (header file), JaLogData.h (header file), JaFloodApp.nc (example application)

[edit] JaBlinkerC

  • Description:
    This module is for easy blinking of LEDs with just one command. It is made with the hope that it be a useful tool for easy debugging
  • Providing Interfaces:
    • JaLedBlinker as LedBlinker
  • How to use:
    • Refer to the interface JaLedBlinker.

[edit] JaIDCommC

  • Description:
    This module says the name of application, its version, and the mote's TOS_NODE_ID on the given links when requested.
  • Using Interfaces:
    • AMSend
    • Receive
  • How to use:
    1. Instantiate this module.
    2. Make wires for AMSend and Receive interfaces of this module with whatever communication module which provides the corresponding interfaces.
    3. In your Makefile, add to CFLAGS major version (as a number in [0,255]), minor version (as a number in [0,255]), and you application's name (as a string wrapped by double quotation marks); JA_APP_MAJOR_VERSION is the macro name for the major version, JA_APP_MINOR_VERSION for the minor version, and JA_APP_NAME for the application name.
Example of nesc code)
components new JaIDCommC();
components ActiveMessageC as Radio;
JaIDCommC.AMSend -> Radio;
JaIDCommC.Receive -> Radio;

Example of Makefile)

CFLAGS+= -DJA_APP_NAME=\"JaDelayedFlood\"
CFLAGS+= -DJA_APP_MAJOR_VERSION=1 -DJA_APP_MINOR_VERSION=10

So, the application name is "JaDelayedFlood" and its version is 1.10. You don't need to modify the source code to change either the name or the version. Only Makefile.

[edit] JaLogEmulatorC

  • Description:
    This module provides LogRead and LogWrite interfaces. It is created because the LogStorageC doesn't work well so far (until tinyos-2.x-beta2 release) One difference from LogStorageC is that this module doesn't support the circular logging.
  • Providing Interfaces:
    • LogRead, LogWrite

[edit] JaQueuedLoggerC

  • Description:
    This module is for reliable and interval-introduced logging. It is a wrapping module of existing logging modules which provide LogWrite and LogRead interfaces. This module puts logging requests in the queue and processs one by one with a designated intervals (QLOGGER_PROC_INTERVAL defined in JaQueuedLoggerP.nc).
  • Providing Interfaces: LogRead, LogWrite
  • Using Interfaces: LogRead as WrappedLogRead, LogWrite as WrappedLogWrite
  • Why is this created:
    The basic logging in TinyOS is of two phase. For example, when you call LogWrite.append(), the following LogWrite.append() will fail (with the return value of EBUSY) until the response of the first append() is signalled. This makes the algorithm of a application a little subtle; if you need to make a reliable logging mechanism, you need to consider when you called append() command, whether its response has been signalled, how to log the current information later if the previous response has not, etc. This wrapper is an invisible layer between the basic log module and your application making your life easier removing such concerns.
  • How to use:
    1. Instantiate this module with two arguments MAX_ITEM_SIZE and MAX_QUEUE_SIZE. MAX_ITEM_SIZE is the maximum size (in bytes) of data you append or read with a single command. MAX_QUEUE_SIZE indicates how many requests this module can hold before responding the first request.
    2. Connect wires properly.
    3. Use it just like the wrapped module.

[edit] JaUserButtonC

  • Description:
    This module signals when the user button is pushed. It is for TMOTE-SKY only.
  • Providing Interfaces: JaUserButton
  • How to use:
    1. Declare the public module (JaUserButtonC.nc).
    2. Connect a wire properly.
    3. Call JaUserButton.enable() to activate the user button.
    4. For now on, when the user button is pushed, JaUserButton.push() will be signalled.


[edit] JaOneHopLogDumperM

  • Description:
This module provides a reliable one-hop communication for dumping data in the Flash of a mote on a any link if there is a corresponding ActiveMessageC for the link. It supports any kind of log format to be delivered.
The packet format is as follows:
typedef struct __jadumppkt_t
{
	nx_am_addr_t		src;				// source address (or ID)
	nx_uint8_t		op;				// operation
	nx_uint8_t		size;			// the size of this packet in bytes
	nx_uint8_t		seqno;			// sequence number
	nx_uint8_t		data[1];			// the first byte of the data which the rest of data is following.
} jadumppkt_t;

If the module receives a message of this format whose op = JA_LFC_GETALL when the module is idle (meaning that it is not involved in dumping to any other clients), it starts to dump the whole log data to the source of the packet (indicated by 'src'). In more detail, the mechanism is like stop-and-wait ARQ scheme so that the source is required to send an ACK packet (using the same packet format setting op = JA_LFC_ACK and 'seqno' as same as that of the message you're ACKing) after receiving each data packet. Operations indicated by 'op' is as follows:

  • JA_LFC_NOP: no operation
  • JA_LFC_GETALL: request to start dumping to the source.
  • JA_LFC_LOG: Indicating the packet has log data whose beginning is pointed by 'data'.
  • JA_LFC_LOGDONE: Indicating that dumping is completed; this packet doesn't have any log data.
  • JA_LFC_ACK: Indicating that this packet is ACK.
  • JA_LFC_BUSY: Saying that the mote is busy dumping to another client as a reply for JA_LFC_GETALL.
    • JA_LFC_INVALID: Saying that your ACK is invalid as a reply for JA_LFC_ACK.
  • Providing Interfaces: Init, SplitControl
  • Using Interfaces:
    • SplitControl as ComControl : A communication module (e.g. ActiveMessageC) is needed to be connected to this.
    • AMSend as Send : A communication module for sending packets (e.g. ActiveMessageC) is needed to be connected.
    • Receive: A communication module for receiving packets (e.g ActiveMessageC) is needed to be connected. Usually, the module for receiving is same as that of sending.
    • TimeoutTimer : A timer of unit of millisecond is needed to be connected.
    • Packet: A module providing the proper Packet interface is needed to be connected. (e.g. ActiveMessageC)
    • AMPacket: A module providing the proper AMPacket interface is needed to be connected. (e.g. ActiveMessageC)
    • LogRead: A Logger module for reading is needed to be connected (e.g. JaLogEmulatorC)
    • Leds
    • LedBlinker: A module providing the interface JaLedBlinker is needed to be connected.
  • How to use:
    1. Connect all the wires properly. Then, all the tinyos implementing part is done.
    2. In order to get the whole log data,
      1. Make the client program (using Java, Python, C, etc) such that it sends a packet of jadumppkt_t with 'op' = JA_LFC_GETALL in order to start the process. Then, the client will receive a packet of jadumppkt_t with 'op' = JA_LFC_LOG with one element of log data, if the dumping process is successfully initiated. The 'data' points the beginning of the element of log data, and the size of the data is ('size' - sizeof( jadumppkt_t ) + 1). The client should reply it as sending back a packet of jadumppkt_t setting 'seqno' same as that it replies. When the received packet has op = JA_LFC_LOGDONE, all the log data has been done.

[edit] JaSimCounterMilliC

  • Description: JaCounter3MilliC is the counter to be used for TOSSIM providing interfaces Counter<TMilli,uint32_t> and LocalTime<TMilli> for individual motes.
  • Providing Interfaces:
    • Counter<TMilli,uint32_t> as CounterMilli32
    • LocalTime<TMilli> as LocalTimeMilli
  • Why is this created:
    This module is created because there is no module in the basic TinyOS 2.x source tree which can provide an individual mote's local time and/or counter value. This module is intended to provide more realistic simulation.