I am trying to implement a USBSerial device on an STM32F756 custom hardware.
According to the docs, USBSerial inherits from FileHandle. However, I have been unsuccessful in using the USBSerial class as a FileHandle, since it appears the Stream class marks many of the FileHandle functions as protected. The mcu enumerates properly as a COM port on windows, so everything seems to be working in that regard.
I have tried USBSerial::printf, with no success. I have tried USBSerial::getc and ::putc, with no success. I have tried polling the USBSerial in its own thread, with no success. I have attached callbacks using USBSerial::attach. This does in fact trigger the callback when I send a character through my terminal software, however, getc returns 0xFF and not the character I typed. After the first event, it does not seem to work again.
I have delved way deeper into the USBSerial class than I ever wanted to and found that there seems to be an expectation that the flow control pins are necessary, so I configured PuTTY to set the DTR pin, and this did not work.
The USBSerial example in the handbook is laughably brief and incomplete, and I have scoured the forums for a definitive example of how to actually read and write bytes into the USB port. Can anyone provide a better example?
I was able to re-implement the FileHandle API that i needed (read, write) but I had to do so in the USBSerial class, which is ridiculous. All it takes is calling send/send_nb and receive/receive_nb in a FileHandle confoming read/write function.
I think I understand what you are suggesting, since the Stream API should support being treated like a file. However, I don’t think this will work for me as I’m trying to do raw communication, not formatted text (which is what Stream provides).
I find it absurd that a USBSerial device would obfuscate the FileHandle API like this when every other Serial class supports it. This is a common use case for USBSerial devices, but alas, the implementation does not agree.
I am now having a new issue, which is that my USB packets are not actually pushed up the stack to the application unless I first set a breakpoint inside the USBCDC::_receive_isr function, which is bizarre.