commit
59a8df14a8
@ -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.md
Normal file
92
README-BUILDING.md
Normal 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).
|
207
README-EXAMPLES
207
README-EXAMPLES
@ -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.md
Normal file
220
README-EXAMPLES.md
Normal 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.
|
@ -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)
|
@ -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
|
@ -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
|
@ -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.md
Normal file
75
cpu/6502/README.md
Normal 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.
|
@ -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.
|
||||
|
72
cpu/mc1322x/README.md
Normal file
72
cpu/mc1322x/README.md
Normal 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.
|
@ -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
|
||||
|
39
cpu/mc1322x/README.subtree.md
Normal file
39
cpu/mc1322x/README.subtree.md
Normal 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
|
@ -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
|
6
cpu/mc1322x/doc/lqi-pdr/README.md
Normal file
6
cpu/mc1322x/doc/lqi-pdr/README.md
Normal 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
|
@ -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)
|
@ -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.
|
20
examples/cc2530dk/border-router/README.md
Normal file
20
examples/cc2530dk/border-router/README.md
Normal 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.
|
@ -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)
|
165
examples/er-rest-example/README.md
Normal file
165
examples/er-rest-example/README.md
Normal 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)
|
@ -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.
|
45
examples/hello-world/README.md
Normal file
45
examples/hello-world/README.md
Normal 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.
|
109
examples/ipv6/json-ws/README-COSM.md
Normal file
109
examples/ipv6/json-ws/README-COSM.md
Normal 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).
|
@ -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.
|
||||
|
||||
{
|
||||
"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).
|
@ -1,16 +1,20 @@
|
||||
This example features a simple webserver running on top of the IPv6
|
||||
contiki stack on Sky motes to provide sensor values, and with a RPL
|
||||
border router to bridge the sensor network to Internet.
|
||||
Sky websense
|
||||
============
|
||||
|
||||
This example features a simple webserver running on top of the IPv6 contiki
|
||||
stack on Sky motes to provide sensor values, and with a RPL border router to
|
||||
bridge the sensor network to Internet.
|
||||
|
||||
To test the example in COOJA under Linux
|
||||
----------------------------------------
|
||||
|
||||
1. Start COOJA and load the simulation "example-sky-websense.csc"
|
||||
> make TARGET=cooja example-sky-websense.csc
|
||||
|
||||
make TARGET=cooja example-sky-websense.csc
|
||||
|
||||
2. Connect to the COOJA simulation using tunslip6:
|
||||
> make connect-router-cooja
|
||||
|
||||
make connect-router-cooja
|
||||
|
||||
3. You should now be able to browse to the nodes using your web browser:
|
||||
Router: http://[aaaa::0212:7401:0001:0101]/
|
||||
@ -21,16 +25,19 @@ To run the example on real nodes under Linux
|
||||
--------------------------------------------
|
||||
|
||||
1. Program the nodes with the websense application
|
||||
> make TARGET=sky sky-websense.upload
|
||||
|
||||
make TARGET=sky sky-websense.upload
|
||||
|
||||
2. Disconnect the nodes and program one node with the RPL border router
|
||||
> (cd ../rpl-border-router && make TARGET=sky border-router.upload)
|
||||
|
||||
cd ../rpl-border-router && make TARGET=sky border-router.upload
|
||||
|
||||
3. Connect to the border router using tunslip6:
|
||||
> make connect-router
|
||||
|
||||
make connect-router
|
||||
|
||||
4. Reboot the router and note the router IP address
|
||||
|
||||
5. You should now be able to browse to your router node using your web
|
||||
browser: http://[<ROUTER IPv6 ADDRESS>]/. On this page you should
|
||||
see a list of all accessible nodes with their IP adresses.
|
||||
5. You should now be able to browse to your router node using your web browser:
|
||||
http://[<ROUTER IPv6 ADDRESS>]/. On this page you should see a list of all
|
||||
accessible nodes with their IP adresses.
|
@ -3,8 +3,8 @@ ELFloader and shell command 'exec' example for MB851 (STM32W) platform
|
||||
|
||||
Compiles the Contiki hello-world application as a Contiki executable (.ce).
|
||||
The Contiki executable is then uploaded to the MB851 platform via serial, and
|
||||
is stored in the filesystem.
|
||||
Finally, the executable is loaded via the shell command 'exec'.
|
||||
is stored in the filesystem. Finally, the executable is loaded via the shell
|
||||
command 'exec'.
|
||||
|
||||
NOTE:
|
||||
You may have to reduce the ELF loader memory usage (/platform/sky/contiki-conf.h).
|
||||
@ -12,35 +12,38 @@ Since hello-world uses very little memory:
|
||||
#define ELFLOADER_CONF_DATAMEMORY_SIZE 0x100
|
||||
#define ELFLOADER_CONF_TEXTMEMORY_SIZE 0x100
|
||||
|
||||
1. Upload Sky shell with 'exec' command and symbols (requires several
|
||||
recompilations to generate correct symbols):
|
||||
|
||||
1. Upload Sky shell with 'exec' command and symbols (requires several recompilations to generate correct symbols):
|
||||
> make
|
||||
> make CORE=shell-exec-test.mb851
|
||||
> make shell-exec-test.flash CORE=shell-exec-test.mb851 PORT=AUTO
|
||||
|
||||
make
|
||||
make CORE=shell-exec-test.mb851
|
||||
make shell-exec-test.flash CORE=shell-exec-test.mb851 PORT=AUTO
|
||||
|
||||
2. Verify access to the shell and the filesystem:
|
||||
> make login DEV=/dev/comX
|
||||
SHELL> echo hello shell
|
||||
SHELL> echo test | write mytest.txt
|
||||
SHELL> ls
|
||||
SHELL> read mytest.txt
|
||||
[CTRL-C] to exit the shell
|
||||
|
||||
> make login DEV=/dev/comX
|
||||
SHELL> echo hello shell
|
||||
SHELL> echo test | write mytest.txt
|
||||
SHELL> ls
|
||||
SHELL> read mytest.txt
|
||||
[CTRL-C] to exit the shell
|
||||
|
||||
3. Upload Contiki executable hello-world.ce:
|
||||
> make upload-executable DEV=/dev/comX
|
||||
[CTRL-C] to exit the shell when the entire file has been uploaded (after ~30 sec)
|
||||
|
||||
> make upload-executable DEV=/dev/comX
|
||||
[CTRL-C] to exit the shell when the entire file has been uploaded (after ~30 sec)
|
||||
|
||||
4. Verify that hello-world.ce exists in CFS:
|
||||
> make login DEV=/dev/comX
|
||||
SHELL> ls
|
||||
SHELL> read hello-world.ce | size
|
||||
The last command output should equal the size of hello-world.ce in this directory!
|
||||
|
||||
> make login DEV=/dev/comX
|
||||
SHELL> ls
|
||||
SHELL> read hello-world.ce | size
|
||||
|
||||
The last command output should equal the size of hello-world.ce in this
|
||||
directory!
|
||||
|
||||
5. Load and start hello world:
|
||||
SHELL> exec hello-world.ce
|
||||
The program should now start: the output 'Hello, World' appears.
|
||||
|
||||
SHELL> exec hello-world.ce
|
||||
|
||||
The program should now start: the output 'Hello, World' appears.
|
@ -1,7 +1,10 @@
|
||||
Thi is an example based on the udp-ipv6 example. A client periodically sends
|
||||
UDP IPV6 sleep
|
||||
==============
|
||||
|
||||
Thi is an example based on the UDP-IPv6 example. A client periodically sends
|
||||
UDP packets to a fixed server. The client will also go in a deep sleep state
|
||||
during wich all system peripherals are turned off to save as more energy as
|
||||
during which all system peripherals are turned off to save as more energy as
|
||||
possible.
|
||||
|
||||
To avoid blocking the entire OS for too long time, the system periocally
|
||||
To avoid blocking the entire OS for too long time, the system periodically
|
||||
wakes up to let the OS poll processes and dispatch events.
|
@ -1,9 +0,0 @@
|
||||
Compile with WITH_RIME 1 for neighbor discovery and with ENERGEST_CONF_ON
|
||||
for energy estimation.
|
||||
|
||||
Estimated consumption with batteries (2.4 V):
|
||||
Curr Power
|
||||
ENERGEST_TYPE_CPU: 7.5 mA 18 mW
|
||||
ENERGEST_TYPE_LPM: 3 mA 7.2 mW
|
||||
ENERGEST_TYPE_TRANSMIT: 21 mA 50.4 mW
|
||||
ENERGEST_TYPE_LISTEN: 19 mA 45.6 mW
|
37
examples/mb851/webserver-ajax/README.md
Normal file
37
examples/mb851/webserver-ajax/README.md
Normal file
@ -0,0 +1,37 @@
|
||||
Compile with WITH_RIME 1 for neighbor discovery and with ENERGEST_CONF_ON for
|
||||
energy estimation.
|
||||
|
||||
Estimated consumption with batteries (2.4 V):
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td>Curr</td>
|
||||
<td>Power</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>ENERGEST_TYPE_CPU</td>
|
||||
<td>7.5 mA</td>
|
||||
<td>18 mW</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>ENERGEST_TYPE_LPM</td>
|
||||
<td>3 mA</td>
|
||||
<td>7.2 mW</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>ENERGEST_TYPE_TRANSMIT</td>
|
||||
<td>21 mA</td>
|
||||
<td>50.4 mW</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>ENERGEST_TYPE_LISTEN</td>
|
||||
<td>19 mA</td>
|
||||
<td>45.6 mW</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
@ -1,5 +1,8 @@
|
||||
This example just runs the IPv6 stack without any application on the
|
||||
top.
|
||||
New IPv6
|
||||
========
|
||||
|
||||
This example just runs the IPv6 stack without any application on the top.
|
||||
|
||||
To test the stack you can, for example, run a ping6 command:
|
||||
ping6 -I tap0 ff02:0000:0000:0000:0000:0001:ff00:0232
|
||||
|
||||
ping6 -I tap0 ff02:0000:0000:0000:0000:0001:ff00:0232
|
@ -1,11 +0,0 @@
|
||||
Simple ping6 application for testing purpose.
|
||||
|
||||
The user should wait for the prompt and input the ping6 command
|
||||
followed by the destination IPv6 address. The address should not use
|
||||
any abbreviated form (the application does very little input format
|
||||
check).
|
||||
|
||||
E.g. of a correct command:
|
||||
> ping6 fe80:0000:0000:0000:02bd:07ff:fee2:1c00
|
||||
|
||||
The ping6 application will then send PING6_NB = 5 ping request packets.
|
12
examples/ping-ipv6/README.md
Normal file
12
examples/ping-ipv6/README.md
Normal file
@ -0,0 +1,12 @@
|
||||
Simple ping6 application for testing purpose.
|
||||
=============================================
|
||||
|
||||
The user should wait for the prompt and input the ping6 command followed by the
|
||||
destination IPv6 address. The address should not use any abbreviated form (the
|
||||
application does very little input format check).
|
||||
|
||||
E.g. of a correct command:
|
||||
|
||||
> ping6 fe80:0000:0000:0000:02bd:07ff:fee2:1c00
|
||||
|
||||
The ping6 application will then send PING6_NB = 5 ping request packets.
|
@ -1,96 +0,0 @@
|
||||
|
||||
|
||||
Open a terminal and go to "<CONTIKI_HOME>/examples/rest-example/" directory.
|
||||
|
||||
MAIN EXAMPLE:
|
||||
rest-server-example.c : A RESTful server example showing how to use the REST layer to develop server-side applications (possible to run it over either COAP or HTTP)
|
||||
To use COAP as the underlying application protocol, one should define WITH_COAP = 1 in rest-example/Makefile. Otherwise, HTTP is used.
|
||||
Look at the source code to see which resources are available. (check the RESOURCE macros in the code).
|
||||
Each resource has a handler function which is called by the REST layer to serve the request.
|
||||
(i.e. "helloworld" resource has a handler function named "helloworld_handler" which is called when a web service request is received for "helloworld" resource.)
|
||||
|
||||
|
||||
To run REST examples in COOJA on Linux
|
||||
--------------------------------------------
|
||||
|
||||
Accessing the server from outside:
|
||||
1. Start COOJA and load the simulation "rest-server-example.csc" by the following command.
|
||||
make TARGET=cooja rest-server-example.csc
|
||||
|
||||
2. After loading the COOJA file, open another another terminal pointing to the same directory and connect to the COOJA simulation using tunslip6:
|
||||
make connect-router-cooja
|
||||
|
||||
3. You need to use a COAP or HTTP client to interact with the COOJA nodes running REST code.
|
||||
In this setting, two servers are available:
|
||||
IP addresses are aaaa::0212:7402:0002:0202 and aaaa::0212:7403:0003:0303. COAP uses 61616, whereas HTTP uses 8080 port in default configuration.
|
||||
First, ping the COOJA nodes to test the connectivity.
|
||||
ping6 aaaa::0212:7402:0002:0202
|
||||
ping6 aaaa::0212:7403:0003:0303
|
||||
|
||||
HTTP Examples
|
||||
You can use curl as an http client to interact with the COOJA motes running REST code.
|
||||
curl -H "User-Agent: curl" aaaa::0212:7402:0002:0202:8080/helloworld #get helloworld plain text
|
||||
curl -H "User-Agent: curl" aaaa::0212:7402:0002:0202:8080/led?color=green -d mode=off -i #turn off the green led
|
||||
curl -H "User-Agent: curl" aaaa::0212:7402:0002:0202:8080/.well-known/core -i
|
||||
curl -X POST -H "User-Agent: curl" aaaa::0212:7402:0002:0202:8080/helloworld #method not allowed
|
||||
|
||||
COAP Examples
|
||||
You should run a COAP client on your computer. You can use the URLs and methods provided above in HTTP examples to test the COAP Server.
|
||||
For example, Matthias Kovatsch has developed a CoAP Firefox plug-in which is accessible via http://people.inf.ethz.ch/mkovatsc/#pro
|
||||
|
||||
Accessing the server inside the sensor network:
|
||||
(Note: Provided only for COAP implementation)
|
||||
Start COOJA and load the simulation "coap-client-server-example.csc" by the following command.
|
||||
make TARGET=cooja coap-client-server-example.csc
|
||||
|
||||
coap-client-server-example.csc : Runs rest-server-example.c as the server (over COAP) (IP:aaaa::0212:7401:0001:0101)
|
||||
in one node and coap-client-example.c as the client (IP: aaaa::0212:7402:0002:0202) in another node.
|
||||
Client periodically accesses resources of server and prints the payload.
|
||||
|
||||
Note: If the generated binary is bigger than the MOTE code size, then you will get a "region text is full" error.
|
||||
Right now, REST+HTTP example uses (Contiki + ContikiMAC + uIPv6 + RPL + HTTP Server + REST Layer) which does not fit in Tmote Sky memory.
|
||||
To save same code space and make the example fit, you can define static routes rather than using RPL or use nullrdc rather than ContikiMAC.
|
||||
If border router does not fit, then first try to update the Makefile of border router in <CONTIKI_HOME>/examples/ipv6/rpl-border-router by
|
||||
setting WITH_WEBSERVER=0.
|
||||
|
||||
To run REST server on real nodes (i.e. tmote sky)
|
||||
--------------------------------------------
|
||||
|
||||
1. Program the nodes with the rest-server-example
|
||||
make TARGET=sky rest-server-example.upload
|
||||
|
||||
2. Disconnect the nodes and program one node with the RPL border router
|
||||
(cd ../ipv6/rpl-border-router && make TARGET=sky border-router.upload)
|
||||
|
||||
3. Connect to the border router using tunslip6:
|
||||
make connect-router
|
||||
|
||||
4. Reconnect the motes, open new terminal for each mote and run the following command to note their IP addresses (after running the command reset the corresponding mote to get IP address printed)
|
||||
make login TARGET=sky MOTE=2 #Shows the prints for first mote
|
||||
make login TARGET=sky MOTE=3 #For second mote and so on.
|
||||
|
||||
5. Test the connectivity by pinging them.
|
||||
ping6 <IPv6 Address of the MOTE>
|
||||
|
||||
6. Remaining parts are the same with the COOJA example. (i.e. if it is a COAP Server, it's available at <NODE_IP_ADDR>:61616)
|
||||
|
||||
|
||||
To run REST server with minimal-net on Linux
|
||||
--------------------------------------------
|
||||
1. Compile with minimal-net setting.
|
||||
make rest-server-example TARGET=minimal-net
|
||||
|
||||
2. Run the generated executable with sudo and note the IP address of the server which will be printed right after.
|
||||
sudo ./rest-server-example.minimal-net
|
||||
|
||||
3. How to access and test the server is same with the other settings. (i.e. if it is a COAP Server,
|
||||
it's available at <IP_ADDRESS_FROM_STEP_2>:61616 and if it's a HTTP Server it is available at <IP_ADDRESS_FROM_STEP_2>:8080)
|
||||
|
||||
|
||||
To Do
|
||||
*Better option handling needed - ex: critical options are not differentiated for now. Need to add support for some such as Tokens. Also, C/E difference should be added.
|
||||
*Reilable message sending is missing. i.e. client example should resend request in case ACK does not arrive. Same for server pushing (in case of subscriptions)
|
||||
*Add Block transfer example
|
||||
*Add Subscription example
|
||||
*Add an Android/Java COAP Client to Contikiprojects to be able to interact with Contiki.
|
||||
*COAP-specific Method Codes
|
137
examples/rest-example/README.md
Normal file
137
examples/rest-example/README.md
Normal file
@ -0,0 +1,137 @@
|
||||
REST example
|
||||
============
|
||||
|
||||
Open a terminal and go to "<CONTIKI_HOME>/examples/rest-example/" directory.
|
||||
|
||||
MAIN EXAMPLE: rest-server-example.c : A RESTful server example showing how to
|
||||
use the REST layer to develop server-side applications (possible to run it over
|
||||
either COAP or HTTP) To use COAP as the underlying application protocol, one
|
||||
should define WITH_COAP = 1 in rest-example/Makefile. Otherwise, HTTP is used.
|
||||
Look at the source code to see which resources are available. (check the
|
||||
RESOURCE macros in the code). Each resource has a handler function which is
|
||||
called by the REST layer to serve the request. (i.e. "helloworld" resource has
|
||||
a handler function named "helloworld_handler" which is called when a web
|
||||
service request is received for "helloworld" resource.)
|
||||
|
||||
|
||||
To run REST examples in COOJA on Linux
|
||||
--------------------------------------------
|
||||
|
||||
Accessing the server from outside:
|
||||
|
||||
1. Start COOJA and load the simulation "rest-server-example.csc" by the following command.
|
||||
|
||||
make TARGET=cooja rest-server-example.csc
|
||||
|
||||
2. After loading the COOJA file, open another another terminal pointing to the
|
||||
same directory and connect to the COOJA simulation using tunslip6:
|
||||
|
||||
make connect-router-cooja
|
||||
|
||||
3. You need to use a COAP or HTTP client to interact with the COOJA nodes
|
||||
running REST code. In this setting, two servers are available: IP addresses
|
||||
are aaaa::0212:7402:0002:0202 and aaaa::0212:7403:0003:0303. COAP uses
|
||||
61616, whereas HTTP uses 8080 port in default configuration. First, ping
|
||||
the COOJA nodes to test the connectivity.
|
||||
|
||||
ping6 aaaa::0212:7402:0002:0202
|
||||
ping6 aaaa::0212:7403:0003:0303
|
||||
|
||||
HTTP Examples
|
||||
-------------
|
||||
|
||||
You can use curl as an http client to interact with the COOJA motes running
|
||||
REST code.
|
||||
|
||||
curl -H "User-Agent: curl" aaaa::0212:7402:0002:0202:8080/helloworld #get helloworld plain text
|
||||
curl -H "User-Agent: curl" aaaa::0212:7402:0002:0202:8080/led?color=green -d mode=off -i #turn off the green led
|
||||
curl -H "User-Agent: curl" aaaa::0212:7402:0002:0202:8080/.well-known/core -i
|
||||
curl -X POST -H "User-Agent: curl" aaaa::0212:7402:0002:0202:8080/helloworld #method not allowed
|
||||
|
||||
COAP Examples
|
||||
-------------
|
||||
|
||||
You should run a COAP client on your computer. You can use the URLs and methods
|
||||
provided above in HTTP examples to test the COAP Server. For example, Matthias
|
||||
Kovatsch has developed a CoAP Firefox plug-in which is accessible via
|
||||
[http://people.inf.ethz.ch/mkovatsc/#pro](http://people.inf.ethz.ch/mkovatsc/#pro)
|
||||
|
||||
Accessing the server inside the sensor network: (Note: Provided only for COAP
|
||||
implementation) Start COOJA and load the simulation
|
||||
"coap-client-server-example.csc" by the following command.
|
||||
|
||||
make TARGET=cooja coap-client-server-example.csc
|
||||
|
||||
coap-client-server-example.csc : Runs rest-server-example.c as the server (over
|
||||
COAP) (IP:aaaa::0212:7401:0001:0101) in one node and coap-client-example.c as
|
||||
the client (IP: aaaa::0212:7402:0002:0202) in another node. Client
|
||||
periodically accesses resources of server and prints the payload.
|
||||
|
||||
Note: If the generated binary is bigger than the MOTE code size, then you will
|
||||
get a "region text is full" error. Right now, REST+HTTP example uses (Contiki
|
||||
& ContikiMAC & uIPv6 & RPL & HTTP Server & REST Layer) which does not fit in
|
||||
Tmote Sky memory. To save same code space and make the example fit, you can
|
||||
define static routes rather than using RPL or use nullrdc rather than
|
||||
ContikiMAC. If border router does not fit, then first try to update the
|
||||
Makefile of border router in <CONTIKI_HOME>/examples/ipv6/rpl-border-router by
|
||||
setting WITH_WEBSERVER=0.
|
||||
|
||||
To run REST server on real nodes (i.e. tmote sky)
|
||||
--------------------------------------------
|
||||
|
||||
1. Program the nodes with the rest-server-example
|
||||
|
||||
make TARGET=sky rest-server-example.upload
|
||||
|
||||
2. Disconnect the nodes and program one node with the RPL border router
|
||||
|
||||
cd ../ipv6/rpl-border-router && make TARGET=sky border-router.upload
|
||||
|
||||
3. Connect to the border router using tunslip6:
|
||||
|
||||
make connect-router
|
||||
|
||||
4. Reconnect the motes, open new terminal for each mote and run the following
|
||||
command to note their IP addresses (after running the command reset the
|
||||
corresponding mote to get IP address printed)
|
||||
|
||||
make login TARGET=sky MOTE=2 #Shows the prints for first mote
|
||||
make login TARGET=sky MOTE=3 #For second mote and so on.
|
||||
|
||||
5. Test the connectivity by pinging them.
|
||||
|
||||
ping6 <IPv6 Address of the MOTE>
|
||||
|
||||
6. Remaining parts are the same with the COOJA example. (i.e. if it is a COAP
|
||||
Server, it's available at <NODE_IP_ADDR>:61616)
|
||||
|
||||
|
||||
To run REST server with minimal-net on Linux
|
||||
--------------------------------------------
|
||||
1. Compile with minimal-net setting.
|
||||
|
||||
make rest-server-example TARGET=minimal-net
|
||||
|
||||
2. Run the generated executable with sudo and note the IP address of the server
|
||||
which will be printed right after.
|
||||
|
||||
sudo ./rest-server-example.minimal-net
|
||||
|
||||
3. How to access and test the server is same with the other settings. (i.e. if
|
||||
it is a COAP Server, it's available at <IP_ADDRESS_FROM_STEP_2>:61616 and if
|
||||
it's a HTTP Server it is available at <IP_ADDRESS_FROM_STEP_2>:8080)
|
||||
|
||||
TODO
|
||||
----
|
||||
|
||||
- Better option handling needed - ex: critical options are not differentiated
|
||||
for now. Need to add support for some such as Tokens. Also, C/E difference
|
||||
should be added.
|
||||
- Reilable message sending is missing. i.e. client example should resend
|
||||
request in case ACK does not arrive. Same for server pushing (in case of
|
||||
subscriptions)
|
||||
- Add Block transfer example
|
||||
- Add Subscription example
|
||||
- Add an Android/Java COAP Client to Contikiprojects to be able to interact
|
||||
with Contiki.
|
||||
- COAP-specific Method Codes
|
@ -1,50 +0,0 @@
|
||||
Sensinode platform example and test applications
|
||||
- by Zach Shelby (zach@sensinode.com)
|
||||
|
||||
Some more examples by George Oikonomou - Loughborough University
|
||||
cc2431-location-engine, udp-ipv6, broadcast-rime
|
||||
blink-hello, event-post, timer-test
|
||||
<oikonomou@users.sourceforge.net>
|
||||
|
||||
This directory contains example and test applications for
|
||||
Sensinode CC2430 based devices. By default it is set to use the
|
||||
sensinode platform:
|
||||
|
||||
/platform/sensinode
|
||||
/cpu/cc2430
|
||||
|
||||
To build an application:
|
||||
|
||||
make [app_name]
|
||||
make hello_world
|
||||
|
||||
To build and upload an application using the Sensinode nano_programmer
|
||||
included under /tools (default /dev/ttyUSB0):
|
||||
|
||||
make [app_name].upload
|
||||
make hello_world.upload
|
||||
|
||||
To dump the serial port output (default /dev/ttyUSB0):
|
||||
|
||||
make sensinode.serialdump
|
||||
|
||||
To configure the hardware model, you can include a make option e.g. for
|
||||
the N601 (N100 is assumed by default):
|
||||
|
||||
make hello_world DEFINES=MODEL_N601
|
||||
|
||||
These make options are defined in /platform/sensinode/Makefile.sensinode
|
||||
|
||||
Descriptions of applications:
|
||||
udp-ipv6 UDP client-server example over uIPv6. Uses link-local and global
|
||||
addresses. Button 1 on the client will send an echo request.
|
||||
broadcast-rime Just a broadcast rime example, slightly modified
|
||||
sensors Demonstrating button and ADC functionality
|
||||
cc2431-location-engine
|
||||
Example demonstrating the usage cc2431 location engine (blind node)
|
||||
N.B. Not all sensinode devides have a cc2431
|
||||
event-post Demonstrating the interaction between two processes with custom events
|
||||
blink-hello Hello World with LED blinking.
|
||||
timer-test Same as clock_test above + testing the rtimer-arch code
|
||||
border-router 802.15.4 to SLIP bridge example. The node will forward packets
|
||||
from the 15.4 network to its UART (and thus a connected PC over SLIP)
|
60
examples/sensinode/README.md
Normal file
60
examples/sensinode/README.md
Normal file
@ -0,0 +1,60 @@
|
||||
Sensinode platform example and test applications
|
||||
================================================
|
||||
|
||||
by Zach Shelby <zach@sensinode.com>
|
||||
|
||||
Some more examples by George Oikonomou <oikonomou@users.sourceforge.net> -
|
||||
Loughborough University
|
||||
|
||||
cc2431-location-engine, udp-ipv6, broadcast-rime blink-hello, event-post,
|
||||
timer-test
|
||||
|
||||
This directory contains example and test applications for Sensinode CC2430
|
||||
based devices. By default it is set to use the sensinode platform:
|
||||
|
||||
/platform/sensinode
|
||||
/cpu/cc2430
|
||||
|
||||
To build an application:
|
||||
|
||||
make [app_name]
|
||||
make hello_world
|
||||
|
||||
To build and upload an application using the Sensinode nano_programmer included
|
||||
under /tools (default /dev/ttyUSB0):
|
||||
|
||||
make [app_name].upload
|
||||
make hello_world.upload
|
||||
|
||||
To dump the serial port output (default /dev/ttyUSB0):
|
||||
|
||||
make sensinode.serialdump
|
||||
|
||||
To configure the hardware model, you can include a make option e.g. for the
|
||||
N601 (N100 is assumed by default):
|
||||
|
||||
make hello_world DEFINES=MODEL_N601
|
||||
|
||||
These make options are defined in /platform/sensinode/Makefile.sensinode
|
||||
|
||||
Descriptions of applications:
|
||||
|
||||
- udp-ipv6: UDP client-server example over uIPv6. Uses link-local and global
|
||||
addresses. Button 1 on the client will send an echo request.
|
||||
|
||||
- broadcast-rime: Just a broadcast rime example, slightly modified
|
||||
|
||||
- sensors: Demonstrating button and ADC functionality
|
||||
|
||||
- cc2431-location-engine: Example demonstrating the usage cc2431 location
|
||||
engine (blind node) N.B. Not all sensinode devides have a cc2431
|
||||
|
||||
- event-post: Demonstrating the interaction between two processes with custom
|
||||
events
|
||||
|
||||
- blink-hello: Hello World with LED blinking.
|
||||
|
||||
- timer-test: Same as clock_test above + testing the rtimer-arch code
|
||||
|
||||
- border-router: 802.15.4 to SLIP bridge example. The node will forward packets
|
||||
from the 15.4 network to its UART (and thus a connected PC over SLIP)
|
@ -1,16 +0,0 @@
|
||||
border-router example for sensinode devices.
|
||||
|
||||
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 over USB
|
||||
- run:
|
||||
sudo ./tunslip6 <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.
|
20
examples/sensinode/border-router/README.md
Normal file
20
examples/sensinode/border-router/README.md
Normal file
@ -0,0 +1,20 @@
|
||||
border-router example for sensinode devices
|
||||
===========================================
|
||||
|
||||
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 over USB
|
||||
- run:
|
||||
|
||||
sudo ./tunslip6 <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.
|
@ -1,9 +1,10 @@
|
||||
A very simple sniffer for sensinode devices.
|
||||
============================================
|
||||
|
||||
The cc2430 RF driver supports outputting all captured packets in hexdump
|
||||
format. We turn this on, and turn everything else off. We use a stub RDC
|
||||
driver to make sure no incoming packet ever goes up the stack and no packet is
|
||||
ever sent out.
|
||||
format. We turn this on, and turn everything else off. We use a stub RDC driver
|
||||
to make sure no incoming packet ever goes up the stack and no packet is ever
|
||||
sent out.
|
||||
|
||||
We only initialise the radio driver instead of the entire stack by over-riding
|
||||
the default netstack.c with the one in this directory.
|
50
examples/sky-shell-exec/README.md
Normal file
50
examples/sky-shell-exec/README.md
Normal file
@ -0,0 +1,50 @@
|
||||
ELFloader and shell command 'exec' example for Sky platform
|
||||
-----------------------------------------------------------
|
||||
|
||||
Compiles the Contiki hello-world application as a Contiki executable (.ce).
|
||||
The Contiki executable is then uploaded to the Sky platform via serial, and is
|
||||
stored in the filesystem. Finally, the executable is loaded via the shell
|
||||
command 'exec'.
|
||||
|
||||
NOTE: You may have to reduce the ELF loader memory usage
|
||||
(/platform/sky/contiki-conf.h). Since hello-world uses very little memory:
|
||||
|
||||
#define ELFLOADER_CONF_DATAMEMORY_SIZE 0x100
|
||||
#define ELFLOADER_CONF_TEXTMEMORY_SIZE 0x100
|
||||
|
||||
1. Upload Sky shell with 'exec' command and symbols (requires several
|
||||
recompilations to generate correct symbols):
|
||||
|
||||
make sky-shell-exec.sky
|
||||
make sky-shell-exec.sky CORE=sky-shell-exec.sky
|
||||
make sky-shell-exec.upload CORE=sky-shell-exec.sky
|
||||
|
||||
2. Verify access to the shell and the filesystem:
|
||||
|
||||
> make login
|
||||
SHELL> echo hello shell
|
||||
SHELL> echo test | write mytest.txt
|
||||
SHELL> ls
|
||||
SHELL> read mytest.txt
|
||||
[CTRL-C] to exit the shell
|
||||
|
||||
3. Upload Contiki executable hello-world.ce:
|
||||
|
||||
> make upload-executable
|
||||
[CTRL-C] to exit the shell when the entire file has been uploaded (after
|
||||
~30 sec)
|
||||
|
||||
4. Verify that hello-world.ce exists in CFS:
|
||||
|
||||
> make login
|
||||
SHELL> ls
|
||||
SHELL> read hello-world.ce | size
|
||||
|
||||
The last command output should equal the size of hello-world.ce in this
|
||||
directory!
|
||||
|
||||
5. Load and start hello world:
|
||||
|
||||
SHELL> exec hello-world.ce
|
||||
|
||||
The program should now start: the output 'Hello, World' appears.
|
@ -1,46 +0,0 @@
|
||||
ELFloader and shell command 'exec' example for Sky platform
|
||||
-----------------------------------------------------------
|
||||
|
||||
Compiles the Contiki hello-world application as a Contiki executable (.ce).
|
||||
The Contiki executable is then uploaded to the Sky platform via serial, and
|
||||
is stored in the filesystem.
|
||||
Finally, the executable is loaded via the shell command 'exec'.
|
||||
|
||||
NOTE:
|
||||
You may have to reduce the ELF loader memory usage (/platform/sky/contiki-conf.h).
|
||||
Since hello-world uses very little memory:
|
||||
#define ELFLOADER_CONF_DATAMEMORY_SIZE 0x100
|
||||
#define ELFLOADER_CONF_TEXTMEMORY_SIZE 0x100
|
||||
|
||||
|
||||
1. Upload Sky shell with 'exec' command and symbols (requires several recompilations to generate correct symbols):
|
||||
> make sky-shell-exec.sky
|
||||
> make sky-shell-exec.sky CORE=sky-shell-exec.sky
|
||||
> make sky-shell-exec.upload CORE=sky-shell-exec.sky
|
||||
|
||||
|
||||
2. Verify access to the shell and the filesystem:
|
||||
> make login
|
||||
SHELL> echo hello shell
|
||||
SHELL> echo test | write mytest.txt
|
||||
SHELL> ls
|
||||
SHELL> read mytest.txt
|
||||
[CTRL-C] to exit the shell
|
||||
|
||||
|
||||
3. Upload Contiki executable hello-world.ce:
|
||||
> make upload-executable
|
||||
[CTRL-C] to exit the shell when the entire file has been uploaded (after ~30 sec)
|
||||
|
||||
|
||||
4. Verify that hello-world.ce exists in CFS:
|
||||
> make login
|
||||
SHELL> ls
|
||||
SHELL> read hello-world.ce | size
|
||||
The last command output should equal the size of hello-world.ce in this directory!
|
||||
|
||||
|
||||
5. Load and start hello world:
|
||||
SHELL> exec hello-world.ce
|
||||
The program should now start: the output 'Hello, World' appears.
|
||||
|
@ -1,21 +0,0 @@
|
||||
This is an example of bursts support in CSMA/ContikiMAC,
|
||||
together with storage of long packet queue in CFS. This
|
||||
is useful to support large fragmented UDP datagrams or
|
||||
continuous data streaming. The current implementation
|
||||
is a simplified version of the techniques presented in
|
||||
"Lossy Links, Low Power, High Throughput", published in
|
||||
the proceeding of ACM SenSys 2011.
|
||||
|
||||
In this example, node with ID==5 sends bursts of UDP
|
||||
datagrams to node with ID==1, the root of the RPL dodag.
|
||||
|
||||
Testing in cooja:
|
||||
$make TARGET=cooja udp-stream.csc
|
||||
|
||||
Testing on Tmote sky:
|
||||
1) set node IDs to different motes so node 5 sends to
|
||||
node 1 (using examples/sky-shell)
|
||||
2) compile and program:
|
||||
$make TARGET=sky udp-stream.upload
|
||||
3) monitor motes with:
|
||||
$make login MOTE=xxx
|
30
examples/udp-stream/README.md
Normal file
30
examples/udp-stream/README.md
Normal file
@ -0,0 +1,30 @@
|
||||
UDP stream
|
||||
==========
|
||||
|
||||
This is an example of bursts support in CSMA/ContikiMAC, together with storage
|
||||
of long packet queue in CFS. This is useful to support large fragmented UDP
|
||||
datagrams or continuous data streaming. The current implementation is a
|
||||
simplified version of the techniques presented in "Lossy Links, Low Power, High
|
||||
Throughput", published in the proceeding of ACM SenSys 2011.
|
||||
|
||||
In this example, node with ID==5 sends bursts of UDP datagrams to node with
|
||||
ID==1, the root of the RPL dodag.
|
||||
|
||||
Testing in cooja:
|
||||
-----------------
|
||||
|
||||
make TARGET=cooja udp-stream.csc
|
||||
|
||||
Testing on Tmote sky:
|
||||
---------------------
|
||||
|
||||
1. Set node IDs to different motes so node 5 sends to node 1 (using
|
||||
examples/sky-shell)
|
||||
|
||||
2. Compile and program:
|
||||
|
||||
make TARGET=sky udp-stream.upload
|
||||
|
||||
3. Monitor motes with:
|
||||
|
||||
make login MOTE=xxx
|
@ -1,54 +0,0 @@
|
||||
This example features a simple webserver running on top of the IPv6
|
||||
contiki stack. It differs from the generic webserver6 example in that
|
||||
wherever possible data is stored in avr flash memory instead of RAM.
|
||||
In addition are cgi scripts for displaying temperature and voltage sensors,
|
||||
and sleep and radio statistics, on web pages.
|
||||
|
||||
A bare $make will use the avr-raven platform. Alternate compatible platforms can
|
||||
be specified, e.g. $make TARGET=avr-atmega128rfa1. In that case the webserver
|
||||
process and web content located in that platform directory will be used.
|
||||
|
||||
The perl script /tools/makefsdata converts web content from (by default)
|
||||
all the files in the /httpd-fs subdirectory into the c source file /httpd-fsdata.c.
|
||||
This file is not deleted in a $make clean so that a rebuild can be done without
|
||||
perl in the toolchain (e.g. from a Windows cmd window). If any web file is
|
||||
changed the dependencies will attempt to update httpd-fsdata.c. If perl
|
||||
is not present, touching httpd-fsdata.c will give it a newer modification date
|
||||
and allow the build to continue.
|
||||
|
||||
Two alternate web contents Huginn and Muninn are included in this directory.
|
||||
Use e.g. $make WEBDIR=Huginn to generate a webserver6-huginn.elf file.
|
||||
Different ipv6 address suffix and server names can be specified in the makefsdata.h
|
||||
file of each directory so that mote addresses will not conflict.
|
||||
|
||||
webserver6.elf is always generated. It is also copied to another file whose name
|
||||
indicates the platform and web directory. $make clean operates only the specified
|
||||
target and webdir. For example:
|
||||
|
||||
$make
|
||||
(builds webserver6.elf and webserver6-avr-raven.elf)
|
||||
$make WEBDIR=huginn
|
||||
(builds webserver6.elf and webserver6-huginn-avr-raven.elf)
|
||||
$make WEBDIR=muninn TARGET=avr-atmega128rfa1
|
||||
(builds webserver6.elf and webserver6-muninn-avr-atmega128rfa1.elf)
|
||||
$make clean WEBDIR=huginn TARGET=avr-atmega128rfa1
|
||||
deletes the avr-atmega128rfa1 objects and webserver6-huginn-avr-atmega128rfa1.elf
|
||||
$make clean
|
||||
deletes the avr-raven objects and webserver6-avr-raven.elf
|
||||
|
||||
$make WEBDIR=xxx always forces regeneration of web content into httpd-fsdata.c and
|
||||
so requires PERL. A bare $make after that will not regenerate httpd-fsdata.c.
|
||||
Use $make WEBDIR=default to switch back to the default /http-fs/ content.
|
||||
|
||||
See Makefile.webserver for optional switches for RPL or a coffee file system.
|
||||
$make UIP_CONF_RPL=1 for a RPL node, or if rpl has become the contiki default,
|
||||
$make UIP_CONF_RPL=0 to override
|
||||
|
||||
Much headbanging can result if you do not $make clean when changing make options,
|
||||
as the normal build dependencies are bypassed and the needed object modules
|
||||
may not be rebuilt.
|
||||
|
||||
$make connect will invoke the /tools/serial-log.pl perl script to connect to
|
||||
your serial debug port. This will log to the console and optional log file,
|
||||
adding useful time stamps. Edit the makefile for your serial port configuration.
|
||||
|
64
examples/webserver-ipv6-raven/README.md
Normal file
64
examples/webserver-ipv6-raven/README.md
Normal file
@ -0,0 +1,64 @@
|
||||
webserver IPv6 raven
|
||||
====================
|
||||
|
||||
This example features a simple webserver running on top of the IPv6 contiki
|
||||
stack. It differs from the generic webserver6 example in that wherever possible
|
||||
data is stored in AVR flash memory instead of RAM. In addition are cgi scripts
|
||||
for displaying temperature and voltage sensors, and sleep and radio statistics,
|
||||
on web pages.
|
||||
|
||||
A bare $make will use the avr-raven platform. Alternate compatible platforms
|
||||
can be specified, e.g. $make TARGET=avr-atmega128rfa1. In that case the
|
||||
webserver process and web content located in that platform directory will be
|
||||
used.
|
||||
|
||||
The perl script /tools/makefsdata converts web content from (by default)
|
||||
all the files in the /httpd-fs subdirectory into the c source file /httpd-fsdata.c.
|
||||
This file is not deleted in a $make clean so that a rebuild can be done without
|
||||
perl in the toolchain (e.g. from a Windows cmd window). If any web file is
|
||||
changed the dependencies will attempt to update httpd-fsdata.c. If perl
|
||||
is not present, touching httpd-fsdata.c will give it a newer modification date
|
||||
and allow the build to continue.
|
||||
|
||||
Two alternate web contents Huginn and Muninn are included in this directory.
|
||||
Use e.g. $make WEBDIR=Huginn to generate a webserver6-huginn.elf file.
|
||||
Different ipv6 address suffix and server names can be specified in the makefsdata.h
|
||||
file of each directory so that mote addresses will not conflict.
|
||||
|
||||
webserver6.elf is always generated. It is also copied to another file whose
|
||||
name indicates the platform and web directory. $make clean operates only the
|
||||
specified target and webdir. For example:
|
||||
|
||||
make # builds webserver6.elf and webserver6-avr-raven.elf
|
||||
make WEBDIR=huginn # builds webserver6.elf and webserver6-huginn-avr-raven.elf
|
||||
make WEBDIR=muninn TARGET=avr-atmega128rfa1 # (builds webserver6.elf and webserver6-muninn-avr-atmega128rfa1.elf)
|
||||
make clean WEBDIR=huginn TARGET=avr-atmega128rfa1 # deletes the avr-atmega128rfa1 objects and webserver6-huginn-avr-atmega128rfa1.elf
|
||||
make clean # deletes the avr-raven objects and webserver6-avr-raven.elf
|
||||
|
||||
|
||||
make WEBDIR=xxx
|
||||
|
||||
always forces regeneration of web content into httpd-fsdata.c and so requires
|
||||
PERL. A bare $make after that will not regenerate httpd-fsdata.c. Use
|
||||
|
||||
make WEBDIR=default
|
||||
|
||||
to switch back to the default /http-fs/ content.
|
||||
|
||||
See Makefile.webserver for optional switches for RPL or a coffee file system.
|
||||
|
||||
make UIP_CONF_RPL=1 # for a RPL node, or if rpl has become the contiki default,
|
||||
make UIP_CONF_RPL=0 # to override
|
||||
|
||||
Much head banging can result if you do not _make clean_ when changing make
|
||||
options, as the normal build dependencies are bypassed and the needed object
|
||||
modules may not be rebuilt.
|
||||
|
||||
Connect
|
||||
-------
|
||||
|
||||
make connect
|
||||
|
||||
will invoke the /tools/serial-log.pl perl script to connect to your serial
|
||||
debug port. This will log to the console and optional log file, adding useful
|
||||
time stamps. Edit the makefile for your serial port configuration.
|
@ -1,60 +0,0 @@
|
||||
This example features a simple webserver running on top of the IPv6
|
||||
contiki stack.
|
||||
|
||||
For this example to run properly the UIP_CONF_TCP compilation flag
|
||||
must be set to 1 in the contiki-conf.h file of the platform.
|
||||
|
||||
By default contiki ipv6 nodes are configured with the low-power RPL
|
||||
protocol and direct outgoing packets through the RPL parent to a mesh
|
||||
border router. Access to the webserver thus requires at least one other
|
||||
node to as the RPL root. The Makefile changes the default to no RPL for
|
||||
the minimal-net target. Override the RPL choice with
|
||||
$make TARGET=minimal-net UIP_CONF_RPL=1
|
||||
$make TARGET=any-other UIP_CONF_RPL=0
|
||||
The RPL mesh border router can be configured with this webserver using the
|
||||
/examples/ipv6/rpl-border-router/ example.
|
||||
|
||||
If you are using the minimal-net platform without RPL you can access the
|
||||
webserver through the link local address by appending the interface descriptor
|
||||
shown at launch, e.g.
|
||||
wget http://[fe80::296:98ff:fe00:0232%tap0] (linux)
|
||||
ping http://[fe80::206:98ff:fe00:0202%nnnn] (Windows)
|
||||
The lower 64 bits are derived from the ethernet EUI-48 "mac address" in uip6.c:
|
||||
uip_lladdr_t uip_lladdr = {{0x00,0x06,0x98,0x00,0x02,0x32}};
|
||||
|
||||
The ipv6 prefix can be hard-coded in the build or assigned through a
|
||||
host router advertisement. If hard-coded just assign the prefix to the
|
||||
interface:
|
||||
sudo ip -6 address add fdfd::1/64 dev tap0 (linux)
|
||||
netsh commands or the interface GUI (Windows)
|
||||
|
||||
On linux you can set up router advertisements as follows:
|
||||
- First do 'ifconfig tap0 inet6 3ffe:0501:ffff:0100:0206:98ff:fe00:0231'
|
||||
or 'ip -6 address add 3ffe:0501:ffff:0100:0206:98ff:fe00:0231' dev tap0.
|
||||
- You might need to add a route 'ip -6 route add
|
||||
aaaa:0000:0000:0000:0206:98ff:fe00:0232/64 dev tap0'
|
||||
- Then configure a global address by sending a router advertisement (RA)
|
||||
with a prefix option. You can use radvd for example to generate such a
|
||||
packet.
|
||||
Note: You should set the preferred and valid lifetime to reasonable
|
||||
value to avoid clock wrap-around. E.g.:
|
||||
AdvPreferredLifetime 400;
|
||||
AdvValidLifetime 600;
|
||||
Assume the prefix in the RA is:
|
||||
3ffe:0501:ffff:0100:0000:0000:0000:0000/64.
|
||||
and that the resulting address created by the contiki stack is:
|
||||
3ffe:0501:ffff:0100:0206:98ff:fe00:0232
|
||||
- Finally you can use 'wget http://[3ffe:0501:ffff:0100:0206:98ff:fe00:0232]'
|
||||
to get the web page (index.html file)
|
||||
|
||||
See the wiki page for more details -
|
||||
http://www.sics.se/contiki/wiki/index.php/Setting_up_Wireshark_on_a_Loopback_Interface
|
||||
|
||||
The default webserver and content is in /apps/webserver/...
|
||||
Change that using e.g.
|
||||
$make clean
|
||||
$make WITH_WEBSERVER=webserver-nano
|
||||
$make TARGET=redbee-econotag WITH_WEBSERVER=webserver-nano
|
||||
$make TARGET=avr-raven WITH_WEBSERVER=raven-webserver
|
||||
|
||||
******** Make clean before switching make options! **********
|
69
examples/webserver-ipv6/README.md
Normal file
69
examples/webserver-ipv6/README.md
Normal file
@ -0,0 +1,69 @@
|
||||
This example features a simple webserver running on top of the IPv6 contiki
|
||||
stack.
|
||||
|
||||
For this example to run properly the UIP_CONF_TCP compilation flag must be set
|
||||
to 1 in the contiki-conf.h file of the platform.
|
||||
|
||||
By default contiki ipv6 nodes are configured with the low-power RPL protocol
|
||||
and direct outgoing packets through the RPL parent to a mesh border router.
|
||||
Access to the webserver thus requires at least one other node to as the RPL
|
||||
root. The Makefile changes the default to no RPL for the minimal-net target.
|
||||
Override the RPL choice with
|
||||
|
||||
make TARGET=minimal-net UIP_CONF_RPL=1
|
||||
make TARGET=any-other UIP_CONF_RPL=0
|
||||
|
||||
The RPL mesh border router can be configured with this webserver using the
|
||||
/examples/ipv6/rpl-border-router/ example.
|
||||
|
||||
If you are using the minimal-net platform without RPL you can access the
|
||||
webserver through the link local address by appending the interface descriptor
|
||||
shown at launch, e.g.
|
||||
|
||||
wget http://[fe80::296:98ff:fe00:0232%tap0] (linux)
|
||||
ping http://[fe80::206:98ff:fe00:0202%nnnn] (Windows)
|
||||
|
||||
The lower 64 bits are derived from the ethernet EUI-48 "mac address" in uip6.c:
|
||||
|
||||
uip_lladdr_t uip_lladdr = {{0x00,0x06,0x98,0x00,0x02,0x32}};
|
||||
|
||||
The ipv6 prefix can be hard-coded in the build or assigned through a
|
||||
host router advertisement. If hard-coded just assign the prefix to the
|
||||
interface:
|
||||
|
||||
sudo ip -6 address add fdfd::1/64 dev tap0 (linux)
|
||||
netsh commands or the interface GUI (Windows)
|
||||
|
||||
On linux you can set up router advertisements as follows:
|
||||
|
||||
ifconfig tap0 inet6 3ffe:0501:ffff:0100:0206:98ff:fe00:0231
|
||||
ip -6 address add 3ffe:0501:ffff:0100:0206:98ff:fe00:0231 dev tap0
|
||||
|
||||
- You might need to add a route:
|
||||
|
||||
ip -6 route add aaaa:0000:0000:0000:0206:98ff:fe00:0232/64 dev tap0
|
||||
|
||||
- Then configure a global address by sending a router advertisement (RA) with a
|
||||
prefix option. You can use radvd for example to generate such a packet.
|
||||
Note: You should set the preferred and valid lifetime to reasonable value to
|
||||
avoid clock wrap-around. E.g.:
|
||||
|
||||
AdvPreferredLifetime 400;
|
||||
AdvValidLifetime 600;
|
||||
|
||||
Assume the prefix in the RA is: 3ffe:0501:ffff:0100:0000:0000:0000:0000/64.
|
||||
and that the resulting address created by the contiki stack is:
|
||||
3ffe:0501:ffff:0100:0206:98ff:fe00:0232
|
||||
- Finally you can use:
|
||||
|
||||
wget http://[3ffe:0501:ffff:0100:0206:98ff:fe00:0232]
|
||||
|
||||
The default webserver and content is in /apps/webserver/...
|
||||
Change that using e.g.
|
||||
|
||||
make clean
|
||||
make WITH_WEBSERVER=webserver-nano
|
||||
make TARGET=redbee-econotag WITH_WEBSERVER=webserver-nano
|
||||
make TARGET=avr-raven WITH_WEBSERVER=raven-webserver
|
||||
|
||||
*Beware: Make clean before switching make options!*
|
@ -1,16 +1,21 @@
|
||||
This example features a simple webserver running on top of the IPv6
|
||||
contiki stack on Zolertia Z1 motes to provide sensor values, and with
|
||||
a RPL border router to bridge the sensor network to Internet.
|
||||
Z1 websense
|
||||
===========
|
||||
|
||||
This example features a simple webserver running on top of the IPv6 contiki
|
||||
stack on Zolertia Z1 motes to provide sensor values, and with a RPL border
|
||||
router to bridge the sensor network to Internet.
|
||||
|
||||
|
||||
To test the example in COOJA under Linux
|
||||
----------------------------------------
|
||||
|
||||
1. Start COOJA and load the simulation "example-z1-websense.csc"
|
||||
> make TARGET=cooja example-z1-websense.csc
|
||||
|
||||
make TARGET=cooja example-z1-websense.csc
|
||||
|
||||
2. Connect to the COOJA simulation using tunslip6:
|
||||
> make connect-router-cooja
|
||||
|
||||
make connect-router-cooja
|
||||
|
||||
3. You should now be able to browse to the nodes using your web browser:
|
||||
Router: http://[aaaa::0212:7401:0001:0101]/
|
||||
@ -21,13 +26,16 @@ To run the example on real nodes under Linux
|
||||
--------------------------------------------
|
||||
|
||||
1. Program the nodes with the websense application
|
||||
> make TARGET=z1 z1-websense.upload
|
||||
|
||||
make TARGET=z1 z1-websense.upload
|
||||
|
||||
2. Disconnect the nodes and program one node with the RPL border router
|
||||
> (cd ../rpl-border-router && make TARGET=z1 border-router.upload)
|
||||
|
||||
cd ../rpl-border-router && make TARGET=z1 border-router.upload
|
||||
|
||||
3. Connect to the border router using tunslip6:
|
||||
> make connect-router
|
||||
|
||||
make connect-router
|
||||
|
||||
4. Reboot the router and note the router IP address
|
||||
|
@ -1,23 +1,22 @@
|
||||
Apple II
|
||||
========
|
||||
|
||||
The platform/apple2enh/ directory is used for targeting an Enhanced Apple //e
|
||||
(or compatible) computer. Most things are shared between the 6502-based targets
|
||||
so please consult cpu/6502/README for further details.
|
||||
|
||||
|
||||
The following Apple II Ethernet cards are supported:
|
||||
|
||||
- Uthernet: Use driver cs8900a.eth with address $C0x0 (x = 8 + slot number).
|
||||
- LANceGS: Use driver lan91c96.eth with address $C0x0 (x = 8 + slot number).
|
||||
|
||||
|
||||
In most cases it is desirable to use an emulator for the development and testing
|
||||
of a Contiki application. AppleWin is especially well suited as it emulates the
|
||||
Uthernet card in slot 3. It is available at http://applewin.berlios.de/.
|
||||
|
||||
|
||||
The 'disk' make goal requires AppleCommander 1.3.5 or later. It is available at
|
||||
http://applecommander.sourceforge.net/.
|
||||
|
||||
|
||||
The apple2enh target supports a PFS that requires much less RAM than the POSIX
|
||||
file system. However this benefit comes with the following restrictions:
|
||||
|
@ -1,3 +1,6 @@
|
||||
Atari
|
||||
=====
|
||||
|
||||
The platform/atari/ directory is used for targeting an Atari 8-bit computer.
|
||||
Most things are shared between the 6502-based targets so please consult
|
||||
cpu/6502/README for further details.
|
||||
@ -7,7 +10,6 @@ The following Atari 8-bit Ethernet card is supported:
|
||||
|
||||
- Atari 8-bit Ethernet Project: Use driver cs8900a.eth with address $D500.
|
||||
|
||||
|
||||
The 'disk' make goal requires HiassofT's dir2atr program. It is available at
|
||||
http://www.horus.com/~hias/atari/ - either as source code (being part of the
|
||||
'AtariSIO driver and utilities for Linux') or as Win32 binary program (being
|
@ -1,7 +1,9 @@
|
||||
Commodore 128
|
||||
=============
|
||||
|
||||
The platform/c128/ directory is used for targeting a Commodore 128 computer.
|
||||
Most things are shared between the 6502-based targets so please consult
|
||||
cpu/6502/README for further details.
|
||||
|
||||
cpu/6502/README.md for further details.
|
||||
|
||||
The following C64 Ethernet cards are supported:
|
||||
|
||||
@ -9,11 +11,10 @@ The following C64 Ethernet cards are supported:
|
||||
- TFE: Use driver cs8900a.eth with address $DE00.
|
||||
- ETH64: Use driver lan91c96.eth with address $DE00.
|
||||
|
||||
In most cases it is desirable to use an emulator for the development and
|
||||
testing of a Contiki application. VICE is especially well suited as it emulates
|
||||
both the RR-Net and TFE Ethernet cards. It is available at
|
||||
[http://www.viceteam.org](http://www.viceteam.org).
|
||||
|
||||
In most cases it is desirable to use an emulator for the development and testing
|
||||
of a Contiki application. VICE is especially well suited as it emulates both the
|
||||
RR-Net and TFE Ethernet cards. It is available at http://www.viceteam.org/.
|
||||
|
||||
|
||||
The c128 target supports a PFS that requires less RAM than the POSIX file system
|
||||
and converts UNIX path names to CMD syntax for CMD drives.
|
||||
The c128 target supports a PFS that requires less RAM than the POSIX file
|
||||
system and converts UNIX path names to CMD syntax for CMD drives.
|
@ -1,3 +1,6 @@
|
||||
Commodore 64
|
||||
============
|
||||
|
||||
The platform/c64/ directory is used for targeting a Commodore 64 computer.
|
||||
Most things are shared between the 6502-based targets so please consult
|
||||
cpu/6502/README for further details.
|
@ -1,29 +1,36 @@
|
||||
Win32
|
||||
=====
|
||||
|
||||
The platform/win32/ directory contains a showcase of Contiki 1.x technologies
|
||||
ported to the Contiki 2.x environment. As such it serves primarily two purposes:
|
||||
ported to the Contiki 2.x environment. As such it serves primarily two
|
||||
purposes:
|
||||
|
||||
- Allow for easy interactive experience of the Contiki applications with user
|
||||
interface, especially the Contiki web browser.
|
||||
- Allow for easy regression tests of the code in core/ctk/ and most of the code
|
||||
in apps/.
|
||||
|
||||
The employed Contiki 1.x technologies include:
|
||||
|
||||
- The 'Contiki Tool Kit' (CTK) UI framework in general
|
||||
- CTK running in a character based environment (here the Win32 Console API)
|
||||
- CTK mouse support
|
||||
- Dynamic loading and unloading of Contiki programs (.PRG) and Contiki program
|
||||
descriptions (.DSC) based on dynamically loadable libraries (here Win32 DLLs)
|
||||
|
||||
A typical Contiki 1.x implementation consists of a core binary (containing among
|
||||
others the uIP and CTK libraries) and the program (and program description)
|
||||
binaries which are both loaded by the core and reference the core libraries.
|
||||
Therefore the Contiki 2.x project-based build system doesn't suit exactly. So
|
||||
in order to be able to leverage the Contiki 2.x build system to its maximum
|
||||
extend two makefiles are necessary:
|
||||
A typical Contiki 1.x implementation consists of a core binary (containing
|
||||
among others the uIP and CTK libraries) and the program (and program
|
||||
description) binaries which are both loaded by the core and reference the core
|
||||
libraries. Therefore the Contiki 2.x project-based build system doesn't suit
|
||||
exactly. So in order to be able to leverage the Contiki 2.x build system to its
|
||||
maximum extend two makefiles are necessary:
|
||||
|
||||
- Makefile plays the role of a Contiki 2.x project Makefile
|
||||
- Makefile.win32 is an ordinary (yet complex) Contiki 2.x Makefile.$(TARGET)
|
||||
|
||||
As platform/win32/Makefile.win32 includes cpu/native/Makefile.native the WinPcap
|
||||
library is used for network I/O. Please consult cpu/native/net/README-WPCAP for
|
||||
further details.
|
||||
As platform/win32/Makefile.win32 includes cpu/native/Makefile.native the
|
||||
WinPcap library is used for network I/O. Please consult
|
||||
cpu/native/net/README-WPCAP for further details.
|
||||
|
||||
Both a Cygwin Bash Shell and an ordinary Windows Command Prompt are fine for
|
||||
runtime. But in order to experience the CTK mouse support it is necessary to
|
||||
@ -33,4 +40,4 @@ Windows system menu under 'Properties'.
|
||||
As the console is used for displaying the actual user interface the log output
|
||||
is routed to the debug output. DebugView is a very lean program for displaying
|
||||
the debug output in case no debugger is active and does so. It is available at
|
||||
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx.
|
||||
[http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx](http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx).
|
@ -1,6 +1,10 @@
|
||||
Win32 - VC
|
||||
==========
|
||||
|
||||
The 'win32' target allows projects to be built using two different toolchains:
|
||||
|
||||
1. GCC / Cygwin
|
||||
GCC / Cygwin
|
||||
------------
|
||||
|
||||
Start your build from a Cygwin Shell and set TARGET=win32 to use this toolchain.
|
||||
The result will be similiar to the 'minimal-net' target. The advantage of 'win32'
|
||||
@ -8,11 +12,13 @@ over 'minimal-net' is the support for GUI applications using the Contiki Toolkit
|
||||
(CTK). For this reason several projects in the /examples directory are built in
|
||||
the target 'win32' by default.
|
||||
|
||||
2. VC++ / GnuWin
|
||||
VC++ / GnuWin
|
||||
-------------
|
||||
|
||||
Start your build from a VC++ Command Prompt and set TARGET=win32 to use this
|
||||
toolchain. You need however a few addional tools in your PATH:
|
||||
- cp.exe / rm.exe (http://gnuwin32.sourceforge.net/packages/coreutils.htm)
|
||||
- make.exe (http://gnuwin32.sourceforge.net/packages/make.htm)
|
||||
- sed.exe (http://gnuwin32.sourceforge.net/packages/sed.htm)
|
||||
- makedepend.exe (http://llg.cubic.org/docs/vc7.html)
|
||||
|
||||
- cp.exe / rm.exe [http://gnuwin32.sourceforge.net/packages/coreutils.htm](http://gnuwin32.sourceforge.net/packages/coreutils.htm)
|
||||
- make.exe [http://gnuwin32.sourceforge.net/packages/make.htm](http://gnuwin32.sourceforge.net/packages/make.htm)
|
||||
- sed.exe [http://gnuwin32.sourceforge.net/packages/sed.htm](http://gnuwin32.sourceforge.net/packages/sed.htm)
|
||||
- makedepend.exe [http://llg.cubic.org/docs/vc7.html](http://llg.cubic.org/docs/vc7.html)
|
@ -1,16 +1,18 @@
|
||||
se.sics.coffee is a library for the Coffee File System. It is able to
|
||||
generate file system images and to extract information from existing
|
||||
images.
|
||||
se.sics.coffee is a library for the Coffee File System. It is able to generate
|
||||
file system images and to extract information from existing images.
|
||||
|
||||
Building:
|
||||
---------
|
||||
|
||||
./build.sh
|
||||
./build.sh
|
||||
|
||||
Usage:
|
||||
------
|
||||
|
||||
java -jar coffee.jar [-p <platform>] [-i|e|r <file>] [-l|s] <file system image>
|
||||
java -jar coffee.jar [-p <platform>] [-i|e|r <file>] [-l|s] <file system image>
|
||||
|
||||
Options:
|
||||
--------
|
||||
|
||||
-p Selects the platform configuration of Coffee to use.
|
||||
Valid choices: sky (default), esb.
|
||||
@ -21,5 +23,6 @@ Options:
|
||||
-s Prints file system statistics.
|
||||
|
||||
Author:
|
||||
-------
|
||||
|
||||
Nicolas Tsiftes <nvt@sics.se>
|
@ -1,7 +0,0 @@
|
||||
MSPSim support for the COOJA Simulator
|
||||
--------------------------------------
|
||||
|
||||
MSPSim source code access:
|
||||
Standalone MSPSim is available from http://sourceforge.net/projects/mspsim.
|
||||
|
||||
-- Fredrik Österlind, 18/3 2008
|
7
tools/cooja/apps/mspsim/README.md
Normal file
7
tools/cooja/apps/mspsim/README.md
Normal file
@ -0,0 +1,7 @@
|
||||
MSPSim support for the COOJA Simulator
|
||||
--------------------------------------
|
||||
|
||||
MSPSim source code access: Standalone MSPSim is available from
|
||||
[http://sourceforge.net/projects/mspsim](http://sourceforge.net/projects/mspsim).
|
||||
|
||||
-- Fredrik Österlind, 18/3 2008
|
20
tools/cooja/examples/jni_test/README.md
Normal file
20
tools/cooja/examples/jni_test/README.md
Normal file
@ -0,0 +1,20 @@
|
||||
_The JNI tests have been replaced by the Cooja configuration wizard._
|
||||
|
||||
The JNI tests assisted in configuring Cooja for compiling and linking Java
|
||||
Native Interface (JNI) enabled Contiki libraries. Such Contiki libraries are
|
||||
used by Cooja's Contiki Motes: motes simulated at the operating system
|
||||
abstraction level.
|
||||
|
||||
The new configuration wizard is started from inside Cooja, and exercises the
|
||||
same functionality as the JNI tests. In contrast, the wizard is directly
|
||||
connected to the current Cooja configuration, removing the need to migrate the
|
||||
configuration between JNI tests and Cooja.
|
||||
|
||||
To start the wizard:
|
||||
|
||||
cd tools/cooja
|
||||
ant run # Start COOJA
|
||||
|
||||
Menu > Settings > Compiler configuration wizard
|
||||
|
||||
-- Fredrik Osterlind, fros@sics.se, March 2009
|
@ -1,18 +0,0 @@
|
||||
The JNI tests have been replaced by the Cooja configuration wizard.
|
||||
|
||||
The JNI tests assisted in configuring Cooja for compiling and linking
|
||||
Java Native Interface (JNI) enabled Contiki libraries. Such Contiki
|
||||
libraries are used by Cooja's Contiki Motes: motes simulated at the
|
||||
operating system abstraction level.
|
||||
|
||||
The new configuration wizard is started from inside Cooja, and exercises
|
||||
the same functionality as the JNI tests. In contrast, the wizard
|
||||
is directly connected to the current Cooja configuration, removing the
|
||||
need to migrate the configuration between JNI tests and Cooja.
|
||||
|
||||
To start the wizard:
|
||||
* Start COOJA:
|
||||
tools/cooja> ant run
|
||||
* Menu > Settings > Compiler configuration wizard
|
||||
|
||||
-- Fredrik Osterlind, fros@sics.se, March 2009
|
@ -1,13 +0,0 @@
|
||||
The tools/release-tools directory contains files for building and
|
||||
testing Contiki releases. To compile a release of Contiki, run
|
||||
|
||||
make RELEASE=2.3
|
||||
|
||||
for Contiki 2.3. It is also possible to compile a release of a
|
||||
specific CVS tag or other non-numbered version, such as the current
|
||||
CVS HEAD, like this:
|
||||
|
||||
make TAG=HEAD
|
||||
|
||||
The compile-examples and compile-platform directories are used for
|
||||
running nightly builds of the CVS version of Contiki.
|
15
tools/release-tools/README.md
Normal file
15
tools/release-tools/README.md
Normal file
@ -0,0 +1,15 @@
|
||||
Release tools
|
||||
=============
|
||||
|
||||
The tools/release-tools directory contains files for building and testing
|
||||
Contiki releases. To compile a release of Contiki, run
|
||||
|
||||
make RELEASE=2.6
|
||||
|
||||
for Contiki 2.6. It is also possible to compile a release of a specific git tag
|
||||
or other non-numbered version, such as the current git HEAD, like this:
|
||||
|
||||
make TAG=HEAD
|
||||
|
||||
The compile-examples and compile-platform directories are used for running
|
||||
nightly builds of the git version of Contiki.
|
@ -1,27 +1,31 @@
|
||||
Nano Programmer
|
||||
# Nano Programmer
|
||||
|
||||
Programming tool for the Sensinode Nano series using Dxxx development boards.
|
||||
|
||||
Copyright 2007-2008 Sensinode Ltd.
|
||||
|
||||
1a - Installation (Linux)
|
||||
## Installation
|
||||
|
||||
### Linux
|
||||
|
||||
No external libraries required.
|
||||
|
||||
1b - Installation (Windows/Cygwin)
|
||||
### Windows/Cygwin
|
||||
|
||||
Installation procedure:
|
||||
See the nano_usb_programmer README file on how to install FTDI library
|
||||
for nano_usb_programmer. The nano_programmer build system will fetch
|
||||
the library from there.
|
||||
|
||||
2 - Usage
|
||||
## Usage
|
||||
|
||||
Usage info for the Nano Programmer is available with command
|
||||
./nano_programmer --help. Note that use might require root/administrator privileges
|
||||
|
||||
./nano_programmer --help
|
||||
|
||||
Note that use might require root/administrator privileges
|
||||
depending on system configuration.
|
||||
|
||||
3 - Known problems
|
||||
## Known problems
|
||||
|
||||
Occasional timing failures resulting in "Reinit failed."-messages do come
|
||||
up in some PC configurations. If you experience programming failures (the programmer
|
||||
@ -29,6 +33,6 @@ is not able to recover), please report your system configuration to Sensinode.
|
||||
On Linux, it is known that the "brltty" program causes problems with the FTDI
|
||||
serial driver. Uninstalling brltty resolves the problem.
|
||||
|
||||
4 - README Version
|
||||
## Version
|
||||
|
||||
v1.3 2008-01-31 Martti Huttunen Multi-platform build and created instructions
|
||||
v1.3 2008-01-31 Martti Huttunen Multi-platform build and created instructions
|
@ -1,56 +0,0 @@
|
||||
Nano USB Programmer
|
||||
|
||||
An USB programmer for the Sensinode NanoRouter N600.
|
||||
|
||||
Copyright 2007-2008 Sensinode Ltd.
|
||||
|
||||
1a - Installation (Linux)
|
||||
|
||||
The installation is quite simple but requires the user to obtain the FTDI
|
||||
development library. The installation also requires root privileges in
|
||||
some phases (the ldconfig command to be more specific). Running the
|
||||
Nano_USB_Programmer executable might also require root privileges.
|
||||
|
||||
-unpack the Nano_USB_Programmer-v[xxx].zip to a directory
|
||||
-get the FTDI development library from
|
||||
|
||||
http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx0.4.13.tar.gz
|
||||
|
||||
-unpack the ftdi archive
|
||||
-copy the library static_lib/libftd2xx.a.[version] into /usr/lib
|
||||
-copy the library libftd2xx.so.[version] into /usr/lib
|
||||
-make a symbolic link to the library, for example:
|
||||
ln -s /usr/lib/libftd2xx.so.0.4.13 /usr/lib/libftd2xx.so
|
||||
-run ldconfig
|
||||
-copy the header files (*.h) into the nano_usb_programmer/ftdi_linux/ directory
|
||||
-go to the programmer directory and run make
|
||||
|
||||
1b - Installation (Windows/Cygwin)
|
||||
Installation procedure:
|
||||
-The FTDI library can be downloaded at:
|
||||
|
||||
http://www.ftdichip.com/Drivers/CDM/CDM%202.02.04%20WHQL%20Certified.zip
|
||||
|
||||
-Copy header files (ftd2xx.h), ftd2xx.lib and ftd2xx.dll to nano_usb_programmer/ftdi_win32
|
||||
-Copy the ftd2xx.dll to your windows system32 directory
|
||||
|
||||
2 - Usage
|
||||
|
||||
Usage info for the Nano_USB_Programmer is available with command
|
||||
./nano_usb_programmer --help. Note that use might require root/administrator privileges
|
||||
depending on system configuration.
|
||||
|
||||
3 - Known problems (Linux)
|
||||
|
||||
There's one known problem at the moment. The N600 must be unplugged and
|
||||
plugged in again after it has been programmed or the MAC address has been
|
||||
read from it before it can respond to the programmer again. The reason for
|
||||
this is the FTDI library is not perfectly integrated with the Linux
|
||||
serial driver.
|
||||
|
||||
4 - README Version
|
||||
|
||||
v1.0 2007-11-14 Mikko Saarnivala Initial release
|
||||
v1.1 2007-11-15 Mikko Saarnivala A small error in the instructions fixed
|
||||
v1.2 2007-11-19 Mikko Saarnivala Added the FTDI CBUS2 value handling
|
||||
v1.3 2008-01-31 Martti Huttunen Multi-platform build and updated instructions
|
60
tools/sensinode/nano_usb_programmer/README.md
Normal file
60
tools/sensinode/nano_usb_programmer/README.md
Normal file
@ -0,0 +1,60 @@
|
||||
Nano USB Programmer
|
||||
===================
|
||||
|
||||
An USB programmer for the Sensinode NanoRouter N600.
|
||||
|
||||
Copyright 2007-2008 Sensinode Ltd.
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
### Linux
|
||||
|
||||
The installation is quite simple but requires the user to obtain the FTDI
|
||||
development library. The installation also requires root privileges in some
|
||||
phases (the ldconfig command to be more specific). Running the
|
||||
Nano_USB_Programmer executable might also require root privileges.
|
||||
|
||||
- unpack the Nano_USB_Programmer-v[xxx].zip to a directory
|
||||
- get the FTDI development library from
|
||||
[http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx0.4.13.tar.gz](http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx0.4.13.tar.gz)
|
||||
- unpack the ftdi archive
|
||||
- copy the library static_lib/libftd2xx.a.[version] into /usr/lib
|
||||
- copy the library libftd2xx.so.[version] into /usr/lib
|
||||
- make a symbolic link to the library, for example: ln -s
|
||||
/usr/lib/libftd2xx.so.0.4.13 /usr/lib/libftd2xx.so
|
||||
- run ldconfig
|
||||
- copy the header files into the nano_usb_programmer/ftdi_linux/ directory
|
||||
- go to the programmer directory and run make
|
||||
|
||||
### Windows/Cygwin
|
||||
|
||||
- The FTDI library can be downloaded at:
|
||||
|
||||
[http://www.ftdichip.com/Drivers/CDM/CDM%202.02.04%20WHQL%20Certified.zip](http://www.ftdichip.com/Drivers/CDM/CDM%202.02.04%20WHQL%20Certified.zip)
|
||||
|
||||
- Copy header files (ftd2xx.h), ftd2xx.lib and ftd2xx.dll to nano_usb_programmer/ftdi_win32
|
||||
- Copy the ftd2xx.dll to your windows system32 directory
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
Usage info for the Nano_USB_Programmer is available with command
|
||||
./nano_usb_programmer --help. Note that use might require root/administrator
|
||||
privileges depending on system configuration.
|
||||
|
||||
Known problems (Linux)
|
||||
----------------------
|
||||
|
||||
There's one known problem at the moment. The N600 must be unplugged and plugged
|
||||
in again after it has been programmed or the MAC address has been read from it
|
||||
before it can respond to the programmer again. The reason for this is the FTDI
|
||||
library is not perfectly integrated with the Linux serial driver.
|
||||
|
||||
README Version
|
||||
--------------
|
||||
|
||||
v1.0 2007-11-14 Mikko Saarnivala Initial release
|
||||
v1.1 2007-11-15 Mikko Saarnivala A small error in the instructions fixed
|
||||
v1.2 2007-11-19 Mikko Saarnivala Added the FTDI CBUS2 value handling
|
||||
v1.3 2008-01-31 Martti Huttunen Multi-platform build and updated instructions
|
@ -1,26 +0,0 @@
|
||||
STM32W Flasher 2.0.0b2 for Linux
|
||||
|
||||
A programmer for development boards based on STM32W108 microcontroller.
|
||||
It works with the following boards (with FT232R or STM32F103 as USB-serial converter):
|
||||
MB850, MB851, MB950, MB951, MB954
|
||||
|
||||
|
||||
- Installation
|
||||
|
||||
Installation is not required.
|
||||
Hal package has to be present in your system.
|
||||
|
||||
|
||||
- Usage
|
||||
|
||||
Run the program with -h option for usage info.
|
||||
|
||||
|
||||
- Notes
|
||||
|
||||
This program may require root privileges when programming boards with
|
||||
FT232R chip.
|
||||
In Ubuntu, if you want to flash using Make, type 'sudo -s' before that.
|
||||
|
||||
This version of STM32W Flasher does not support jlink yet.
|
||||
|
26
tools/stm32w/stm32w_flasher/README.md
Normal file
26
tools/stm32w/stm32w_flasher/README.md
Normal file
@ -0,0 +1,26 @@
|
||||
STM32W Flasher 2.0.0b2 for Linux
|
||||
================================
|
||||
|
||||
A programmer for development boards based on STM32W108 microcontroller.
|
||||
It works with the following boards (with FT232R or STM32F103 as USB-serial converter):
|
||||
MB850, MB851, MB950, MB951, MB954
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
Installation is not required.
|
||||
Hal package has to be present in your system.
|
||||
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
Run the program with -h option for usage info.
|
||||
|
||||
|
||||
Notes
|
||||
-----
|
||||
|
||||
- This program may require root privileges when programming boards with FT232R chip.
|
||||
- In Ubuntu, if you want to flash using Make, type 'sudo -s' before that.
|
||||
- This version of STM32W Flasher does not support jlink yet.
|
@ -1,27 +0,0 @@
|
||||
See siscslow_ethernet.c for information about translation between
|
||||
802.15.4 and 802.3 addresses.
|
||||
Devices must have a proper EUI-64 address for this bridge to work.
|
||||
If the EUI-64 address of the devices cannot be changed and they are
|
||||
incompatible with the translation mechanism, you have to change the
|
||||
translation rules (they are defined in mac_createSicslowpanLongAddr()
|
||||
and mac_createEthernetAddr()).
|
||||
|
||||
Usage example:
|
||||
|
||||
run tapslip6 (source file are located in tools folder).
|
||||
|
||||
./tapslip6 -p 2001:db8:bbbb:abce::/64
|
||||
|
||||
where 2001:db8:bbbb:abce:: is the network address and 64 is the the
|
||||
prefix length. The remaining 64 bits will be derived from the EUI-64 (two
|
||||
middle bytes will be removed).
|
||||
|
||||
You can also simply create an edge router in one of the network nodes:
|
||||
you have to enable routing and set the appropriate forwarding rules, as
|
||||
shown in contiki-init-net.c. Then you have to add the corresponding
|
||||
rule on your machine, for example:
|
||||
route -A inet6 add 2001:db8:bbbb:abcd::/64 gw 2001:db8:bbbb:abce:
|
||||
280:e102::8a.
|
||||
|
||||
where 2001:db8:bbbb:abce:280:e102::6c is the address of the edge
|
||||
node and 2001:db8:bbbb:abcd::/64 is the lowpan address.
|
26
tools/stm32w/uip6_bridge/README.md
Normal file
26
tools/stm32w/uip6_bridge/README.md
Normal file
@ -0,0 +1,26 @@
|
||||
See siscslow_ethernet.c for information about translation between 802.15.4 and
|
||||
802.3 addresses. Devices must have a proper EUI-64 address for this bridge to
|
||||
work. If the EUI-64 address of the devices cannot be changed and they are
|
||||
incompatible with the translation mechanism, you have to change the translation
|
||||
rules (they are defined in mac_createSicslowpanLongAddr() and
|
||||
mac_createEthernetAddr()).
|
||||
|
||||
Usage example:
|
||||
|
||||
run tapslip6 (source file are located in tools folder).
|
||||
|
||||
./tapslip6 -p 2001:db8:bbbb:abce::/64
|
||||
|
||||
where 2001:db8:bbbb:abce:: is the network address and 64 is the the prefix
|
||||
length. The remaining 64 bits will be derived from the EUI-64 (two middle bytes
|
||||
will be removed).
|
||||
|
||||
You can also simply create an edge router in one of the network nodes: you have
|
||||
to enable routing and set the appropriate forwarding rules, as shown in
|
||||
contiki-init-net.c. Then you have to add the corresponding rule on your
|
||||
machine, for example:
|
||||
|
||||
route -A inet6 add 2001:db8:bbbb:abcd::/64 gw 2001:db8:bbbb:abce:280:e102::8a.
|
||||
|
||||
where 2001:db8:bbbb:abce:280:e102::6c is the address of the edge node and
|
||||
2001:db8:bbbb:abcd::/64 is the lowpan address.
|
22
tools/stm32w/wpcapslip6/README.md
Normal file
22
tools/stm32w/wpcapslip6/README.md
Normal file
@ -0,0 +1,22 @@
|
||||
wpcapslip6
|
||||
==========
|
||||
|
||||
This software needs a working network adapter. You can install a Microsoft
|
||||
Loopback adapter. (remeber to reboot after the installation procedure).
|
||||
|
||||
In order to install this kind of device in Windows 7, use devcon utility (you
|
||||
can download it from Microsoft website).
|
||||
|
||||
devcon.exe install %windir%\inf\netloop.inf *msloop
|
||||
|
||||
This utility can be used in conjunction with the uip6-bridge or the
|
||||
rpl-border-router (the latter on Windows Vista and later only).
|
||||
|
||||
An example of usage with the RPL border router:
|
||||
|
||||
wpcapslip6 -s COMXX -b aaaa:: -a aaaa:1::1/128 02-00-00-00-00-01
|
||||
|
||||
where 02-00-00-00-00-01 is the MAC address of the local network adapter.
|
||||
|
||||
-a aaaa:1::1/128 can be omitted if an IP address is already set to the network
|
||||
adapter.
|
@ -1,19 +0,0 @@
|
||||
This software needs a working network adapter. You can install a Microsoft Loopback adapter.
|
||||
(remeber to reboot after the installation procedure).
|
||||
|
||||
In order to install this kind of device in Windows 7, use
|
||||
devcon utility (you can download it from Microsoft website).
|
||||
|
||||
> devcon.exe install %windir%\inf\netloop.inf *msloop
|
||||
|
||||
|
||||
This utility can be used in conjunction with the uip6-bridge or the rpl-border-router
|
||||
(the latter on Windows Vista and later only).
|
||||
|
||||
|
||||
An example of usage with the RPL border router:
|
||||
wpcapslip6 -s COMXX -b aaaa:: -a aaaa:1::1/128 02-00-00-00-00-01
|
||||
|
||||
where 02-00-00-00-00-01 is the MAC address of the local network adapter.
|
||||
-a aaaa:1::1/128 can be omitted if an IP address is already set
|
||||
to the network adapter.
|
158
tools/z80/hex2bin/README.md
Normal file
158
tools/z80/hex2bin/README.md
Normal file
@ -0,0 +1,158 @@
|
||||
hexameter : Convert Intel hex files to a binary file
|
||||
====================================================
|
||||
|
||||
version 2.1.0 Copyright (c) 2003-2008, Takahide Matsutsuka.
|
||||
|
||||
What is it?
|
||||
-----------
|
||||
|
||||
It converts Intel hex files, which emitted by SDCC-Z80 compiler, to a binary
|
||||
file. You can attach additional prefix and/or suffix file to comply the file
|
||||
with arbitrary binary format. It provides a development environment of C
|
||||
language on PC-6001 and other old computers.
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
Installation can be done in the following steps.
|
||||
|
||||
1. Download and install SDCC from [http://sdcc.sf.net](http://sdcc.sf.net)
|
||||
Version 2.8.0 has been tested. SDCC is a cross-compiler for Z80 and other
|
||||
8bit CPUs. Extract an archive on your disk, say "c:/sdcc".
|
||||
|
||||
2. Place hexameter.exe and prefix/suffix files to any path-available directory.
|
||||
|
||||
Use
|
||||
---
|
||||
|
||||
1. Write your own C code.
|
||||
|
||||
2. Compile your code using SDCC. While linking, you need to specify options
|
||||
for SDCC so that the code can be worked on your machine. See
|
||||
sample/Makefile for actual usage.
|
||||
|
||||
sdcc -mz80 -c YOUR_CODE1.c
|
||||
sdcc -mz80 -c YOUR_CODE2.c
|
||||
|
||||
This step creates a file YOUR_CODE1.o and YOUR_CODE2.o respectively, which
|
||||
run on Z80-based machine.
|
||||
|
||||
for target in YOUR_CODE1.o YOUR_CODE2.o; do echo $@ >> YOUR_LIB.lib $@; done
|
||||
|
||||
This step makes a library file.
|
||||
|
||||
sdcc -mz80 --no-std-crt0 --code-loc 0x840f --data-loc 0 -o YOUR_APP.ihx crt0.o -lYOUR_LIB.lib
|
||||
|
||||
- -mz80 specifies the Z80 mode.
|
||||
- --code-loc specifies the start address of your object code. Basically, it
|
||||
depends on the machine and RAM size. As for PC-6001, 0x840f for 32kB, or
|
||||
0xc40f for 16kB. As for PC-6001mkII, it would be 0x800f. If you are not
|
||||
sure what you are about to do, just leave it as default 0x840f.
|
||||
- --data-loc 0 specifies the code is followed by data. You can specify an
|
||||
arbitrary address instead.
|
||||
- --no-std-crt0 indicates that you use your own crt0 instead of sdcc's
|
||||
default crt0 object. The customized crt0.o file is in lib directory of
|
||||
this release.
|
||||
|
||||
3. Convert ihx file to cas file using hexameter
|
||||
|
||||
hexameter <ihx_file|binary_file> [ihx_file|binary_file ...]
|
||||
|
||||
The ihx files are just attached in the specified order.
|
||||
|
||||
Here you can take some options:
|
||||
-o <filename> specify output file name
|
||||
-d <name>=<value> define ihx-specific value replacement
|
||||
-v verbose output
|
||||
-b <size> size of the output file in hexadecimal bytes.
|
||||
only if the size of the output is less than the size
|
||||
specified, the trailing bytes will filled by zeroes.
|
||||
note that it doesn't mean the size of output is
|
||||
restricted by the given size.
|
||||
-h displays simple usage
|
||||
|
||||
You can find various predefined library file in "lib" directory.
|
||||
Each of them may take its own optional value, which you can specify
|
||||
with -d option.
|
||||
|
||||
4. Example
|
||||
|
||||
The following is a typical example to convert from ihx files to
|
||||
PC-6001 loadable cassette format.
|
||||
|
||||
hexameter -v TAPE=myfile mode2.ihx mycode2.ihx -o myapp.p6
|
||||
|
||||
Note that TAPE value is defined in mode2.ihx, defines cassette file name.
|
||||
|
||||
5. Load your cas file into your 6001 emulator.
|
||||
|
||||
I've checked it working on the following emulators:
|
||||
|
||||
[iP6Win](http://www.retropc.net/mm/pc6001)
|
||||
|
||||
IHX extentions
|
||||
--------------
|
||||
|
||||
To support run-time user specified values in ihx files, Hexameter supports
|
||||
extended ihx files. Examples are located in ihx directory.
|
||||
|
||||
For example, mode2.ihx has the following line.
|
||||
|
||||
:06000a02TAPE
|
||||
|
||||
As in normal ihx format, the first 9 characters conform to the following
|
||||
format:
|
||||
|
||||
:AABBBBCC
|
||||
AA bytes encoded in this line
|
||||
BBBB start address of this line
|
||||
CC type of this line
|
||||
|
||||
The normal ihx file, which sdcc emits, has the type 00 (data) and 01 (end of
|
||||
file). In addition to this, Hexameter supports the following types.
|
||||
|
||||
02 string
|
||||
03 byte
|
||||
04 word (encoded in little endian)
|
||||
|
||||
The rest of line defines a name of the definition. In the example above, the
|
||||
name TAPE is assigned to this line. You can use latin alphabets, numbers, and
|
||||
underscore for the name. Letters are case-sensitive.
|
||||
|
||||
When you run Hexameter, you can specify a value for this definition like:
|
||||
|
||||
hexameter -d TAPE=xxxx
|
||||
|
||||
Since this example defines 06 in the bytes field, TAPE can have up to six
|
||||
characters. This string will override the memory location 000a specified in
|
||||
the second field.
|
||||
|
||||
For type 03 (byte) and 04 (word), bytes field has no effect.
|
||||
|
||||
|
||||
Note
|
||||
----
|
||||
|
||||
- Cygwin dependency has been removed.
|
||||
- SDCC has many isuues regarding compilation. Don't blame me about them! :)
|
||||
|
||||
History
|
||||
-------
|
||||
|
||||
03/29/2003 1.0.0 First version
|
||||
04/20/2003 1.0.1 Mode option has been added
|
||||
09/01/2007 1.1.0 ROM-mode has been added
|
||||
09/28/2007 1.2.0 Customized crt0 has been introduced to clear global data
|
||||
03/15/2008 1.3.0 VRAM options introduced
|
||||
04/28/2008 1.4.0 Header file option introduced
|
||||
|
||||
05/17/2008 2.0.0 Migrated to hexameter, to support more flexible configurations
|
||||
07/16/2008 2.1.0 Support arguments in ihx file, remove prefix/suffix instead
|
||||
07/18/2008 2.1.1 Cygwin dependency has been removed
|
||||
10/02/2008 2.1.2 Template for sdos 1.1 has been added
|
||||
12/14/2009 2.1.3 A minor bug in Linux environment has been fixed
|
||||
|
||||
Enjoy!
|
||||
|
||||
[http://www.markn.org](http://www.markn.org)
|
||||
<markn@markn.org>
|
@ -1,163 +0,0 @@
|
||||
hexameter : Convert Intel hex files to a binary file
|
||||
version 2.1.0
|
||||
Copyright (c) 2003-2008, Takahide Matsutsuka.
|
||||
|
||||
1/ What is it?
|
||||
|
||||
It converts Intel hex files, which emitted by SDCC-Z80 compiler, to
|
||||
a binary file. You can attach additional prefix and/or suffix file
|
||||
to comply the file with arbitrary binary format.
|
||||
It provides a development environment of C language on PC-6001 and
|
||||
other old computers.
|
||||
|
||||
|
||||
2/ Installation
|
||||
|
||||
Installation can be done in the following steps.
|
||||
|
||||
a) Download and install SDCC from http://sdcc.sf.net/
|
||||
Version 2.8.0 has been tested.
|
||||
SDCC is a cross-compiler for Z80 and other 8bit CPUs.
|
||||
Extract an archive on your disk, say "c:/sdcc".
|
||||
|
||||
b) Place hexameter.exe and prefix/suffix files to any path-available
|
||||
directory.
|
||||
|
||||
|
||||
3/ Use
|
||||
|
||||
a) Write your own C code.
|
||||
|
||||
b) Compile your code using SDCC.
|
||||
While linking, you need to specify options for SDCC so that the
|
||||
code can be worked on your machine.
|
||||
See sample/Makefile for actual usage.
|
||||
|
||||
% sdcc -mz80 -c YOUR_CODE1.c
|
||||
% sdcc -mz80 -c YOUR_CODE2.c
|
||||
|
||||
This step creates a file YOUR_CODE1.o and YOUR_CODE2.o respectively,
|
||||
which run on Z80-based machine.
|
||||
|
||||
% for target in YOUR_CODE1.o YOUR_CODE2.o; do echo $@ >> YOUR_LIB.lib $@; done
|
||||
|
||||
This step makes a library file.
|
||||
|
||||
sdcc -mz80 --no-std-crt0 --code-loc 0x840f --data-loc 0 -o YOUR_APP.ihx crt0.o -lYOUR_LIB.lib
|
||||
|
||||
-mz80 specifies the Z80 mode.
|
||||
--code-loc specifies the start address of your object code.
|
||||
Basically, it depends on the machine and RAM size. As for PC-6001,
|
||||
0x840f for 32kB, or 0xc40f for 16kB. As for PC-6001mkII, it would
|
||||
be 0x800f.
|
||||
If you are not sure what you are about to do, just leave it as
|
||||
default 0x840f.
|
||||
--data-loc 0 specifies the code is followed by data.
|
||||
You can specify an arbitrary address instead.
|
||||
--no-std-crt0 indicates that you use your own crt0 instead of sdcc's
|
||||
default crt0 object. The customized crt0.o file is in lib directory
|
||||
of this release.
|
||||
|
||||
c) Convert ihx file to cas file using hexameter
|
||||
|
||||
hexameter <ihx_file|binary_file> [ihx_file|binary_file ...]
|
||||
The ihx files are just attached in the specified order.
|
||||
|
||||
Here you can take some options:
|
||||
-o <filename> specify output file name
|
||||
-d <name>=<value> define ihx-specific value replacement
|
||||
-v verbose output
|
||||
-b <size> size of the output file in hexadecimal bytes.
|
||||
only if the size of the output is less than the size
|
||||
specified, the trailing bytes will filled by zeroes.
|
||||
note that it doesn't mean the size of output is
|
||||
restricted by the given size.
|
||||
-h displays simple usage
|
||||
|
||||
You can find various predefined library file in "lib" directory.
|
||||
Each of them may take its own optional value, which you can specify
|
||||
with -d option.
|
||||
|
||||
d) Example
|
||||
|
||||
The following is a typical example to convert from ihx files to
|
||||
PC-6001 loadable cassette format.
|
||||
% hexameter -v TAPE=myfile mode2.ihx mycode2.ihx -o myapp.p6
|
||||
Note that TAPE value is defined in mode2.ihx, defines cassette file name.
|
||||
|
||||
e) Load your cas file into your 6001 emulator.
|
||||
|
||||
I've checked it working on the following emulators:
|
||||
|
||||
VirtualTrek
|
||||
http://www.geocities.com/emucompboy/
|
||||
iP6Win
|
||||
http://www.retropc.net/mm/pc6001/
|
||||
PC-6001VW
|
||||
http://bernie.hp.infoseek.co.jp/develop/pc6001vw.html
|
||||
|
||||
|
||||
4/ IHX extentions
|
||||
|
||||
To support run-time user specified values in ihx files, Hexameter supports
|
||||
extended ihx files. Examples are located in ihx directory.
|
||||
|
||||
For example, mode2.ihx has the following line.
|
||||
|
||||
:06000a02TAPE
|
||||
|
||||
As in normal ihx format, the first 9 characters conform to the following
|
||||
format:
|
||||
|
||||
:AABBBBCC
|
||||
AA bytes encoded in this line
|
||||
BBBB start address of this line
|
||||
CC type of this line
|
||||
|
||||
The normal ihx file, which sdcc emits, has the type 00 (data) and 01 (end of
|
||||
file). In addition to this, Hexameter supports the following types.
|
||||
|
||||
02 string
|
||||
03 byte
|
||||
04 word (encoded in little endian)
|
||||
|
||||
The rest of line defines a name of the definition. In the example above,
|
||||
the name TAPE is assigned to this line. You can use latin alphabets,
|
||||
numbers, and underscore (_) for the name. Letters are case-sensitive.
|
||||
|
||||
When you run Hexameter, you can specify a value for this definition like:
|
||||
hexameter -d TAPE=xxxx
|
||||
|
||||
Since this example defines 06 in the bytes field, TAPE can have up to
|
||||
six characters. This string will override the memory location 000a
|
||||
specified in the second field.
|
||||
|
||||
For type 03 (byte) and 04 (word), bytes field has no effect.
|
||||
|
||||
|
||||
5/ Note
|
||||
|
||||
- Cygwin dependency has been removed.
|
||||
|
||||
- SDCC has many isuues regarding compilation. Don't blame me about them! :)
|
||||
|
||||
|
||||
6/ History
|
||||
|
||||
03/29/2003 1.0.0 First version
|
||||
04/20/2003 1.0.1 Mode option has been added
|
||||
09/01/2007 1.1.0 ROM-mode has been added
|
||||
09/28/2007 1.2.0 Customized crt0 has been introduced to clear global data
|
||||
03/15/2008 1.3.0 VRAM options introduced
|
||||
04/28/2008 1.4.0 Header file option introduced
|
||||
|
||||
05/17/2008 2.0.0 Migrated to hexameter, to support more flexible configurations
|
||||
07/16/2008 2.1.0 Support arguments in ihx file, remove prefix/suffix instead
|
||||
07/18/2008 2.1.1 Cygwin dependency has been removed
|
||||
10/02/2008 2.1.2 Template for sdos 1.1 has been added
|
||||
12/14/2009 2.1.3 A minor bug in Linux environment has been fixed
|
||||
|
||||
Enjoy!
|
||||
|
||||
http://www.markn.org/
|
||||
markn@markn.org
|
Loading…
Reference in New Issue
Block a user