01.06.2013 Views

IPC@CHIP Documentation - SC12 @CHIP-RTOS V1.10

IPC@CHIP Documentation - SC12 @CHIP-RTOS V1.10

IPC@CHIP Documentation - SC12 @CHIP-RTOS V1.10

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>IPC<strong>@CHIP</strong></strong> <strong>Documentation</strong> Index<br />

FOSSIL<br />

Fossil API - <strong>SC12</strong> <strong>@CHIP</strong>-<strong>RTOS</strong> <strong>V1.10</strong><br />

Here is the API definition for access to the COM and EXT serial ports.<br />

The @Chip-<strong>RTOS</strong> offers the Fossil API for serial port communication. The Fossil standard uses software<br />

interrupt 0x14. These functions provide access to the @Chip-<strong>RTOS</strong> internal serial port driver for receiving and<br />

sending data via the serial ports.<br />

Here is a short description how the @Chip-<strong>RTOS</strong> internal serial port driver operates:<br />

Each serial port has two software buffers (queues), one for data pending transmission and one for storing<br />

received data bytes. The default size of each queue is 1024 bytes. The size of these transmit and receive<br />

queues are configurable via chip.ini entries.<br />

Transfers between these software queues and the serial port hardware are carried out by either Direct Memory<br />

Access (DMA) hardware or by hardware interrupt (IRQ) driven software. By default, the two available DMA<br />

machines are applied to the two serial port receivers. This configuration reduces the likelihood of character loss<br />

at the receiver. This leaves the two serial port transmitters operating with hardware interrupt (IRQ) driven<br />

software. Alternately, receivers can be configured for interrupt driven mode (IRQ receive mode) with the<br />

chip.ini options, which frees up the DMA device for other usage. The DMA can be applied to transmitters with<br />

the SERIAL SEND_DMA option.<br />

The serial port hardware issues a signal to either software (IRQ hardware interrupt) or to the DMA when ever the<br />

serial port transmit register is empty or a receiver byte is ready. This signal initiates the next byte transfer<br />

between the appropriate software queue and the hardware register, in or out. (This discussion is slightly over<br />

simplified. The driver actually uses an additional intermediate RAM buffer for DMA transfers.)<br />

Note that the serial port hardware send/receive buffers are only one byte deep. So interrupt driven receivers (as<br />

opposed to DMA driven) can easily lose characters, particularly at higher baud rates.<br />

The COM / EXT serial ports may also be referred to as a UART (abbreviation for "Universal Asynchronous<br />

Receiver/Transmitter").<br />

For some useful comments see Programming notes<br />

New in version 1.10B: Install a user callback function<br />

New in version 1.10B: Enable/Disable UART receiver<br />

New in version 1.10B: Enable/Disable UART transmitter<br />

● Interrupt_0x14_function_0x00:_Set baud rate<br />

● Interrupt_0x14_function_0x01:_Put byte in output buffer, wait if needed.<br />

● Interrupt_0x14_function_0x02:_Get a byte from the serial port, wait if none available.<br />

● Interrupt_0x14_function_0x03:_Status request<br />

Page 326 / 400

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

Saved successfully!

Ooh no, something went wrong!