Firmware 2008

[guerra]

Henning and I have been working hard in order to release the firmware of robots as soon as possible. Unfortunately it has taken longer than we desired but finally the day of the first release of some code has come.

Today I uploaded to the CVS repository in SourceForge a first working version of the firmware sources for the 2008 robots. To download the sources use the following commands:

Code:

cvs -d:pserver:anonymous@pv-league.cvs.sourceforge.net:/cvsroot/pv-league login
cvs -z3 -d:pserver:anonymous@pv-league.cvs.sourceforge.net:/cvsroot/pv-league co -P firmware2008

This will download a folder with the name firmware2008/ to your system. This folder has two subfolders:

• arm-at91sam7x256: the sources for the ARM firmware
• avr-attiny84: the sources for the AVR firmware

For those that want to improve the ARM firmware it might be interesting to start by reading the file arm-at91sam7x256/README. For those that do not want to bother compiling the firmware or simply do not have the time I am providing binaries attached to this post. The ARM binary files provided are described below:

• listener.bin: The ordinary command listening behavior.
• listener-withdebug.bin: Same as above but printing verbose debug output via serial port (if attached to the programmer board)
• serial-to-irda.bin: This firmware is for use attached to the programmer board. It receives commands from the serial port and forward these commands via irda.

The AVR firmware is compiled and uploaded by running the following commands:

make
make fuse
make load

If you do not want to compile the firmware you can use the binary file provided attached here as well. You need to have at least avrdude installed and an Atmel ISP programmer. Notice that you always need to set the fuses of the AVR by running "make fuse", even if you download the firmware binary.

A video showing how to program the firmwares in the controller is provided here. In the video we did not have to type "make fuse" because the fuse were already programmed before, but you always have to set the fuses the first time you program the controller board.

For using the firmware serial-to-irda.bin you need to have the controller board attached to the programmer and connect a serial cable (usb-to-serial cable also works). You can connect to the controller using the following command:

Code:

screen /dev/ttyUSB0 115200

Substituting /dev/ttyUSB0 with the appropriate device that points to your serial cable. Then you can type commands directly into the controller and once you press enter these commands are sent via infrared. Then you can put in front of this board a robot running the firmware listener.bin or another programmer board with a controller attached running the firmware listener-withdebug.bin (the later can also connect to the same computer via another serial cable).

Here is a list of valid commands that you can use to test if the robots are listening and executing commands correctly:

Code:

fw,14
stop
lst,(fw,14),(slps,01),stop
sid,00,(fw,14)
sid,00,(chsid,01)
sid,00,stop
sid,01,stop
lp,03,(lst,(fw,14),(slps,01),stop,(slps,01))

[Henning]

hi,

Some little notations for the AVR:

If you "make load" the makefile tries to compile the firmware again. Just use this command to flash:

Code:

sudo avrdude -p t84 -c avrispmkII -P usb -U flash:w:main_avr.hex -v

also the fuse command has  to be done as root: "Sudo make fuse".
Remember to set the ARM in "reset" on the Programmer, otherwise you get an error from avrdude.

As mentioned the makefile is prepared for the atmel ISP programmer. In fact, avrdude supports a lot more of programmers.

dasa3    = serial port banging, reset=!dtr sck=rts mosi=txd miso=cts [/etc/avrdude.conf:770]
  dasa     = serial port banging, reset=rts sck=dtr mosi=txd miso=cts [/etc/avrdude.conf:757]
  siprog   = Lancos SI-Prog <http://www.lancos.com/siprogsch.html> [/etc/avrdude.conf:744]
  ponyser  = design ponyprog serial, reset=!txd sck=rts mosi=dtr miso=cts [/etc/avrdude.conf:731]
  frank-stk200 = Frank STK200                   [/etc/avrdude.conf:696]
  blaster  = Altera ByteBlaster             [/etc/avrdude.conf:683]
  ere-isp-avr = ERE ISP-AVR <http://www.ere.co.th/download/sch050713.pdf> [/etc/avrdude.conf:673]
  atisp    = AT-ISP V1.1 programming cable for AVR-SDK1 from <http://micro-research.co.th/>  [/etc/avrdude.conf:663]
  dapa     = Direct AVR Parallel Access cable [/etc/avrdude.conf:652]
  xil      = Xilinx JTAG cable              [/etc/avrdude.conf:639]
  futurlec = Futurlec.com programming cable. [/etc/avrdude.conf:622]
  abcmini  = ABCmini Board, aka Dick Smith HOTCHIP [/etc/avrdude.conf:612]
  picoweb  = Picoweb Programming Cable, http://www.picoweb.net/ [/etc/avrdude.conf:602]
  sp12     = Steve Bolt's Programmer        [/etc/avrdude.conf:591]
  alf      = Nightshade ALF-PgmAVR, http://nightshade.homeip.net/ [/etc/avrdude.conf:575]
  bascom   = Bascom SAMPLE programming cable [/etc/avrdude.conf:565]
  dt006    = Dontronics DT006               [/etc/avrdude.conf:555]
  pony-stk200 = Pony Prog STK200               [/etc/avrdude.conf:543]
  stk200   = STK200                         [/etc/avrdude.conf:527]
  bsd      = Brian Dean's Programmer, http://www.bsdhome.com/avrdude/ [/etc/avrdude.conf:516]
  pavr     = Jason Kyle's pAVR Serial Programmer [/etc/avrdude.conf:508]
  dragon_dw = Atmel AVR Dragon in debugWire mode [/etc/avrdude.conf:501]
  dragon_hvsp = Atmel AVR Dragon in HVSP mode  [/etc/avrdude.conf:493]
  dragon_pp = Atmel AVR Dragon in PP mode    [/etc/avrdude.conf:485]
  dragon_isp = Atmel AVR Dragon in ISP mode   [/etc/avrdude.conf:477]
  dragon_jtag = Atmel AVR Dragon in JTAG mode  [/etc/avrdude.conf:469]
  jtag2dw  = Atmel JTAG ICE mkII in debugWire mode [/etc/avrdude.conf:461]
  jtag2isp = Atmel JTAG ICE mkII in ISP mode [/etc/avrdude.conf:453]
  jtag2    = Atmel JTAG ICE mkII            [/etc/avrdude.conf:445]
  jtag2fast = Atmel JTAG ICE mkII            [/etc/avrdude.conf:437]
  jtag2slow = Atmel JTAG ICE mkII            [/etc/avrdude.conf:429]
  jtagmkII = Atmel JTAG ICE mkII            [/etc/avrdude.conf:421]
  jtag1slow = Atmel JTAG ICE (mkI)           [/etc/avrdude.conf:414]
  jtag1    = Atmel JTAG ICE (mkI)           [/etc/avrdude.conf:406]
  jtagmkI  = Atmel JTAG ICE (mkI)           [/etc/avrdude.conf:398]
  avr911   = Atmel AppNote AVR911 AVROSP    [/etc/avrdude.conf:392]
  avr109   = Atmel AppNote AVR109 Boot Loader [/etc/avrdude.conf:386]
  butterfly = Atmel Butterfly Development Board [/etc/avrdude.conf:380]
  usbasp   = USBasp, http://www.fischl.de/usbasp/ [/etc/avrdude.conf:374]
  avr910   = Atmel Low Cost Serial Programmer [/etc/avrdude.conf:368]
  stk500hvsp = Atmel STK500 V2 in high-voltage serial programming mode [/etc/avrdude.conf:362]
  stk500pp = Atmel STK500 V2 in parallel programming mode [/etc/avrdude.conf:356]
  stk500v2 = Atmel STK500 Version 2.x firmware [/etc/avrdude.conf:350]
  stk500v1 = Atmel STK500 Version 1.x firmware [/etc/avrdude.conf:344]
  stk500   = Atmel STK500                   [/etc/avrdude.conf:338]
  avrisp2  = Atmel AVR ISP mkII             [/etc/avrdude.conf:328]
  avrispmkII = Atmel AVR ISP mkII             [/etc/avrdude.conf:322]
  avrispv2 = Atmel AVR ISP V2               [/etc/avrdude.conf:316]
  avrisp   = Atmel AVR ISP                  [/etc/avrdude.conf:310]

You can change the flash commands to your needs.

If you like to change firmware, and want to compile you need following packets installed:

Code:

avrdude, avrdude-doc, binutils-avr, gcc-avr, avr-libc

In Ubuntu the avr-libc is missing the object file for our avr, the attiny84. In debian it is available. So what i did is
1. Download the source of avr-libc: http://packages.debian.org/source/sid/avr-libc
2 ./configure --build=`./config.guess` --host=avr
to create the makefile and steal the object file from:
3. sudo cp avr-libc-1.6.2.orig/avr/lib/avr25/attiny84/crttn84.o /usr/avr/lib

This should work for the AVR in ubuntu 7.10

Regards,

Henning

[guerra]

In the attachment a picture showing how I arranged a test setup for the robots, controllers and programmers.

Material needed:

• One robot body
• Two robot controller boards
• Two usb-to-serial cables (e.g. FTDI or PL2303)
• Two 5V AC/DC adapters
• One B-type USB cable (for ARM firmware uploading)

In one programmer I attached a controller board with the ARM firmware serial-to-irda.bin (left in the picture). In the other programmer I attached a controller board with the ARM firmware listener-withdebug.bin (right in the picture). In this second programmer I also placed a robot body in order to see the resulting actions in the wheels. Both controllers had the same AVR firmware.

I attached two usb-to-serial cable adapters to my laptop. Connected each cable to each programmer board. Then I used the command "dmesg" to find out the device names of the cables. Usually they are called something like /dev/ttyUSB0 or /dev/cu.usbserial-FTDGBGEW or /dev/cu.PL2303-003014FD or something similar. Then I opened two terminal windows, made sure both could be viewed at the same time and in each one I executed the command "screen /dev/ttyUSB0 115200" (addressing one different cable in each window). After that I connected the AC/DC adapters to the boards and then I could already see the first messages in the terminals.

I placed the programmers aligned in front of each other in such a way so that the IrDA modules where facing each other. The LED jumpers
should be disconnected in order not to cause any external light interference (as shown in the picture). Then I started typing commands in the terminal corresponding to the sender and looking for the debug responses in the terminal of the receiver. Notice that the two jumpers found near the bottom left corner of the controller spot should be put on in order to allow serial communications. If those jumpers are not on then serial communication cannot reach the cable.

Here is a copy of the commands list that is also found in the file README of the ARM firmware:

Code:

USING
-=-=-=-

The commands are sent to the robot following separate by commas. The format is
very simple. The easiest way to understand is by examples. See the examples
below.

If you desire to make the robot go forward with speed 10 then use the following
command:

Ex.1:
fw,0a

Notice that the number is passed in hexadecimal notation with small caps and it
should always be represented in exactly two bytes. The command in the example 1
above is a command that take one argument. Some commands take one argument, other
commands take several arguments, other commands take no argument.

A example of command that take no argument is this one:

Ex.2:
stop

The command in example 2 will stop the robot.

There are some special commands that take actions on other nested commands, and
the nested commands are passed as one argument by using parenthesis. See the
example below:

Ex.3:
lst,(fw,14),(slps,01),stop

The command in example 3 is one such special command. This command allows a list
of commands to be executed in sequence. The list of commands is passed as arguments.
In the example 3 there are three arguments, it brakes down like this:

Ex.3 brake down:
     Command: lst
1st Argument: fw,14
        2nd Argument: slps,01
        3rd Argument: stop

The command slps makes the robot controller halt for one second. The command makes
the robot go forward with velocity hexadecimal 14 (decimal 20) for one second and
then stop.

You can nest several levels, see below:

Ex.4:
lp,03,(lst,(fw,14),(slps,01),stop,(slps,01))

The command of example 4 is a loop command. The first argument tells how many times
to run the loop and the second argument is the command to be executed in the loop.
This last argument is also another nested list of commands. This command makes
the robot go forward for one second, stop for one second and repeat that 3 times.

All the examples above are commands that are broadcasted and executed by all robots.
In order to control the robots independently one can pass the address of the receiver
by specifying the id. There are two types of ids in the robots: (a) firmware id and
(b) software id. The firmware id is fixed in the flash memory as a constant in the
program and cannot change during runtime. The software id can be changed dynamically.
See the examples below:

Ex.5:
fid,00,(fw,14)
Ex.6:
sid,00,(fw,14)

The example 5 shows the usage of the firmware id, the example 6 shows the usage of
the software id. The first argument is the id of the recepient of the message and
the second argument is the command to be executed by this recepient.

For changing the software id of a specific robot see example below:

Ex.7:
sid,00,(chsid,01)

The above command changes the software id to 01 only in the robots that currently
have software id 00.

One can also send commands to several robots in one single message. See example
below:

Ex.8:
sbkt,(fw,14),stop,(sl,14),(bw,05)

The example 8 shows the software id bucket command. When this command is issued
all robots of id 00 will execute the first argument, robots with id 01 will execute
the second argument and so on. In the example above it brakes down like this:

Ex. 9 break down:
                command: sbkt
command to first robot: fw,14
command to second robot: stop
command to third robot: sl,14
command to fourth robot: bw,05

Equivalently one can use the firmware id bucket command like the one below:

Ex. 10:
fbkt,stop,(fl,1e),stop,stop

The command above will stop all robots exept for robot with firmware id 01
which will turn its left wheel with speed hexadecimal 1e (decimal 30).




 LIST OF COMMANDS
-=-=-=-=-=-=-=-=-=-

Below all commands currently implemented are listed in detail and their
arguments are enumerated. To implement more commands have a look into
the sources inside the folder "commands/".


Command: dbgu
-----------------------

Arguments: 1 or more

Behavior:
Sends the string of each argument through the serial port
This should be used when the controller is connected to the programmer
for debugging.

Example:
dbgu,hello,world


Commands: fl,bl,fr,br
-----------------------

Arguments: 1 hexadecimal number between 00 and 1e inclusive.

Behavior:
Sets the speed and the direction of rotation of a single wheel.
The "f" is for forward, "b" for backward, "l" for left and "r"
for right.

Example:
fl,14


Commands: fw,bw
-----------------------

Arguments: 1 hexadecimal number between 00 and 1e inclusive.

Behavior:
Sets the speed and the direction of rotation of both wheels.
The "fw" is for forward, "bw" for backward.

Example:
fw,14


Commands: sl,sr
-----------------------

Arguments: 1 hexadecimal number between 00 and 1e inclusive.

Behavior:
Makes the robot spin right "sr" or left "sl". Both wheels
have the same speed but oposite directions.

Example:
sl,14


Command: stop
-----------------------

Arguments: none

Behavior:
Makes the robot stop the wheels.

Example:
stop


Commands: slpms, slpcs, slpds, slps, slpi, slph
-----------------------------------------------

Arguments: 1 hexadecimal number between 00 and 1e inclusive.

Behavior:
Makes the robot halt for a period of time corresponding to
the argument value. The commands work in different scales
of time like below:
slpms : miliseconds (s/1000)
slpcs : centiseconds (s/100)
slpds : deciseconds (s/10)
slps : seconds (s)
slpm : minutes (s*60)
slph : hours (s*3600)

Example:
slps,01


Command: lst
-----------------------

Arguments: 1 or more

Behavior:
Execute each command in the arguments in sequence.

Example:
lst,(fw,14),(slps,01),stop


Command: lp
-----------------------

Arguments: 1 or more

Behavior:
The first argument tell how many times the second argument
should be executed. Can be used combined with lists and
other loops recursively.

Example:
lp,03,(lst,(fw,14),(slps,01),stop,(slps,01))



Commands: sid,fid
-----------------------

Arguments: 1

Behavior:
Only the robot that matches the id corresponding to the first
argument will execute the command given in the second argument.
The "sid" command tries to match software id and the "fid" tries
to match the firmware id.

Example:
sid,00,(fw,14)



Command: chsid
-----------------------

Arguments: 1

Behavior:
Changes the software id of the robot

Examples:
chsid,01
## Changes all robots to software id 01
sid,00,(chsid,01)
## Change robots with software id 00 to software id 01



Command: sbkt,fbkt
-----------------------

Arguments: 1

Behavior:
Each robot executes the command in his bucket, according to
its id. The command "fbkt" tries to distribute commands
according to firmware ids and "sbkt" according to software
ids.

Examples:
sbkt,stop,(fw,14)
## Robot with software id 00 run "stop", robot with
## software id 01 will execute "fw,14"