LabWindows/CVI
Serial problem with LabWindows/CVI 8.0.1
We are doing a FlushOutQ call on some of our serial instruments, but they also have the outqueue size == -1 
. The flush call is meaningless I would think in this case.
We don't seem to have trouble with CVI 8.1 RTE on these commercial instruments (five different instruments from five different manufacturers) but we haven't used them a lot under 8.1 because the devices designed in-house have trouble.
We have three different devices using a Xilinx FPGA implementing a serial port using the UartLite IP Core. These stopped dead in their tracks with CVI 8.1, and they have a 512 byte output Q but FlushOutQ is not being called on these.
We run at 57,000bps, 19,200bps, and 115,200 bps on these. All quit working with CVI 8.1. All work with CVI 7.1.1. All are doing volumnuous, full duplex i/o, mostly ooutput from the PC to the device.
We had trouble with these when using a USB - rs-232 converter as well. I suspect something's just not quite right with the Xilinx implementation. Why it would show up so dramatically on 8.1 is still a mystery to me.
Menchar
. The flush call is meaningless I would think in this case.We don't seem to have trouble with CVI 8.1 RTE on these commercial instruments (five different instruments from five different manufacturers) but we haven't used them a lot under 8.1 because the devices designed in-house have trouble.
We have three different devices using a Xilinx FPGA implementing a serial port using the UartLite IP Core. These stopped dead in their tracks with CVI 8.1, and they have a 512 byte output Q but FlushOutQ is not being called on these.
We run at 57,000bps, 19,200bps, and 115,200 bps on these. All quit working with CVI 8.1. All work with CVI 7.1.1. All are doing volumnuous, full duplex i/o, mostly ooutput from the PC to the device.
We had trouble with these when using a USB - rs-232 converter as well. I suspect something's just not quite right with the Xilinx implementation. Why it would show up so dramatically on 8.1 is still a mystery to me.
Menchar
Exactly. The NI library can't directly affect any of the low level behavior of the port - that's controlled by the driver.
That's what makes me think that inter-frame timing may have been shortened up (this is an effect that the 8.1 CVI library could conceivably have induced), and if the UartLite IP Core is, for example, shortening up the stop bit, then this could explain the situation - it's unable to detect the framing if not given some extra time at the end of a frame (effectively stretching the stop bit). Bit clock differences can creep across the frame and are at the greatest variance when sampling the stop bit as well I imagine. PC com ports are supposedly quite tolerant of bit clock errors.
We can send an extra stop bit to the device, that might help it on receive - sending an extra stop bit is always benign according to how I understand serial framing.
I'm not in control of the deployed systems - I can't easily set up a debugging scenario - and since we know that 7.1.1 doesn't show the problem, it's no longer a hot issue, especially since the individuals who implemented the Xilinx don't want me to be able to prove they've screwed up
Thanks for hanging in here with me on this.
menchar
That's what makes me think that inter-frame timing may have been shortened up (this is an effect that the 8.1 CVI library could conceivably have induced), and if the UartLite IP Core is, for example, shortening up the stop bit, then this could explain the situation - it's unable to detect the framing if not given some extra time at the end of a frame (effectively stretching the stop bit). Bit clock differences can creep across the frame and are at the greatest variance when sampling the stop bit as well I imagine. PC com ports are supposedly quite tolerant of bit clock errors.
We can send an extra stop bit to the device, that might help it on receive - sending an extra stop bit is always benign according to how I understand serial framing.
I'm not in control of the deployed systems - I can't easily set up a debugging scenario - and since we know that 7.1.1 doesn't show the problem, it's no longer a hot issue, especially since the individuals who implemented the Xilinx don't want me to be able to prove they've screwed up
Thanks for hanging in here with me on this.
menchar
More info - I didn't fully respond to Mert's questions.
The effect is that the serial link to the Xilinx-based device breaks. They don't do a good job with error handling, so they're really not sure just what's gone wrong - whether it's an error returned from a serial library call, or whether a CRC doesn't match, or whether a command wasn't ACK'd - they don't know.
I could resolve this most likely simply by putting a scope on the serial port and looking at frames. They could add error handling also to resolve this but they don't really want to and I'm not going to do it for free
But - I don't want to get frozen at CVI 8.0 from now on out because some goober mis-implemented a serial port in an FPGA. We are telling the world it's an rs-232 / rs-422 serial port too - sooner or later one of our customers will be calling and asking why the serial com doesn't work.
As far as the FlushOutQ() race, I guess I'm curious how that manifests. If you've got data in the outqueue, and you flush it before it's been emitted (or more likely, handed off to the serial driver) I don't know what you would expect to happen, other than some of the data may get flushed. Maybe if the flush isn't fully effective - some data squeaks out after the flush.
Menchar
The effect is that the serial link to the Xilinx-based device breaks. They don't do a good job with error handling, so they're really not sure just what's gone wrong - whether it's an error returned from a serial library call, or whether a CRC doesn't match, or whether a command wasn't ACK'd - they don't know.
I could resolve this most likely simply by putting a scope on the serial port and looking at frames. They could add error handling also to resolve this but they don't really want to and I'm not going to do it for free
But - I don't want to get frozen at CVI 8.0 from now on out because some goober mis-implemented a serial port in an FPGA. We are telling the world it's an rs-232 / rs-422 serial port too - sooner or later one of our customers will be calling and asking why the serial com doesn't work.
As far as the FlushOutQ() race, I guess I'm curious how that manifests. If you've got data in the outqueue, and you flush it before it's been emitted (or more likely, handed off to the serial driver) I don't know what you would expect to happen, other than some of the data may get flushed. Maybe if the flush isn't fully effective - some data squeaks out after the flush.
Menchar
