You can use all of the serial stream functions and properties, even though some are not actually used. You may want to check the BytesAvailable property before reading bytes from the stream. That documentation that Chris Stratton linked is good.

BaudRate and Terminator settings are not relevant to USB.You can probably leave them with default values, or use 115,200 and CR/LF (if Windows) or LF (if Linux) if something is required. The documentation in that link is for a generic serial stream. The USB device class that you have implemented on the MCU is a CDC (Communications Device Class) based interface. When you connect this to your PC the host O/S loads a class driver that make is look like a serial (COM) port to the rest of the system. MATLAB allows the COM device to be opened as a serial stream. ctd...

@ChrisStratton I hadn't considered that the buffering would be higher up in the stream implementation, but that makes a lot more sense. Thanks.

@ChrisStratton It appears that flushing the stream in MATLAB just clears out the buffer, rather than making sure that anything pending has been sent. I've had similar problems in C++, where calling fflush() on the stream makes sure that the data is gone before the next statement is executed.

@ChrisStratton I agree that the delay is not the right thing to do in production code, but to investigate why the problem is occurring it may yield clues. The embedded USB driver that the o/p is using is fairly simple and should (massive assumption) issue the bulk IN packet containing the data in a fairly timely manner, relative to MATLAB. Also, I meant that he should try to flush the Write (OUT) stream, not the read stream. USB drivers like to cache bulk data to send multiple small packets (relative to higher layer) in a single bulk transaction.

@TripeHound Yes, it's exactly having a tight loop. That's what the o/p is asking for: a tight loop for a short delay that doesn't get removed by the compiler optimisation. There are places where a tight loop is not a bad way to do a short delay, particularly in an embedded system that's not multitasking.

You don't even need to use interrupts, just poll the count register. This should be defined as a volatile, so the compiler will not optimise it out. IMO, SysTick is a good choice, as it's often configured to give an 'O/S timer', e.g. a microsecond timer. You will then have simple wait_microseconds(100); kind of things in the code.

Try putting a pause in between the write and the read on the MATLAB side, possibly a flush too, as the underlying O/S will have USB buffering in place. From a USB perspective, there will probably be at least one IN/NAK microframe between the RX and TX, so make the delay at least 250 us (2 microframes) and maybe as much as 1ms, just to be sure (assuming it's USB 2.0).

Turn off the watchdog and other interrupt sources, then use the SLEEP instruction (see section 14 of the datasheet). It would be different on a different microcontroller, but that will stop the one that you're using.

This is working great. With the addition of the DMA and the micro clocked at 80 MHz (40MIPS), the CPU load is under 5% for the DMA ISRs and all of the processing of the frequency data from both signals of both devices captured by the driver. It took a while to get all the peripheral configuration right, but worth the effort. Thanks.

Yes, three (or four) per device and two devices.

This does look like a good idea, however I'm not sure I have enough Timer/Counter peripherals on my device to do this. It looks like 8 would be required: four for each transducer. I'm already using one as a milliseond timer and another for a Quadrature Encoder velocity counter. I'll have to have a think about it.