Devices that use FTDI but are not...

Bunny

Bunny

I have a device, it's an 0590:00d4 temperature sensor. Technically, it's an embedded FTDI and runs at 115200 baud connected to a host of sensors in a package the size of your thumbnail. It's actually quite nifty. A 2JCIE-BU01 by Omron.
You can read about them here: OMRON SITE.

With a simple command like this on $linux-of-choice, I get a serial port I can talk to.
ACTION!="add|change", GOTO="permissions_end"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", \
ATTRS{idVendor}=="0590", ATTRS{idProduct}=="00d4", \
RUN+="/sbin/modprobe ftdi_sio", \
RUN+="/bin/sh -c 'echo 0590 00d4 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'"
LABEL="permissions_end"
Click to expand...
No compiling things, nothing. From then on, my random device gets treated just as if it was a serial port. (Of course, I have to find it and positively ID it, but that isn't too hard.)

What is the FreeBSD equivalent? At first I thought devd could do something like "if you see this, it's actually an ftdi" but no joy.

Someone is bound to suggest "change the VID/PID", while that may be a work around, it is not a solution.
 
Is it an FT232 chip? It's a common chip used for USB to serial, but can also do GPIO, I2C, etc.
 
There is a config file that overrides which vendor/product IDs get mapped to which driver. Given that this is an FTDI chip, and given that on Linux it can use the standard USB serial driver and then looks like a standard serial port, it probably will be handled by the FreeBSD ucom driver. The only problem is that I can't remember what file that is; I used to think it was /etc/usb-something or /etc/dev-something.
 
Phishfry said:
No add VID/PID to ufdti and usbdevs. Recompile kernel. That is the solution to step one.

Click to expand...
Thanks for this and to the OP for this thread. I have a similar issue with a barcode printer which can emulate an FTDI USB to serial adapter and connect via it's USB port. (I also used a very similar udev rule to the OP in Linux to achieve the same end and it works there). If I can get it working, I'm happy to document the process. Will report back (eventually) if I have any success.
 
Ok success.

Here is how I did it:

First you will need to ensure you have the source component installed and your system fully up to date.

If you don't have src enabled, you can enable it in /etc/freebsd-update.conf. You should then be able to run freebsd-update to get the source.

Code: 
# Components of the base system which should be kept updated.
Components src world kernel

Also for other methods, such as git:
docs.freebsd.org

Chapter 26. Updating and Upgrading FreeBSD

Information about how to keep a FreeBSD system up-to-date with freebsd-update or Git, how to rebuild and reinstall the entire base system, etc
docs.freebsd.org docs.freebsd.org

(you may still have to git pull the source first to /usr/src before freebsd-update can upgrade it - I can't recall that bit, as I always just install source anyway)

Then add a line for your vendor, if it doesn't already exist in the file, to the bottom of the vendor list in /usr/src/sys/dev/usb/usbdevs. I suggest you back up this file first.

This is the line for my particular case:

Code: 
vendor CITIZEN          0x2730  Citizen Systems

Followed by a section under the "product" stanzas further down:

Code: 
/* Citizen Barcode printer products */
product CITIZEN CITIZEN_USB_SERIAL             0x0fff  FTDI compatible adapter

You would need to add your product/vendor and product/vendor IDs instead.

Then add a line for your device in /usr/src/sys/dev/usb/serial/uftdi.c :

Code: 
static const STRUCT_USB_HOST_ID uftdi_devs[] = {
#define UFTDI_DEV(v, p, i) \
  { USB_VPI(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, i) }
        UFTDI_DEV(ACTON, SPECTRAPRO, 0),
        UFTDI_DEV(ALTI2, N3, 0),
        UFTDI_DEV(ANALOGDEVICES, GNICE, UFTDI_JTAG_IFACE(0)),
        UFTDI_DEV(ANALOGDEVICES, GNICEPLUS, UFTDI_JTAG_IFACE(0)),
        UFTDI_DEV(ATMEL, STK541, 0),
        UFTDI_DEV(BAYER, CONTOUR_CABLE, 0),
        
        [...]

        UFTDI_DEV(TML, USB_SERIAL, 0),
        UFTDI_DEV(TTI, QL355P, 0),
        UFTDI_DEV(UBLOX, XPLR_M9, 0),
        UFTDI_DEV(UNKNOWN4, NF_RIC, 0),
        UFTDI_DEV(CITIZEN, CITIZEN_USB_SERIAL , 0),
#undef UFTDI_DEV
};

In my case it's the "CITIZEN_USB_SERIAL" line. You would give it a different name, to reflect your specific hardware, but it must match what you defined in usbdevs.

Finally you will need to recompile the kernel and reboot. This should only be a matter of:

Code: 
# cd /usr/src
# make -j4 buildkernel
# make installkernel
# reboot

But refer to documentation for your own specific case: https://docs.freebsd.org/en/books/handbook/kernelconfig/

In my case, the device and mode of operation is rather obscure - i.e. hardly anyone uses these printers in "virtual com port" mode, so I doubt there will be much interest in committing this change.
 
Thanks for your interest Phishfry and apologies for the late response.

The virtual COM mode has to be enabled within the printer's own configuration. When in the default "Printer" device class mode, the device detects and installs as a typical "line printer" device and is usable for most use cases. In Virtual COM mode, the only supported option is a Windows driver from the vendor, which doesn't seem to be well maintained.

In my specific case, a serial connection is used and the software communicates directly with the printer using the supported Datamax emulation. So there is no CUPS or printer drivers involved, regardless of the OS.

So it could literally be just me with this requirement.

I've tested on a CL-S521 CL-S521II. The similar "621" models will also work. All of these are based on a nearly 20 year old design, with some small improvements, mostly in firmware.

Some of their newer machines have the FTDI chip integrated - so no idea if those will be easier or more difficult to get working. I might actually have one of those lying around and could test it. (They're likely integrating the FTDI chip so that they can do away with the physical serial port and controller chip to cut costs.)

Anyway 2 months later and nothing from the OP, which is a pity as I don't think the solution I posted above is that complex - and I believe it will work for them.
 
You must log in or register to reply here.
Back
Top