Estoy teniendo dificultades para leer un puerto de comunicación virtual USB en la Octava de GNU, y hay algunos acontecimientos extraños en los que me gustaría recibir información.
Actualmente tengo un dispositivo de puerto de comunicación virtual CDC USB que programé para responder a comandos en serie con la computadora. El dispositivo es una placa de microcontrolador (STM32F401C Discovery board) con un grioscopio. El grioscopio se lee sobre SPI en el microcontrolador y luego el micro transmite los datos a la computadora. Espera hasta que reciba los comandos "x", "y" o "z" para enviar datos y luego continúa enviando datos para esa coordenada hasta que se detenga un bit (algo que no sea "x", "y" o " z ", normalmente uso" s ") se envía.
Al utilizar CuteCom, puedo interactuar bien con el dispositivo, por ejemplo. enviar el comando "xs" devolverá un paquete de 6 bytes de los datos de velocidad angular del eje x (tal vez algo como "+00021"). Utilizando GNU Octave y su paquete de control de instrumentos, puedo leer en todas las coordenadas, pero al enviar la cadena "xs", el dispositivo solo recibirá el byte "x" y transmitirá los datos del eje x continuamente.
Esto se puede solucionar agregando un retraso de 1 ms de caracteres. El dispositivo STM que lee los comandos en serie espera 1 ms entre los bytes que lee también, porque anteriormente era capaz de enviar muchas cadenas para el eje x antes de recibir el comando "s".
Entonces funciona, ¿verdad? Aparentemente no. El extraño comportamiento comienza aquí, como cuando ejecuto la secuencia de comando-luego-lectura en Octave una vez, todo funciona, pero en un bucle los datos leídos son solo el eje x. Pensé que esto era un problema de tiempo, y tenía curiosidad por ver qué se leía desde el puerto directamente usando CuteCom.
Cuando CuteCom está monitoreando el puerto serie en busca de datos, Octave lee los datos correctamente durante el ciclo. Pero cuando no está monitoreando el puerto serie, solo leerá el eje x.
No entiendo por qué tener CuteCom ejecutándose en paralelo con el script Octave causaría que el proceso se realice de la manera esperada, pero sin que CuteCom ejecute los datos, se dañará. Aquí está el script de octava de GNU:
pkg load instrument-control;
pkg load signal;
s1 = serial("/dev/ttyACM0");
set(s1,'baudrate',115200);
set(s1, 'bytesize',8);
set(s1,'parity','n');
set(s1,'stopbits',1);
set(s1,'timeout',100); %10.0 seconds
sleep(0.5);
srl_flush(s1);
datax = [];
datay = [];
dataz = [];
negativex = false;
negativey = false;
negativez = false;
xd = 0;
yd = 0;
zd = 0;
delaytime = 1000; %delay time in microseconds (us)
hold on;
for i = 1:500
srl_write(s1,"x");
usleep(delaytime);
xd = str2num(char(srl_read(s1,6)));
srl_write(s1,"s");
usleep(delaytime);
srl_write(s1,"y");
usleep(delaytime);
yd = str2num(char(srl_read(s1,6)));
srl_write(s1,"s");
usleep(delaytime);
srl_write(s1,"z");
usleep(delaytime);
zd = str2num(char(srl_read(s1,6)));
srl_write(s1,"s");
usleep(delaytime);
datax = [datax xd];
datay = [datay yd];
dataz = [dataz zd];
if mod(i, 10) == 0
hold off;
plot(datax,'r');
hold on;
plot(datay,'b');
plot(dataz,'g');
drawnow;
endif
endfor
%
El resultado para los tres ejes cuando CuteCom no se está ejecutando (observe cómo se copian los datos para las tres líneas, con el pequeño retraso entre ellas):
Elresultadodelabuenasalidadedatos,cuandoCuteComseestáejecutando(tengaencuentaquelosdatosdecadaejesoncoherentesyclaros):
¿Alguien ha encontrado algo como esto antes? ¿Qué errores se cometieron para que esto suceda?
Gracias de antemano.
Sam