deac
/
osd-contiki
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update to markdown 

- Spellchecking
- Update plain text to github markdown
ico
Rémy Léone 2013-03-26 13:09:49 +01:00
parent f8edbbb8d2
commit 7b40a568a6
73 changed files with 1826 additions and 1574 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
README-BUILDING
View File

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

92
README-BUILDING.markdown Normal file
View File

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

207
README-EXAMPLES
View File

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

220
README-EXAMPLES.markdown Normal file
View File

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

5
README → README.markdown
View File

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

5
apps/webserver-nano/httpd-fs/makefsdata.ignore/README.makefsdata
View File

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

7
apps/webserver-nano/httpd-fs/makefsdata.ignore/README.makefsdata.markdown Normal file
View File

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

74
cpu/6502/README
View File

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

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

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

74
cpu/mc1322x/README
View File

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

72
cpu/mc1322x/README.markdown Normal file
View File

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

39
cpu/mc1322x/README.subtree
View File

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

39
cpu/mc1322x/README.subtree.markdown Normal file
View File

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

7
cpu/mc1322x/doc/lqi-pdr/README
View File

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

6
cpu/mc1322x/doc/lqi-pdr/README.markdown Normal file
View File

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

23
cpu/native/net/README-WPCAP → cpu/native/net/README-WPCAP.markdown
View File

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

16
examples/cc2530dk/border-router/README
View File

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

20
examples/cc2530dk/border-router/README.markdown Normal file
View File

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

116
examples/er-rest-example/README
View File

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

165
examples/er-rest-example/README.markdown Normal file
View File

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

35
examples/hello-world/README
View File

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

45
examples/hello-world/README.markdown Normal file
View File

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

109
examples/ipv6/json-ws/README-COSM.markdown Normal file
View File

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

106
examples/ipv6/json-ws/README-COSM.txt
View File

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

29
examples/ipv6/sky-websense/README → examples/ipv6/sky-websense/README.markdown
View File

@ -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.

0
examples/mb851/mb851-websense/README → examples/mb851/mb851-websense/README.markdown
View File

47
examples/mb851/shell-exec/README.txt → examples/mb851/shell-exec/README.markdown
View File

@ -3,44 +3,47 @@ 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).
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.

9
examples/mb851/udp-ipv6-sleep/README → examples/mb851/udp-ipv6-sleep/README.markdown
View File

@ -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.

9
examples/mb851/webserver-ajax/README
View File

@ -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.markdown Normal file
View 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>

9
examples/new-ipv6/README → examples/new-ipv6/README.markdown
View File

@ -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

11
examples/ping-ipv6/README
View File

@ -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.markdown Normal file
View 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.

96
examples/rest-example/README
View File

@ -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.markdown Normal file
View 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

50
examples/sensinode/README
View File

@ -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.markdown Normal file
View 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)

16
examples/sensinode/border-router/README
View File

@ -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.markdown Normal file
View 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.

7
examples/sensinode/sniffer/README → examples/sensinode/sniffer/README.markdown
View File

@ -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.markdown Normal file
View 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.

46
examples/sky-shell-exec/README.txt
View File

@ -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.

21
examples/udp-stream/README
View File

@ -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.markdown Normal file
View 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

54
examples/webserver-ipv6-raven/README
View File

@ -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.markdown Normal file
View 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.

60
examples/webserver-ipv6/README
View File

@ -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.markdown Normal file
View 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!*

24
examples/z1/ipv6/z1-websense/README → examples/z1/ipv6/z1-websense/README.markdown
View File

@ -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

7
platform/apple2enh/README → platform/apple2enh/README.markdown
View File

@ -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:

4
platform/atari/README → platform/atari/README.markdown
View File

@ -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

19
platform/c128/README → platform/c128/README.markdown
View File

@ -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.markdown 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.

3
platform/c64/README → platform/c64/README.markdown
View File

@ -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.

29
platform/win32/README-1.X → platform/win32/README-1.X.markdown
View File

@ -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).

18
platform/win32/README-VC → platform/win32/README-VC.markdown
View File

@ -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)

13
tools/coffee-manager/README.TXT → tools/coffee-manager/README.markdown
View File

@ -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>

7
tools/cooja/apps/mspsim/README
View File

@ -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.markdown Normal file
View 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.markdown Normal file
View 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

18
tools/cooja/examples/jni_test/README.txt
View File

@ -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

13
tools/release-tools/README
View File

@ -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.markdown Normal file
View 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.

24
tools/sensinode/nano_programmer/README → tools/sensinode/nano_programmer/README.markdown
View File

@ -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
Usage info for the Nano Programmer is available with command
./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

56
tools/sensinode/nano_usb_programmer/README
View File

@ -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.markdown Normal file
View 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

26
tools/stm32w/stm32w_flasher/README
View File

@ -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.markdown Normal file
View 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.

27
tools/stm32w/uip6_bridge/README
View File

@ -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.markdown Normal file
View 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.markdown Normal file
View 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.

19
tools/stm32w/wpcapslip6/README.txt
View File

@ -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.markdown Normal file
View 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>

163
tools/z80/hex2bin/README.txt
View File

@ -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