USB cables

I have just finished designing a board that uses the FTDI quad serial port USB chip. This board is designed to be mounted inside a PC case, so doesn't have a standard USB connector on it and instead has a 4 pin socket that accepts a crimp header style connector. The board worked fine when connected to my Windows PC, but when I installed it inside a PC running Linux it had problems. Everything seemed fine until I started using the USB serial ports - they would work fine at first, but then report errors and eventually the USB device would be disconnected and the 4 serial ports (/dev/ttyUSB0 to 3) would disappear.
The sort of errors appearing in /var/log/syslog were:

Nov 3 13:49:23 minibox2 kernel: [ 1787.820556] usb 5-8: USB disconnect, address 5
Nov 3 13:49:23 minibox2 kernel: [ 1787.820556] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Nov 3 13:49:23 minibox2 kernel: [ 1787.820556] ftdi_sio 5-8:1.0: device disconnected
Nov 3 13:49:23 minibox2 kernel: [ 1787.820556] ftdi_sio 5-8:1.1: device disconnected
Nov 3 13:49:23 minibox2 kernel: [ 1787.820556] ftdi_sio 5-8:1.2: device disconnected
Nov 3 13:49:23 minibox2 kernel: [ 1787.820556] ftdi_sio ttyUSB3: FTDI USB Serial Device converter now disconnected from ttyUSB3
Nov 3 13:49:23 minibox2 kernel: [ 1787.820556] ftdi_sio 5-8:1.3: device disconnected

and

Nov 3 15:37:42 minibox2 kernel: [ 132.047082] hub 5-0:1.0: port 8 disabled by hub (EMI?), re-enabling...
Nov 3 15:37:42 minibox2 kernel: [ 132.047082] usb 5-8: USB disconnect, address 5
Nov 3 15:37:42 minibox2 kernel: [ 132.051081] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Nov 3 15:37:42 minibox2 kernel: [ 132.051081] ftdi_sio 5-8:1.0: device disconnected
Nov 3 15:37:42 minibox2 kernel: [ 132.051081] ftdi_sio 5-8:1.1: device disconnected
Nov 3 15:37:42 minibox2 kernel: [ 132.051081] ftdi_sio 5-8:1.2: device disconnected
Nov 3 15:37:42 minibox2 kernel: [ 132.051081] ftdi_sio ttyUSB3: FTDI USB Serial Device converter now disconnected from ttyUSB3
Nov 3 15:37:42 minibox2 kernel: [ 132.051081] ftdi_sio 5-8:1.3: device disconnected
Nov 3 15:37:42 minibox2 kernel: [ 132.293491] ehci_hcd 0000:00:1d.7: port 8 reset error -110
Nov 3 15:37:42 minibox2 kernel: [ 132.293491] hub 5-0:1.0: hub_port_status failed (err = -32)
Nov 3 15:37:42 minibox2 kernel: [ 132.656542] hub 5-0:1.0: unable to enumerate USB device on port 8
Nov 3 15:38:02 minibox2 kernel: [ 165.111640] ftdi_sio: error from flowcontrol urb
Nov 3 15:38:02 minibox2 kernel: [ 165.111658] ftdi_sio: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW
Nov 3 15:38:02 minibox2 kernel: [ 165.111834] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
Nov 3 15:38:28 minibox2 kernel: [ 203.066197] ftdi_sio ttyUSB2: FTDI USB Serial Device converter now disconnected from ttyUSB2

I first suspected the driver (I didn't spot the "port 8 disabled by hub (EMI?), re-enabling..." messages at first) and tried rebuilding it with no luck. Eventually I realised that it was the cable that I had connecting the USB on my board to the USB header on the PC motherboard. I had made up a cable just using 4 pieces of hookup wire - not such a good idea with the speed of USB - so I suspect that the USB connection to my board was getting excessive noise and errors. All I had to do to fix the problem initially was to twist the D+ and D- wires together - that was enough to improve it and get it working! I recommend, however, using a shielded cable (as recommended by the USB 2.0 standard).

Delphi modal form not closing

I just spent a frustrating afternoon trying to fix a problem in someone else's code written in Delphi 5 (I know it's ancient, but there are good reasons why it hasn't been upgraded).
I had a modal form that was displayed using ShowModal and when a comms error occured I set ModalResult to mrAbort expecting the form to close, but it wouldn't.
The form uses a serial port component (see http://comport.sf.net/ ) and has an OnRxChar callback on the serial port component set up to process characters. The OnRxChar callback is set to a method of the modal form. It turns out that the window won't close until you "unhook" the callback so I had to do the following to get it to close :

// Close the form when an error occurs
procedure TGetFilesForm.Stop;
begin
// Must get rid of the rx callback, otherwise
// the form won't close
if _comport <> nil then
_comport.OnRxChar := nil;
ModalResult := mrAbort;
end;

Convert Postscript to PDF

To get my gschem circuit schematics in PDF I print them from gschem to a Postscript file and then convert the Postscript file to PDF using gs, as follows:
gs -q -dSAFER -dNOPAUSE -dBATCH -sOutputFile=circuit.pdf -sDEVICE=pdfwrite -f circuit.ps

Export gEDA PCB layout to DXF

I am using gEDA PCB to layout a circuit board and needed to export the layout to a DXF file so that the mechanical designer can check it against the plastic housing design. Here's what you do:
1. Export the layout form PCB to Postscript- tick the "multiple files" box so that each page is a separate Postscript file
2. Merge the Postscript files with the outline and assembly with psmerge - "psmerge -opcb.ps pcb.outline.ps pcb.frontassembly.ps"
3. Convert the Postscript file to DXF with pstoedit - "pstoedit -f dxf pcb.ps pcb.dxf"

I usually print out the Postscript file to check the footprints I am using against the actual parts I am using. Note that this does not work if you convert the Postscript files to PDF - you seem to then have a file that does not print out to scale.

Blogging as a personal notebook

I thought I might try this new-fangled blogging thing to see if it is a good way to keep track of useful bits of information, particularly related to my work.
I work with Embedded Systems (electronics and software) so I am continuously finding out new bits of information on hardware or software that I will want to remember some day.