How can I speed up this code?

I am taking data from a NI USB-8451 daq, and I need to read from 8 different sensors. The maximum clock rate I can use with my current sensors is 800,000 khz. Right now, achieving 8 reads is taking anywhere from .008 to .02 seconds. I want to read from the Ni daq at a rate of 100 Hz, which right now I am not able to achieve. My timing needs to be extremely consistent.

Code:

data1 = read(handles.niusb8451_1, 2);

data2 = read(handles.niusb8451_2, 2);

data3 = read(handles.niusb8451_3, 2);

data4 = read(handles.niusb8451_4, 2);

data5 = read(handles.niusb8451_5, 2);

data6 = read(handles.niusb8451_6, 2);

data7 = read(handles.niusb8451_7, 2);

data8 = read(handles.niusb8451_8, 2);

Also I need to write to a Ni USB-6525 Daq twice a second, which takes around .00256 sec. I would like to speed this up also.

Is there anything I can do?

[dpb]

Unless the ADC can be triggered to collect the data in background I'd guess probably not with high-level Matlab code.

There's really nothing you can do to control task-switching and the like that goes on on an "ordinary" PC without being a whole lot closer to the hardware.

[John D'Errico]

This is simply not something you can control in MATLAB. If you need it to be better, then you will need to write special purpose code yourself for the reads and writes. Sorry. As DPB says, you need to get closer to the hardware. The MATLAB environment insulates you too much from it, and potentially adds some unwanted overhead.

[Walter Roberson]

Can you add all of the lines together to form a single object that you could read() all at the same time?

[dpb]

From the NI datasheet--"... USB-8451 is a USB interface that provides ... communication for the test, validation, and programming of consumer electronics devices such as ... (ADCs) ... the NI USB-8451 includes 8 general-purpose digital I/O lines..."

So, it doesn't even have the ADC on board; it's only the interface element. Each one of those calls has to go thru the interface, then it has to address the ADC and package the request then relay the response. You'll have to look at the spec for the ADC board you're actually using and see if it can buffer results that you can then upload en mass; that'll then likely be the bottleneck that while you're doing that it'll take longer than the next buffer so you'll have intermittent gaps. Only if you can swap buffers onboard will you have any chance with this architecture; to do this kind of thing basically means writing low-level code.

You possibly, depending upon the API supplied, write mex files that could call from Matlab.

In the old days I did quite a lot with various NI cards but everything was written using the standalone libraries in (preferably) Fortran with a VisualBASIC frontend GUI. All that critical stuff was offloaded to the card, basically. One later job used 2 channels of 100 kHz data from accelerometers "listening" to pulverized coal flow in the burner-supply pipes. The sample time was set between scans to be only once a second or slower, data acq wasn't continuous at all. 100 Hz should be achievable with the above buffering scheme though with modern compute power. The above was nearly 30 yr ago now so PC power was much less than now.

[Walter Roberson]

Looking at the commands you are using, it appears you are using spi(); for those I do not see any mechanism for bundling several ports together.