will fail to compile.
<itemizedlist>
<listitem>
+<para>
AO_EXTI_MODE_PULL_UP. Apply a pull-up to the pin; a
disconnected pin will read as 1.
+</para>
</listitem>
<listitem>
+<para>
AO_EXTI_MODE_PULL_DOWN. Apply a pull-down to the pin;
a disconnected pin will read as 0.
+</para>
</listitem>
<listitem>
+<para>
0. Don't apply either a pull-up or pull-down. A
disconnected pin will read an undetermined value.
+</para>
</listitem>
</itemizedlist>
</para>
<title>__sfr, __sfr16, __sfr32, __sbit</title>
<para>
Access to physical registers in the device use this mode
- which declares the variable name, it's type and the
+ which declares the variable name, its type and the
address it lives at. No memory is allocated for these
variables.
</para>
ao_dma_abort(uint8_t id)
</programlisting>
<para>
- Terminate any in-progress DMA transation, marking its
+ Terminate any in-progress DMA transaction, marking its
'done' variable with the AO_DMA_ABORTED bit.
</para>
</section>
ao_dma_abort(uint8_t id)
</programlisting>
<para>
- Terminate any in-progress DMA transation, marking its
+ Terminate any in-progress DMA transaction, marking its
'done' variable with the AO_DMA_ABORTED bit.
</para>
</section>
<title>Stdio interface</title>
<para>
AltOS offers a stdio interface over USB, serial and the RF
- packet link. This provides for control of the device localy or
+ packet link. This provides for control of the device locally or
remotely. This is hooked up to the stdio functions by providing
the standard putchar/getchar/flush functions. These
automatically multiplex the available communication channels;
<para>
Flushes the current console device output buffer. Any
pending characters will be delivered to the target device.
- xo </para>
+ </para>
</section>
<section>
<title>ao_add_stdio</title>
variable with one of the following values:
<variablelist>
<varlistentry>
- <title>ao_cmd_success</title>
+ <term>ao_cmd_success</term>
<listitem>
<para>
The command was parsed successfully. There is no
</listitem>
</varlistentry>
<varlistentry>
- <title>ao_cmd_lex_error</title>
+ <term>ao_cmd_lex_error</term>
<listitem>
<para>
A token in the line was invalid, such as a number
</listitem>
</varlistentry>
<varlistentry>
- <title>ao_syntax_error</title>
+ <term>ao_syntax_error</term>
<listitem>
<para>
The command line is invalid for some reason other
</chapter>
<chapter>
<title>CC1111 Radio peripheral</title>
- <para>
- The CC1111 radio transceiver sends and receives digital packets
- with forward error correction and detection. The AltOS driver is
- fairly specific to the needs of the TeleMetrum and TeleDongle
- devices, using it for other tasks may require customization of
- the driver itself. There are three basic modes of operation:
- <orderedlist>
- <listitem>
- <para>
- Telemetry mode. In this mode, TeleMetrum transmits telemetry
- frames at a fixed rate. The frames are of fixed size. This
- is strictly a one-way communication from TeleMetrum to
- TeleDongle.
- </para>
- </listitem>
- <listitem>
- <para>
- Packet mode. In this mode, the radio is used to create a
- reliable duplex byte stream between TeleDongle and
- TeleMetrum. This is an asymmetrical protocol with
- TeleMetrum only transmitting in response to a packet sent
- from TeleDongle. Thus getting data from TeleMetrum to
- TeleDongle requires polling. The polling rate is adaptive,
- when no data has been received for a while, the rate slows
- down. The packets are checked at both ends and invalid
- data are ignored.
- </para>
- <para>
- On the TeleMetrum side, the packet link is hooked into the
- stdio mechanism, providing an alternate data path for the
- command processor. It is enabled when the unit boots up in
- 'idle' mode.
- </para>
- <para>
- On the TeleDongle side, the packet link is enabled with a
- command; data from the stdio package is forwarded over the
- packet link providing a connection from the USB command
- stream to the remote TeleMetrum device.
- </para>
- </listitem>
- <listitem>
- <para>
- Radio Direction Finding mode. In this mode, TeleMetrum
- constructs a special packet that sounds like an audio tone
- when received by a conventional narrow-band FM
- receiver. This is designed to provide a beacon to track
- the device when other location mechanisms fail.
- </para>
- </listitem>
- </orderedlist>
- </para>
+ <section>
+ <title>Radio Introduction</title>
+ <para>
+ The CC1111 radio transceiver sends and receives digital packets
+ with forward error correction and detection. The AltOS driver is
+ fairly specific to the needs of the TeleMetrum and TeleDongle
+ devices, using it for other tasks may require customization of
+ the driver itself. There are three basic modes of operation:
+ <orderedlist>
+ <listitem>
+ <para>
+ Telemetry mode. In this mode, TeleMetrum transmits telemetry
+ frames at a fixed rate. The frames are of fixed size. This
+ is strictly a one-way communication from TeleMetrum to
+ TeleDongle.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Packet mode. In this mode, the radio is used to create a
+ reliable duplex byte stream between TeleDongle and
+ TeleMetrum. This is an asymmetrical protocol with
+ TeleMetrum only transmitting in response to a packet sent
+ from TeleDongle. Thus getting data from TeleMetrum to
+ TeleDongle requires polling. The polling rate is adaptive,
+ when no data has been received for a while, the rate slows
+ down. The packets are checked at both ends and invalid
+ data are ignored.
+ </para>
+ <para>
+ On the TeleMetrum side, the packet link is hooked into the
+ stdio mechanism, providing an alternate data path for the
+ command processor. It is enabled when the unit boots up in
+ 'idle' mode.
+ </para>
+ <para>
+ On the TeleDongle side, the packet link is enabled with a
+ command; data from the stdio package is forwarded over the
+ packet link providing a connection from the USB command
+ stream to the remote TeleMetrum device.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Radio Direction Finding mode. In this mode, TeleMetrum
+ constructs a special packet that sounds like an audio tone
+ when received by a conventional narrow-band FM
+ receiver. This is designed to provide a beacon to track
+ the device when other location mechanisms fail.
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
+ </section>
<section>
<title>ao_radio_set_telemetry</title>
<programlisting>
the radio operation.
</para>
</section>
- <para>
- In telemetry mode, you can send or receive a telemetry
- packet. The data from receiving a packet also includes the RSSI
- and status values supplied by the receiver. These are added
- after the telemetry data.
- </para>
<section>
- <title>ao_radio_send</title>
+ <title>Radio Telemetry</title>
+ <para>
+ In telemetry mode, you can send or receive a telemetry
+ packet. The data from receiving a packet also includes the RSSI
+ and status values supplied by the receiver. These are added
+ after the telemetry data.
+ </para>
+ <section>
+ <title>ao_radio_send</title>
<programlisting>
void
ao_radio_send(__xdata struct ao_telemetry *telemetry);
sending, and ao_radio_put() afterwards, to correctly
serialize access to the radio device.
</para>
- </section>
- <section>
- <title>ao_radio_recv</title>
+ </section>
+ <section>
+ <title>ao_radio_recv</title>
<programlisting>
void
ao_radio_recv(__xdata struct ao_radio_recv *radio);
received, or zero if the operation was aborted (from some
other task calling ao_radio_abort()).
</para>
+ </section>
</section>
- <para>
- In radio direction finding mode, there's just one function to
- use
- </para>
<section>
- <title>ao_radio_rdf</title>
+ <title>Radio Direction Finding</title>
+ <para>
+ In radio direction finding mode, there's just one function to
+ use
+ </para>
+ <section>
+ <title>ao_radio_rdf</title>
<programlisting>
void
ao_radio_rdf(int ms);
This sends an RDF packet lasting for the specified amount
of time. The maximum length is 1020 ms.
</para>
+ </section>
</section>
- <para>
- Packet mode is asymmetrical and is configured at compile time
- for either master or slave mode (but not both). The basic I/O
- functions look the same at both ends, but the internals are
- different, along with the initialization steps.
- </para>
<section>
- <title>ao_packet_putchar</title>
+ <title>Radio Packet Mode</title>
+ <para>
+ Packet mode is asymmetrical and is configured at compile time
+ for either master or slave mode (but not both). The basic I/O
+ functions look the same at both ends, but the internals are
+ different, along with the initialization steps.
+ </para>
+ <section>
+ <title>ao_packet_putchar</title>
<programlisting>
void
ao_packet_putchar(char c);
slave side, any pending data will be sent the next time
the master polls for data.
</para>
- </section>
- <section>
- <title>ao_packet_pollchar</title>
+ </section>
+ <section>
+ <title>ao_packet_pollchar</title>
<programlisting>
char
ao_packet_pollchar(void);
otherwise returns AO_READ_AGAIN. On the master side, if
this empties the buffer, it triggers a poll for more data.
</para>
- </section>
- <section>
- <title>ao_packet_slave_start</title>
+ </section>
+ <section>
+ <title>ao_packet_slave_start</title>
<programlisting>
void
ao_packet_slave_start(void);
This is available only on the slave side and starts a task
to listen for packet data.
</para>
- </section>
- <section>
- <title>ao_packet_slave_stop</title>
+ </section>
+ <section>
+ <title>ao_packet_slave_stop</title>
<programlisting>
void
ao_packet_slave_stop(void);
<para>
Disables the packet slave task, stopping the radio receiver.
</para>
- </section>
- <section>
- <title>ao_packet_slave_init</title>
+ </section>
+ <section>
+ <title>ao_packet_slave_init</title>
<programlisting>
void
ao_packet_slave_init(void);
that when packet slave mode is enabled, characters will
get send and received through the stdio functions.
</para>
- </section>
- <section>
- <title>ao_packet_master_init</title>
+ </section>
+ <section>
+ <title>ao_packet_master_init</title>
<programlisting>
void
ao_packet_master_init(void);
<para>
Adds the 'p' packet forward command to start packet mode.
</para>
+ </section>
</section>
</chapter>
</book>