The detector unit is based on the ATMEL at90s2313 microcontroller. It continually polls the output of the detector module and records if any of the output logic lines have been triggered. This detector also integrates extra buttons to interface with a host computer running a race management program.

Most of my avr gcc code uses an 'xrom' section which is defined after the .fini sections. Here's my linker definitions. To use the modified linker definitions, the 'T' linker option should be used: e.g. "-Td:/". The default linker scripts are in the ldscripts directory ("avr/lib/ldscripts" for me). Or, you can try using "avr-ld --verbose" which will dump the default internal linker scrip (or at least tell you where the default internal linker script is)t.

Additionally, you may find the gnu2msdev utility useful. It takes gnu warning and error messages and converts them into a form that the microsoft visual c++ ide can understand.

interface connections

downstream: control unit --> DB9 male --> (DB9 female --> ribbon cable --> IDC 2x5 female header) --> IDC 2x5 male header --> detector module

upstream: control unit --> DB9 female --> (standard DB9 extension cable) --> DB9 male --> communications hub

downstream to detector module

DB9 male

  1. +5V
  2. start trigger IN (active LOW)
  3. NC
  4. ready light (OUT)
  5. GND
  6. detector out 1 (IN)
  7. detector out 2 (IN)
  8. detector out 3 (IN)
  9. detector out 4 (IN)

upstream to communications hub

DB9 female

  1. +5V
  2. AT90s2313 pin 3 (TXD)
  3. AT90s2313 pin 2 (RXD)
  4. NC
  5. GND
  6. NC
  7. NC
  8. NC
  9. NC

theory of operation

The polling detector consists of the microcontroller and the associated i/o connections. The schematic may be found here.

Detector-in lines are all set to high impedance. These are meant to be connected to the logic outputs of the detector module.

Switch input lines are set to weakly pulled high, input. Because the microcontroller has internal pull-ups enabled on those lines, external pull-ups are not necessary. Switches are normally open, but when closed, pull the input pin to ground.

The trigger input is configured just like a local switch - activated when grounded. Depending on the length of the wire between the start trigger and the control unit, an external pull-up resistor (connected to the trigger input pin) may be necessary.

Serial data TXD and RXD are connected to the communications hub. These are RS232 lines, but at logic levels instead of standard RS232 levels. Note that the TXD line is inverted by the 2N3904 transistor so that it will idle high instead of low.

Output LEDs have power sourced through the microcontroller. The LEDs don't require much power so this is ok. LEDs are connected to external current limiting resistors.

The microcontroller's reset pin is connected to an external pull-up resistor. An optional switch that pulls the reset input to ground is used to reset the microcontroller. The optional switch is best implemented as an onboard header that can be momentarily shorted by a jumper, screwdriver, paper clip, etc..

The following is the command set that it understands: (all commands are sent from the controller host)

description command command data status reply status reply data comments

query positions P   p [p1][p2][p3][p4] Numerical positions starting from 1, or "-" if not triggered. No comma separator.
query time T n t time Request the time of lane n where n is from 1 to 4. Times returned in possibly zero-padded hexadecimal number of milliseconds, or "-" if not triggered.
If the start trigger is not used, times are relative to the first position.
set race ready LED L [0|1|b] l   Off (default), On, Blink
query flags F   f [S|s][C|c][R|r][N|n] Start, Commit, Reset, New selection. No comma separator.
Capital letters indicate flag set. Flags reset on query.
local reset r   r   Reset positions and timers (controller host can trigger the same function as the race reset button)
set address A alpha-numeric     Set the address of the control unit. This address will be written to the control unit's eeprom. Controller host does not expect a reply. When this command is executed, regardless of whether the address is valid or not, the control unit re-initializes. Addresses are [0..9][A..Z][a..z] only.
hard reset R       Global reset of the control unit. Controller host does not expect a reply. Implement as re-initialization of the control unit.


Commands are sent in the following format:

">"<address><command>[command data].

Address is the alpha-numeric address of the unit, Command is documented above. If the address is "!", all connected control units are addressed. Typically, the "!" should only be used to set the address to eeprom of a control unit if it is the only control unit on the bus.

All commands are preceded by the ">" character and terminated by the "." character. The controller should execute the command following receipt of the "." character.

Status replies are sent in the following format:

"<"<address><status reply>[status reply data].

All status replies are preceded by the "<" character. The status reply is completed on the transmission of the "." character.

The controller host must be prepared to receive any response from a control unit. The status reply may not necessarily correspond to the command sent.

The following is an example command / reply sequence



The pin-outs to the microcontroller:

signal group direction physical pin description

detector in in PB.0 polling from detector module logic outputs
  in PB.1  
  in PB.2  
  in PB.3  

buttons in PB.4 commit race
  in PB.5 reset race
  in PB.6 new selection
trigger in in PB.7 starts race timer (optional)

serial data in PD.0 serial data receive
  out PD.1 serial data transmit

output LEDs out PD.2 outputs race results
  out PD.3  
  out PD.4  
  out PD.5  

ready light out PD.6 ready to race

'detector in' pins are high impedance inputs. 'button' (and 'trigger in') pins are inputs with internal pull-up: connect button pin to ground to assert'. LED outputs source current so LEDs should be connected from the output pins to ground. Sourcing current at LED outputs shouldn't be a problem because the at90s2313, being a CMOS device, should be able to source and sink equally well - and each LED shouldn't doesn't take too much drive current anyway.

source code

This archive contains source code and a hex file ready to program into an ATMEL at90s2313. The entire archive is released under the GPL except for uart.c and uart.h which I do not hold the copyright to. uart.c and uart.h are included because I have modified them to cut down on the total compiled code size.

Configured parameters are: 8 MHz clock crystal; 19200 8n1, no flow control communications.

Note that this code has not been fully tested yet.

Source code has been provided for convenience only. It may not compile on your setup, but the hex file should run on any at90s2313.