From: sleeper75se (sleeper75se_at_yahoo.se)
Date: 2002-02-04 23:24:06
Hi Doug and John,
don't get me wrong - I'd love to use Java, it's just that I
encountered some problems in my testing.
Suppose the signal processing is done in native code, and only the
user interface is written in Java.
Data is received over the serial port and cooked into samples, then
these samples are passed on to the native code for processing.
If the samples are represented as a vector of int-objects, you must
call the methods GetIntArrayElements() and ReleaseIntArrayElements()
at the beginning and end of the native method, like this (from Sun's
JNI-tutorial):
JNIEXPORT jint JNICALL
Java_IntArray_sumArray(JNIEnv *env, jobject obj, jintArray arr)
{
jsize len = (*env)->GetArrayLength(env, arr);
int i, sum = 0;
jint *body = (*env)->GetIntArrayElements(env, arr, 0);
for (i=0; i<len; i++) {
sum += body[i];
}
(*env)->ReleaseIntArrayElements(env, arr, body, 0);
return sum;
}
AFAIK, Java might have split the array/vector into several sections,
meaning that the Get/Release methods copies the data into a single
block.
As long as we're just working with the raw samples, that is ok, but
when we split the signal into multiple bands, perhaps 30 per channel,
we get a lot more data to copy... and performance will suffer.
Another problem that cropped up: how does one keep the garbage
collector from preempting the process? Most people using a normal
application won't notice, but a 100ms "hickup" now and then isn't
exactly "real-time".
Doug, since you're the Java guru here ;-), maybe you have some clever
solutions? Or am I seeing problems where there are none to be found?
Regards,
Andreas
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:38 BST