0

I'm attempting to write to the parallel port for the first time using the vxWorks lptDrv driver, but a call to write() always seems to return a -1. Here's the code I'm using:

#define PARALLEL_PORT "/lpt/0"

/* Create a device for the parallel port */
lptDevCreate(PARALLEL_PORT,0)

/*open the parallel port*/
parallelPortFD = open(PARALLEL_PORT,  O_CREAT|O_WRONLY, 0))

LOCAL UINT32 watchdogBit = 0x01;
if (write(parallelPortFD, (char*) watchdogBit, sizeof(UINT32)) == -1)
{
    /* Always hits this block */
}

Both calls to lptDevCreate and open return okay. I currently don't have the hardware plugged into the parallel port, so that makes it difficult to test, but I don't think that would cause a write failure either.

For some more info, I was able to call lptShow(), but I'm not sure what I'm looking at:

controlReg        = 0xff
statusReg         = 0xff
created           = TRUE
autofeed          = TRUE
inservice         = FALSE
normalInt         = 0
defaultInt        = 0
retryCnt          = 1
busyWait   (loop) = 10000
strobeWait (loop) = 10000
timeout    (sec)  = 1
intLevel   (IRQ)  = 7
bjsample
  • 45
  • 1
  • 5
  • What vxWorks version, board & BSP? Those are essential elements when dealing with hardware issues. Looking at the show routine, doesn't look like you're talking to the port hardware and interrupt aren't hooked up. You should look at lpt driver source code. – Benoit Dec 17 '11 at 14:40
  • vxWorks 6.7 using the Intel Core 2 BSP on the Cook Forest Board. I think. I'm pulling my information from code and didn't do the initial hardware/BSP setup (nor do I know how). I believe I corrected one problem. The kernel configuration had a different port number than the BIOS, so I updated the kernel config to match. I see "controlReg = 0xe" and "statusReg = 0x78" now when doing an lptShow(). However, I still get an error when calling write(). – bjsample Dec 23 '11 at 17:21

1 Answers1

0

The kernel configuration had a different port number than the BIOS, so I updated the kernel config to match. That then showed the statusReg set to 0x78, indicating that 1. the port was busy and 2. an out of paper error. Since nothing was plugged into the parallel port, it showed a 0x78 as the default status. I still don't have the hardware to test the port, but wind river support was seeing similar results without a device plugged in, which was then corrected when something was connected to the port. Thanks to Benoit for the response that got me moving again.

bjsample
  • 45
  • 1
  • 5