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

Top of list
Index page
3. Since @CHIP-RTOS 1.02B XON/XOFF mode is available also with the serial DMA receive mode
in use.
Please note: Because of the internal functionality of DMA it is not possible to immediately detect
an XON or XOFF character from the connected peer. It is possible that an overrun situation at
the peer (e.g. GSM modem) can occur. Nevertheless we enable this mode because some GSM
modems (any??) support only XON/XOFF as serial flow control mechanism.
4. The default serial receiver queue size is 1024 bytes. If the default DMA receive mode is used, it
is advised to increase the receiver queue size in Chip.ini up to a minimum value of 2048 bytes to
prevent a possible buffer overrun (even if hard handshake is used). This can only happen with
the default queue size of 1024 bytes if the user doesn't call the Fossil API read block function
frequently enough. If the application programmer does not increase this buffer size up to the
recommended value, they should call the Fossil API read block function with sufficient buffer
size in the CX-Register to flush the internal buffers and prevent a receive buffer overrun.
5. Serial ports, running with IRQ receive mode:
The two serial ports of the IPC@CHIP have no hardware FIFO buffer. Only one incoming
character can be stored direct by the ports. As a consequence of this behaviour, it is possible
that incoming characters get lost because of missed or delayed receiver interrupt execution (see
Operating mode of serial ports). E.g.: Writing a flash sector (e.g. happens when writing a file
at Drive A:) disables all interrupt execution for about 15 ms. If the serial port is configured with a
baud rate of 9600, incoming characters can be lost during this time.
Loss or delayed execution of serial receiver interrupts depends on the number and the execution
frequency of all enabled interrupts in the IPC@CHIP system. It depends also on execution times
of users interrupt service functions and the duration of interrupt masking periods (CLI / STI
instruction sequences).
6. For a given serial port the fossil functions are not reentrant. Do not call fossil functions for the
same serial port from different tasks. However for different serial ports, the fossil functions are
reentrant. E.g. task A can operate the COM port using fossil functions concurrently with task B
operating the EXT port using the same fossil functions.
Fossil API
Working with Float Data Types
1. The IPC@CHIP does not provide a floating point co-processor. So if you want to use floating
point data types you need to enable the math-emulation in your compiler. In Borland C++ 5.02
see the option "Emulation" under the Target Expert's (right mouse click on your Exe-file in your
project) "Math Support".
2. The Borland Math Emulation libraries are not made for usage in a multitasking system like the
@CHIP-RTOS. If you want to use float data types in tasks other than your main (DOS) task,
please pay attention to the following work around solution (Using Borland 5.02, Memory model
large):
a) For floating point emulator usage, the current stack (the stack of the task) must have offset 0.
To achieve this, the task stack must be far array located in a separate segment:
unsigned int far task_stack[TASK_STACKSIZE];
Note: The CGI callbacks execute on the Web server's stack, which satisifies this "offset 0
present" requirement.
Page 13 / 400