Microchip Technology DV164139 数据表
Low Pin Count USB Development Kit User’s Guide
DS41356B-page 30
© 2009 Microchip Technology Inc.
Referring to the flowchart in Figure 2-6, the firmware located in the ProcessIO() first
checks if the previous RS-232 transmission has been sent via the USB using the
RS232_Out_Data_Rdy
checks if the previous RS-232 transmission has been sent via the USB using the
RS232_Out_Data_Rdy
flag. If this flag is cleared (indicating previous transmission
has been sent), firmware then checks if any new data has been sent from the RS-232
connection and is ready to be transmitted via the USB using the getsUSBUSART().
This function copies data into a buffer and returns the number of bytes the buffer con-
tains. The function ensures that only the expected numbers of bytes, in this case 64,
are actually copied into this buffer. Also, if there is no data available, the function
returns a zero value indicating no data is available. In this way the function does not
wait for data and is therefore, non-blocking, keeping in mind that all firmware must
conform to this multitasking environment.
connection and is ready to be transmitted via the USB using the getsUSBUSART().
This function copies data into a buffer and returns the number of bytes the buffer con-
tains. The function ensures that only the expected numbers of bytes, in this case 64,
are actually copied into this buffer. Also, if there is no data available, the function
returns a zero value indicating no data is available. In this way the function does not
wait for data and is therefore, non-blocking, keeping in mind that all firmware must
conform to this multitasking environment.
Following the RS-232 data check, the firmware then checks if the EUSART transmit
register, TXREG, is empty. This is accomplished using the mTxRdyUSART() macro,
which checks the TRMT bit in the TXSTA (Transmit Status Control) register in the
EUSART peripheral. If the TRMT bit is cleared, the TXREG is Full, and Empty if the
TRMT bit is set. Note that this bit is automatically set following a successful transmis-
sion from the TXREG. If set, the data collected into the buffer by the getsUSBUSART()
is then transferred into the TXREG one byte at a time each time through the main loop.
Again, such macros take care of the low-level RS-232 communication in a non-blocking
fashion so the user doesn’t have to. If the TXREG isn’t empty, then the previous data
has not been transmitted via the USB and should not be overwritten.
register, TXREG, is empty. This is accomplished using the mTxRdyUSART() macro,
which checks the TRMT bit in the TXSTA (Transmit Status Control) register in the
EUSART peripheral. If the TRMT bit is cleared, the TXREG is Full, and Empty if the
TRMT bit is set. Note that this bit is automatically set following a successful transmis-
sion from the TXREG. If set, the data collected into the buffer by the getsUSBUSART()
is then transferred into the TXREG one byte at a time each time through the main loop.
Again, such macros take care of the low-level RS-232 communication in a non-blocking
fashion so the user doesn’t have to. If the TXREG isn’t empty, then the previous data
has not been transmitted via the USB and should not be overwritten.
The firmware next checks to see if the CDC class device is ready to transmit data. This
is accomplished by using the mUSBUSARTIsTxrfReady() flag. The user must ensure
that this flag is set to ‘1’ before calling the putUSBUSART() function. As a safety pre-
caution, this function checks the state one more time to make sure it does not override
any pending transactions. This function writes data to the USB.
is accomplished by using the mUSBUSARTIsTxrfReady() flag. The user must ensure
that this flag is set to ‘1’ before calling the putUSBUSART() function. As a safety pre-
caution, this function checks the state one more time to make sure it does not override
any pending transactions. This function writes data to the USB.
The CDCTxSevice()
services the transfer of data to the host. This function keeps
track of a state machine and breaks up long strings of data into multiple USB data pack-
ets. It is called once each time through the main program loop. The state machine for
the CDCTxService() is shown in Figure 2-7 and the source code can be found in the
usb_function_cdc.c
ets. It is called once each time through the main program loop. The state machine for
the CDCTxService() is shown in Figure 2-7 and the source code can be found in the
usb_function_cdc.c
source file. The reader is encouraged to reference this
firmware and compare it against the state diagram at their leisure.