您最多选择25个主题 主题必须以字母或数字开头,可以包含连字符 (-),并且长度不得超过35个字符

USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
USBSerial_BigBuffer - T4.x (multi devices) This delta originated to do the work similar to what was done for the MIDI code base and support two versions of the object. All of the code was renamed to a new base class USBSerialBase which has everything, except the main buffer. Two sub-classes were made that the only difference is the size of the buffer to hold all of the USB RX and TX information. This started off to try to support an FT2232H device which transers 512 bytes at a time instead of what most of our devices were transfering which is 64 bytes. While doing this, I found that we have a similar issue with the T4.x boards which now transfer 512 bytes as well and our Serial object would not handle it. So there are two sublasses: ``` USBSerial - for those up to 64 byte transfers USBSerial_BigBuffer - for up to 512 bytes ``` Note: by default the biguffer version will only handle those devices > 64 bytes, but you can pass in an optional parameter of the minimum size, so doing something like: ``` USBSerial_BigBuffer userial(myusb, 1); ``` Will handle all up to 512. Also the FTDI2232H supports two USB to Serial objects, and our code was setup that in most cases including when we put in VID:PID pair in our table, the code would claim would claim the object at device level so only one USB Serial adapter. So changed table to support saying for this VID:PID claim at interface level. It now works, but not sure for the device I have as it is a USB to Serial and JTAG and not sure how to test 2nd one. But while doing this created a test sketch for Multiple Host USB Serial objects and the two are claimed by this. I also created a new version of the Teensy USBToSerial example sketch that if you configure USB type to Dual Serial or Triple Serial will output SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then tried T4 configured for Dual plugged into T4.1 with above sketch and could talk to both USB Serial adapters. The Claim code was rearranged a lot, so hopefully did not break anything. But tested with T4 as mentioned, both Single and Dual Serial T3.2 with Single Serial, plus: Serial, Joystick, Keyboard... FTDI - USB to Serial adapter (Sparkfun) CP2104 - Adafruit PL2303 - some clones ... So hopefully most things are still working
4 年前
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338
  1. /* USB EHCI Host for Teensy 3.6
  2. * Copyright 2017 Paul Stoffregen (paul@pjrc.com)
  3. *
  4. * Permission is hereby granted, free of charge, to any person obtaining a
  5. * copy of this software and associated documentation files (the
  6. * "Software"), to deal in the Software without restriction, including
  7. * without limitation the rights to use, copy, modify, merge, publish,
  8. * distribute, sublicense, and/or sell copies of the Software, and to
  9. * permit persons to whom the Software is furnished to do so, subject to
  10. * the following conditions:
  11. *
  12. * The above copyright notice and this permission notice shall be included
  13. * in all copies or substantial portions of the Software.
  14. *
  15. * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
  16. * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
  17. * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
  18. * IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
  19. * CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
  20. * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
  21. * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  22. *
  23. * Note: special thanks to the Linux kernel for the CH341's method of operation, particularly how the baud rate is encoded.
  24. */
  25. #include <Arduino.h>
  26. #include "USBHost_t36.h" // Read this header first for key info
  27. #define print USBHost::print_
  28. #define println USBHost::println_
  29. //#define ENABLE_DEBUG_PINS
  30. #ifdef ENABLE_DEBUG_PINS
  31. #define debugDigitalToggle(pin) {digitalWriteFast(pin, !digitalReadFast(pin));}
  32. #define debugDigitalWrite(pin, state) {digitalWriteFast(pin, state);}
  33. #else
  34. #define debugDigitalToggle(pin) {;}
  35. #define debugDigitalWrite(pin, state) {;}
  36. #endif
  37. /************************************************************/
  38. // Define mapping VID/PID - to Serial Device type.
  39. /************************************************************/
  40. USBSerialBase::product_vendor_mapping_t USBSerialBase::pid_vid_mapping[] = {
  41. // FTDI mappings.
  42. {0x0403, 0x6001, USBSerialBase::FTDI, 0},
  43. {0x0403, 0x8088, USBSerialBase::FTDI, 1}, // 2 devices try to claim at interface level
  44. // PL2303
  45. {0x67B,0x2303, USBSerialBase::PL2303, 0},
  46. // CH341
  47. {0x4348, 0x5523, USBSerialBase::CH341, 0},
  48. {0x1a86, 0x7523, USBSerialBase::CH341, 0 },
  49. {0x1a86, 0x5523, USBSerialBase::CH341, 0 },
  50. // Silex CP210...
  51. {0x10c4, 0xea60, USBSerialBase::CP210X, 0 }
  52. };
  53. /************************************************************/
  54. // Initialization and claiming of devices & interfaces
  55. /************************************************************/
  56. void USBSerialBase::init()
  57. {
  58. contribute_Pipes(mypipes, sizeof(mypipes)/sizeof(Pipe_t));
  59. contribute_Transfers(mytransfers, sizeof(mytransfers)/sizeof(Transfer_t));
  60. contribute_String_Buffers(mystring_bufs, sizeof(mystring_bufs)/sizeof(strbuf_t));
  61. driver_ready_for_device(this);
  62. format_ = USBHOST_SERIAL_8N1;
  63. }
  64. bool USBSerialBase::claim(Device_t *dev, int type, const uint8_t *descriptors, uint32_t len)
  65. {
  66. print("USBSerial(", _max_rxtx, DEC);
  67. println(")claim this=", (uint32_t)this, HEX);
  68. print("vid=", dev->idVendor, HEX);
  69. print(", pid=", dev->idProduct, HEX);
  70. print(", bDeviceClass = ", dev->bDeviceClass);
  71. print(", bDeviceSubClass = ", dev->bDeviceSubClass);
  72. println(", bDeviceProtocol = ", dev->bDeviceProtocol);
  73. print_hexbytes(descriptors, len);
  74. //---------------------------------------------------------------------------
  75. // Lets try to map CDCACM devices only at device level
  76. if ((dev->bDeviceClass == 2) && (dev->bDeviceSubClass == 0)) {
  77. if (type != 0) return false;
  78. // It is a communication device see if we can extract the data...
  79. // Try some ttyACM types?
  80. // This code may be similar to MIDI code.
  81. // But first pass see if we can simply look at the interface...
  82. // Lets walk through end points and see if we
  83. // can find an RX and TX bulk transfer end point.
  84. // 0 1 2 3 4 5 6 7 8 *9 10 1 2 3 *4 5 6 7 *8 9 20 1 2 *3 4 5 6 7 8 9*30 1 2 3 4 5 6 7 8 *9 40 1 2 3 4 5 *6 7 8 9 50 1 2
  85. // USB2AX
  86. //09 04 00 00 01 02 02 01 00 05 24 00 10 01 04 24 02 06 05 24 06 00 01 07 05 82 03 08 00 FF 09 04 01 00 02 0A 00 00 00 07 05 04 02 10 00 01 07 05 83 02 10 00 01
  87. //09 04 01 00 02 0A 00 00 00 07 05 04 02 10 00 01 07 05 83 02 10 00 01
  88. // Teensy 3.6
  89. //09 04 00 00 01 02 02 01 00 05 24 00 10 01 05 24 01 01 01 04 24 02 06 05 24 06 00 01 07 05 82 03 10 00 40 09 04 01 00 02 0A 00 00 00 07 05 03 02 40 00 00 07 05 84 02 40 00 00
  90. //09 04 01 00 02 0A 00 00 00 07 05 03 02 40 00 00 07 05 84 02 40 00 00
  91. const uint8_t *p = descriptors;
  92. const uint8_t *end = p + len;
  93. if (p[0] != 9 || p[1] != 4) return false; // interface descriptor
  94. //println(" bInterfaceClass=", p[5]);
  95. //println(" bInterfaceSubClass=", p[6]);
  96. if (p[5] != 2) return false; // bInterfaceClass: 2 Communications
  97. if (p[6] != 2) return false; // bInterfaceSubClass: 2 serial
  98. p += 9;
  99. println(" Interface is Serial");
  100. uint8_t rx_ep = 0;
  101. uint8_t tx_ep = 0;
  102. uint16_t rx_size = 0;
  103. uint16_t tx_size = 0;
  104. interface = 0; // clear out any interface numbers passed in.
  105. while (p < end) {
  106. len = *p;
  107. if (len < 4) return false;
  108. if (p + len > end) return false; // reject if beyond end of data
  109. uint32_t type = p[1];
  110. //println("type: ", type);
  111. // Unlike Audio, we need to look at Interface as our endpoints are after them...
  112. if (type == 4 ) { // Interface - lets remember it's number...
  113. interface = p[2];
  114. println(" Interface: ", interface);
  115. }
  116. else if (type == 0x24) { // 0x24 = CS_INTERFACE,
  117. uint32_t subtype = p[2];
  118. print(" CS_INTERFACE - subtype: ", subtype);
  119. if (len >= 4) print(" ", p[3], HEX);
  120. if (len >= 5) print(" ", p[4], HEX);
  121. if (len >= 6) print(" ", p[5], HEX);
  122. switch (subtype) {
  123. case 0: println(" - Header Functional Descriptor"); break;
  124. case 1: println(" - Call Management Functional"); break;
  125. case 2: println(" - Abstract Control Management"); break;
  126. case 4: println(" - Telephone Ringer"); break;
  127. case 6: println(" - union Functional"); break;
  128. default: println(" - ??? other"); break;
  129. }
  130. // First pass ignore...
  131. } else if (type == 5) {
  132. // endpoint descriptor
  133. if (p[0] < 7) return false; // at least 7 bytes
  134. if (p[3] == 2) { // First try ignore the first one which is interrupt...
  135. println(" Endpoint: ", p[2], HEX);
  136. switch (p[2] & 0xF0) {
  137. case 0x80:
  138. // IN endpoint
  139. if (rx_ep == 0) {
  140. rx_ep = p[2] & 0x0F;
  141. rx_size = p[4] | (p[5] << 8);
  142. println(" rx_size = ", rx_size);
  143. }
  144. break;
  145. case 0x00:
  146. // OUT endpoint
  147. if (tx_ep == 0) {
  148. tx_ep = p[2];
  149. tx_size = p[4] | (p[5] << 8);
  150. println(" tx_size = ", tx_size);
  151. }
  152. break;
  153. default:
  154. println(" invalid end point: ", p[2]);
  155. return false;
  156. }
  157. }
  158. } else {
  159. println(" Unknown type: ", type);
  160. return false; // unknown
  161. }
  162. p += len;
  163. }
  164. print(" exited loop rx:", rx_ep);
  165. println(", tx:", tx_ep);
  166. if (!rx_ep || !tx_ep) return false; // did not get our two end points
  167. if (!init_buffers(rx_size, tx_size)) return false;
  168. println(" rx buffer size:", rxsize);
  169. println(" tx buffer size:", txsize);
  170. rxpipe = new_Pipe(dev, 2, rx_ep & 15, 1, rx_size);
  171. if (!rxpipe) return false;
  172. txpipe = new_Pipe(dev, 2, tx_ep, 0, tx_size);
  173. if (!txpipe) {
  174. // TODO: free rxpipe
  175. return false;
  176. }
  177. sertype = CDCACM;
  178. rxpipe->callback_function = rx_callback;
  179. queue_Data_Transfer(rxpipe, rx1, (rx_size < 64)? rx_size : 64, this);
  180. rxstate = 1;
  181. if (rx_size > 128) {
  182. queue_Data_Transfer(rxpipe, rx2, rx_size, this);
  183. rxstate = 3;
  184. }
  185. txstate = 0;
  186. txpipe->callback_function = tx_callback;
  187. baudrate = 115200;
  188. // Wish I could just call Control to do the output... Maybe can defer until the user calls begin()
  189. // control requires that device is setup which is not until this call completes...
  190. println("Control - CDCACM DTR...");
  191. // Need to setup the data the line coding data
  192. mk_setup(setup, 0x21, 0x22, 3, 0, 0);
  193. queue_Control_Transfer(dev, &setup, NULL, this);
  194. control_queued = true;
  195. pending_control = 0x0; // Maybe don't need to do...
  196. return true;
  197. }
  198. //---------------------------------------------------------------------------
  199. // Else lets see if this is a PID/VID we know something about.
  200. // See if the vendor_id:product_id is in our list of products.
  201. sertype = UNKNOWN;
  202. for (uint8_t i = 0; i < (sizeof(pid_vid_mapping)/sizeof(pid_vid_mapping[0])); i++) {
  203. if ((dev->idVendor == pid_vid_mapping[i].idVendor) && (dev->idProduct == pid_vid_mapping[i].idProduct)) {
  204. sertype = pid_vid_mapping[i].sertype;
  205. if (pid_vid_mapping[i].claim_at_type != type) {
  206. println("Serial device wants to map at interface level");
  207. return false;
  208. }
  209. break;
  210. }
  211. }
  212. if (sertype == UNKNOWN) {
  213. // Not in our list see if CDCACM type...
  214. // only at the Interface level
  215. if (type != 1) return false;
  216. // TTYACM: <Composit device>
  217. //
  218. // We first tried to claim a simple ttyACM device like a teensy who is configured
  219. // only as Serial at the device level like what was done for midi
  220. //
  221. // However some devices are a compisit of multiple Interfaces, so see if this Interface
  222. // is of the CDC Interface class and 0 for SubClass and protocol
  223. // Todo: some of this can maybe be combined with the Whole device code above.
  224. if (descriptors[0] != 9 || descriptors[1] != 4) return false; // interface descriptor
  225. if (descriptors[4] < 2) return false; // less than 2 end points
  226. if (descriptors[5] != 0xA) return false; // bInterfaceClass, 0xa = CDC data
  227. if (descriptors[6] != 0) return false; // bInterfaceSubClass
  228. if (descriptors[7] != 0) return false; // bInterfaceProtocol
  229. sertype = CDCACM;
  230. // Lets see if we can fold in the ACM stuff here...
  231. }
  232. // Lets try to locate the end points. Code is common across these devices
  233. println("len = ", len);
  234. uint8_t count_end_points = descriptors[4];
  235. if (count_end_points < 2) return false; // not enough end points
  236. if (len < 23) return false;
  237. if (descriptors[0] != 9) return false; // length 9
  238. // Lets walk through end points and see if we
  239. // can find an RX and TX bulk transfer end point.
  240. //Example vid=67B, pid=2303
  241. // 0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 20 1 2 3 4 5 6 7 8 9
  242. //09 04 00 00 03 FF 00 00 00 07 05 81 03 0A 00 01 07 05 02 02 40 00 00 07 05 83 02 40 00 00
  243. // lets see about FTD2232H
  244. //09 04 00 00 02 FF FF FF 02 07 05 81 02 00 02 00 07 05 02 02 00 02 00 09 04 01 00 02 FF FF FF 02 07 05 83 02 00 02 00 07 05 04 02 00 02 00
  245. //09 04 01 00 02 FF FF FF 02 07 05 83 02 00 02 00 07 05 04 02 00 02 00
  246. uint32_t rxep = 0;
  247. uint32_t txep = 0;
  248. uint16_t rx_size = 0;
  249. uint16_t tx_size = 0;
  250. uint32_t descriptor_index = 9;
  251. while (count_end_points-- && ((rxep == 0) || txep == 0)) {
  252. if (descriptors[descriptor_index] != 7) return false; // length 7
  253. if (descriptors[descriptor_index+1] != 5) return false; // ep desc
  254. uint16_t ep_size = descriptors[descriptor_index+4] + (uint16_t)(descriptors[descriptor_index+5] << 8);
  255. if ((descriptors[descriptor_index+3] == 2)
  256. && (ep_size <= _max_rxtx) && (ep_size >= _min_rxtx)) {
  257. // have a bulk EP size
  258. if (descriptors[descriptor_index+2] & 0x80 ) {
  259. rxep = descriptors[descriptor_index+2];
  260. rx_size = ep_size;
  261. } else {
  262. txep = descriptors[descriptor_index+2];
  263. tx_size = ep_size;
  264. }
  265. }
  266. descriptor_index += 7; // setup to look at next one...
  267. }
  268. // Try to verify the end points.
  269. if (!check_rxtx_ep(rxep, txep)) return false;
  270. print("USBSerial, rxep=", rxep & 15);
  271. print("(", rx_size);
  272. print("), txep=", txep);
  273. print("(", tx_size);
  274. println(")");
  275. if (!init_buffers(rx_size, tx_size)) return false;
  276. println(" rx buffer size:", rxsize);
  277. println(" tx buffer size:", txsize);
  278. rxpipe = new_Pipe(dev, 2, rxep & 15, 1, rx_size);
  279. if (!rxpipe) return false;
  280. txpipe = new_Pipe(dev, 2, txep, 0, tx_size);
  281. if (!txpipe) {
  282. //free_Pipe(rxpipe);
  283. return false;
  284. }
  285. rxpipe->callback_function = rx_callback;
  286. queue_Data_Transfer(rxpipe, rx1, rx_size, this);
  287. rxstate = 1;
  288. txstate = 0;
  289. txpipe->callback_function = tx_callback;
  290. baudrate = 115200;
  291. // Now do specific setup per type
  292. switch (sertype) {
  293. //---------------------------------------------------------------------
  294. // FTDI
  295. case FTDI:
  296. {
  297. pending_control = 0x0F;
  298. mk_setup(setup, 0x40, 0, 0, 0, 0); // reset port
  299. queue_Control_Transfer(dev, &setup, NULL, this);
  300. control_queued = true;
  301. return true;
  302. }
  303. //------------------------------------------------------------------------
  304. // Prolific
  305. // TODO: Note: there are probably more vendor/product pairs.. Maybe should create table of them
  306. case PL2303:
  307. {
  308. // First attempt keep it simple...
  309. println("PL2303: readRegister(0x04)");
  310. // Need to setup the data the line coding data
  311. mk_setup(setup, 0xC0, 0x1, 0x8484, 0, 1);
  312. queue_Control_Transfer(dev, &setup, setupdata, this);
  313. control_queued = true;
  314. setup_state = 1; // We are at step one of setup...
  315. pending_control = 0x3f;
  316. return true;
  317. }
  318. //------------------------------------------------------------------------
  319. // CH341
  320. case CH341:
  321. {
  322. println("CH341: 0xC0, 0x5f, 0, 0, 8");
  323. // Need to setup the data the line coding data
  324. mk_setup(setup, 0xC0, 0x5f, 0, 0, sizeof(setupdata));
  325. queue_Control_Transfer(dev, &setup, setupdata, this);
  326. control_queued = true;
  327. setup_state = 1; // We are at step one of setup...
  328. pending_control = 0x7f;
  329. return true;
  330. }
  331. //------------------------------------------------------------------------
  332. // CP210X
  333. case CP210X:
  334. {
  335. println("CP210X: 0x41, 0x11, 0, 0, 0 - reset port");
  336. // Need to setup the data the line coding data
  337. mk_setup(setup, 0x41, 0x11, 0, 0, 0);
  338. queue_Control_Transfer(dev, &setup, NULL, this);
  339. control_queued = true;
  340. setup_state = 1; // We are at step one of setup...
  341. pending_control = 0xf;
  342. return true;
  343. }
  344. case CDCACM:
  345. {
  346. println("Control - CDCACM LINE_CODING");
  347. setupdata[0] = 0; // Setup baud rate 115200 - 0x1C200
  348. setupdata[1] = 0xc2;
  349. setupdata[2] = 0x1;
  350. setupdata[3] = 0;
  351. setupdata[4] = 0; // 0 - 1 stop bit, 1 - 1.5 stop bits, 2 - 2 stop bits
  352. setupdata[5] = 0; // 0 - None, 1 - Odd, 2 - Even, 3 - Mark, 4 - Space
  353. setupdata[6] = 8; // Data bits (5, 6, 7, 8 or 16)
  354. mk_setup(setup, 0x21, 0x20, 0, 0, 7);
  355. queue_Control_Transfer(dev, &setup, setupdata, this);
  356. pending_control = 0x04; // Maybe don't need to do...
  357. control_queued = true;
  358. return true;
  359. }
  360. //------------------------------------------------------------------------
  361. // PID:VID - not in our product list.
  362. default:
  363. break;
  364. }
  365. return false;
  366. }
  367. // check if two legal endpoints, 1 receive & 1 transmit
  368. bool USBSerialBase::check_rxtx_ep(uint32_t &rxep, uint32_t &txep)
  369. {
  370. if ((rxep & 0x0F) == 0) return false;
  371. if ((txep & 0x0F) == 0) return false;
  372. uint32_t rxdir = rxep & 0xF0;
  373. uint32_t txdir = txep & 0xF0;
  374. if (rxdir == 0x80 && txdir == 0x00) {
  375. return true;
  376. }
  377. if (rxdir == 0x00 && txdir == 0x80) {
  378. std::swap(rxep, txep);
  379. return true;
  380. }
  381. return false;
  382. }
  383. // initialize buffer sizes and pointers
  384. bool USBSerialBase::init_buffers(uint32_t rsize, uint32_t tsize)
  385. {
  386. // buffer must be able to hold 2 of each packet, plus buffer
  387. // space to hold RX and TX data.
  388. if (_big_buffer_size < (rsize + tsize) * 3 + 2) return false;
  389. rx1 = (uint8_t *)_bigBuffer;
  390. rx2 = rx1 + rsize;
  391. tx1 = rx2 + rsize;
  392. tx2 = tx1 + tsize;
  393. rxbuf = tx2 + tsize;
  394. // FIXME: this assume 50-50 split - not true when rsize != tsize
  395. rxsize = (_big_buffer_size - (rsize + tsize) * 2) / 2;
  396. txsize = rxsize;
  397. txbuf = rxbuf + rxsize;
  398. rxhead = 0;
  399. rxtail = 0;
  400. txhead = 0;
  401. txtail = 0;
  402. rxstate = 0;
  403. return true;
  404. }
  405. void USBSerialBase::disconnect()
  406. {
  407. }
  408. void USBSerialBase::control(const Transfer_t *transfer)
  409. {
  410. println("control callback (serial) ", pending_control, HEX);
  411. control_queued = false;
  412. // We will split this up by Serial type, maybe different functions?
  413. //-------------------------------------------------------------------------
  414. // First FTDI
  415. if (sertype == FTDI) {
  416. if (pending_control & 1) {
  417. pending_control &= ~1;
  418. // set data format
  419. uint16_t ftdi_format = format_ & 0xf; // This should give us the number of bits.
  420. // now lets extract the parity from our encoding
  421. ftdi_format |= (format_ & 0xe0) << 3; // they encode bits 9-11
  422. // See if two stop bits
  423. if (format_ & 0x100) ftdi_format |= (0x2 << 11);
  424. mk_setup(setup, 0x40, 4, ftdi_format, 0, 0); // data format 8N1
  425. queue_Control_Transfer(device, &setup, NULL, this);
  426. control_queued = true;
  427. return;
  428. }
  429. // set baud rate
  430. if (pending_control & 2) {
  431. pending_control &= ~2;
  432. uint32_t baudval = 3000000 / baudrate;
  433. mk_setup(setup, 0x40, 3, baudval, 0, 0);
  434. queue_Control_Transfer(device, &setup, NULL, this);
  435. control_queued = true;
  436. return;
  437. }
  438. // configure flow control
  439. if (pending_control & 4) {
  440. pending_control &= ~4;
  441. mk_setup(setup, 0x40, 2, 0, 1, 0);
  442. queue_Control_Transfer(device, &setup, NULL, this);
  443. control_queued = true;
  444. return;
  445. }
  446. // set DTR
  447. if (pending_control & 8) {
  448. pending_control &= ~8;
  449. mk_setup(setup, 0x40, 1, 0x0101, 0, 0);
  450. queue_Control_Transfer(device, &setup, NULL, this);
  451. control_queued = true;
  452. return;
  453. }
  454. // clear DTR
  455. if (pending_control & 0x80) {
  456. pending_control &= ~0x80;
  457. println("FTDI clear DTR");
  458. mk_setup(setup, 0x40, 1, 0x0100, 0, 0);
  459. queue_Control_Transfer(device, &setup, NULL, this);
  460. control_queued = true;
  461. return;
  462. }
  463. }
  464. //-------------------------------------------------------------------------
  465. // Now CDCACM
  466. if (sertype == CDCACM) {
  467. if (pending_control & 2) {
  468. pending_control &= ~2;
  469. // Should probably use data structure, but that may depend on byte ordering...
  470. setupdata[0] = (baudrate) & 0xff; // Setup baud rate 115200 - 0x1C200
  471. setupdata[1] = (baudrate >> 8) & 0xff;
  472. setupdata[2] = (baudrate >> 16) & 0xff;
  473. setupdata[3] = (baudrate >> 24) & 0xff;
  474. setupdata[4] = (format_ & 0x100)? 2 : 0; // 0 - 1 stop bit, 1 - 1.5 stop bits, 2 - 2 stop bits
  475. setupdata[5] = (format_ & 0xe0) >> 5; // 0 - None, 1 - Odd, 2 - Even, 3 - Mark, 4 - Space
  476. setupdata[6] = format_ & 0x1f; // Data bits (5, 6, 7, 8 or 16)
  477. print("CDCACM setup: ");
  478. print_hexbytes(&setupdata, 7);
  479. mk_setup(setup, 0x21, 0x20, 0, 0, 7);
  480. queue_Control_Transfer(device, &setup, setupdata, this);
  481. control_queued = true;
  482. return;
  483. }
  484. // configure flow control
  485. if (pending_control & 4) {
  486. pending_control &= ~4;
  487. println("Control - 0x21,0x22, 0x3");
  488. // Need to setup the data the line coding data
  489. mk_setup(setup, 0x21, 0x22, 3, 0, 0);
  490. queue_Control_Transfer(device, &setup, NULL, this);
  491. control_queued = true;
  492. return;
  493. }
  494. if (pending_control & 0x80) {
  495. pending_control &= ~0x80;
  496. println("Control - 0x21,0x22, 0x0 - clear DTR");
  497. // Need to setup the data the line coding data
  498. mk_setup(setup, 0x21, 0x22, 0, 0, 0);
  499. queue_Control_Transfer(device, &setup, NULL, this);
  500. control_queued = true;
  501. return;
  502. }
  503. }
  504. //-------------------------------------------------------------------------
  505. // Now PL2303 - Which appears to be a little more complicated
  506. if (sertype == PL2303) {
  507. if (pending_control & 1) {
  508. // Still in larger setup state mode
  509. switch (setup_state) {
  510. case 1:
  511. println("PL2303: writeRegister(0x04, 0x00)");
  512. mk_setup(setup, 0x40, 1, 0x0404, 0, 0); //
  513. queue_Control_Transfer(device, &setup, NULL, this);
  514. setup_state = 2;
  515. control_queued = true;
  516. return;
  517. case 2:
  518. println("PL2303: readRegister(0x04)");
  519. mk_setup(setup, 0xC0, 0x1, 0x8484, 0, 1);
  520. queue_Control_Transfer(device, &setup, setupdata, this);
  521. control_queued = true;
  522. setup_state = 3;
  523. return;
  524. case 3:
  525. println("PL2303: v1 = readRegister(0x03)");
  526. mk_setup(setup, 0xC0, 0x1, 0x8383, 0, 1);
  527. queue_Control_Transfer(device, &setup, setupdata, this);
  528. control_queued = true;
  529. setup_state = 4;
  530. return;
  531. case 4:
  532. println("PL2303: readRegister(0x04)");
  533. // Do we need this value long term or we could just leave in setup data?
  534. pl2303_v1 = setupdata[0]; // save the first bye of version
  535. mk_setup(setup, 0xC0, 0x1, 0x8484, 0, 1);
  536. queue_Control_Transfer(device, &setup, setupdata, this);
  537. control_queued = true;
  538. setup_state = 5;
  539. return;
  540. case 5:
  541. println("PL2303: writeRegister(0x04, 0x01)");
  542. mk_setup(setup, 0x40, 1, 0x0404, 1, 0); //
  543. queue_Control_Transfer(device, &setup, NULL, this);
  544. setup_state = 6;
  545. control_queued = true;
  546. return;
  547. case 6:
  548. println("PL2303: readRegister(0x04)");
  549. mk_setup(setup, 0xC0, 0x1, 0x8484, 0, 1);
  550. queue_Control_Transfer(device, &setup, setupdata, this);
  551. control_queued = true;
  552. setup_state = 7;
  553. return;
  554. case 7:
  555. println("PL2303: v2 = readRegister(0x03)");
  556. mk_setup(setup, 0xC0, 0x1, 0x8383, 0, 1);
  557. queue_Control_Transfer(device, &setup, setupdata, this);
  558. control_queued = true;
  559. setup_state = 8;
  560. return;
  561. case 8:
  562. pl2303_v2 = setupdata[0]; // save the first bye of version
  563. print(" PL2303 Version ", pl2303_v1, HEX);
  564. println(":", pl2303_v2, HEX);
  565. println("PL2303: writeRegister(0, 1)");
  566. mk_setup(setup, 0x40, 1, 0, 1, 0); //
  567. queue_Control_Transfer(device, &setup, NULL, this);
  568. setup_state = 9;
  569. control_queued = true;
  570. return;
  571. case 9:
  572. println("PL2303: writeRegister(1, 0)");
  573. mk_setup(setup, 0x40, 1, 1, 0, 0); //
  574. queue_Control_Transfer(device, &setup, NULL, this);
  575. setup_state = 10;
  576. control_queued = true;
  577. return;
  578. case 10:
  579. println("PL2303: writeRegister(2, 44)");
  580. mk_setup(setup, 0x40, 1, 2, 0x44, 0); //
  581. queue_Control_Transfer(device, &setup, NULL, this);
  582. setup_state = 11;
  583. control_queued = true;
  584. return;
  585. case 11:
  586. println("PL2303: writeRegister(8, 0)");
  587. mk_setup(setup, 0x40, 1, 8, 0, 0); //
  588. queue_Control_Transfer(device, &setup, NULL, this);
  589. setup_state = 12;
  590. control_queued = true;
  591. return;
  592. case 12:
  593. println("PL2303: writeRegister(9, 0)");
  594. mk_setup(setup, 0x40, 1, 9, 0, 0); //
  595. queue_Control_Transfer(device, &setup, NULL, this);
  596. setup_state = 13;
  597. control_queued = true;
  598. return;
  599. case 13:
  600. println("PL2303: Read current Baud/control");
  601. mk_setup(setup, 0xA1, 0x21, 0, 0, 7);
  602. queue_Control_Transfer(device, &setup, setupdata, this);
  603. control_queued = true;
  604. break;
  605. }
  606. pending_control &= ~1; // We are finally going to leave this list and join the rest
  607. if (control_queued) return;
  608. }
  609. // set baud rate
  610. if (pending_control & 2) {
  611. pending_control &= ~2;
  612. // See what the read returned earlier
  613. print("PL2303: Returned configuration data: ");
  614. print_hexbytes(setupdata, 7);
  615. // Should probably use data structure, but that may depend on byte ordering...
  616. setupdata[0] = (baudrate) & 0xff; // Setup baud rate 115200 - 0x1C200
  617. setupdata[1] = (baudrate >> 8) & 0xff;
  618. setupdata[2] = (baudrate >> 16) & 0xff;
  619. setupdata[3] = (baudrate >> 24) & 0xff;
  620. setupdata[4] = (format_ & 0x100)? 2 : 0; // 0 - 1 stop bit, 1 - 1.5 stop bits, 2 - 2 stop bits
  621. setupdata[5] = (format_ & 0xe0) >> 5; // 0 - None, 1 - Odd, 2 - Even, 3 - Mark, 4 - Space
  622. setupdata[6] = format_ & 0x1f; // Data bits (5, 6, 7, 8 or 16)
  623. print("PL2303: Set baud/control: ", baudrate, HEX);
  624. print(" = ");
  625. print_hexbytes(&setupdata, 7);
  626. mk_setup(setup, 0x21, 0x20, 0, 0, 7);
  627. queue_Control_Transfer(device, &setup, setupdata, this);
  628. control_queued = true;
  629. return;
  630. }
  631. if (pending_control & 4) {
  632. pending_control &= ~4;
  633. println("PL2303: writeRegister(0, 0)");
  634. mk_setup(setup, 0x40, 1, 0, 0, 0); //
  635. queue_Control_Transfer(device, &setup, NULL, this);
  636. control_queued = true;
  637. return;
  638. }
  639. if (pending_control & 8) {
  640. pending_control &= ~8;
  641. println("PL2303: Read current Baud/control");
  642. memset(setupdata, 0, sizeof(setupdata)); // clear it to see if we read it...
  643. mk_setup(setup, 0xA1, 0x21, 0, 0, 7);
  644. queue_Control_Transfer(device, &setup, setupdata, this);
  645. control_queued = true;
  646. }
  647. if (pending_control & 0x10) {
  648. pending_control &= ~0x10;
  649. print("PL2303: Returned configuration data: ");
  650. print_hexbytes(setupdata, 7);
  651. // This sets the control lines (0x1=DTR, 0x2=RTS)
  652. println("PL2303: 0x21, 0x22, 0x3");
  653. mk_setup(setup, 0x21, 0x22, 3, 0, 0); //
  654. queue_Control_Transfer(device, &setup, NULL, this);
  655. control_queued = true;
  656. return;
  657. }
  658. if (pending_control & 0x20) {
  659. pending_control &= ~0x20;
  660. println("PL2303: 0x21, 0x22, 0x3");
  661. mk_setup(setup, 0x21, 0x22, 3, 0, 0); //
  662. queue_Control_Transfer(device, &setup, NULL, this);
  663. control_queued = true;
  664. }
  665. if (pending_control & 0x80) {
  666. pending_control &= ~0x80;
  667. println("PL2303: 0x21, 0x22, 0x0"); // Clear DTR/RTS
  668. mk_setup(setup, 0x21, 0x22, 0, 0, 0); //
  669. queue_Control_Transfer(device, &setup, NULL, this);
  670. control_queued = true;
  671. }
  672. }
  673. if (sertype == CH341) {
  674. #if 0
  675. print(" Transfer: ");
  676. print_hexbytes(&transfer->setup, sizeof(setup_t));
  677. if (transfer->length) {
  678. print(" data: ");
  679. print_hexbytes(transfer->buffer, transfer->length);
  680. }
  681. #endif
  682. if (pending_control & 1) {
  683. // Still in larger setup state mode
  684. switch (setup_state) {
  685. case 1:
  686. print(" Returned: ");
  687. print_hexbytes(transfer->buffer, transfer->length);
  688. println("CH341: 40, a1, 0, 0, 0");
  689. mk_setup(setup, 0x40, 0xa1, 0, 0, 0); //
  690. queue_Control_Transfer(device, &setup, NULL, this);
  691. setup_state = 2;
  692. control_queued = true;
  693. return;
  694. case 2:
  695. ch341_setBaud(0); // send the first byte of the baud rate
  696. control_queued = true;
  697. setup_state = 3;
  698. return;
  699. case 3:
  700. ch341_setBaud(1); // send the second byte of the baud rate
  701. control_queued = true;
  702. setup_state = 4;
  703. return;
  704. case 4:
  705. println("CH341: c0, 95, 2518, 0, 8");
  706. mk_setup(setup, 0xc0, 0x95, 0x2518, 0, sizeof(setup)); //
  707. queue_Control_Transfer(device, &setup, setupdata, this);
  708. setup_state = 5;
  709. control_queued = true;
  710. return;
  711. case 5:
  712. print(" Returned: ");
  713. print_hexbytes(transfer->buffer, transfer->length);
  714. println("CH341: 40, 0x9a, 0x2518, 0x0050, 0");
  715. mk_setup(setup, 0x40, 0x9a, 0x2518, 0x0050, 0); //
  716. queue_Control_Transfer(device, &setup, NULL, this);
  717. setup_state = 6;
  718. control_queued = true;
  719. return;
  720. case 6:
  721. println("CH341: c0, 95, 0x706, 0, 8 - get status");
  722. mk_setup(setup, 0xc0, 0x95, 0x706, 0, sizeof(setup)); //
  723. queue_Control_Transfer(device, &setup, setupdata, this);
  724. setup_state = 7;
  725. control_queued = true;
  726. return;
  727. case 7:
  728. print(" Returned: ");
  729. print_hexbytes(transfer->buffer, transfer->length);
  730. println("CH341: 40, 0xa1, 0x501f, 0xd90a, 0");
  731. mk_setup(setup, 0x40, 0xa1, 0x501f, 0xd90a, 0); //
  732. queue_Control_Transfer(device, &setup, NULL, this);
  733. setup_state = 8;
  734. control_queued = true;
  735. break;
  736. }
  737. pending_control &= ~1; // We are finally going to leave this list and join the rest
  738. if (control_queued) return;
  739. }
  740. // set baud rate
  741. if (pending_control & 2) {
  742. pending_control &= ~2;
  743. ch341_setBaud(0); // send the first byte of the baud rate
  744. control_queued = true;
  745. return;
  746. }
  747. if (pending_control & 4) {
  748. pending_control &= ~4;
  749. ch341_setBaud(1); // send the first byte of the baud rate
  750. control_queued = true;
  751. return;
  752. }
  753. if (pending_control & 8) {
  754. pending_control &= ~8;
  755. uint16_t ch341_format;
  756. switch (format_) {
  757. default:
  758. // These values were observed when used on PC... Need to flush out others.
  759. case USBHOST_SERIAL_8N1: ch341_format = 0xc3; break;
  760. case USBHOST_SERIAL_7E1: ch341_format = 0xda; break;
  761. case USBHOST_SERIAL_7O1: ch341_format = 0xca; break;
  762. case USBHOST_SERIAL_8N2: ch341_format = 0xc7; break;
  763. }
  764. println("CH341: 40, 0x9a, 0x2518: ", ch341_format, HEX);
  765. mk_setup(setup, 0x40, 0x9a, 0x2518, ch341_format, 0); //
  766. queue_Control_Transfer(device, &setup, NULL, this);
  767. control_queued = true;
  768. return;
  769. }
  770. if (pending_control & 0x10) {
  771. pending_control &= ~0x10;
  772. // This is setting handshake need to figure out what...
  773. // 0x20=DTR, 0x40=RTS send ~ of values.
  774. println("CH341: 0x40, 0xa4, 0xff9f, 0, 0 - Handshake");
  775. mk_setup(setup, 0x40, 0xa4, 0xff9f, 0, 0); //
  776. queue_Control_Transfer(device, &setup, NULL, this);
  777. control_queued = true;
  778. return;
  779. }
  780. if (pending_control & 0x20) {
  781. pending_control &= ~0x20;
  782. // This is setting handshake need to figure out what...
  783. println("CH341: c0, 95, 0x706, 0, 8 - get status");
  784. mk_setup(setup, 0xc0, 0x95, 0x706, 0, sizeof(setup)); //
  785. queue_Control_Transfer(device, &setup, setupdata, this);
  786. control_queued = true;
  787. return;
  788. }
  789. if (pending_control & 0x40) {
  790. pending_control &= ~0x40;
  791. print(" Returned: ");
  792. print_hexbytes(transfer->buffer, transfer->length);
  793. println("CH341: 0x40, 0x9a, 0x2727, 0, 0");
  794. mk_setup(setup, 0x40, 0x9a, 0x2727, 0, 0); //
  795. queue_Control_Transfer(device, &setup, NULL, this);
  796. return;
  797. }
  798. if (pending_control & 0x80) {
  799. pending_control &= ~0x80;
  800. println("CH341: 0x40, 0xa4, 0xffff, 0, 0 - Handshake");
  801. mk_setup(setup, 0x40, 0xa4, 0xffff, 0, 0); //
  802. queue_Control_Transfer(device, &setup, NULL, this);
  803. control_queued = true;
  804. return;
  805. }
  806. }
  807. //-------------------------------------------------------------------------
  808. // First CP210X
  809. if (sertype == CP210X) {
  810. if (pending_control & 1) {
  811. pending_control &= ~1;
  812. // set data format
  813. uint16_t cp210x_format = (format_ & 0xf) << 8; // This should give us the number of bits.
  814. // now lets extract the parity from our encoding bits 5-7 and in theres 4-7
  815. cp210x_format |= (format_ & 0xe0) >> 1; // they encode bits 9-11
  816. // See if two stop bits
  817. if (format_ & 0x100) cp210x_format |= 2;
  818. mk_setup(setup, 0x41, 3, cp210x_format, 0, 0); // data format 8N1
  819. println("CP210x setup, 0x41, 3, cp210x_format ",cp210x_format, HEX);
  820. queue_Control_Transfer(device, &setup, NULL, this);
  821. control_queued = true;
  822. return;
  823. }
  824. // set baud rate
  825. if (pending_control & 2) {
  826. pending_control &= ~2;
  827. setupdata[0] = (baudrate) & 0xff; // Setup baud rate 115200 - 0x1C200
  828. setupdata[1] = (baudrate >> 8) & 0xff;
  829. setupdata[2] = (baudrate >> 16) & 0xff;
  830. setupdata[3] = (baudrate >> 24) & 0xff;
  831. mk_setup(setup, 0x40, 0x1e, 0, 0, 4);
  832. println("CP210x Set Baud 0x40, 0x1e");
  833. queue_Control_Transfer(device, &setup, setupdata, this);
  834. control_queued = true;
  835. return;
  836. }
  837. // Appears to be an enable command
  838. if (pending_control & 4) {
  839. pending_control &= ~4;
  840. memset(setupdata, 0, sizeof(setupdata)); // clear out the data
  841. println("CP210x 0x41, 0, 1");
  842. mk_setup(setup, 0x41, 0, 1, 0, 0);
  843. queue_Control_Transfer(device, &setup, NULL, this);
  844. control_queued = true;
  845. return;
  846. }
  847. // MHS_REQUEST
  848. if (pending_control & 8) {
  849. pending_control &= ~0x88;
  850. mk_setup(setup, 0x41, 7, 0x0303, 0, 0);
  851. queue_Control_Transfer(device, &setup, NULL, this);
  852. control_queued = true;
  853. println("CP210x 0x41, 7, 0x0303");
  854. return;
  855. }
  856. }
  857. }
  858. #define CH341_BAUDBASE_FACTOR 1532620800
  859. #define CH341_BAUDBASE_DIVMAX 3
  860. void USBSerialBase::ch341_setBaud(uint8_t byte_index) {
  861. if (byte_index == 0) {
  862. uint32_t factor;
  863. uint16_t divisor;
  864. factor = (CH341_BAUDBASE_FACTOR / baudrate);
  865. divisor = CH341_BAUDBASE_DIVMAX;
  866. while ((factor > 0xfff0) && divisor) {
  867. factor >>= 3;
  868. divisor--;
  869. }
  870. factor = 0x10000 - factor;
  871. factor = (factor & 0xff00) | divisor;
  872. setupdata[0] = factor & 0xff; // save away the low byte for 2nd message
  873. println("CH341: 40, 0x9a, 0x1312... (Baud word 0):", factor, HEX);
  874. mk_setup(setup, 0x40, 0x9a, 0x1312, factor, 0); //
  875. } else {
  876. // Second packet use the byte we saved away during the calculation above
  877. println("CH341: 40, 0x9a, 0x0f2c... (Baud word 1):", setupdata[0], HEX);
  878. mk_setup(setup, 0x40, 0x9a, 0x0f2c, setupdata[0], 0); //
  879. }
  880. queue_Control_Transfer(device, &setup, setupdata, this);
  881. control_queued = true;
  882. }
  883. /************************************************************/
  884. // Interrupt-based Data Movement
  885. /************************************************************/
  886. void USBSerialBase::rx_callback(const Transfer_t *transfer)
  887. {
  888. if (!transfer->driver) return;
  889. ((USBSerial *)(transfer->driver))->rx_data(transfer);
  890. }
  891. void USBSerialBase::tx_callback(const Transfer_t *transfer)
  892. {
  893. if (!transfer->driver) return;
  894. ((USBSerial *)(transfer->driver))->tx_data(transfer);
  895. }
  896. void USBSerialBase::rx_data(const Transfer_t *transfer)
  897. {
  898. uint32_t len = transfer->length - ((transfer->qtd.token >> 16) & 0x7FFF);
  899. debugDigitalToggle(6);
  900. // first update rxstate bitmask, since buffer is no longer queued
  901. if (transfer->buffer == rx1) {
  902. rxstate &= 0xFE;
  903. } else if (transfer->buffer == rx2) {
  904. rxstate &= 0xFD;
  905. }
  906. // get start of data and actual length
  907. const uint8_t *p = (const uint8_t *)transfer->buffer;
  908. if (sertype == FTDI) {
  909. if (len >= 2) {
  910. p += 2;
  911. len -= 2;
  912. } else {
  913. len = 0;
  914. }
  915. }
  916. if (len > 0) {
  917. print("rx token: ", transfer->qtd.token, HEX);
  918. print(" transfer length: ", transfer->length, DEC);
  919. print(" len:", len, DEC);
  920. print(" - ", *p, HEX);
  921. println(" ", *(p+1), HEX);
  922. print("rx: ");
  923. print_hexbytes(p, len);
  924. }
  925. // Copy data from packet buffer to circular buffer.
  926. // Assume the buffer will always have space, since we
  927. // check before queuing the buffers
  928. uint32_t head = rxhead;
  929. uint32_t tail = rxtail;
  930. if (++head >= rxsize) head = 0;
  931. uint32_t avail;
  932. if (len > 0) {
  933. //print("head=", head);
  934. //print(", tail=", tail);
  935. avail = rxsize - head;
  936. //print(", avail=", avail);
  937. //println(", rxsize=", rxsize);
  938. if (avail > len) avail = len;
  939. memcpy(rxbuf + head, p, avail);
  940. if (len <= avail) {
  941. head += avail - 1;
  942. if (head >= rxsize) head = 0;
  943. } else {
  944. head = len - avail - 1;
  945. memcpy(rxbuf, p + avail, head + 1);
  946. }
  947. rxhead = head;
  948. }
  949. // TODO: can be this more efficient? We know from above which
  950. // buffer is no longer queued, so possible skip most of this work?
  951. rx_queue_packets(head, tail);
  952. }
  953. // re-queue packet buffer(s) if possible
  954. void USBSerialBase::rx_queue_packets(uint32_t head, uint32_t tail)
  955. {
  956. uint32_t avail;
  957. if (head >= tail) {
  958. avail = rxsize - 1 - head + tail;
  959. } else {
  960. avail = tail - head - 1;
  961. }
  962. uint32_t packetsize = rx2 - rx1;
  963. if (avail >= packetsize) {
  964. if ((rxstate & 0x01) == 0) {
  965. queue_Data_Transfer(rxpipe, rx1, packetsize, this);
  966. rxstate |= 0x01;
  967. } else if ((rxstate & 0x02) == 0) {
  968. queue_Data_Transfer(rxpipe, rx2, packetsize, this);
  969. rxstate |= 0x02;
  970. }
  971. if ((rxstate & 0x03) != 0x03 && avail >= packetsize * 2) {
  972. if ((rxstate & 0x01) == 0) {
  973. queue_Data_Transfer(rxpipe, rx1, packetsize, this);
  974. rxstate |= 0x01;
  975. } else if ((rxstate & 0x02) == 0) {
  976. queue_Data_Transfer(rxpipe, rx2, packetsize, this);
  977. rxstate |= 0x02;
  978. }
  979. }
  980. }
  981. }
  982. void USBSerialBase::tx_data(const Transfer_t *transfer)
  983. {
  984. uint32_t mask;
  985. uint8_t *p = (uint8_t *)transfer->buffer;
  986. debugDigitalWrite(5, HIGH);
  987. if (p == tx1) {
  988. println("tx1:");
  989. mask = 1;
  990. //txstate &= 0xFE;
  991. } else if (p == tx2) {
  992. println("tx2:");
  993. mask = 2;
  994. //txstate &= 0xFD;
  995. } else {
  996. debugDigitalWrite(5, LOW);
  997. return; // should never happen
  998. }
  999. // check how much more data remains in the transmit buffer
  1000. uint32_t head = txhead;
  1001. uint32_t tail = txtail;
  1002. uint32_t count;
  1003. if (head >= tail) {
  1004. count = head - tail;
  1005. } else {
  1006. count = txsize + head - tail;
  1007. }
  1008. uint32_t packetsize = tx2 - tx1;
  1009. // Only output full packets unless the flush bit was set.
  1010. if ((count == 0) || ((count < packetsize) && ((txstate & 0x4) == 0) )) {
  1011. // not enough data in buffer to fill a full packet
  1012. txstate &= ~(mask | 4); // turn off that transfer and make sure the flush bit is not set
  1013. debugDigitalWrite(5, LOW);
  1014. return;
  1015. }
  1016. // immediately transmit another full packet, if we have enough data
  1017. if (count >= packetsize) count = packetsize;
  1018. else txstate &= ~(mask | 4); // This packet will complete any outstanding flush
  1019. println("TX:moar data!!!!");
  1020. if (++tail >= txsize) tail = 0;
  1021. uint32_t n = txsize - tail;
  1022. if (n > count) n = count;
  1023. memcpy(p, txbuf + tail, n);
  1024. if (n >= count) {
  1025. tail += n - 1;
  1026. if (tail >= txsize) tail = 0;
  1027. } else {
  1028. uint32_t len = count - n;
  1029. memcpy(p + n, txbuf, len);
  1030. tail = len - 1;
  1031. }
  1032. txtail = tail;
  1033. queue_Data_Transfer(txpipe, p, count, this);
  1034. debugDigitalWrite(5, LOW);
  1035. }
  1036. void USBSerialBase::flush()
  1037. {
  1038. print("USBSerialBase::flush");
  1039. if (txhead == txtail) {
  1040. println(" - Empty");
  1041. return; // empty.
  1042. }
  1043. debugDigitalWrite(32, HIGH);
  1044. NVIC_DISABLE_IRQ(IRQ_USBHS);
  1045. txtimer.stop(); // Stop longer timer.
  1046. txtimer.start(100); // Start a mimimal timeout
  1047. // timer_event(nullptr); // Try calling direct - fails to work
  1048. NVIC_ENABLE_IRQ(IRQ_USBHS);
  1049. while (txstate & 3) ; // wait for all of the USB packets to be sent.
  1050. println(" completed");
  1051. debugDigitalWrite(32, LOW);
  1052. }
  1053. void USBSerialBase::timer_event(USBDriverTimer *whichTimer)
  1054. {
  1055. debugDigitalWrite(7, HIGH);
  1056. println("txtimer");
  1057. uint32_t count;
  1058. uint32_t head = txhead;
  1059. uint32_t tail = txtail;
  1060. if (head == tail) {
  1061. println(" *** Empty ***");
  1062. debugDigitalWrite(7, LOW);
  1063. return; // nothing to transmit
  1064. } else if (head > tail) {
  1065. count = head - tail;
  1066. } else {
  1067. count = txsize + head - tail;
  1068. }
  1069. uint8_t *p;
  1070. if ((txstate & 0x01) == 0) {
  1071. p = tx1;
  1072. txstate |= 0x01;
  1073. } else if ((txstate & 0x02) == 0) {
  1074. p = tx2;
  1075. txstate |= 0x02;
  1076. } else {
  1077. txstate |= 4; // Tell the TX code to do flush code.
  1078. println(" *** No buffers ***");
  1079. debugDigitalWrite(7, LOW);
  1080. return; // no outgoing buffers available, try again later
  1081. }
  1082. uint32_t packetsize = tx2 - tx1;
  1083. // Possible for remaining ? packet size and not have both?
  1084. if (count > packetsize) {
  1085. txstate |= 4; // One of the active transfers will handle the remaining parts
  1086. count = packetsize;
  1087. }
  1088. if (++tail >= txsize) tail = 0;
  1089. uint32_t n = txsize - tail;
  1090. if (n > count) n = count;
  1091. memcpy(p, txbuf + tail, n);
  1092. if (n >= count) {
  1093. tail += n - 1;
  1094. if (tail >= txsize) tail = 0;
  1095. } else {
  1096. uint32_t len = count - n;
  1097. memcpy(p + n, txbuf, len);
  1098. tail = len - 1;
  1099. }
  1100. txtail = tail;
  1101. print(" TX data (", count);
  1102. print(") ");
  1103. print_hexbytes(p, count);
  1104. queue_Data_Transfer(txpipe, p, count, this);
  1105. debugDigitalWrite(7, LOW);
  1106. }
  1107. /************************************************************/
  1108. // User Functions - must disable USBHQ IRQ for EHCI access
  1109. /************************************************************/
  1110. void USBSerialBase::begin(uint32_t baud, uint32_t format)
  1111. {
  1112. NVIC_DISABLE_IRQ(IRQ_USBHS);
  1113. baudrate = baud;
  1114. bool format_changed = format != format_;
  1115. format_ = format;
  1116. switch (sertype) {
  1117. default:
  1118. case CDCACM: pending_control |= 0x6; break;
  1119. case FTDI: pending_control |= (format_changed? 0xf : 0xe); break; // Set BAUD, FLOW, DTR
  1120. case PL2303: pending_control |= 0x1e; break; // set more stuff...
  1121. case CH341: pending_control |= 0x1e; break;
  1122. case CP210X: pending_control |= 0xf; break;
  1123. }
  1124. if (!control_queued) control(NULL);
  1125. NVIC_ENABLE_IRQ(IRQ_USBHS);
  1126. // Wait until all packets have been queued before we return to caller.
  1127. while (pending_control) {
  1128. yield(); // not sure if we want to yield or what?
  1129. }
  1130. }
  1131. void USBSerialBase::end(void)
  1132. {
  1133. NVIC_DISABLE_IRQ(IRQ_USBHS);
  1134. switch (sertype) {
  1135. default:
  1136. case CDCACM: pending_control |= 0x80; break;
  1137. case FTDI: pending_control |= 0x80; break; // clear DTR
  1138. case PL2303: pending_control |= 0x80; break;
  1139. case CH341: pending_control |= 0x80; break;
  1140. }
  1141. if (!control_queued) control(NULL);
  1142. NVIC_ENABLE_IRQ(IRQ_USBHS);
  1143. // Wait until all packets have been queued before we return to caller.
  1144. while (pending_control) {
  1145. yield(); // not sure if we want to yield or what?
  1146. }
  1147. }
  1148. int USBSerialBase::available(void)
  1149. {
  1150. if (!device) return 0;
  1151. uint32_t head = rxhead;
  1152. uint32_t tail = rxtail;
  1153. if (head >= tail) return head - tail;
  1154. return rxsize + head - tail;
  1155. }
  1156. int USBSerialBase::peek(void)
  1157. {
  1158. if (!device) return -1;
  1159. if (rxhead == rxtail) return -1;
  1160. return rxbuf[rxtail];
  1161. }
  1162. int USBSerialBase::read(void)
  1163. {
  1164. if (!device) return -1;
  1165. if (rxhead == rxtail) return -1;
  1166. int c = rxbuf[rxtail];
  1167. if (++rxtail >= rxsize) rxtail = 0;
  1168. if ((rxstate & 0x03) != 0x03) {
  1169. NVIC_DISABLE_IRQ(IRQ_USBHS);
  1170. rx_queue_packets(rxhead, rxtail);
  1171. NVIC_ENABLE_IRQ(IRQ_USBHS);
  1172. }
  1173. return c;
  1174. }
  1175. int USBSerialBase::availableForWrite()
  1176. {
  1177. if (!device) return 0;
  1178. uint32_t head = txhead;
  1179. uint32_t tail = txtail;
  1180. if (head >= tail) return txsize - 1 - head + tail;
  1181. return tail - head - 1;
  1182. }
  1183. size_t USBSerialBase::write(uint8_t c)
  1184. {
  1185. if (!device) return 0;
  1186. uint32_t head = txhead;
  1187. if (++head >= txsize) head = 0;
  1188. while (txtail == head) {
  1189. // wait...
  1190. }
  1191. txbuf[head] = c;
  1192. txhead = head;
  1193. //print("head=", head);
  1194. //println(", tail=", txtail);
  1195. // if full packet in buffer and tx packet ready, queue it
  1196. NVIC_DISABLE_IRQ(IRQ_USBHS);
  1197. uint32_t tail = txtail;
  1198. if ((txstate & 0x03) != 0x03) {
  1199. // at least one packet buffer is ready to transmit
  1200. uint32_t count;
  1201. if (head >= tail) {
  1202. count = head - tail;
  1203. } else {
  1204. count = txsize + head - tail;
  1205. }
  1206. uint32_t packetsize = tx2 - tx1;
  1207. if (count >= packetsize) {
  1208. //println("txsize=", txsize);
  1209. uint8_t *p;
  1210. if ((txstate & 0x01) == 0) {
  1211. p = tx1;
  1212. txstate |= 0x01;
  1213. } else /* if ((txstate & 0x02) == 0) */ {
  1214. p = tx2;
  1215. txstate |= 0x02;
  1216. }
  1217. // copy data to packet buffer
  1218. if (++tail >= txsize) tail = 0;
  1219. uint32_t n = txsize - tail;
  1220. if (n > packetsize) n = packetsize;
  1221. //print("memcpy, offset=", tail);
  1222. //println(", len=", n);
  1223. memcpy(p, txbuf + tail, n);
  1224. if (n >= packetsize) {
  1225. tail += n - 1;
  1226. if (tail >= txsize) tail = 0;
  1227. } else {
  1228. //n = txsize - n;
  1229. uint32_t len = packetsize - n;
  1230. //println("memcpy, offset=0, len=", len);
  1231. memcpy(p + n, txbuf, len);
  1232. tail = len - 1;
  1233. }
  1234. txtail = tail;
  1235. //println("queue tx packet, newtail=", tail);
  1236. debugDigitalWrite(7, HIGH);
  1237. queue_Data_Transfer(txpipe, p, packetsize, this);
  1238. debugDigitalWrite(7, LOW);
  1239. NVIC_ENABLE_IRQ(IRQ_USBHS);
  1240. return 1;
  1241. }
  1242. }
  1243. // otherwise, set a latency timer to later transmit partial packet
  1244. txtimer.stop();
  1245. txtimer.start(write_timeout_);
  1246. NVIC_ENABLE_IRQ(IRQ_USBHS);
  1247. return 1;
  1248. }