using Linux w/ 634 USB

T

ticketstub

New member
Ok folks.. after much frustration with trying to get my 634 serial running on Redhat 7.1 with a Aten USB -> Serial adaptor (pl-2303 chipset)... I've decided to give up. I'm now skeptical whether or not the 634 USB will work under Linux.

So... I should be able to just plug the 634 USB into my USB port and access it via /dev/ttyUSB0, right? Has anyone had success with this?

Just want to check before I drop even more money into this already expensive project..

-Shawn
Crystalfontz LCD Blog
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 
L

lrrp

New member
More info on USB chipset?

Hi,

Based on your answer to Shaun, I've been fighting with the FTDI USB driver (updated to 1.2.1) on my RH8.0 system with very limited success.

I'm guessing that you are using the FT8U232AM and a a SO8 serial EEPROM (to provide the custom product information). I can't verify without de-installing the unit and even then, I'm not sure it's visable.

The unit is reporting the FTDI vendor code (0x0403), but is reporting an odd product ID (I'm guessing it's yours) of 0xFC08 in the /proc/bus/usb/devices data.

The best I've gotten so far is that after mangling the FTD driver to think that the 0xFC08 ID is a FT8U232AM, I can connect to /dev/usb/ttyUSB0 at 19200 8N1 and see the text echoed to the LCD. The problem is that much more than that, including trying to close the connection, and the device and controlling process hang solid. Trying to run lcd4linux clears the screen and then hangs solid. The only way to clear this condition is a reboot -- since the filesystem can't be unmounted cleanly due to the hang, there is also an FSCK on reboot.... :(

Can you confirm the chipset that you are using? I'd like to drop the driver maintainer a note and see if there is any hope of getting the USB 632 working under Linux. To do so, I'm going to need to give him the correct information.

Thanks,

LRRP
 
CF Tech

CF Tech

Administrator
We currenty use these addresses:

0x0403:0xFC08 is a 632
0x0403:0xFC09 is a 634

If you think the identifier is the problem, you could theoretically hack the EEPROM back to the 0x0403:0x6001 so Linux really does think it is just the FTDI bare chip. If you think that is it, PM me and I'll give you instructions. You will need a Windows box for that (sorry).

I would think if the developer were willing to either release the source or add the above addresses in, it should work as well as the FTDI that has the default ID.
 
L

lrrp

New member
Thanks for the reply.

Did you mean to indicate that the 0x0403:0xFC09 is a 634?

Mostly I wanted to verify that you were using a FT8U232AM before I started pestering the driver maintainer.

The identifier should not be a problem. Its easy enough to hack a different ID code into the source and it shouldn't be too hard to re-write the code to handle a fair number of codes that all map back to the same chip. It is an open source driver, so I might even end up providing some patches to do the mapping (even with my poor C skills).

There are other, more signifigant, problems with the driver as a whole right now -- like the driver hand on trying to close the port. Since I was forcing the IDs, I wanted to make sure that I was forcing it to the right chipset (the driver covers a couple hardware variants).

Thanks for the codes, and the confirmation that it's a FT8U232AM (0x0403:0x6001).

LRRP
 
L

lrrp

New member
Thanks. Progress has been one step forward, followed by one step back.

Found references in archived mailing list traffic for the FTDI driver that the latest version (1.2.1) was reworked to support USB subsystem changes in the 2.4.20 kernel and may not work with any older kernels. Too bad nobody thought of adding a comment to the source code to that effect. :rolleyes:

After making the product ID changes to the driver in the kernel source tree and building the kernel, the driver hang problems seem to be resolved.

The problem is that neither lcd4linux or LCDproc will work properly with the display.

The latest version of lcd4linux will draw bars (offset and a little mangled -- but it will draw them), but generally refuses to write text to the display (this would seem to be the easy part). Mailing list traffic indicates that there are known problems with the v2.0 firmware behaving in an odd fashion. One person calims lcd4linux works right on his serial 634 (w/ 2.0FW) about 1 in 20 times.

The latest version of LCDProc (and last night's CVS snapshot) thinks it's running fine, but does nothing with the display.

Both programs work as expected if you set the output to the text based curses display. Minicom works fine, echoing text to the display and is proving to be handy -- allowing me you send a Ctrl-Z to reset the display to a known state.

Will continue to work on this in my spare time and will try to get an enhancement request in to add additional product ID numbers in the serial driver.

LRRP
 
T

ticketstub

New member
Needed to upgrade to RH 7.3

Thanks guys... I spoke with the developer of the USB pl2303 driver and determined that I needed to upgrade my version of RedHat Linux.

Once I upgraded from Redhat 7.1 to Redhat 7.3 (2.4.7) the USB problems were resolved. No more kernal dumps! I have since been able to address the 634 LCD module without any problems at the device address /dev/ttyUSB0

Awwwwyeah!
Shawn
 
L

lrrp

New member
Shawn,

Can you get LCDproc or lcd4linux to work with the display? As you can see in the past postings, I've been working with RH8.0 and with the FTDI driver.

If the pl2303 driver works, it would be strange, but good.

Will have to try it if I ever get out of work this weekend.

LRRP
 
W

wayn3

New member
which version of the kernel?

Are you using the stock kernel sources with 8.0, or are you using the latest stable? 2.4.20 works well with the FT232BM chip. Which version of the ftds_sio driver are you using?
 
L

lrrp

New member
I'm using the 2.4.20 kernel on top of RH 8. I'm using the 1.2.1 driver that was bundled in the 2.4.20 kernel source.

I misread the start of this thread, ticketstub is using a seperate serial to USB converter with his serial 634. I'm using the actual USB 632.

I'd also like to verify that the USB based units should be showing "i19.2k" on display init. From other posts, the "i" is supposed to indicate that the RS232 interface is running in 'inverted" mode. I'd think that if it were wrong, I wouldn't be able to get minicom to echo to the display, but I did want to verify the switch settings that came from the factory are right.

LRRP
 
USB LCD Displays - Graphic and Character LCDs with a Keypad
L

lrrp

New member
OK, after playing around with it for a couple of days, I've been able to get lcd4linux to work after a fashion.

I had to insert delays into the code between any writes that were issued to the serial device. After doing this, the lcd4proc software begain to function normally. It looks like writes that are sent right after each other are stomping on each other.

As far as I know (but can't confirm), the V2.0 serial displays work fine with the normal linux serial driver at 19.2kbit/s. The datasheet for the serial units indicates that no handshaking needs to be done as the display should always complete requests faster than the max serial I/O speed.

Assuming that the above is true, it looks like it may be a problem with the ftdi driver. Will post something to the driver mailing list tonight.

LRRP
 
T

ticketstub

New member
Linux: serial works...USB doesn't

No, I'm not using LCDproc or lcd4linux.. I'm using Cajun.. which is Perl code for MP3 playback that has its own routines for writing to the devices.

I'm using a separate pl2303 based USB --> serial converter...That works fine with the serial-based 634 USB screens at 9600 baud.

HOWEVER!!! I just purchased the USB version of the screens...
I can't get my new 634 USB screens to work with Linux. They aren't being recognized by the RH 7.3 USB modules. That means I don't get a mapping to /dev/ttyUSB0 at all. Humm.. any suggestions? I think this is what you guys are having problems with too!!

Shawn
 
L

lrrp

New member
Ticketstub,

There, so I'm NOT insane after all.... ;)

Here is a quick summary of what I've done so far, YMMV:

0. You should see a device when you cat /proc/bus/usb/devices. It will be identified as a Crystalfontz display. Note the vendor id and the product id in case I mees it up later on in the text.

1. You NEED to use the 2.4.20 kernel. The needed version of the ftdi driver (1.2.1) is included in the source and it needs the USB code from the 2.4.20 or higher kernel.

2. You will need to edit the ftds_sio.h header (this is from memory, so I may be a little off) in linux/drivers/usb/serial. Look for a line in the header file that defines a device with a vendor code of "0403" and product ID of "6001". Change the product ID to "fc09" for the 634.

3. Compile and install new kernel. If the device still doesn't show up, try doing a "depmod ftds_sio".

4. If you are living well, and I haven't mangled the instructions, then /dev/usb/ttyUSB0 should work (path may be different if you aren't using devfs).

Hopefully, Cajun will just work for you at 19.2kbit/s then. I'm very interested in how this turns out for you.

If the above instructions aren't clear enough or if you want to get additional detail, PM me with your e-mail address and I'll write up something better when I get home from the office.

LRRP
 
W

wayn3

New member
lrrp,

I am confirming that I am experiencing the same behavior as you, with the exact set up (assuming you patched the vendor and product codes in the ftdi_sio driver like I did -- under the 8U232AM table).

The interesting thing is that if you connect to the chip with minicom, with 19200 8N1 no hardware flow control, it connects and displays text properly. This doesn't convince me it's a driver problem. I still have some things I want to try first before I draw conclusions.

wayn3
 
W

wayn3

New member
Patch to work around lcd4linux & LCDproc

In order to work around the problems with LCDproc and lcd4linux, change the open() calls to NOT pass O_NDELAY. The open would look like:

fd = open (device, O_RDWR | O_NOCTTY );

This should take care of most problems. I'm looking to get the CFontz driver in LCDproc to be more officially fixed, perhaps this week.

wayn3
 
L

lrrp

New member
Wayn3,

Yes, the serial driver maintainer sent me the same input over the weekend. There is a potential problem with this approach as it may result in a hang on open if the device is unavialable on open.

When I have some time in the next couple days, I'm going to try to play with some different scenarios and see if and where I can get myself in trouble if the O_NDELAY flag is removed. I'm a little afraid that this was an intentional decision to remove the possability of hangs.

I'm still not sure what it says if there aren't any reported problems from people using the non-USB versions of the displays with the v2.0 firmware at 19.2kbit/s.

Thanks,

LRRP
 
M

Membris Khan

New member
Hello guys, I'm from Spain and I have purchased the CF 634 USB (it's incredible!!).

After read this topic I don't yet understand totally what I need in order to get working my LCD module.

I'm using Gentoo Linux and a kernel 2.6.10 compiled by me. I have USB an pl2303 (module) support but I don't have any route in /dev such as /dev/usb/ttyUSB0 or /dev/ttyUSB0.

I don't understand... I need pl2303 or ftdi??.

Exactly, what I have to choose at the kernel menuconfig to support my module?

- USB support
- Prolific 2303 Single Port Serial Driver
- something more??



Until now I think that the route to device was /dev/usb/tts/0 (it's the only that seems to work). When I use test program I have this output but the LCD doesn't show anything.

# ./test632_634 /dev/usb/tts/0 9600
Ultra-simple CFA-632 / CFA-634 command-line communications example.
Crystalfontz America, Inc. http://www.crystalfontz.com

Usage:
./test632_634 PORT BAUD
PORT is something like "/dev/ttyS0" or "/dev/usb/ttyUSB1"
BAUD is 1200, 2400, 4800, 9600 or 19200
To clear the display, enter "clear" as an optional third parameter

Serial_Init:: success
"/dev/usb/tts/0" opened at "9600" baud.

Done.
Click to expand...
Before start with configure on lcd4linux (I have other 2x20 CF parport running succesfuly) I want to be sure that I use correct port/route.

Thanks :)
 
M

Membris Khan

New member
I now really need help, please help me :(

I have compiled my kernel with FTDI support and now my LCD it's registered!

Finally the dev route was /dev/usb/tts/1, but now I have a strange problem... when I run test632_634, the LCD shows a lot of strange characters.

With lcd4linux I get same output but constantly...

There is a photo of the output in the LCD:




I have read around the forum without success but I have not idea about this problem :( :(
 
You must log in or register to reply here.
Top