search

davidthings / tinyfpga_bx_usbserial

USB Serial on the TinyFPGA BX
Apache License 2.0
133 stars 38 forks source link

Fix: close #1 Serial port does not mount on MacOS #2

Closed daviddurand closed 4 years ago

daviddurand commented 5 years ago

This change fixed the USB mounting of the serial endpoint for me. I haven't done much testing, but the loopback seems to be working ok on two Mojave instances (laptop and desktop).

Next up... I'm going to see if I can get it connected to the picosoc example.

davidthings commented 5 years ago

Thanks a lot for looking into this David. I'll take a look this w/e.

daviddurand commented 5 years ago

It was fortuitous. I was able to notice that the Mac was requesting string resources, even though all the string IDs in the descriptors were 0. I think this is because you can get the device language that way. Then I saw that the case statement in the state machine was missing not only STRING, but various other requests, and it seemed that the error return was the same for most of them.

Once that was done, the enumeration and creation of the serial device succeeded. I wasn't able to test other OSes yet, but I'd be surprised if replacing undefined behavior with an error result as defined in the USB standard would mess things up. It looks like a few other states/cases could be added to return descriptors individually, but since it's working, why waste cells.

nalzok commented 4 years ago

Hi there, I'm also having issue #1 and I can confirm this pull request can resolve it. The two serial endpoints on my system (macOS Mojave) are called /dev/cu.usbmodem14101 and /dev/tty.usbmodem14101.

What the difference between cu.* and tty.*, by the way?

markoskin commented 4 years ago

Unfortunately this did not fix the Mac OS X issue for me w/Catalina. Not sure how the boot loader works honestly...

daviddurand commented 4 years ago

What the difference between cu.* and tty.*, by the way?

One is the modem version of the serial device. I think the endpoint announces modem control, but doesn't really do anything functional. Since some systems claim modem devices immediately, removing modem-nature from the USB descriptor might help some problems.

nalzok commented 4 years ago

@daviddurand I see. Both seem to have the word "modem" in their names, though. Just curious, should I prefer any one over the other?

daviddurand commented 4 years ago

Unfortunately this did not fix the Mac OS X issue for me w/Catalina. Not sure how the boot loader works honestly...

This code isn't used in the actual boot loader, but was derived from it. The test image that you'll get from make will just echo the stream fed in and out. This project really needs to be connected to something else to be very useful. If you build it you should get a new USB serial device that will just echo back to you. If a new device doesn't show up in /dev/ when you flash the built image, I'd like to know.

@daviddurand I see. Both seem to have the word "modem" in their names, though. Just curious, should I prefer any one over the other?

tty.* version is the "non-modem" version. Sorry, I commented without reading the question carefully. Since these devices aren't really serial lines interfaced to USB, there's likely not any difference, but if you were trying to route IP over it, I think the system would insist on the cu.* version.