Poor choices for USB descriptor on CFA735

[tedmarshall]

It's probably too late to change, but Crystalfontz make some poor decisions on the contents of the USB descriptor for the new CFA735. When I plugged one into a Linux box (recent Ubuntu), it enumerated as /dev/ttyACM0 (Abstract Communications Modem) instead of /dev/ttyUSB0 (as for CFA635). Checking with "lsusb -v", I discovered the following values in the device's USB descriptor:

bInterfaceClass      2   communications
bInterfaceSubclass   2  Abstract (modem)
bInterfaceProtocol   1  AT-command (v.25ter)

Thus, you are telling the OS that the module is a standard modem! By the way, the OS driver also tries to talk AT protocol to the device. This has no real effect but is kind of ugly.

This is not a real big deal. Changing my code to talk to /dev/ttyACM0 makes everything work fine. However, this could have problems if there is other software on the system that tries to talk to a modem on the system. Also, it just plain violates the USB standard!

BTW, the CFA635 sets bInterfaceClass to 255 (vendor specific), as does a USB-to-serial dongle I tried.

I don't know if there is a better set of values to describe a display, but I'd have preferred to see 255, just for backward compatibility.

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[tedmarshall]

I just found another interesting and, so for, undocumented difference between the CFA635 and CFA735.

On the CFA635, the USB interface does not power up the display until the OS driver connects to the device.

On the other hand, the CFA735 powers up the display as soon as it receives 5 volts from the host interface. On the motherboard we use, this occurs as soon as the power supply receives power (but is not yet turned on) and provides +5VSB. Also, at least under Linux, the driver disconnecting from the device on shutdown does not turn off the display on the 735.

Thus, at least under Linux, as long as the computer is plugged in, even if turned off, the 735 display is powered. I haven't tried Windows so I don't know if that driver will power down the display on shutdown, but the display would still power up as soon as the computer is plugged in.

This is actually good for us, as with the 635, we opened JP2 and supplied +5V on H1 to get the same effect and we no longer have to do this. However, I expect that you will receive complaints from some of your other users.

 

[CF Support]

It's probably too late to change, but Crystalfontz make some poor decisions on the contents of the USB descriptor for the new CFA735. When I plugged one into a Linux box (recent Ubuntu), it enumerated as /dev/ttyACM0 (Abstract Communications Modem) instead of /dev/ttyUSB0 (as for CFA635). Checking with "lsusb -v", I discovered the following values in the device's USB descriptor:

bInterfaceClass      2   communications
bInterfaceSubclass   2  Abstract (modem)
bInterfaceProtocol   1  AT-command (v.25ter)

Thus, you are telling the OS that the module is a standard modem! By the way, the OS driver also tries to talk AT protocol to the device. This has no real effect but is kind of ugly.

With this arrangement, the CFA-735 uses communications class driver (USB CDC) for the device as opposed to a custom driver for this product. You did not need to compile anything, taint your kernel, or wait for a driver to be accepted by the community. For us, getting a module to you and working with minimal intervention is valuable. Using the Communication Device Class is common among manufacturers of microcontrollers for just these reasons. Our device responds to the CDC ACM control functions as required by the specification.

Our choice (and many microcontroller vendor's choice) of bInterfaceProtocol = 0x1 (AT-command) was in response to a limitation of an earlier version of Linux to only configure a tty when bInterfaceProtocol = 0x1. Our preference would have been to use 0x0 as it is "No class specific protocol required" or use 0xff for vendor specifc. Using 0x0 does work in modern versions while 0xff does not. We very well may release a new version of the firmware where bInterfaceProtocol = 0x0. If you would like I can send you a beta version of that firmware when available.

It's probably too late to change, but Crystalfontz make some poor decisions on the contents of the This is not a real big deal. Changing my code to talk to /dev/ttyACM0 makes everything work fine. However, this could have problems if there is other software on the system that tries to talk to a modem on the system.

Also, it just plain violates the USB standard!

We appreciate your feedback on this in regards to how it affects you and may affect other customers. We will continue to investigate it. As far as violating the USB standard, we did create a device that conforms to the CDC ACM specification for control and data endpoints. A device using the CDC specification doesn't necessarily have to be a modem, it could have just as easily been part of the Ethernet Emulation Model. Conforming to the Abstract Control Model, which is commonly exposed as a serial style interface, makes the most sense for us and our user base.

It's probably too late to change, but Crystalfontz make some poor decisions on the contents of the
BTW, the CFA635 sets bInterfaceClass to 255 (vendor specific), as does a USB-to-serial dongle I tried.

I don't know if there is a better set of values to describe a display, but I'd have preferred to see 255, just for backward compatibility.

Any USB to serial dongle you have tried under Linux will have a driver in the kernel that would need to be written from scratch or modified to communicate with a new USB device. Their devices that are vendor specific will require a custom protocol.

We appreciate your feedback on this matter and we will evaluate your feedback and that from our other customers to evaluate the impact. We will also be releasing a open source version of the firmware to run on the CFA-735 that you may modify to fit your needs. Any other feedback is appreciated.

 

[CF Support]

I just found another interesting and, so for, undocumented difference between the CFA635 and CFA735.

On the CFA635, the USB interface does not power up the display until the OS driver connects to the device.

On the other hand, the CFA735 powers up the display as soon as it receives 5 volts from the host interface. On the motherboard we use, this occurs as soon as the power supply receives power (but is not yet turned on) and provides +5VSB. Also, at least under Linux, the driver disconnecting from the device on shutdown does not turn off the display on the 735.

Thus, at least under Linux, as long as the computer is plugged in, even if turned off, the 735 display is powered. I haven't tried Windows so I don't know if that driver will power down the display on shutdown, but the display would still power up as soon as the computer is plugged in.

This is actually good for us, as with the 635, we opened JP2 and supplied +5V on H1 to get the same effect and we no longer have to do this. However, I expect that you will receive complaints from some of your other users.

This is a known issue that we are discussing with customers as to which way they prefer. Our current thinking is that we will conform more tightly to the USB specification by default in this regard and give users the option to break conformance with a software configuration.

Thank you for your feedback.

 

[CF Support]

FYI: Sample code for user firmware https://forum.crystalfontz.com/showthread.php?7068-Welcome