You are right, that the bigbuffer was setup to handle USB High Speed devices, which typically have transfers of 512 bytes instead of 64 bytes, as well as higher speeds. the ,1 was a hack as by default it will only claim high speed serial...
Thanks for your reply. VID\PID = 0403:6001
I did run HIDDeviceInfo.ino with Debug:
port change: 10001803
connect
begin reset
port change: 10001005
port enabled
end recovery
new_Device: 12 Mbit/sec
new_Pipe
enumeration:
enumeration...
You might try your tests using just "USBSerial serial(myusb);".
I suspect that the FTDI is only a Full-Speed link, not the 480Mb/second High-Speed for which USBSerial_BigBuffer was designed. Just today, I found that BigBuffer will crash the...
I believe that, without the "-n" command line option included, the "echo" command in linux will terminate the data to be sent with either CR, or LF, and possibly CR/LF. You might try adding additional characters to your rCmd array & inserting...
OK, well shucks, did you also try these (in case the device doesn't like CR/LF together . . . hoping that one of them provides the missing magic):
byte rCmd[] = {255, 3, 1, 13};
- OR -
byte rCmd[] = {255, 3, 1, 10};
then using...
No not explicitly although I have tried {255, 3, 1, 13, 10} and {255, 3, 1, 10, 13}, although using RealTerm (a great tool!) I can confirm that neither CR nor LF are needed, just the 3 numbers.
I have noticed that using RealTerm under Windows I can get the same bad behaviour (flashing comms lights, but no control) if I set the BAUD to anything other than 9600 (8n1).
So this has me wondering, is this just an issue with the BAUD of the...
Thanks for your reply. I have previously tried that by defining:
byte rCmd[] = {255, 3, 1, 13, 10};
and then,
userial.write(rCmd, 5);
But sadly it still doesn't work.
I'm using a Teensy 4.1 with USBHost_t36 to control an 8-relay USB box, specifically a KMTronic box. It works great! So I bought another one.
Unbeknown to me the first KMTronic uses CDC, whereas the second one I bought uses FTDI and doesn't...