% avrora -help all
Avrora [Beta 1.6.0] - (c) 2003-2005 UCLA Compilers Group
Usage: avrora [-action=action] [options]
Usage: avrora -help [category]
Avrora provides help in many categories that are all accessible from the
ALL HELP CATEGORIES
Below is a listing of all the help categories available.
Help for Avrora actions.
The "analyze-stack" option invokes the built-in stack analysis
tool on the specified program. It uses an abstract
interpretation of the program to determine the possible
interrupt masks at each program point and determines the
worst-case stack depth in the presence of interrupts.
The "atmel" input format reads programs that are written in
assembly language in the format supported by the Atmel
assembler. Nearly all of the directives are supported, except
The "auto" input format reads a program from a single file at
a time. It uses the extension of the filename as a clue to
decide what input reader to use for that file. For example, an
extension of ".asm" is considered to be a program in Atmel
The "calls" monitor tracks the call/return behavior of the
program as it executes, displaying the stacking up of function
calls and interrupt handlers.
The "cfg" action builds and displays a control flow graph of
the given input program. This is useful for better program
understanding and for optimizations. The graph can be
outputted in a textual format, or the format supported by the
"dot" graph tool.
The "dbbc" action tests the operation of the Dynamic Basic
Block Compiler (DBBC) in Avrora, which dynamically compiles
AVR code to Java source code.
The "energy" is a monitor to trace energy consumption.
The "energy-log" monitor traces energy consumption and logs it
for each node to a file named energy$NODE.log
The "energy profile" monitor tracks the power consumption of
procedures and displays a report at the end of execution.
The "gas" input format reads programs that are written in GAS
format assembly language. A subset of the directives and
syntax is supported. No linking functionality is currently
implemented; all symbol references must be defined in one
The "gdb" monitor implements the GNU Debugger (gdb) remote
serial protocol. The server will create a server socket which
GDB can connect to in order to send commands to Avrora. This
allows gdb to be used as a front end for debugging a program
running inside of Avrora.
The "gui" action launches a GUI allowing the user to
interactively create simulations, complete with graphical
Help for the supported program input formats.
The "interactive" monitor allows the user to interact with the
program asit executes, including placing breakpoints,
watchpoints, and inspecting the stateof the simulation.
Currently, it only supports terminating the simulation at
The interrupt monitor tracks changes to the state of
interrupts, including posting, enabling, and invoking of
This "ioregs" monitor tracks the updates to IO registers on
the microcontroller, including IO registers corresponding to
devices such as the timer, UART, SPI, etc.
The "isdl" action invokes the instruction set description
language (ISDL) processing tool, which is used internally in
Avrora to describe the AVR instruction set and generate the
interpreter and disassembler.
This action invokes the inter-procedural side-effect analysis
The "memory" monitor collects information about the memory
usage statistics of the program, including the number of reads
and writes to every byte of data memory.
Help for the supported simulation monitors.
The "objdump" input format reads programs that are the output
of the "avr-objdump" utility provided with avr-binutils. For
example, an ELF file must first be disassembled with
"avr-objdump -zhD" to create a text file readable by this
input format. The "-zhD" options are very important: the
output will not be parseable otherwise.
The "odpp" input format reads programs that are the output of
the "avr-objdump" utility provided with avr-binutils and that
have been preprocessed with Avrora's preprocessor utility.
The "packet" monitor tracks packets sent and received by nodes
in a sensor network.
The "profile" monitor profiles the execution history of every
instruction in the program and generates a textual report of
the execution frequency for all instructions.
The "real-time" monitor slows down the simulation so that it
runs as close as possible to real-time.
The sensor network simulation is used for simulating multiple
sensor nodes simultaneously. These nodes can communicate with
each other wirelessly to exchange packets that include sensor
data and routing information for a multi-hop network.
Currently, only the "mica2" platform sensor nodes are
The "serial" monitor allows the serial port (UART) of a node
in the simulation to be connected to a socket so that data
from the program running in the simulation can be outputted,
and external data can be fed into the serial port of the
The "simperf" monitor profiles the performance of the
simulator itself by periodically recording the cycles executed
and total time consumed by simulation and generates a report.
The "simulate" action creates a simulation with the specified
program(s) for the specified node(s). The simulation type
might be as simple as a single node with a single program, or
a multiple-node sensor network simulation or robotics
Help for supported simulation types.
The "single" simulation type corresponds to a standard
simulation of a single microcontroller with a single program.
The "sleep" is a monitor that tracks statistics about the
sleeping patterns of programs, including the total number of
cycles awake and the total number of cycles asleep during the
The "stack" monitor tracks the height of the stack while the
program executes, reporting the maximum stack height seen.
The "test" action invokes the internal automated testing
framework that runs test cases supplied at the command line.
The test cases are used in regressions for diagnosing bugs.
The "trace" monitor traces the execution of the entire program
by printing every instruction as it executes.
The "trip-time" monitor records profiling information about
the program that consists of the time it takes (on average) to
reach one point from another point in the program.
For more information, see the online documentation at
To report bugs or seek help, consult the Avrora mailing list:
Please include the version number [Beta 1.6.0] when posting to the list.