Update to markdown

- Spellchecking
- Update plain text to github markdown
This commit is contained in:
Rémy Léone 2013-03-26 13:09:49 +01:00
parent f8edbbb8d2
commit 7b40a568a6
73 changed files with 1826 additions and 1574 deletions

View File

@ -1,96 +0,0 @@
The Contiki build system
The Contiki build system is designed to make it easy to compile
Contiki applications for different hardware platforms or into a
simulation platform by simply supplying different parameters to the
make command, without having to edit makefiles or modify the
application code.
The file example project in examples/hello-world/ shows how the
Contiki build system works. The hello-world.c application can be built
into a complete Contiki system by running make in the
examples/hello-world/ directory. Running make without parameters will
build a Contiki system using the native target. The native target is a
special Contiki platform that builds an entire Contiki system as a
program that runs on the development system. After compiling the
application for the native target it is possible to run the Contiki
system with the application by running the file hello-world.native. To
compile the application and a Contiki system for the ESB platform the
command make TARGET=esb is used. This produces a hello-world.esb file
that can be loaded into an ESB board.
To compile the hello-world application into a stand-alone executable
that can be loaded into a running Contiki system, the command make
hello-world.ce is used. To build an executable file for the ESB
platform, make TARGET=esb hello-world.ce is run.
To avoid having to type TARGET= every time make is run, it is possible
to run make TARGET=esb savetarget to save the selected target as the
default target platform for subsequent invocations of make. A file
called Makefile.target containing the currently saved target is saved
in the project's directory.
Beside TARGET= there's DEFINES= which allows to set arbitrary variables
for the C preprocessor in form of a comma-separated list. Again it is
possible to avoid having to re-type i.e. DEFINES=MYTRACE,MYVALUE=4711
by running make TARGET=esb DEFINES=MYTRACE,MYVALUE=4711 savedefines. A
file called Makefile.esb.defines is saved in the project's directory
containing the currently saved defines for the ESB platform.
Makefiles used in the Contiki build system The Contiki build system is
composed of a number of Makefiles. These are:
* Makefile: the project's makefile, located in the project directory.
* Makefile.include: the system-wide Contiki makefile, located in
the root of the Contiki source tree.
* Makefile.$(TARGET) (where $(TARGET) is the name of the platform
that is currently being built): rules for the specific platform,
located in the platform's subdirectory in the platform/
directory.
* Makefile.$(CPU) (where $(CPU) is the name of the CPU or
microcontroller architecture used on the platform for which
Contiki is built): rules for the CPU architecture, located in
the CPU architecture's subdirectory in the cpu/ directory.
* Makefile.$(APP) (where $(APP) is the name of an application in
the apps/ directory): rules for applications in the apps/
directories. Each application has its own makefile.
The Makefile in the project's directory is intentionally simple. It
specifies where the Contiki source code resides in the system and
includes the system-wide Makefile, Makefile.include. The project's
makefile can also define in the APPS variable a list of applications
from the apps/ directory that should be included in the Contiki
system. The Makefile used in the hello-world example project looks
like this:
CONTIKI_PROJECT = hello-world
all: $(CONTIKI_PROJECT)
CONTIKI = ../..
include $(CONTIKI)/Makefile.include
First, the location of the Contiki source code tree is given by
defining the CONTIKI variable. Next, the name of the application is
defined. Finally, the system-wide Makefile.include is included.
The Makefile.include contains definitions of the C files of the core
Contiki system. Makefile.include always reside in the root of the
Contiki source tree. When make is run, Makefile.include includes the
Makefile.$(TARGET) as well as all makefiles for the applications in
the APPS list (which is specified by the project's Makefile).
Makefile.$(TARGET), which is located in the platform/$(TARGET)/
directory, contains the list of C files that the platform adds to the
Contiki system. This list is defined by the CONTIKI_TARGET_SOURCEFILES
variable. The Makefile.$(TARGET) also includes the Makefile.$(CPU)
from the cpu/$(CPU)/ directory.
The Makefile.$(CPU) typically contains definitions for the C compiler
used for the particular CPU. If multiple C compilers are used, the
Makefile.$(CPU) can either contain a conditional expression that
allows different C compilers to be defined, or it can be completely
overridden by the platform specific makefile Makefile.$(TARGET).

92
README-BUILDING.markdown Normal file
View File

@ -0,0 +1,92 @@
The Contiki build system
========================
The Contiki build system is designed to make it easy to compile Contiki
applications for different hardware platforms or into a simulation platform by
simply supplying different parameters to the make command, without having to
edit makefiles or modify the application code.
The file example project in examples/hello-world/ shows how the Contiki build
system works. The hello-world.c application can be built into a complete
Contiki system by running make in the examples/hello-world/ directory. Running
make without parameters will build a Contiki system using the native target.
The native target is a special Contiki platform that builds an entire Contiki
system as a program that runs on the development system. After compiling the
application for the native target it is possible to run the Contiki system with
the application by running the file hello-world.native. To compile the
application and a Contiki system for the ESB platform the command make
TARGET=esb is used. This produces a hello-world.esb file that can be loaded
into an ESB board.
To compile the hello-world application into a stand-alone executable that can
be loaded into a running Contiki system, the command make hello-world.ce is
used. To build an executable file for the ESB platform, make TARGET=esb
hello-world.ce is run.
To avoid having to type TARGET= every time make is run, it is possible to run
make TARGET=esb savetarget to save the selected target as the default target
platform for subsequent invocations of make. A file called Makefile.target
containing the currently saved target is saved in the project's directory.
Beside TARGET= there's DEFINES= which allows to set arbitrary variables for the
C preprocessor in form of a comma-separated list. Again it is possible to avoid
having to re-type i.e. DEFINES=MYTRACE,MYVALUE=4711 by running make TARGET=esb
DEFINES=MYTRACE,MYVALUE=4711 savedefines. A file called Makefile.esb.defines is
saved in the project's directory containing the currently saved defines for the
ESB platform.
Makefiles used in the Contiki build system The Contiki build system is composed
of a number of Makefiles. These are:
* Makefile: the project's makefile, located in the project directory.
* Makefile.include: the system-wide Contiki makefile, located in the root of
the Contiki source tree.
* Makefile.$(TARGET) (where $(TARGET) is the name of the platform that is
currently being built): rules for the specific platform, located in the
platform's subdirectory in the platform/ directory.
* Makefile.$(CPU) (where $(CPU) is the name of the CPU or microcontroller
architecture used on the platform for which Contiki is built): rules for the
CPU architecture, located in the CPU architecture's subdirectory in the cpu/
directory.
* Makefile.$(APP) (where $(APP) is the name of an application in the apps/
directory): rules for applications in the apps/ directories. Each application
has its own makefile.
The Makefile in the project's directory is intentionally simple. It specifies
where the Contiki source code resides in the system and includes the
system-wide Makefile, Makefile.include. The project's makefile can also define
in the APPS variable a list of applications from the apps/ directory that
should be included in the Contiki system. The Makefile used in the hello-world
example project looks like this:
CONTIKI_PROJECT = hello-world
all: $(CONTIKI_PROJECT)
CONTIKI = ../..
include $(CONTIKI)/Makefile.include
First, the location of the Contiki source code tree is given by defining the
CONTIKI variable. Next, the name of the application is defined. Finally, the
system-wide Makefile.include is included.
The Makefile.include contains definitions of the C files of the core Contiki
system. Makefile.include always reside in the root of the Contiki source tree.
When make is run, Makefile.include includes the Makefile.$(TARGET) as well as
all makefiles for the applications in the APPS list (which is specified by the
project's Makefile).
Makefile.$(TARGET), which is located in the platform/$(TARGET)/ directory,
contains the list of C files that the platform adds to the Contiki system. This
list is defined by the CONTIKI_TARGET_SOURCEFILES variable. The
Makefile.$(TARGET) also includes the Makefile.$(CPU) from the cpu/$(CPU)/
directory.
The Makefile.$(CPU) typically contains definitions for the C compiler used for
the particular CPU. If multiple C compilers are used, the Makefile.$(CPU) can
either contain a conditional expression that allows different C compilers to be
defined, or it can be completely overridden by the platform specific makefile
Makefile.$(TARGET).

View File

@ -1,207 +0,0 @@
The examples/ directory contains a few examples that will help you get
started with Contiki.
To run the example programs, you need either to be running Linux or
FreeBSD (or any other *nix-type system), or install Cygwin if you are
running Microsoft Windows (http://www.cygwin.com/). As a minimum you
will need to have the gcc C compiler installed. To run the examples in
the 'netsim' target, you need to have GTK 1.x development libraries
installed. These are usually called 'gtk-devel', 'libgtk1-devel' or
similar in your Linux software installation programs.
compile-platforms/
A test script that compiles Contiki for a number of platforms and
reports any errors found during the build.
email/
An email program supporting SMTP. It can be compiled and run in the
'win32' target by typing the following commands:
cd examples/email
make
./email-client.win32
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/win32/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP as well.
esb/
A set of demo applications for the ESB board.
ftp/
An FTP client supporting download. It can be compiled and run in the
'win32' target by typing the following commands:
cd examples/ftp
make
./ftp-client.win32
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/win32/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP as well.
hello-world/
A really simple Contiki program that shows how to write Contiki
programs. To compile and test the program, go into the hello-world
directory:
cd examples/hello-world
Run the 'make' command.
make
This will compile the hello-world program in the 'native' target.
This causes the entire Contiki operating system and the hello-world
application to be compiled into a single program that can be run by
typing the following command:
./hello-world.native
This will print out the following text:
Contiki initiated, now starting process scheduling
Hello, world
The program will then appear to hang, and must be stopped by
pressing the C key while holding down the Control key.
irc/
An IRC client. It can be compiled and run in the 'win32' target by
typing the following commands:
cd examples/irc
make
./irc-client.win32
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/win32/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP as well.
multi-threading/
A quite simple demonstration of the Contiki multi-threading library
employing two worker threads each running a recursive function. It
can be compiled and run in the 'native' target by typing the
following commands:
cd examples/multi-threading
make
./multi-threading.native
rime/
Contains a set of examples on how to use the Rime communications
stack. To run those examples in the 'netsim' target (a very simple
Contiki network simulator), compile the programs with:
make TARGET=netsim
You will need to have GTK 1.x development libraries installed.
Run the different programs:
./test-abc.netsim
./test-meshroute.netsim
./test-rudolph0.netsim
./test-rudolph1.netsim
./test-treeroute.netsim
./test-trickle.netsim
Most of the examples requires you to click with the middle mouse
button on one of the simulated nodes for something to happen.
sky/
Examples inteded for running on the Tmote Sky board. To compile
those, you need to have msp430-gcc (the gcc C compiler for the
MSP430 microcontroller) installed.
The follwing programs are included:
blink.c A simple program that blinks the on-board LEDs
sky-collect.c Collects sensor data and energy profile values
to a sink. Press the "user" button on the Tmote
Sky that is connected to the PC to make the node a
sink.
test-button.c Toggles the LEDs when the button is pressed.
test-cfs.c Tests the 1 mb flash memory of the Tmote Sky
telnet-server/
A simple TCP telnet server with a simple command shell. It can be
compiled and run in the 'minimal-net' target by typing the following
commands:
cd examples/telnet-server
make
./telnet-server.minimal-net
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/minimal-net/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP as well if you are running
Microsoft Windows.
webbrowser/
A text mode web browser supporting links and forms. It can be compiled
and run in the 'win32' target by typing the following commands:
cd examples/webbrowser
make
./webbrowser.win32
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/win32/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP as well.
webserver/
A web server supporting dynamic content creation using "scripts" which
are actually compiled-in C-functions. It can be compiled and run in the
'minimal-net' target by typing the following commands:
cd examples/webserver
make
./webserver-example.minimal-net
As an alternative to the static and dynamic compiled-in content the web
server can instead support "external" static-only content loaded from
any storage supported by the 'Contiki File System' (CFS) interface. To
compile it in the 'minimal-net' target and have it load files from disk
use the following command:
make HTTPD-CFS=1
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/minimal-net/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP as well if you are running
Microsoft Windows.
wget/
A command line program that retrieves files from web servers and saves
them using the 'Contiki File System' (CFS). It can be compiled and run
in the 'minimal-net' target by typing the following commands:
cd examples/wget
make
./wget.minimal-net
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/minimal-net/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP as well if you are running
Microsoft Windows.

220
README-EXAMPLES.markdown Normal file
View File

@ -0,0 +1,220 @@
Contiki Examples
================
The examples/ directory contains a few examples that will help you get
started with Contiki.
To run the example programs, you need either to be running Linux or FreeBSD (or
any other UNIX-type system), or install Cygwin if you are running Microsoft
Windows [http://cygwin.com](http://cygwin.com). As a minimum you will need to
have the gcc C compiler installed. To run the examples in the 'netsim' target,
you need to have GTK 1.x development libraries installed. These are usually
called 'gtk-devel', 'libgtk1-devel' or similar in your Linux software
installation programs.
compile-platforms/
------------------
A test script that compiles Contiki for a number of platforms and reports any
errors found during the build.
email/
------
An email program supporting SMTP. It can be compiled and run in the 'win32'
target by typing the following commands:
cd examples/email
make
./email-client.win32
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/win32/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP as well.
esb/
----
A set of demo applications for the ESB board.
ftp/
----
An FTP client supporting download. It can be compiled and run in the 'win32'
target by typing the following commands:
cd examples/ftp
make
./ftp-client.win32
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/win32/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP as well.
hello-world/
------------
A really simple Contiki program that shows how to write Contiki programs. To
compile and test the program, go into the hello-world directory:
cd examples/hello-world
Run the 'make' command.
make
This will compile the hello-world program in the 'native' target. This causes
the entire Contiki operating system and the hello-world application to be
compiled into a single program that can be run by typing the following command:
./hello-world.native
This will print out the following text:
Contiki initiated, now starting process scheduling
Hello, world
The program will then appear to hang, and must be stopped by pressing the C key
while holding down the Control key.
irc/
----
An IRC client. It can be compiled and run in the 'win32' target by
typing the following commands:
cd examples/irc
make
./irc-client.win32
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/win32/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP as well.
multi-threading/
----------------
A quite simple demonstration of the Contiki multi-threading library
employing two worker threads each running a recursive function. It
can be compiled and run in the 'native' target by typing the
following commands:
cd examples/multi-threading
make
./multi-threading.native
rime/
-----
Contains a set of examples on how to use the Rime communications
stack. To run those examples in the 'netsim' target (a very simple
Contiki network simulator), compile the programs with:
make TARGET=netsim
You will need to have GTK 1.x development libraries installed.
Run the different programs:
./test-abc.netsim
./test-meshroute.netsim
./test-rudolph0.netsim
./test-rudolph1.netsim
./test-treeroute.netsim
./test-trickle.netsim
Most of the examples requires you to click with the middle mouse
button on one of the simulated nodes for something to happen.
sky/
----
Examples inteded for running on the Tmote Sky board. To compile those, you need
to have msp430-gcc (the gcc C compiler for the MSP430 microcontroller)
installed.
The follwing programs are included:
- blink.c A simple program that blinks the on-board LEDs
- sky-collect.c Collects sensor data and energy profile values to a sink.
Press the "user" button on the Tmote Sky that is connected to the PC to make
the node a sink.
- test-button.c Toggles the LEDs when the button is pressed.
- test-cfs.c Tests the 1 mb flash memory of the Tmote Sky
telnet-server/
--------------
A simple TCP telnet server with a simple command shell. It can be
compiled and run in the 'minimal-net' target by typing the following
commands:
cd examples/telnet-server
make
./telnet-server.minimal-net
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/minimal-net/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP as well if you are running
Microsoft Windows.
webbrowser/
-----------
A text mode web browser supporting links and forms. It can be compiled
and run in the 'win32' target by typing the following commands:
cd examples/webbrowser
make
./webbrowser.win32
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/win32/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP as well.
webserver/
----------
A web server supporting dynamic content creation using "scripts" which
are actually compiled-in C-functions. It can be compiled and run in the
'minimal-net' target by typing the following commands:
cd examples/webserver
make
./webserver-example.minimal-net
As an alternative to the static and dynamic compiled-in content the web
server can instead support "external" static-only content loaded from
any storage supported by the 'Contiki File System' (CFS) interface. To
compile it in the 'minimal-net' target and have it load files from disk
use the following command:
make HTTPD-CFS=1
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/minimal-net/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP.markdown as well if you are running
Microsoft Windows.
wget/
-----
A command line program that retrieves files from web servers and saves them
using the 'Contiki File System' (CFS). It can be compiled and run in the
'minimal-net' target by typing the following commands:
cd examples/wget
make
./wget.minimal-net
Most likely you'll have to adjust the TCP/IP values set in main() in
platform/minimal-net/contiki-main.c to match your needs.
Please consult cpu/native/net/README-WPCAP as well if you are running
Microsoft Windows.

View File

@ -1,4 +1,7 @@
The Contiki Operating System
============================
[![Build Status](https://secure.travis-ci.org/contiki-os/contiki.png)](http://travis-ci.org/contiki-os/contiki)
Contiki is an open source operating system that runs on tiny low-power
microcontrollers and makes it possible to develop applications that
@ -13,4 +16,4 @@ and so on.
For more information, see the Contiki website:
http://www.contiki-os.org/
[http://contiki-os.org](http://contiki-os.org)

View File

@ -1,5 +0,0 @@
Move the desired pages into httpd-fs and regenerate httpd-fsdata.c using the PERL script makefsdata.
Stage unused pages in this directory; anything here will be ignored by makefsdata.
When using non-ram storage it must be invoked with the HTTPD_STRING_ATTR!
E.g. cd ~/contiki/apps/webserver (or webserver-nano, -micro, -mini, ...)
../../tools/makefsdata -A HTTPD_STRING_ATTR

View File

@ -0,0 +1,7 @@
Move the desired pages into httpd-fs and regenerate httpd-fsdata.c using the
PERL script makefsdata. Stage unused pages in this directory; anything here
will be ignored by makefsdata. When using non-ram storage it must be invoked
with the HTTPD_STRING_ATTR!
cd ~/contiki/apps/webserver (or webserver-nano, -micro, -mini, ...)
../../tools/makefsdata -A HTTPD_STRING_ATTR

View File

@ -1,74 +0,0 @@
The cpu/6502/ directory is used for targeting 6502-based machines using the cc65
compiler (http://www.cc65.org/).
The Contiki network configuration for 6502-based targets is loaded from a binary
configuration file (by default named contiki.cfg). It has the following format:
- Bytes 1 - 4: IP Address (HiByte first)
- Bytes 5 - 8: Subnet Mask (HiByte first)
- Bytes 9 - 12: Default Router (HiByte first)
- Bytes 13 - 16: DNS Server (HiByte first)
- Bytes 17 - 18: Ethernet card I/O address (LoByte first !)
- Bytes 19 - xx: Ethernet card driver name (ASCII / PETSCII)
An online Contiki configuration file generator is available at two sites:
- http://www.a2retrosystems.com/contiki.html
- http://contiki.cbm8bit.com/
The build for 6502-based machines includes the 'disk' make goal which creates a
bootable floppy disk image containing the project binary, a sample configuration
file and the Ethernet card drivers.
The build for 6502-based machines supports so-called high-level configuration
macros which allow to customize Contiki on a per-project basis. They are set
in form of a comma-separated list as value of the make variable DEFINES on the
make command line. The value of DEFINES can be saved with the 'savedefines' make
goal. The values of the high-level configuration macros are not tracked by the
build so a manual rebuild is necessary on any change. The following high-level
configuration macros may be set:
MTU_SIZE
- Default: 1500
- Purpose: Set the Maximum Transfer Unit size.
CONNECTIONS
- Default: 10
- Purpose: Set the maximum number of concurrent TCP connections.
WITH_LOGGING
- Default: 0
- Purpose: Have log_message() and UIP_LOG() write messages to the screen.
WITH_BOOST
- Default: 0
- Purpose: Significantly improve troughput on sending full sized packets by
splitting them thus workarounding the "delayed acknowledge".
WITH_FORWARDING
- Default: 0
- Purpose: Enable support for the 'IP forwarding' packet driver.
WITH_CLIENT
- Default: 0
- Purpose: Enable support for outgoing TCP connections.
WITH_DNS
- Default: 0
- Purpose: Enable UDP support and initialize resolver process on startup.
WITH_GUI
- Default: 0
- Purpose: Initialize the the CTK process on startup.
WITH_MOUSE
- Default: 0
- Purpose: Enable CTK mouse support and load a mouse driver.
WITH_PFS
- Default: 0
- Purpose: Implement the CFS interface with a Platform-specific File System
instead of the POSIX file system.

75
cpu/6502/README.markdown Normal file
View File

@ -0,0 +1,75 @@
6502
====
The cpu/6502/ directory is used for targeting 6502-based machines using the
cc65 compiler [http://www.cc65.org](http://www.cc65.org).
The Contiki network configuration for 6502-based targets is loaded from a
binary configuration file (by default named contiki.cfg). It has the following
format:
- Bytes 1 - 4: IP Address (HiByte first)
- Bytes 5 - 8: Subnet Mask (HiByte first)
- Bytes 9 - 12: Default Router (HiByte first)
- Bytes 13 - 16: DNS Server (HiByte first)
- Bytes 17 - 18: Ethernet card I/O address (LoByte first !)
- Bytes 19 - xx: Ethernet card driver name (ASCII / PETSCII)
An online Contiki configuration file generator is available at two sites:
- [http://www.a2retrosystems.com/contiki.html](http://www.a2retrosystems.com/contiki.html)
- [http://contiki.cbm8bit.com](http://contiki.cbm8bit.com)
The build for 6502-based machines includes the 'disk' make goal which creates a
bootable floppy disk image containing the project binary, a sample
configuration file and the Ethernet card drivers.
The build for 6502-based machines supports so-called high-level configuration
macros which allow to customize Contiki on a per-project basis. They are set in
form of a comma-separated list as value of the make variable DEFINES on the
make command line. The value of DEFINES can be saved with the 'savedefines'
make goal. The values of the high-level configuration macros are not tracked by
the build so a manual rebuild is necessary on any change. The following
high-level configuration macros may be set:
- MTU_SIZE
- Default: 1500
- Purpose: Set the Maximum Transfer Unit size.
- CONNECTIONS
- Default: 10
- Purpose: Set the maximum number of concurrent TCP connections.
- WITH_LOGGING
- Default: 0
- Purpose: Have log_message() and UIP_LOG() write messages to the screen.
- WITH_BOOST
- Default: 0
- Purpose: Significantly improve troughput on sending full sized packets by
splitting them thus workarounding the "delayed acknowledge".
- WITH_FORWARDING
- Default: 0
- Purpose: Enable support for the 'IP forwarding' packet driver.
- WITH_CLIENT
- Default: 0
- Purpose: Enable support for outgoing TCP connections.
- WITH_DNS
- Default: 0
- Purpose: Enable UDP support and initialize resolver process on startup.
- WITH_GUI
- Default: 0
- Purpose: Initialize the the CTK process on startup.
- WITH_MOUSE
- Default: 0
- Purpose: Enable CTK mouse support and load a mouse driver.
- WITH_PFS
- Default: 0
- Purpose: Implement the CFS interface with a Platform-specific File System
instead of the POSIX file system.

View File

@ -1,74 +0,0 @@
libmc1322x is a library, build system, test code, and utilities for
using the mc13224v from Freescale.
Getting Started
---------------
$ cd tests
$ make
this will build all the test files in libmc1322x/tests for each board
defined in libmc1322x/board. You will have programs like:
rftest-tx_redbee-dev.bin
rftest-tx_redbee-r1.bin
rftest-rx_redbee-dev.bin
rftest-rx_redbee-r1.bin
if you only wanted to build binaries for one board you can do:
$ make BOARD=redbee-dev
You can use mc1322x-load.pl in libmc1322x/tools to run your code:
$ ../tools/mc1322x-load.pl -f rftest-tx_redbee-dev.bin
Incorporating libmc1322x into your own code
-------------------------------------------
The best way to incorporate libmc1322x into your code is as a git
submodule:
$ mkdir newproject
$ cd newproject
$ git init
Initialized empty Git repository in /home/malvira/newproject/.git/
$ git submodule add git://git.devl.org/git/malvira/libmc1322x.git
This will add libmc1322x to your repository. Now to setup the
Makefile:
$ cp libmc1322x/tests/Makefile .
You need to edit the Makefile to point MC1322X to your libmc1322x
submodule:
Change line 1
MC1322X := ..
to
MC1322X := libmc1322x
and edit COBJS and TARGETS accordings. COBJS are all of your common
code for any of your programs. TARGETS are the names of your programs.
For instance, you can have a common routine that prints a welcome
message that is used by two programs a and b. You would add common.o
to COBJS:
COBJS:= common.o
and your target line would read:
TARGETS := a b
COBJS are made for each board --- so it is ok to have board specific
code in there. As an example, tests uses this in tests.c to print the
name of the board in the welcome message. You could also use this to
change your GPIO mappings between boards.

View File

@ -0,0 +1,72 @@
MC1322x
=======
libmc1322x is a library, build system, test code, and utilities for using the
mc13224v from Freescale.
Getting Started
---------------
cd tests
make
this will build all the test files in libmc1322x/tests for each board
defined in libmc1322x/board. You will have programs like:
rftest-tx_redbee-dev.bin
rftest-tx_redbee-r1.bin
rftest-rx_redbee-dev.bin
rftest-rx_redbee-r1.bin
if you only wanted to build binaries for one board you can do:
make BOARD=redbee-dev
You can use mc1322x-load.pl in libmc1322x/tools to run your code:
../tools/mc1322x-load.pl -f rftest-tx_redbee-dev.bin
Incorporating libmc1322x into your own code
-------------------------------------------
The best way to incorporate libmc1322x into your code is as a git submodule:
mkdir newproject
cd newproject
git init
Initialized empty Git repository in /home/malvira/newproject/.git/
git submodule add git://git.devl.org/git/malvira/libmc1322x.git
This will add libmc1322x to your repository. Now to setup the Makefile:
cp libmc1322x/tests/Makefile .
You need to edit the Makefile to point MC1322X to your libmc1322x submodule:
Change line 1
MC1322X := ..
to
MC1322X := libmc1322x
and edit COBJS and TARGETS accordings. COBJS are all of your common code for
any of your programs. TARGETS are the names of your programs.
For instance, you can have a common routine that prints a welcome message that
is used by two programs a and b. You would add common.o to COBJS:
COBJS:= common.o
and your target line would read:
TARGETS := a b
COBJS are made for each board so it is ok to have board specific code in there.
As an example, tests uses this in tests.c to print the name of the board in the
welcome message. You could also use this to change your GPIO mappings between
boards.

View File

@ -1,39 +0,0 @@
The Contiki MC1322x port includes libmc1322x as a subtree. This makes
pulling updates to libmc1322x easy, but pushing changes from contiki
to libmc1322x is not so easy. However, this should not stop you from
implementing core features in contiki first, (especially if you are in
a bind). The way to do this is to make files prefixed with contiki-*
in cpu/mc1322x and add them to Makefile.mc1322x.
For instance, if you need a routine called sleep, but libmc1322x
doesn't have that yet, you could implement sleep in
contiki-crm.c. Feel free to use as many contiki specific things in
here as you want. We can pull these changes directly into the contiki
tree. There is nothing stopping you from making changes to the lib
files --- in fact you should if that is the right thing to do (and
then push your changes upstream). The subtree merge should make it
easy to still pull updates.
You'll also notice that the libmc1322x build system is still
present. This allows you to cd ./tests and make all of the libmc1322x
unit tests as normal. This is a handy way to perform a sainity check
on all of the mc1322x specific code.
The subtree was set up as follows:
From:
http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
Moved mc1322x.lds to mc1322x.lds.contiki
Setup with:
git remote add -f libmc1322x git://git.devl.org/git/malvira/libmc1322x.git
git read-tree --prefix=cpu/mc1322x -u libmc1322x/master
git commit -m "Merge libmc1322x as a subdirectory"
And to do subsequent merges from libmc1322x do:
git pull -s subtree libmc1322x master

View File

@ -0,0 +1,39 @@
MC1322x subtree
===============
The Contiki MC1322x port includes libmc1322x as a subtree. This makes pulling
updates to libmc1322x easy, but pushing changes from contiki to libmc1322x is
not so easy. However, this should not stop you from implementing core features
in contiki first, (especially if you are in a bind). The way to do this is to
make files prefixed with contiki- in cpu/mc1322x and add them to
Makefile.mc1322x.
For instance, if you need a routine called sleep, but libmc1322x doesn't have
that yet, you could implement sleep in contiki-crm.c. Feel free to use as many
contiki specific things in here as you want. We can pull these changes directly
into the contiki tree. There is nothing stopping you from making changes to the
lib files --- in fact you should if that is the right thing to do (and then
push your changes upstream). The subtree merge should make it easy to still
pull updates.
You'll also notice that the libmc1322x build system is still present. This
allows you to cd ./tests and make all of the libmc1322x unit tests as normal.
This is a handy way to perform a sainity check on all of the mc1322x specific
code.
The subtree was set up as follows:
From:
[http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html](http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html)
Moved mc1322x.lds to mc1322x.lds.contiki
Setup with:
git remote add -f libmc1322x git://git.devl.org/git/malvira/libmc1322x.git
git read-tree --prefix=cpu/mc1322x -u libmc1322x/master
git commit -m "Merge libmc1322x as a subdirectory"
And to do subsequent merges from libmc1322x do:
git pull -s subtree libmc1322x master

View File

@ -1,7 +0,0 @@
grep count 1000pkt-64len.txt | cut -d ' ' -f 2,5 | sed 's/ /,/g' |
sort -n > 1000pkt-64len.csv
then:
asy plot.asy
gv plot.eps

View File

@ -0,0 +1,6 @@
lqi-pdr
=======
grep count 1000pkt-64len.txt | cut -d ' ' -f 2,5 | sed 's/ /,/g' | sort -n > 1000pkt-64len.csv
asy plot.asy
gv plot.eps

View File

@ -1,11 +1,11 @@
Contiki network I/O on Microsoft Windows (including the Cygwin environment) is
implemented based on the quite popular WinPcap library that is available at
http://www.winpcap.org/.
[http://winpcap.org](http://winpcap.org).
Developing Contiki network applications most likely involves working with a
network protocol analyzer. Wireshark (formerly known as Ethereal) is a very
popular one that on Windows uses - and actually comes with - the WinPcap
libary. Wireshark is available at http://www.wireshark.org/.
libary. Wireshark is available at [http://wireshark.org](http://wireshark.org).
So with Wireshark installed Contiki network I/O doesn't need any additional
components.
@ -13,14 +13,17 @@ components.
On Windows every Contiki application has one obligatory comand line argument
that identifies the Windows network interface to be used by Contiki. While on
Unix those network interfaces are called i.e. '/dev/tap0' they have on Windows
names like '\Device\NPF_{F76B480A-1D31-4B3D-8002-C0EF49185737}'. In order to
avoid the necessity to enter such names on the command line instead the IPv4
address used by Windows is entered to identify the network interface to be
used by Contiki. Please note that this IPv4 address is _NOT_ the IPv4 address
to be used by Contiki !
names like
\Device\NPF_{F76B480A-1D31-4B3D-8002-C0EF49185737}
In order to avoid the necessity to enter such names on the command line instead
the IPv4 address used by Windows is entered to identify the network interface
to be used by Contiki. Please note that this IPv4 address is _NOT_ the IPv4
address to be used by Contiki !
Contiki network I/O on Windows uses the same MAC address used by Windows. This
approach often described as IP-Aliasing was primarily choosen because it avoids
approach often described as IP-Aliasing was primarily chosen because it avoids
putting the network interface into promiscuous mode. The major benefit of this
is the compatibility with WLAN interfaces - which mostly come with Windows
device drivers incapable of promiscuous mode.
@ -43,5 +46,5 @@ loopback interface as not a true network interface that connects to a network.
This results in generally deactivating both the network identification process
and the firewall for the loopback interface. The details are available in the
Microsoft TechNet Forums thread 'Vista Network Identification for Loopback
Adpater' that is currently available at http://social.technet.microsoft.com/
forums/en-US/itprovistanetworking/thread/66b42761-1b8e-4302-9134-0bb685139f4e/
Adpater' that is currently available at
[link](http://social.technet.microsoft.com/forums/en-US/itprovistanetworking/thread/66b42761-1b8e-4302-9134-0bb685139f4e)

View File

@ -1,16 +0,0 @@
border-router example for the TI SmartRF05EB with a cc2530EM.
This example is meant to be used with tunslip6 in tools/
- Build the code and load it onto your node
- Connect your node to your PC
- run:
sudo ./tunslip6 -s /dev/ttyUSBx <address v6>/<prefix>
This will setup tun0 on your PC over device /dev/ttyUSBx. The address
argument should contain the v6 address that you want to assign to tun0
The node will use this address to obtain the network prefix
for example:
sudo ./tunslip6 aaaa::1/64
This will use aaaa:: / 64 as the prefix for the 15.4 network.

View File

@ -0,0 +1,20 @@
border-router example for the TI SmartRF05EB with a cc2530EM
============================================================
This example is meant to be used with tunslip6 in tools/
- Build the code and load it onto your node
- Connect your node to your PC
- run:
sudo ./tunslip6 -s /dev/ttyUSBx <address v6>/<prefix>
This will setup tun0 on your PC over device /dev/ttyUSBx. The address
argument should contain the v6 address that you want to assign to tun0
The node will use this address to obtain the network prefix
For example:
sudo ./tunslip6 aaaa::1/64
This will use aaaa:: / 64 as the prefix for the 15.4 network.

View File

@ -1,116 +0,0 @@
A Quick Introduction to the Erbium (Er) REST Engine
===================================================
EXAMPLE FILES
-------------
er-example-server.c: A RESTful server example showing how to use the REST layer to develop server-side applications (at the moment only CoAP is implemented for the REST Engine).
er-example-client.c: A CoAP client that polls the /actuators/toggle resource every 10 seconds and cycles through 4 resources on button press (target address is hard-coded).
er-plugtest-server.c: The server used for draft compliance testing at ETSI IoT CoAP Plugtest in Paris, France, March 2012 (configured for minimal-net).
PRELIMINARIES
-------------
- Make sure rpl-border-router has the same stack and fits into mote memory:
You can disable RDC in border-router project-conf.h (not really required as BR keeps radio turned on).
#undef NETSTACK_CONF_RDC
#define NETSTACK_CONF_RDC nullrdc_driver
- For convenience, define the Cooja addresses in /etc/hosts
aaaa::0212:7401:0001:0101 cooja1
aaaa::0212:7402:0002:0202 cooja2
...
- Get the Copper (Cu) CoAP user-agent from https://addons.mozilla.org/en-US/firefox/addon/copper-270430/
- Optional: Save your target as default target
$ make TARGET=sky savetarget
COOJA HOWTO
-----------
Server only:
1) $ make TARGET=cooja server-only.csc
2) Open new terminal
3) $ make connect-router-cooja
4) Start Copper and discover resources at coap://cooja2:5683/
- Choose "Click button on Sky 2" from the context menu of mote 2 (server) after requesting /test/separate
- Do the same when observing /test/event
With client:
1) $ make TARGET=cooja server-client.csc
2) Open new terminal
3) $ make connect-router-cooja
4) Wait until red LED toggles on mote 2 (server)
5) Choose "Click button on Sky 3" from the context menu of mote 3 (client) and watch serial output
TMOTES HOWTO
------------
Server:
1) Connect two Tmote Skys (check with $ make TARGET=sky sky-motelist)
2) $ make TARGET=sky er-example-server.upload MOTE=2
3) $ make TARGET=sky login MOTE=2
4) Press reset button, get address, abort with Ctrl+C:
Line: "Tentative link-local IPv6 address fe80:0000:0000:0000:____:____:____:____"
5) $ cd ../ipv6/rpl-border-router/
6) $ make TARGET=sky border-router.upload MOTE=1
7) $ make connect-router
For a BR tty other than USB0: $ make connect-router-port PORT=X
8) Start Copper and discover resources at coap://[aaaa::____:____:____:____]:5683/
Add a client:
1) Change the hard-coded server address in er-example-client.c to aaaa::____:____:____:____
2) Connect a third Tmote Sky
3) $ make TARGET=sky er-example-client.upload MOTE=3
MINIMAL-NET HOWTO
-----------------
With the target minimal-net you can test your CoAP applications without constraints, i.e., with large buffers, debug output, memory protection, etc.
The er-plugtest-server is thought for the minimal-net platform, as it requires an 1280-byte IP buffer and 1024-byte blocks.
1) $ make TARGET=minimal-net er-plugtest-server
2) $ sudo ./er-plugtest-server.minimal-net
3) Open new terminal
4) $ make connect-minimal
5) Start Copper and discover resources at coap://[fdfd::ff:fe00:10]:5683/
- You can enable the ETSI Plugtest menu in Copper's preferences
Under Windows/Cygwin, WPCAP might need a patch in <cygwin>\usr\include\w32api\in6addr.h:
21,23c21
< #ifdef __INSIDE_CYGWIN__
< uint32_t __s6_addr32[4];
< #endif
---
> u_int __s6_addr32[4];
36d33
< #ifdef __INSIDE_CYGWIN__
39d35
< #endif
DETAILS
-------
Erbium currently implements draft 13.
Central features are commented in er-example-server.c.
In general, apps/er-coap-13 supports:
* All draft 13 header options
* CON Retransmissions (note COAP_MAX_OPEN_TRANSACTIONS)
* Blockwise Transfers (note REST_MAX_CHUNK_SIZE, see er-plugtest-server.c for Block1 uploads)
* Separate Responses (no rest_set_pre_handler() required anymore, note coap_separate_accept(), _reject(), and _resume())
* Resource Discovery
* Observing Resources (see EVENT_ and PRERIODIC_RESOURCE, note COAP_MAX_OBSERVERS)
REST IMPLEMENTATIONS
--------------------
The Makefile uses WITH_COAP to configure different implementations for the Erbium (Er) REST Engine.
* WITH_COAP=13 uses Erbium CoAP 13 apps/er-coap-13/.
The default port for coap-13 is 5683.
* WITH_COAP=12 uses Erbium CoAP 12 apps/er-coap-12/.
The default port for coap-12 is 5683.
* WITH_COAP=7 uses Erbium CoAP 08 apps/er-coap-07/.
The default port for coap-07/-08 is 5683.
* WITH_COAP=3 uses Erbium CoAP 03 apps/er-coap-03/.
The default port for coap-03 is 61616.
er-coap-03 produces some warnings, as it not fully maintained anymore.
* WITH_COAP=0 is a stub to link an Erbium HTTP engine that uses the same resource abstraction (REST.x() functions and RESOURCE macros.
TODOs
-----
* Dedicated Observe buffers
* Optimize message struct variable access (directly access struct without copying)
* Observe client
* Multiple If-Match ETags
* (Message deduplication)

View File

@ -0,0 +1,165 @@
A Quick Introduction to the Erbium (Er) REST Engine
===================================================
EXAMPLE FILES
-------------
- er-example-server.c: A RESTful server example showing how to use the REST
layer to develop server-side applications (at the moment only CoAP is
implemented for the REST Engine).
- er-example-client.c: A CoAP client that polls the /actuators/toggle resource
every 10 seconds and cycles through 4 resources on button press (target
address is hard-coded).
- er-plugtest-server.c: The server used for draft compliance testing at ETSI
IoT CoAP Plugtest in Paris, France, March 2012 (configured for minimal-net).
PRELIMINARIES
-------------
- Make sure rpl-border-router has the same stack and fits into mote memory:
You can disable RDC in border-router project-conf.h (not really required as BR keeps radio turned on).
#undef NETSTACK_CONF_RDC
#define NETSTACK_CONF_RDC nullrdc_driver
- For convenience, define the Cooja addresses in /etc/hosts
aaaa::0212:7401:0001:0101 cooja1
aaaa::0212:7402:0002:0202 cooja2
...
- Get the Copper (Cu) CoAP user-agent from
[https://addons.mozilla.org/en-US/firefox/addon/copper-270430](https://addons.mozilla.org/en-US/firefox/addon/copper-270430)
- Optional: Save your target as default target
make TARGET=sky savetarget
COOJA HOWTO
-----------
###Server only:
make TARGET=cooja server-only.csc
Open new terminal
make connect-router-cooja
- Start Copper and discover resources at coap://cooja2:5683/
- Choose "Click button on Sky 2" from the context menu of mote 2 (server) after
requesting /test/separate
- Do the same when observing /test/event
###With client:
make TARGET=cooja server-client.csc
Open new terminal
make connect-router-cooja
- Wait until red LED toggles on mote 2 (server)
- Choose "Click button on Sky 3" from the context menu of mote 3 (client) and
watch serial output
TMOTES HOWTO
------------
###Server:
1. Connect two Tmote Skys (check with $ make TARGET=sky sky-motelist)
make TARGET=sky er-example-server.upload MOTE=2
make TARGET=sky login MOTE=2
2. Press reset button, get address, abort with Ctrl+C:
Line: "Tentative link-local IPv6 address fe80:0000:0000:0000:____:____:____:____"
cd ../ipv6/rpl-border-router/
make TARGET=sky border-router.upload MOTE=1
make connect-router
For a BR tty other than USB0:
make connect-router-port PORT=X
3. Start Copper and discover resources at:
coap://[aaaa::____:____:____:____]:5683/
### Add a client:
1. Change the hard-coded server address in er-example-client.c to aaaa::____:____:____:____
2. Connect a third Tmote Sky
make TARGET=sky er-example-client.upload MOTE=3
MINIMAL-NET HOWTO
-----------------
With the target minimal-net you can test your CoAP applications without
constraints, i.e., with large buffers, debug output, memory protection, etc.
The er-plugtest-server is thought for the minimal-net platform, as it requires
an 1280-byte IP buffer and 1024-byte blocks.
make TARGET=minimal-net er-plugtest-server
sudo ./er-plugtest-server.minimal-net
Open new terminal
make connect-minimal
- Start Copper and discover resources at coap://[fdfd::ff:fe00:10]:5683/
- You can enable the ETSI Plugtest menu in Copper's preferences
Under Windows/Cygwin, WPCAP might need a patch in
<cygwin>\usr\include\w32api\in6addr.h:
21,23c21
< #ifdef __INSIDE_CYGWIN__
< uint32_t __s6_addr32[4];
< #endif
---
> u_int __s6_addr32[4];
36d33
< #ifdef __INSIDE_CYGWIN__
39d35
< #endif
DETAILS
-------
Erbium currently implements draft 13. Central features are commented in
er-example-server.c. In general, apps/er-coap-13 supports:
- All draft 13 header options
- CON Retransmissions (note COAP_MAX_OPEN_TRANSACTIONS)
- Blockwise Transfers (note REST_MAX_CHUNK_SIZE, see er-plugtest-server.c for
Block1 uploads)
- Separate Responses (no rest_set_pre_handler() required anymore, note
coap_separate_accept(), _reject(), and _resume())
- Resource Discovery
- Observing Resources (see EVENT_ and PRERIODIC_RESOURCE, note
COAP_MAX_OBSERVERS)
REST IMPLEMENTATIONS
--------------------
The Makefile uses WITH_COAP to configure different implementations for the
Erbium (Er) REST Engine.
- WITH_COAP=13 uses Erbium CoAP 13 apps/er-coap-13/. The default port for
coap-13 is 5683.
- WITH_COAP=12 uses Erbium CoAP 12 apps/er-coap-12/. The default port for
coap-12 is 5683.
- WITH_COAP=7 uses Erbium CoAP 08 apps/er-coap-07/. The default port for
coap-07/-08 is 5683.
- WITH_COAP=3 uses Erbium CoAP 03 apps/er-coap-03/. The default port for
coap-03 is 61616. er-coap-03 produces some warnings, as it not fully
maintained anymore.
- WITH_COAP=0 is a stub to link an Erbium HTTP engine that uses the same
resource abstraction (REST.x() functions and RESOURCE macros.
TODOs
-----
- Dedicated Observe buffers
- Optimize message struct variable access (directly access struct without copying)
- Observe client
- Multiple If-Match ETags
- (Message deduplication)

View File

@ -1,35 +0,0 @@
This adds the hello-world process in hello-world.c to the platform build,
which prints "Hello-world" to stdout on startup.
The entire platform is built, with uip stack, radio drivers, routing, etc.
So it is not usually a simple build! The native platform is the default:
$make
$./hello-world.native
Starting Contiki
Hello, world
When switching between ipv4 and ipv6 builds on a platform,
$make TARGET=<platform> clean
else the library for that platform will contain duplicate or unresolved modules.
For example, using a loopback interface with the minimal-net platform:
[To install a loopback see http://www.sourceforge.net/apps/mediawiki/contiki/index.php?title=Capturing_loopback_traffic_with_Wireshark]
$cd /examples/hello-world
$make TARGET=minimal-net
$./hello-world.minimal-net
Hello, world
IP Address: 10.1.1.1
Subnet Mask: 255.0.0.0
Def. Router: 10.1.1.100
^C
$make TARGET=minimal-net clean
$make UIP_CONF_IPV6=1 TARGET=minimal-net
$./hello-world.minimal-net
Hello, world
IPV6 Address: [aaaa::206:98ff:fe00:232]
IPV6 Address: [fe80::206:98ff:fe00:232]
^C
Note to AVR Raven users: Output goes to UART1, not the LCD. To see it,
$make TARGET=avr-raven hello-world.elf
Load the .elf in AVR Studio and connect a hapsim terminal to the 1284p simulation.

View File

@ -0,0 +1,45 @@
Hello-world
===========
This adds the hello-world process in hello-world.c to the platform build, which
prints "Hello-world" to stdout on startup.
The entire platform is built, with uip stack, radio drivers, routing, etc.
So it is not usually a simple build! The native platform is the default:
make
./hello-world.native
Starting Contiki
Hello, world
When switching between ipv4 and ipv6 builds on a platform,
make TARGET=<platform> clean
else the library for that platform will contain duplicate or unresolved
modules.
For example, using a loopback interface with the minimal-net platform:
cd /examples/hello-world
make TARGET=minimal-net
./hello-world.minimal-net
Hello, world
IP Address: 10.1.1.1
Subnet Mask: 255.0.0.0
Def. Router: 10.1.1.100
^C
make TARGET=minimal-net clean
make UIP_CONF_IPV6=1 TARGET=minimal-net
./hello-world.minimal-net
Hello, world
IPV6 Address: [aaaa::206:98ff:fe00:232]
IPV6 Address: [fe80::206:98ff:fe00:232]
^C
Note to AVR Raven users: Output goes to UART1, not the LCD. To see it,
make TARGET=avr-raven hello-world.elf
Load the .elf in AVR Studio and connect a hapsim terminal to the 1284p simulation.

View File

@ -0,0 +1,109 @@
JSON ws
=======
Short description on how to set-up a sensor network for global IPv6 addresses.
NOTE: this assumes that you do not have a native IPv6 connection.
You will need:
- PC with Ubuntu (Linux) - 11 or 12 versions
- A node for the RPL-Border-Router (examples/ipv6/rpl-border-router)
- A node for the json webservice (examples/ipv6/json-ws)
Set-up IPv6 tunnel and Border Router
------------------------------------
1. Ensure that you have gogo6c installed.
sudo apt-get install gogoc
2. Register an account at gogo6 and Freenet6 (http://www.gogo6.com).
The account at Freenet6 is needed by the gogo6c client.
3. Edit the gogoc.conf and set your own Freenet6 user and password by
changing the lines with "userid" and "passwd".
4. Start gogoc at command line
cd contiki/examples/ipv6/json-ws
sudo gogoc -f gogoc.conf -n
This will print your prefix - TSP_PREFIX. In my case
TSP_PREFIX=2001:05c0:1517:e400 (prefixlen is 56).
5. Connect one of the nodes to the PC (via USB or serial) and program
it with the RPL-border-router (assumes Z1 node).
cd contiki/examples/ipv6/rpl-border-router
make DEFINES=DEFINES=NETSTACK_RDC=nullrdc_driver,NULLRDC_CONF_802154_AUTOACK=1 TARGET=z1 border-router.upload
6. Run tunslip6 which will forward IP from the RPL network to the IPv6 tunnel
(and to the Internet).
cd contiki/examples/ipv6/rpl-border-router
make connect-router PREFIX=<TSP_PREFIX>::1/64
When you start this you should get a printout from the border-router
which give you the IPv6 address of it.
Server IPv6 addresses:
2001:05c0:1517:e400:c30c::10a
fe80::c30c:0:0:10a
7. Browse using Mozilla Firefox (or any other browser) to the IPv6 address
given by the border router. This will show you the list of other nodes
connected to the RPL network.
http://[2001:05c0:1517:e400:c30c::10a]/
NOTE: this is a global IPv6 address so it should also be reachable from
any machine on the Internet.
Configuration of COSM submission
--------------------------------
1. Register a COSM account at https://cosm.com/
Set-up a feed and create an API key for the feed.
2. Program the sensor node with (assumes Z1)
cd contiki/examples/ipv6/json-ws
make websense-z1.upload WITH_COSM=1 TARGET=z1
3. Check the IPv6 address of the node via the RPL-border router or by looking
at printouts when booting (make login TARGET=z1)
4. You need to configure the node to push data to the COSM feed and this can be
done in several ways. For convenience a Python script is included that
pushes the configuration to the nodes.
Edit the file 'setcosm.py' and replace "<your-key>" and "<your-feed>" with
your COSM API key and COSM feed id. You can then use this Python script to
configure your nodes.
This is an example that configures the node with IP address
2001:05c0:1517:e400:c30c::10b to push data to the COSM feed with stream 1:
cd contiki/examples/ipv6/json-ws
./setcosm.py [2001:05c0:1517:e400:c30c::10b] 1
Another way to configure the nodes is to use a REST add-on for the web
browser to post a COSM configuration to the node. "REST Client" for Mozilla
Firefox is an example of such add-on.
POST a JSON expression to your node with the following data: This assumes
that you have the feed with id 55180 and want to post to stream 1 in that
feed. The field 'appdata' should be set to the API key you created at the
COSM web site for the feed.
{
"host":"[2001:470:1f10:333::2]",
"port":80,
"path":"/v2/feeds/55180/datastreams/1",
"appdata":"<insert your COSM API key>",
"interval":120,
"proto":"cosm"
}
This will configure the node to periodically push temperature data every
other minute. You can use GET to retrieve the data to se that the node has
been successfully configured (the COSM API key will be visualized as a
number of stars).

View File

@ -1,106 +0,0 @@
Short description on how to set-up a sensor network for global IPv6 addresses.
NOTE: this assumes that you do not have a native IPv6 connection.
You will need:
* PC with Ubuntu (Linux) - 11 or 12 versions
* A node for the RPL-Border-Router (examples/ipv6/rpl-border-router)
* A node for the json webservice (examples/ipv6/json-ws)
Set-up IPv6 tunnel and Border Router
------------------------------------
1. Ensure that you have gogo6c installed.
> sudo apt-get install gogoc
2. Register an account at gogo6 and Freenet6 (http://www.gogo6.com).
The account at Freenet6 is needed by the gogo6c client.
3. Edit the gogoc.conf and set your own Freenet6 user and password by
changing the lines with "userid" and "passwd".
4. Start gogoc at command line
> cd contiki/examples/ipv6/json-ws
> sudo gogoc -f gogoc.conf -n
This will print your prefix - TSP_PREFIX.
In my case TSP_PREFIX=2001:05c0:1517:e400 (prefixlen is 56).
5. Connect one of the nodes to the PC (via USB or serial) and program
it with the RPL-border-router (assumes Z1 node).
> cd contiki/examples/ipv6/rpl-border-router
> make DEFINES=DEFINES=NETSTACK_RDC=nullrdc_driver,NULLRDC_CONF_802154_AUTOACK=1 TARGET=z1 border-router.upload
6. Run tunslip6 which will forward IP from the RPL network to
the IPv6 tunnel (and to the Internet).
> cd contiki/examples/ipv6/rpl-border-router
> make connect-router PREFIX=<TSP_PREFIX>::1/64
When you start this you should get a printout from the border-router
which give you the IPv6 address of it.
Server IPv6 addresses:
2001:05c0:1517:e400:c30c::10a
fe80::c30c:0:0:10a
7. Browse using Mozilla Firefox (or any other browser) to the IPv6 address
given by the border router. This will show you the list of other nodes
connected to the RPL network.
http://[2001:05c0:1517:e400:c30c::10a]/
NOTE: this is a global IPv6 address so it should also be reachable from
any machine on the Internet.
Configuration of COSM submission
--------------------------------
1. Register a COSM account at https://cosm.com/
Set-up a feed and create an API key for the feed.
2. Program the sensor node with (assumes Z1)
> cd contiki/examples/ipv6/json-ws
> make websense-z1.upload WITH_COSM=1 TARGET=z1
3. Check the IPv6 address of the node via the RPL-border router or
by looking at printouts when booting (make login TARGET=z1)
4. You need to configure the node to push data to the COSM feed and
this can be done in several ways. For convenience a Python script
is included that pushes the configuration to the nodes.
Edit the file 'setcosm.py' and replace "<your-key>" and
"<your-feed>" with your COSM API key and COSM feed id. You can then
use this Python script to configure your nodes.
This is an example that configures the node with IP address
2001:05c0:1517:e400:c30c::10b to push data to the COSM feed with
stream 1:
> cd contiki/examples/ipv6/json-ws
> ./setcosm.py [2001:05c0:1517:e400:c30c::10b] 1
Another way to configure the nodes is to use a REST add-on for the
web browser to post a COSM configuration to the node. "REST Client"
for Mozilla Firefox is an example of such add-on.
POST a JSON expression to your node with the following data:
This assumes that you have the feed with id 55180 and want to post
to stream 1 in that feed. The field 'appdata' should be set to the
API key you created at the COSM web site for the feed.