23
uint8 Get_Tx_Preamble_Len(uint8 rate)
This function returns the actual length of the transmit
Preamble that will be DMAed by the firmware when it is
transmitting a frame. The length of the preamble/SFD
is different for each PHY, and in certain implementa-
tions, different for each bit rate.
uint8 Get_Rx_PLCP_Header_Len()
This function returns the number of PLCP header bytes
that will be in received frames. This function is needed
by modules like PHY_Rx for its buffer management.
uint8 Get_Rx_Rate(uint8* PLCP_ptr)
This function is used to obtain the rate from the PLCP
header pointed to by PLCP_ptr. The encoding of the
rate information is different for each PHY. The return
values are ‘0’ for 1 Mbps and ‘1’ for 2 Mbps.
uint8 Get_Tx_PLCP_header_len(uint8 rate)
This function returns the length of the PLCP header in
bytes that must be transmitted for the particular PHY
and data rate. The rate parameter indicates the rate at
which the MAC portion of the frame will be transmitted
and is ‘0’ for 1 Mbps and ‘1’ for 2 Mbps.
uint8 Get_RSSI()
This function returns an RSSI value between 0 and 255,
sampled when this function is called. PHYs that do not
have an RSSI indicator shall return a value of zero. This
function is called by PHY_Rx when it receives the SFD
of a frame.
BOOLEAN Is_PLCP_Header_Good(uint8*
PLCP_ptr)
This function is called by the firmware when it wants to
verify that the PLCP Header pointed to by PLCP_ptr
has a good CRC16. This function returns zero if CRC
was bad and non-zero if CRC was good.
uint16 Get_Length(uint8* PLCP_ptr)
This function extracts and returns the length field from
the PLCP Header pointed to by PLPC_ptr.
Build_PLCP_Header(uint8* PLCP_start, uint16
length, uint8 rate)
This function is called by the firmware to build the PHY
specific PLCP Header in the buffer pointed to by
PLCP_start. The MPDU length and rate information.
uint8* Get_Tx_Preamble(uint8 rate)
This function returns a pointer to the buffer containing the
Preamble that is to be transmitted for each frame. Since
preambles may be different for different rates the rate
parameter is passed to the routine. ‘0’ implies 1 Mbps
and ‘1’ implies 2 Mbps. The Preamble buffer contains the
1-0-1-0 pattern as well as the SFD sequence and any
other special control bytes needed by the PHY. This buffer
must not be changed since the firmware does not copy
it to its own array but uses it in place.
Set_PHY_Rate(uint8 rate)
This function is called to allow the programming of any
PHY specific registers that may be required in order to
change the rate of the PHY. The rate parameter is ‘0’ for
1 Mbps and ‘1’ for 2 Mbps.
The function is called by the firmware when it pre-loads
the TX DMA FIFO with the rate specific preamble for the
next expected transmission.
User_Function()
This API function is called by the firmware once every
time around its main loop. Any function that the integra-
tor may need can be placed here. A byte in the Control
Block is reserved as a means for the driver to commu-
nicate with this function. Possible uses for this function
are, updating any LED’s, monitoring any PHY status
lines, etc.
Unsigned16 rel_time_to_
μ
sec_est()
This API function is called by the firmware in order to
get a quick conversion from the Am79C930 real time
clock to a value in microseconds. This operation is called
at time-critical points in the firmware and, therefore, the
API routine must have a short execution time. An
indexed jump into a small table with interpolations
thereafter would be one possible implementation that
could meet the execution-time criteria. The sample API
routine that is provided is sufficient for all implementa-
tions that use a 32.768kHz crystal. For any system
implementation in which any other value of crystal is
used, this routine needs to be modified to accommodate
the difference in crystal frequency.
Unsigned32 rel_time_to_
μ
sec()
This API function is called by the firmware in order to
get a much more accurate conversion from the
Am79C930 real time clock to a value in microseconds
than the rel_time_to_usec_est() function can provide.
This operation is called at points in the firmware when
execution time is not critical and, therefore, the API rou-
tine should include a much more sophisticated algo-
rithm giving a much more exact conversion. The sample
API routine that is provided is sufficient for all implemen-
tations that use a 32.768 kHz crystal. For any system
implementation in which any other value of crystal is
used, this routine needs to be modified to accommodate
the difference in crystal frequency.
Unsigned32
μ
sec_to_rel_time()
This routine converts a 32-bit number (max allowed val-
ue 8,000,000) in units of
μ
secs to 32768 Hz clock ticks.
The conversion is accurate to one tick. Partial ticks are
truncated since the error is not expected to accumulate.
This routine accomplishes the divide by 30.51
μ
sec by
first multiplying by 512 and dividing by 15625. (equiva-
lent to 32768/1000000). This operation s critical n time!
The sample API routine that is provided is sufficient for