10.07.2015 Views

CF2 API Reference (PDF) - Persistor Instruments Inc

CF2 API Reference (PDF) - Persistor Instruments Inc

CF2 API Reference (PDF) - Persistor Instruments Inc

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>CF2</strong> <strong>API</strong> <strong>Reference</strong>STDIO WarningThe ANSI C I/O libraries provided with the <strong>CF2</strong> are, for the most part, even higher level wrappers to thesedriver functions. However, in an effort of duplicate exactly the behavior of the ANSI stdio system, the stdiofunctions often provide software buffering and queues. While you should feel free to use and inter-mingleboth these driver level functions and stdio functions, it should be noted that due to the software bufferingused by the stdio library, the outcome of intermingling these two groups of functions can yield unexpectedresults. If you, as a developer, choose to use both libraries, you should be careful to flush the buffers of eachsubsystem (driver calls and stdio) before using the other. Not doing so will not cause any fatal problems, butcan cause confusion. For instance, if you were using the stdio printf function, and then immediately followed itwith a driver call that also output data to the serial port, it is likely that the data output by the driver callwould appear on the serial port before the data printed with stdio printf.Error CodesMany of the driver calls, particularly those which deal with fetching a byte from the receive portion of themain UART, return a short integer (16 bits) instead of a char (8 bits) as you might expect. The reason for thisis so that error information can be passed back with the character. The character fetched is always in theLSB(low 8 bits) of the short so that if it is automatically typecast into a char, your character will survive andonly the error codes will be lost. Similarly, if a char is passed to a function that expects a short for thepurpose of holding error codes in the MSB, there should not be any unexpected behavior. In the MSB (high 8bits) are error codes that are tested using the following masks:enum {RxD_OR_MASK = 0x8000 // Overrun Error Flag, RxD_NF_MASK = 0x4000 // Noise Error Flag, RxD_FE_MASK = 0x2000 // Framing Error Flag, RxD_PF_MASK = 0x1000 // Parity Error Flag, RxD_BOV_MASK = 0x0800 // Buffer Overflow Flag, RxD_TOSS_MASK = 0x0400 // Throw Away Flag (user sets), RxD_RPTF_MASK = 0x0200 // Repeat Filter Call Flag (user sets), RxD_ERR_MASK = 0xF800 // Any Error Flags, RxD_DATA9_MASK = 0x01FF // Receive Data, 9 Bits, RxD_DATA8_MASK = 0x00FF // Receive Data, 8 Bits, RxD_DATA7_MASK = 0x007F // Receive Data, 7 Bits (ASCII), RxD_NO_DATA = 0xFCFF // Return value for no data available};By AND'ing any of these masks with the short that is returned with a given function, the user's application candetermine what, if any, error occurred during the operation._cfx_sercomm.h contains the error code enumeration.PERSISTOR<strong>Instruments</strong> <strong>Inc</strong>.53 of 84<strong>CF2</strong> <strong>API</strong> <strong>Reference</strong>7/19/2005

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!