bjarnoldus commented 10 years ago

I have a question and was hoping you would be able to help me with this. I'm using the PL2303 driver on OS X 10.8 and I noticed that when I transmit a 0xFF byte it actually sends 2 0xFF bytes (I can see this on the TX pin using a CRO). I had a look at the source and noticed the code below, which I'm guessing is the cause.

if FIX_PARITY_PROCESSING

    if(*Buffer == 0xff)
        addBytetoQueue(Queue, 0xff);

endif

Is this correct behavior and if so is there a way around this? The device I'm talking to returns an error when I send a packet containing a FF byte.

Just FYI, I used the code below for testing below:

_fd = open([name UTF8String], O_RDWR | O_NOCTTY | O_NONBLOCK );

if (_fd != -1)
{
    struct termios newtio;

    bzero(&newtio, sizeof(newtio));
    cfmakeraw(&newtio);
    newtio.c_cflag = CS8 | CLOCAL | CREAD | PARENB;
    newtio.c_iflag = IGNPAR | IGNBRK;
    newtio.c_oflag = 0;
    newtio.c_lflag = 0;
    newtio.c_cc[VMIN]=0;
    newtio.c_cc[VTIME]=10;
    cfsetispeed (&newtio, B115200);
    cfsetospeed (&newtio, B115200);

    tcflush(_fd, TCIOFLUSH);
    tcsetattr(_fd,TCSANOW,&newtio);

    int flags = fcntl(_fd, F_GETFL);
    fcntl(_fd, F_SETFL, flags & ~O_NONBLOCK);
}

const uint8_t data[] = { 0xFF, 0x00, 0xFF, 0x00, 0xFF, 0x00, 0xFF, 0x00, 0xFF, 0x00 };
while (true)
{
    write (_fd, data, 1);
    usleep(100*1000);
}

Kind Regards, Martin

bjarnoldus commented 10 years ago

https://github.com/morpheby/osx-pl2303/commit/2709e5bf91cf3c3258fb6353cebd66940a79de23

ghost commented 10 years ago

I just ran into this today. Is there a fix forthcoming?

Regards,

_murat

tfeldmann commented 10 years ago

This bit me today. I thought it was my code -- took some hard hours to debug! A fix would be very much appreciated.

bjarnoldus commented 9 years ago

I removed the parity handling for now. This problem should be solved.

bjarnoldus / mac-osx-pl2303

PARITY_PROCESSING introduces error #1

if FIX_PARITY_PROCESSING

endif