I/O From Hardware to int[]?

M

Matt Newcomb

G'day,

I've got a piece of hardware that writes 32 bit int's ( big endian )
into a direct ByteBuffer ( via a JNI call ). The data is organized
into frames 480 integers long. The code is running on a little endian
machine. I've been calling:

ByteBuffer inData;
nidaq.readData(inData)

inData.order(ByteOrder.littleEndian)
IntBuffer processData = inData.asIntBuffer()


Then calling buffer.get a bunch of times to copy one frame at a time
into an int[] for analysis.

I'm kind of new with java, and I wouldn't think you could do this with
a strongly typed language, but is there anyway to cast a byte[] to an
int[] to avoid all this copying of data? I'd like the extra
performance.

Thanks,

Matt
 
A

Anthony Borla

Matt Newcomb said:
G'day,

I've got a piece of hardware that writes 32 bit int's
( big endian ) into a direct ByteBuffer ( via a JNI call ).
The data is organized into frames 480 integers long.
The code is running on a little endian machine.
I've been calling:

ByteBuffer inData;
nidaq.readData(inData)

inData.order(ByteOrder.littleEndian)
IntBuffer processData = inData.asIntBuffer()

Then calling buffer.get a bunch of times to copy one
frame at a time into an int[] for analysis.

Use 'IntBuffer' instead of 'ByteBuffer'; look at 'ByteBuffer's'
'asIntBuffer' method. Also, why not read *all* data in in one operation ?
Much more efficient if you can do this.
I'm kind of new with java, and I wouldn't think you
could do this with a strongly typed language, but is
there anyway to cast a byte[] to an int[] to avoid all
this copying of data? I'd like the extra performance.

No, there isn't - strong language typing prevents it.

A Java array is an object, and either contains references to other objects
[i.e. like a C / C++ array of pointers], or manages access to a contiguous
chunk of storage for primitive values [much like a single dimension C / C++
array of primitives].

You'd think it *might* be possible to cast arrays of primitive types from
one type to another, however, as mentioned, the language does not allow it.

I hope this helps.

Anthony Borla
 
H

Harald Hein

Matt Newcomb said:
I'm kind of new with java, and I wouldn't think you could do this
with a strongly typed language, but is there anyway to cast a
byte[] to an int[] to avoid all this copying of data? I'd like
the extra performance.

Since you use JNI, why not change the JNI implementation to directly
deliver what you need in Java? If you want an IntBuffer, let the JNI
code build an IntBuffer.
 
C

Chris Smith

Matt said:
inData.order(ByteOrder.littleEndian)
IntBuffer processData = inData.asIntBuffer()
Then calling buffer.get a bunch of times to copy one frame at a time
into an int[] for analysis.

I'm kind of new with java, and I wouldn't think you could do this with
a strongly typed language, but is there anyway to cast a byte[] to an
int[] to avoid all this copying of data? I'd like the extra
performance.

Matt,

What makes you think there's any data being copied? I seriously doubt
that there is. Do you understand what's meant when the API docs for
"asIntBuffer" specify that the method returns a live IntBuffer "view" of
the ByteBuffer? That means that the buffer is not copied elsewhere; a
new interface is provided to exactly the same data.

So basically, I think you've already accomplished your goal, though you
didn't know it yet. You didn't "cast a byte[] to an int[]" (in fact,
you never had a byte[] in the first place), but you did manage to
achieve looking at bytes as ints without copying the data.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,432
Messages
2,571,682
Members
48,796
Latest member
Greg L.

Latest Threads

Top