TC65 JAVA User's Guide | s |
Strictly confidential / Released |
|
5.9.2Pin I/O
The pin I/O test was designed to find out how fast a Java MIDlet can process URCs caused by Pin I/O and react to these URCs. The URCs are generated by feeding an input pin with an external frequency. As soon as the Java MIDlet is informed about the URC, it tries to regenerate the feeding frequency by toggling another output pin.
input pin |
| Test MIDlet | |
external frequency |
| ||
| ATCommandListener. | ||
poll input pin | send URC | ||
ATEvent() | |||
|
| ||
set output pin |
| ATCommand. | |
| send(...) | ||
|
| ||
output pin |
|
| |
generated frequency |
|
|
Figure 12: Test case for measuring Java MIDlet performance and handling pin-IO
The results of this test show that the delay from changing the state on the input pin to a state change on the output pin is at least around 50 ms, but that time strongly depends on the amount of garbage to collect and number of threads to be served by the virtual machine. Consequently, pin I/O is not suitable for generating or detecting frequencies.
5.9.3Data Rates on RS-232 API
For details about the software platform and interfaces refer to Chapter 4, "Software Platform". This section summarises limitations and preconditions for performance when using the interface CommConnection from package com.siemens.mp.io (refer to [5]).
The data rate on RS232 depends on the size of the buffer used for reading from and writing to the serial interface. It is recommended that method read (byte[ ] b) be used for reading from the serial interface. The recommended buffer size is 2kbyte. To achieve error free data transmission the flow control on CommConnection must be switched on: <autorts> and <autocts>, the same for the connected device.
Different use cases are listed to give an idea of the attainable data rates. All applications for measurement use only one thread and no additional activities other than those described were carried out in parallel.
TC65 JAVA User's Guide_V05 | Page 30 of 90 | 26.09.2005 |
