История изменений

Там доступа нет к ttyACM0, рутовать надо, для приложения это не очень подходит. В целом думаю, на C с драйвером в ядре всё будет работать нормально. Без драйвера в ядре с libftdi (драйвер для FTDI-чипов в юзерспейсе поверх libusb) не знаю, но это очень уж сложно, пока без этого попробую обойтись.

что бы я сделал:

1. перестал искать соломинку в чужом глазу (выискивать отмазки про USB), а взялся-бы за свой код :-)

2. убрал запись в порт из цикла опроса. У тебя измерительный прибор, он льёт гору показаний, а обратно пишешь в него крайне редко и мало. Но на каждые 28 байт проверяешь мутекс

3. посчитал и поставил таймер в чтение (там где mSerialPort.read(buffer, mReadTimeout)). Чуть больше чем надо на приём 28 байт. Просто не очень хорошо постоянно долбить read() впустую

4. посмотрел что происходит в OnNewData() - там вполне может втормаживать. Скорее какую-то часть PAD (та фигнь которая режет поток на пакеты) вынес оттуда непосредственно ближе к чтению

Там доступа нет к ttyACM0, рутовать надо, для приложения это не очень подходит. В целом думаю, на C с драйвером в ядре всё будет работать нормально. Без драйвера в ядре с libftdi (драйвер для FTDI-чипов в юзерспейсе поверх libusb) не знаю, но это очень уж сложно, пока без этого попробую обойтись.

что бы я сделал:

1. перестал искать соломинку в чужом глазу (выискивать отмазки про USB), а взялся-бы за свой код :-)

2. убрал запись в порт из цикла опроса. У тебя измерительный прибор, он льёт гору показаний, а обратно пишешь в него крайне редко и мало. Но на каждые 28 байт проверяешь мутекс

3. посчитал и поставил таймер в чтение (там где mSerialPort.read(buffer, mReadTimeout)). Чуть больше чем надо на приём 28 байт. Просто не очень хорошо постоянно долбить read() впустую

4. посмотрел что происходит в OnNewData() - там вполне может втормаживать. Скорее какую-то часть PAD (та фигнь которая режет поток на пакеты) вынес оттуда непосредственно к чтению