TC65 JAVA User's Guide
Strictly confidential / Released
5.9.2
Pin 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.
external frequency
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.3
Data 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
input pin
poll input pin
send URC
set output pin
output pin
Page 30 of 90
s
Test MIDlet
ATCommandListener.
ATEvent()
ATCommand.
send(...)
26.09.2005