Comtrol eCos - Manual (Page 777)

Writing New Devices - host
...
if { < some condition > } {
synth::send_reply < error code > 0 ""
return
}
...
synth::send_reply < reply code > $packet_len $packet
}
...
}
The id argument is the same device id that was passed to the instantiate function, and is typically used as an array
index to access per-device data. The request , arg1 , arg2 , and max_rxlen are the same values that were passed
to synth_auxiliary_xchgmsg on the target-side, although since this is a Tcl script obviously the numbers have
been converted to strings. The txdata buffer is raw data as transmitted by the target, or an empty string if the I/O
operation does not involve any additional data. The Tcl procedures binary scan, string index and string range
may be found especially useful when manipulating this buffer.
txlen is provided for convenience, although string
length $txdata would give the same information.
The code for actually processing the request is of course device specific. If the target does not expect a reply
then the request handler should just return when finished. If a reply is expected then there should be a call to
synth::send_reply. The first argument is the reply code, and will be turned into a 32-bit integer on the target side.
The second argument specifies the length of the reply data, and the third argument is the reply data itself. For some
devices the Tcl procedure binary format may prove useful. If the reply involves just a code and no additional data,
the second and third arguments should be
0 and an empty string respectively.
Attempts to send a reply when none is expected, fail to send a reply when one is expected, or send a reply that is
larger than the target-side expects, will all be detected by the I/O auxiliary and result in run-time error messages.
It is not possible for the host-side code to send unsolicited messages to the target. If host-side code needs attention
from the target, for example because some I/O operation has completed, then an interrupt should be raised.
Interrupts
The I/O auxiliary provides a number of procedures for interrupt handling.
synth::interrupt_allocate < name >
synth::interrupt_get_max
synth::interrupt_get_devicename < vector >
synth::interrupt_raise < vector >
synth::interrupt_allocate is normally called during device instantiation, and returns the next free interrupt vector.
This can be passed on to the target-side device driver in response to a suitable request, and it can then install an
interrupt handler on that vector. Interrupt vector
0 is used within the target-side code for the real-time clock, so the
allocated vectors will start at 1 . The argument identifies the device, for example eth0 . This is not actually used
internally, but can be accessed by user-initialization scripts that provide some sort of interrupt monitoring facility
(typically via the
interrupt hook ). It is possible for a single device to allocate multiple interrupt vectors, but the
synthetic target supports a maximum of 32 such vectors.
synth::interrupt_get_max returns the highest interrupt vector that has been allocated, or 0 if there have been
no calls to synth::interrupt_allocate. synth::interrupt_get_devicename returns the string that was passed to
synth::interrupt_allocate when the vector was allocated.
673