*/
/**
+ * BaseStation is a reimplementation of the standard BaseStation application using
+ * the TOSThreads thread library. It transparently forwards any AM messages it
+ * receives from its radio interface to its serial interface and vice versa.
+ *
+ * <p>On the serial link, BaseStation sends and receives simple active
+ * messages (not particular radio packets): on the radio link, it
+ * sends radio active messages, whose format depends on the network
+ * stack being used. BaseStation will copy its compiled-in group ID to
+ * messages moving from the serial link to the radio, and will filter
+ * out incoming radio messages that do not contain that group ID.</p>
+ *
+ * <p>BaseStation includes queues in both directions, with a guarantee
+ * that once a message enters a queue, it will eventually leave on the
+ * other interface. The queues allow the BaseStation to handle load
+ * spikes.</p>
+ *
+ * <p>BaseStation acknowledges a message arriving over the serial link
+ * only if that message was successfully enqueued for delivery to the
+ * radio link.</p>
+ *
+ * <p>The LEDS are programmed to toggle as follows:</p>
+ * <ul>
+ * <li><b>LED0:</b> Message bridged from serial to radio</li>
+ * <li><b>LED1:</b> Message bridged from radio to serial</li>
+ * <li><b>LED2:</b> Dropped message due to queue overflow in either direction</li>
+ * </ul>
+ *
* @author Kevin Klues <klueska@cs.stanford.edu>
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
*/
/**
+ * BaseStation is a reimplementation of the standard BaseStation application using
+ * the TOSThreads thread library. It transparently forwards any AM messages it
+ * receives from its radio interface to its serial interface and vice versa.
+ *
+ * <p>On the serial link, BaseStation sends and receives simple active
+ * messages (not particular radio packets): on the radio link, it
+ * sends radio active messages, whose format depends on the network
+ * stack being used. BaseStation will copy its compiled-in group ID to
+ * messages moving from the serial link to the radio, and will filter
+ * out incoming radio messages that do not contain that group ID.</p>
+ *
+ * <p>BaseStation includes queues in both directions, with a guarantee
+ * that once a message enters a queue, it will eventually leave on the
+ * other interface. The queues allow the BaseStation to handle load
+ * spikes.</p>
+ *
+ * <p>BaseStation acknowledges a message arriving over the serial link
+ * only if that message was successfully enqueued for delivery to the
+ * radio link.</p>
+ *
+ * <p>The LEDS are programmed to toggle as follows:</p>
+ * <ul>
+ * <li><b>LED0:</b> Message bridged from serial to radio</li>
+ * <li><b>LED1:</b> Message bridged from radio to serial</li>
+ * <li><b>LED2:</b> Dropped message due to queue overflow in either direction</li>
+ * </ul>
+ *
* @author Kevin Klues <klueska@cs.stanford.edu>
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
*/
/**
+ * BaseStation is a reimplementation of the standard BaseStation application using
+ * the TOSThreads thread library. It transparently forwards any AM messages it
+ * receives from its radio interface to its serial interface and vice versa.
+ *
+ * <p>On the serial link, BaseStation sends and receives simple active
+ * messages (not particular radio packets): on the radio link, it
+ * sends radio active messages, whose format depends on the network
+ * stack being used. BaseStation will copy its compiled-in group ID to
+ * messages moving from the serial link to the radio, and will filter
+ * out incoming radio messages that do not contain that group ID.</p>
+ *
+ * <p>BaseStation includes queues in both directions, with a guarantee
+ * that once a message enters a queue, it will eventually leave on the
+ * other interface. The queues allow the BaseStation to handle load
+ * spikes.</p>
+ *
+ * <p>BaseStation acknowledges a message arriving over the serial link
+ * only if that message was successfully enqueued for delivery to the
+ * radio link.</p>
+ *
+ * <p>The LEDS are programmed to toggle as follows:</p>
+ * <ul>
+ * <li><b>LED0:</b> Message bridged from serial to radio</li>
+ * <li><b>LED1:</b> Message bridged from radio to serial</li>
+ * <li><b>LED2:</b> Dropped message due to queue overflow in either direction</li>
+ * </ul>
+ *
* @author Kevin Klues <klueska@cs.stanford.edu>
*/
*/
/**
+ * Blink is a simple application used to test the basic functionality of
+ * TOSThreads.
+ *
+ * Upon a successful burn, you should see LED0 flashing with a period of every
+ * 200ms, and LED1 and LED2 flashing in unison with a period of 1000ms.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
*/
*/
/**
+ * Blink is a simple application used to test the basic functionality of
+ * TOSThreads.
+ *
+ * Upon a successful burn, you should see LED0 flashing with a period of every
+ * 200ms, and LED1 and LED2 flashing in unison with a period of 1000ms.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
*/
*/
/**
- * @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
+ * Blink is a simple application used to test the basic functionality of
+ * TOSThreads using dynamic threads rather than static threads.
+ *
+ * Upon a successful burn, you should see LED0 flashing with a period of every
+ * 200ms, and LED1 and LED2 flashing in unison with a period of 1000ms.
*
- * This is the dynamic thread implementation of Blink.
+ * @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
configuration BlinkAppC {}
*/
/**
- * @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
+ * Blink is a simple application used to test the basic functionality of
+ * TOSThreads using dynamic threads rather than static threads.
+ *
+ * Upon a successful burn, you should see LED0 flashing with a period of every
+ * 200ms, and LED1 and LED2 flashing in unison with a period of 1000ms.
*
- * This is the dynamic thread implementation of Blink.
+ * @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
module BlinkC {
*/
/**
+ * This application is used to test the threaded version of the API for accessing
+ * sensors on the basicsb sensor board.
+ *
+ * This application simply takes sensor readings in an infinite loop from the
+ * Photo and Temperature sensors on the basicsb sensor board and forwards them
+ * over the serial interface. Upon successful transmission, LED0 is toggled.
+ *
+ * A successful test will result in the TestBasicsbSensors mote constantly
+ * flickering LED0. Additionally, messages containing the sensor readings should
+ * be forwarded over the serial interface as verified by running the following
+ * for the platform of interest:
+ * java net.tinyos.tools.Listen -comm serial@/dev/ttyUSBXXX:<baud_rate>
+ *
+ * Once this java application is running, you should see output containing the
+ * sensor readings being streamed to your terminal.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
*/
*/
/**
+ * This application is used to test the threaded version of the API for performing
+ * block storage.
+ *
+ * This application first checks the size of the block storage volume, and
+ * erases it. Then, it randomly writes records, followed by a verification
+ * with read.
+ *
+ * Successful running of this application results in LED0 being ON
+ * throughout the duration of the erase, write, and read sequence. Finally,
+ * if all tests pass, LED1 is turned ON. Otherwise, all three LEDs are
+ * turned ON to indicate problems.
+ *
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
*/
/**
+ * This application is used to test the threaded version of the API for performing
+ * block storage.
+ *
+ * This application first checks the size of the block storage volume, and
+ * erases it. Then, it randomly writes records, followed by a verification
+ * with read.
+ *
+ * Successful running of this application results in LED0 being ON
+ * throughout the duration of the erase, write, and read sequence. Finally,
+ * if all tests pass, LED1 is turned ON. Otherwise, all three LEDs are
+ * turned ON to indicate problems.
+ *
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
* THE POSSIBILITY OF SUCH DAMAGE.
*/
-/*
+/**
+ * TestCollection is a reimplementation of the Multihop Oscilloscope application
+ * using TOSThreads. It periodically samples a universal software-based SineSensor
+ * and broadcasts a message every few readings. These readings can be displayed by
+ * the Java "Oscilloscope" application found in the the TestCollection/java
+ * subdirectory. The sampling rate starts at 4Hz, but can be changed from the Java
+ * application.
+ *
+ * At least two motes must be used by this application, with one of them installed
+ * as a base station. Base station motes can be created by installing them with
+ * NODE_ID % 500 == 0.
+ * i.e. make <platform> threads install.0
+ * make <platform> threads install.500
+ * make <platform> threads install.1000
+ *
+ * All other nodes can be installed with arbitrary NODE_IDs.
+ * make <platform> threads install.123
+ *
+ * Successful running of this application is verified by all NON-base station motes
+ * periodically flashing LED1 upon sending a message, and the base station mote,
+ * flashing LED2 upon successful reception of a message. Additionally, correct
+ * operation should be verified by running the java tool described in the following
+ * section.
+ *
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
* THE POSSIBILITY OF SUCH DAMAGE.
*/
-/*
+/**
+ * TestCollection is a reimplementation of the Multihop Oscilloscope application
+ * using TOSThreads. It periodically samples a universal software-based SineSensor
+ * and broadcasts a message every few readings. These readings can be displayed by
+ * the Java "Oscilloscope" application found in the the TestCollection/java
+ * subdirectory. The sampling rate starts at 4Hz, but can be changed from the Java
+ * application.
+ *
+ * At least two motes must be used by this application, with one of them installed
+ * as a base station. Base station motes can be created by installing them with
+ * NODE_ID % 500 == 0.
+ * i.e. make <platform> threads install.0
+ * make <platform> threads install.500
+ * make <platform> threads install.1000
+ *
+ * All other nodes can be installed with arbitrary NODE_IDs.
+ * make <platform> threads install.123
+ *
+ * Successful running of this application is verified by all NON-base station motes
+ * periodically flashing LED1 upon sending a message, and the base station mote,
+ * flashing LED2 upon successful reception of a message. Additionally, correct
+ * operation should be verified by running the java tool described in the following
+ * section.
+ *
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
--- /dev/null
+README for TOSThreads TestJoin
+Author/Contact: tinyos-help@millennium.berkeley.edu
+Author: Kevin Klues <klueska@cs.stanford.edu>
+
+Description:
+
+TestJoin is a simple application used to test the basic functionality of
+the join() system call for waiting on a set of threads in a TOSThreads
+based application.
+
+You can install TestJoin on a mote via the following command:
+ make <platform> threads install
+
+Valid platforms are currently: tmote, telosb, iris, mica2, and micaz
+
+Upon a successful burn, you should first see LED0 flash twice with a period of
+1s and LED1 flash 4 times with a period of 1s. After these are done,
+LED2 should come on and stay on.
+
+Tools:
+ None.
+
+Known bugs/limitations:
+ None.
*/
/**
+ * TestJoin is a simple application used to test the basic functionality of
+ * the join() system call for waiting on a set of threads in a TOSThreads
+ * based application.
+ *
+ * Upon a successful burn, you should first see LED0 flash twice with a period of
+ * 1s and LED1 flash 4 times with a period of 1s. After these are done,
+ * LED2 should come on and stay on.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
*/
components new ThreadC(100) as NullThread;
components new ThreadC(100) as TinyThread0;
components new ThreadC(100) as TinyThread1;
- components new ThreadC(100) as TinyThread2;
MainC.Boot <- TestJoinC;
TestJoinC.NullThread -> NullThread;
TestJoinC.TinyThread0 -> TinyThread0;
TestJoinC.TinyThread1 -> TinyThread1;
- TestJoinC.TinyThread2 -> TinyThread2;
TestJoinC.Leds -> LedsC;
}
*/
/**
+ * TestJoin is a simple application used to test the basic functionality of
+ * the join() system call for waiting on a set of threads in a TOSThreads
+ * based application.
+ *
+ * Upon a successful burn, you should first see LED0 flash twice with a period of
+ * 1s and LED1 flash 4 times with a period of 1s. After these are done,
+ * LED2 should come on and stay on.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
*/
interface Thread as NullThread;
interface Thread as TinyThread0;
interface Thread as TinyThread1;
- interface Thread as TinyThread2;
interface Leds;
}
}
for(;;){
call TinyThread0.start(NULL);
call TinyThread1.start(NULL);
- call TinyThread2.start(NULL);
- call TinyThread1.join();
call TinyThread0.join();
- call TinyThread2.join();
+ call TinyThread1.join();
+ call Leds.led2Toggle();
}
}
event void TinyThread0.run(void* arg) {
call TinyThread1.sleep(1000);
}
}
- event void TinyThread2.run(void* arg) {
- int i;
- for(i=0; i<6; i++){
- call Leds.led2Toggle();
- call TinyThread2.sleep(1000);
- }
- }
}
*/
/**
+ * This application tests the operation of the Printf client in TOSThreads. It
+ * continuously prints the value of a counter starting at 0, increasing as it
+ * prints.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
*/
*/
/**
+ * This application tests the operation of the Printf client in TOSThreads. It
+ * continuously prints the value of a counter starting at 0, increasing as it
+ * prints.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
*/
*/
/**
+ * This application is used to test the threaded version of the API for accessing
+ * the software based SineSensor usable by any platform for demonstration purposes.
+ *
+ * This application simply takes sensor readings in an infinite loop from the
+ * SineSensor and forwards them over the serial interface. Upon successful
+ * transmission, LED0 is toggled.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
*/
*/
/**
+ * This application is used to test the threaded version of the API for accessing
+ * the software based SineSensor usable by any platform for demonstration purposes.
+ *
+ * This application simply takes sensor readings in an infinite loop from the
+ * SineSensor and forwards them over the serial interface. Upon successful
+ * transmission, LED0 is toggled.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
*/
*/
/**
- * Base station implementation using tosthreads
+ * BaseStation is a reimplementation of the standard BaseStation application using
+ * the TOSThreads thread library. It transparently forwards any AM messages it
+ * receives from its radio interface to its serial interface and vice versa.
+ *
+ * <p>On the serial link, BaseStation sends and receives simple active
+ * messages (not particular radio packets): on the radio link, it
+ * sends radio active messages, whose format depends on the network
+ * stack being used. BaseStation will copy its compiled-in group ID to
+ * messages moving from the serial link to the radio, and will filter
+ * out incoming radio messages that do not contain that group ID.</p>
+ *
+ * <p>BaseStation includes queues in both directions, with a guarantee
+ * that once a message enters a queue, it will eventually leave on the
+ * other interface. The queues allow the BaseStation to handle load
+ * spikes.</p>
+ *
+ * <p>BaseStation acknowledges a message arriving over the serial link
+ * only if that message was successfully enqueued for delivery to the
+ * radio link.</p>
+ *
+ * <p>The LEDS are programmed to toggle as follows:</p>
+ * <ul>
+ * <li><b>LED0:</b> Message bridged from serial to radio</li>
+ * <li><b>LED1:</b> Message bridged from radio to serial</li>
+ * <li><b>LED2:</b> Dropped message due to queue overflow in either direction</li>
+ * </ul>
*
* @author Kevin Klues <klueska@cs.stanford.edu>
*/
*/
/**
+ * Blink is a simple application used to test the basic functionality of
+ * TOSThreads.
+ *
+ * Upon a successful burn, you should see LED0 flashing with a period of every
+ * 200ms, and LED1 and LED2 flashing in unison with a period of 1000ms.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
*/
*/
/**
+ * This application is derived from a similar application in the TinyThread
+ * implementation by William P. McCartney from Cleveland State University (2006)
+ *
+ * This application stresses the operation of the thread based AM commands for
+ * packet transmission and reception. To run this application you will need to
+ * burn it on one mote with NODE_ID 0, and a second mote with NODE_ID 1.
+ *
+ * Three different threads run that each contain an infinite loop that first sends
+ * a message and then waits to receive a message before returning to the top of the
+ * loop. After each message reception, one of the onboard LEDs is toggled to
+ * indicate that it was received. Thread 0 blinks LED0, thread 1 blinks LED1, and
+ * thread 2 blinks LED2. The three threads run independently, and three different
+ * messages are bounced back and forth between the two motes in an unsynchronized
+ * fashion. In contrast to the more complicated Bounce application found in the
+ * normal nesC threads version of this application, once a thread receives a
+ * message it will immediately flip on its LED instead of waiting on a Barrier and
+ * synchronizing the LEDs to come on only once messages have been received from all
+ * threads. In this way, messages are bounced back and forth between the two motes
+ * in an asynchronous fashion, and LEDS are toggled immediately upon message
+ * reception..
+ *
+ * Successful running of this application results in each LED bouncing back and
+ * forth between each mote independent of one another. This will continue in an
+ * finite loop forever.
+ *
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
*/
/**
+ * Null is an empty skeleton application for testing the basic compilation and
+ * runtime of a c-based tosthreads application. It is useful to test that the build
+ * environment is functional in its most minimal sense, i.e., you can correctly
+ * compile an application. It is also useful to test the minimum power consumption
+ * of a node when it has absolutely no interrupts or resources active.
+ *
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
*/
/**
+ * SenseAndSend is a threaded implementation of an application that takes various
+ * sensor readings in parallel (by dedicating one thread to each reading), and
+ * assembling them into a packet to be sent out over the radio. It is written
+ * specifically for use with the tmote onboard sensor package, and will not compile
+ * for any other platforms.
+ *
+ * Readings are taken from each of the 4 oboard sensors and sent out over the radio
+ * interface in an infinite loop. Upon successful transmission, LED0 is toggled,
+ * and the process starts over again.
+ *
+ * A successful test will result in LED0 toggling periodically at a rate of
+ * approximately 220ms (the time it takes to take a humidity + temperature sensor
+ * reading since they share the same hardware and cannot be taken in parallel).
+ *
+ * Additionally, a base station application should be run to verify the reception
+ * of packets sent from a SenseAndSend mote, with reasonable looking sensor data.
+ *
* @author Kevin Klues <klueska@cs.stanford.edu>
*/
*/
/**
+ * SenseStoreAndForward is a threaded implementation of an application that takes
+ * various sensor readings in parallel (by dedicating one thread to each reading),
+ * logs them to flash, and then sends them out over the radio at some later time.
+ * In the current implementation, sensor readings are taken as quickly as possible,
+ * and records containing a set of readings from each iteration are batched out
+ * over the radio every 10000ms. This application is written specifically for use
+ * with the tmote onboard sensor package, and will not compile for any other
+ * platforms.
+ *
+ * Readings are taken from each of the 4 oboard sensors and logged to flash as one
+ * record in an infinite loop. Records are then read out of flash and and sent out
+ * over the radio interface in separate infinite loop. Before the application
+ * starts running, the entire contents of the flash drive are erased.
+ *
+ * A successful test will result in LED0 remaining solid for approximately 6s while
+ * the flash is being erased. After that LED0 will toggle with each successful set
+ * of sensor readings logged to flash, at a rate of approximately 220ms (the time
+ * it takes to take a humidity + temperature sensor reading since they share the
+ * same hardware and cannot be taken in parallel). Also, LED1 will begin toggling
+ * in rapid succession once every 10000ms as records are successfully read from
+ * flash and sent out over the radio. Once all of the records currently recorded
+ * to flash since the last batch of sends have been sent out, LED2 Toggles to
+ * indicate completion. This process continues in an infinite loop forever.
+ *
+ * Additionally, a base station application should be run to verify the reception
+ * of packets sent from a SenseStoreAndForward mote, with reasonable looking sensor
+ * data.
+ *
* @author Kevin Klues <klueska@cs.stanford.edu>
*/
set it to 57600.
Known bugs/limitations:
- Warnings are issued about fan out on the 'Snoop.receive' and 'Receive.receive'
- events. These warnings are harmless and are the result of providing a C based
- API in which all events for receiving and snooping must be handled even if not
- used by a particular application. The warnings occur because the underlying
- CTP or MultihopLQI stacks wire up to particular AM ids, which are also wired
- into the C API for handling message reception.
+ None
*/
/**
+ * TestCollection is a reimplementation of the Multihop Oscilloscope application
+ * using TOSThreads. It periodically samples a universal software-based SineSensor
+ * and broadcasts a message every few readings. These readings can be displayed by
+ * the Java "Oscilloscope" application found in the the TestCollection/java
+ * subdirectory. The sampling rate starts at 4Hz, but can be changed from the Java
+ * application.
+ *
+ * At least two motes must be used by this application, with one of them installed
+ * as a base station. Base station motes can be created by installing them with
+ * NODE_ID % 500 == 0.
+ * i.e. make <platform> threads install.0
+ * make <platform> threads install.500
+ * make <platform> threads install.1000
+ *
+ * All other nodes can be installed with arbitrary NODE_IDs.
+ * make <platform> threads install.123
+ *
+ * Successful running of this application is verified by all NON-base station motes
+ * periodically flashing LED1 upon sending a message, and the base station mote,
+ * flashing LED2 upon successful reception of a message. Additionally, correct
+ * operation should be verified by running the java tool described in the following
+ * section.
+ *
* @author Kevin Klues <klueska@cs.stanford.edu>
*/
--- /dev/null
+README for TOSThreads TestJoin
+Author/Contact: tinyos-help@millennium.berkeley.edu
+Author: Kevin Klues <klueska@cs.stanford.edu>
+
+Description:
+
+TestJoin is a simple application used to test the basic functionality of
+the join() system call for waiting on a set of threads in a TOSThreads
+based application.
+
+You can install TestJoin on a mote via the following command:
+ make <platform> threads install
+
+Valid platforms are currently: tmote, telosb, iris, mica2, and micaz
+
+Upon a successful burn, you should first see LED0 flash twice with a period of
+1s and LED1 flash 4 times with a period of 1s. After these are done,
+LED2 should come on and stay on.
+
+Tools:
+ None.
+
+Known bugs/limitations:
+ None.
*/
/**
+ * TestJoin is a simple application used to test the basic functionality of
+ * the join() system call for waiting on a set of threads in a TOSThreads
+ * based application.
+ *
+ * Upon a successful burn, you should first see LED0 flash twice with a period of
+ * 1s and LED1 flash 4 times with a period of 1s. After these are done,
+ * LED2 should come on and stay on.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
*/
tosthread_t init;
tosthread_t blink0;
tosthread_t blink1;
-tosthread_t blink2;
void init_thread(void* arg);
void blink0_thread(void* arg);
void blink1_thread(void* arg);
-void blink2_thread(void* arg);
void tosthread_main(void* arg) {
//Use stack estimator to calculate maximum stack size
for(;;) {
tosthread_create(&blink0, blink0_thread, NULL, BLINK0_STACK_SIZE);
tosthread_create(&blink1, blink1_thread, NULL, BLINK1_STACK_SIZE);
- tosthread_create(&blink2, blink2_thread, NULL, BLINK2_STACK_SIZE);
- tosthread_join(&blink2);
tosthread_join(&blink0);
tosthread_join(&blink1);
+ led2Toggle();
}
}
}
}
-void blink2_thread(void* arg) {
- int i;
- for(i=0; i<6; i++) {
- led2Toggle();
- tosthread_sleep(1000);
- }
-}
*/
/**
+ * TestLogStorage is a threaded implementation of an application that takes a dummy
+ * sensor readings of a counter, logs it flash, and then sends it out over the
+ * serial port at some later time. In the current implementation, each sensor reading is
+ * taken once every 3000ms, and records containing a set of readings from each
+ * iteration are batched out over the radio every 10000ms. This application is
+ * very similar to the SenseStoreAndForward application contained in this same
+ * directory, except that it is written using a dummy sensor value instead of
+ * sensors specific to the tmote onboard suite. In this way, the LogStorage
+ * functionality can be tested in conjunction with the sending facility in a
+ * platform independent way.
+ *
+ * Readings are taken from the dummy sensor and logged to flash as one record in an
+ * infinite loop. Records are then read out of flash and and sent out over the
+ * serial interface in separate infinite loop. Before the application starts
+ * running, the entire contents of the flash drive are erased.
+ *
+ * A successful test will result in LED0 remaining solid for approximately 6s while
+ * the flash is being erased. After that LED0 will toggle with each successful
+ * sensor readings logged to flash, at a rate of 3000ms. Also, LED1 will begin
+ * toggling in rapid succession once every 10000ms as records are successfully read
+ * from flash and sent out over the serial port. Once all of the records currently
+ * recorded to flash since the last batch of sends have been sent out, LED2 Toggles
+ * to indicate completion. This process continues in an infinite loop forever.
+ *
* @author Kevin Klues <klueska@cs.stanford.edu>
*/
*/
/**
+ * This application tests the operation of the Printf client in TOSThreads. It
+ * continuously prints the value of a counter starting at 0, increasing as it
+ * prints.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
*/
*/
/**
+ * This application is used to test the threaded version of the API for accessing
+ * the software based SineSensor usable by any platform for demonstration purposes.
+ *
+ * This application simply takes sensor readings in an infinite loop from the
+ * SineSensor and forwards them over the serial interface. Upon successful
+ * transmission, LED0 is toggled.
+ *
* @author Kevin Klues <klueska@cs.stanford.edu>
*/
*/
/**
+ * This application stresses the creation and destruction of dynamic threads by
+ * spawning lots and lots of threads over and over again and letting them run to
+ * completion. Three different thread start functions are used, each toggling one
+ * of LED0, LED1, and LED2 every 256 spawnings. The time at which each LED is
+ * toggled is offset so that the three LEDS do not come on in unison.
+ *
+ * Successful running of this application will result in all three leds flashing at
+ * a rate determined by how long it takes to spawn a thread on a given platform.
+ * All three LEDs should flash at this rate in an infinite loop forever. Given the
+ * dynamics on the mote the rate may vary over time, but the important thing is
+ * that all three LEDs continue to toggle at a reasonably visible rate.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
*/
*/
/**
+ * LoadFromRAM is a simple program that dynamically loads two loadable
+ * programs hardcoded in the byte arrays; One program is Blink, and the
+ * other one is Basestation.
+ *
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
*/
/**
+ * LoadFromRAM is a simple program that dynamically loads two loadable
+ * programs hardcoded in the byte arrays; One program is Blink, and the
+ * other one is Basestation.
+ *
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
programs hardcoded in the byte arrays; One program is Blink, and the
other one is Basestation.
-If you would like to generate your own loadable program:
- tosthreads-gen-dynamic-app ../../capps/Blink/Blink.c
+You can install LoadFromRAM on a mote via the following command:
+ make <platform> install
+
+If you would like to generate your own loadable program run, for example:
+ cd ../../capps/Blink
+ make telosb dynthreads
+ (the output file needed is ../../capps/Blink/build/telosb/dynthreads/main.tos)
+
+Tools:
+ None.
+
+Known bugs/limitations:
+ None.
--- /dev/null
+#-*-makefile-*-
+######################################################################
+#
+# Makes the entire suite of TinyOS applications for a given platform.
+#
+# Author: Martin Turon
+# Date: August 18, 2005
+#
+######################################################################
+# $Id$
+
+# MAKECMDGOALS is the way to get the arguments passed into a Makefile ...
+TARGET=$(MAKECMDGOALS)
+NESDOC_TARGET=$(filter-out nesdoc,$(TARGET))
+
+# Here is a way to get the list of subdirectories in a Makefile ...
+ROOT=.
+SUBDIRS := $(shell find * -type d)
+
+# Okay, match any target, and recurse the subdirectories
+%:
+ @for i in $(SUBDIRS); do \
+ HERE=$$PWD; \
+ if [ -f $$i/Makefile ]; then \
+ echo Building ... $(PWD)/$$i; \
+ echo make $(TARGET); \
+ cd $$i; \
+ $(MAKE) $(TARGET); \
+ cd $$HERE; \
+ fi; \
+ done
+
+threads:
+ @:
+cthreads:
+ @:
+dynthreads:
+ @:
+
+BASEDIR = $(shell pwd | sed 's@\(.*\)/apps.*$$@\1@' )
+# The output directory for generated documentation
+DOCDIR = $(BASEDIR)/doc/nesdoc
+
+nesdoc:
+ @echo This target rebuilds documentation for all known platforms.
+ @echo It DOES NOT overwrite any existing documentation, thus, it
+ @echo is best run after deleting all old documentation.
+ @echo
+ @echo To delete all old documentation, delete the contents of the
+ @echo $(DOCDIR) directory.
+ @echo
+ @echo Press Enter to continue, or ^C to abort.
+ @read
+ for platform in `ncc -print-platforms`; do \
+ $(MAKE) $$platform docs.nohtml.preserve; \
+ nesdoc -o $(DOCDIR) -html -target=$$platform; \
+ done
1.) Load SerialLoader:
make telosb install bsl,<device_port>
-2.) Create the loadable code, Blink.tos:
- tosthreads-gen-dynamic-app ../../capps/Blink/Blink.c
+2.) Create the loadable code, main.tos:
+ cd ../../capps/Blink
+ make telosb dynthreads
+ (the output file needed is ../../capps/Blink/build/telosb/dynthreads/main.tos)
3.) Clear the byte array in the mote RAM buffer:
./serialloader.py <device_port> 0
4.) Upload the binary:
- ./serialloader.py <device_port> 1 Blink.tos
+ ./serialloader.py <device_port> 1 main.tos
5.) Run the binary:
./serialloader.py <device_port> 7
+
+Tools:
+ None.
+
+Known bugs/limitations:
+ None.
+
*/
/**
+ * SerialLoader receives loadable programs from the serial port and stores
+ * it in a byte array. Then, when it receives the command to load the code,
+ * it makes the call to the dynamic loader.
+ *
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
* @author Jeongyeup Paek <jpaek@enl.usc.edu>
*/
*/
/**
+ * SerialLoader receives loadable programs from the serial port and stores
+ * it in a byte array. Then, when it receives the command to load the code,
+ * it makes the call to the dynamic loader.
+ *
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
* @author Jeongyeup Paek <jpaek@enl.usc.edu>
**/
*/
/**
+ * SerialLoaderFlash is similar to SerialLoader in that it receives
+ * loadable programs from the serial port. However, SerialLoaderFlash
+ * stores them on the external flash. Then, when it receives the command to
+ * load the code, it makes the call to the dynamic loader.
+ *
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
*/
/**
+ * SerialLoaderFlash is similar to SerialLoader in that it receives
+ * loadable programs from the serial port. However, SerialLoaderFlash
+ * stores them on the external flash. Then, when it receives the command to
+ * load the code, it makes the call to the dynamic loader.
+ *
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
1.) Load SerialLoader:
make telosb install bsl,<device_port>
-2.) Create the loadable code, Blink.tos:
- tosthreads-gen-dynamic-app ../../capps/Blink/Blink.c
+2.) Create the loadable code, main.tos:
+ cd ../../capps/Blink
+ make telosb dynthreads
+ (the output file needed is ../../capps/Blink/build/telosb/dynthreads/main.tos)
3.) Erase the external flash:
./serialloader.py <device_port> 0
4.) Upload the binary:
- ./serialloader.py <device_port> 1 Blink.tos
+ ./serialloader.py <device_port> 1 main.tos
5.) Run the binary:
./serialloader.py <device_port> 7
+
+Tools:
+ None.
+
+Known bugs/limitations:
+ None.
+
*/
/**
+ * SerialLoaderFlash is similar to SerialLoader in that it receives
+ * loadable programs from the serial port. However, SerialLoaderFlash
+ * stores them on the external flash. Then, when it receives the command to
+ * load the code, it makes the call to the dynamic loader.
+ *
* @author Kevin Klues (klueska@cs.stanford.edu)
* @author Chieh-Jan Mike Liang <cliang4@cs.jhu.edu>
*/
projects / tinyos-2.x.git / commitdiff