Does the Bytes At Port property node "read out" the bytes from the UART FIFO?

[Broken_Arrow]

I've been using Bytes at Port with expected results for years (well, at least since VISA was forced on us in Version 7). I've recently ran into a situation where it is important to know if that property node (Bytes at Port) is physically shifting out the bytes in the hardware UART in order to get it's answer.

For example, Serial Read, if wired "hard-wired" to read 36 bytes, should read out 36 bytes and they're gone forever. But lets say we never use Read, just Bytes at Port, and it says there's 36. How does it know there's 36 bytes without pulling the bytes out of the UART?

Any insight would be appreciated.

Message Edited by Broken Arrow on 02-29-2008 10:22 PM
a spell checker would be nice
Message Edited by Broken Arrow on 02-29-2008 10:22 PM

Message Edited by Broken Arrow on 02-29-2008 10:25 PM

[rpursley8]

I think the data is read out of the UART and stored in a receive buffer.  The Bytes at Port actually lets you know how many bytes are in the buffer.  Hopefully a NI guy will respond to confirm or correct.

[tst]

I don't have an answer, but:

---

Broken Arrow wrote:

a spell checker would be nice

---

At least in Internet Explorer you have a button in the message editor which opens a spell checker: .

[Broken_Arrow]

No ideas on this issue? NI ? Dennis? Peter Griffin?

[pBerg]

Howdy BA,

The device driver automatically moves bytes of data from the UART into the software buffer. This happens automatically. What the Bytes at Port property does is it counts the number of bytes in the software buffer and returns this value based on the number of bytes in the software buffer--not the UART.

I hope this helps!

[Broken_Arrow]

Great answer pBerg, thanks.

...so let me ask this. Given that the UART in questions is divided up into 4 parts, and let say the parts are 16, 32, 64, and 128 bytes, and knowing that on a hardware level, you can only tell if a UART is 1/4 full, 1/2 full, 3/4 full, or 4/4 full, how does LabVIEW (VISA) tell that there are (for example) 2 bytes "at port" since you have to shift out an entire 1/4 of the UART, so in our case, you can only tell if there was 16, 32, 64, and 128 bytes, not 2. (??)

[pBerg]

Howdy BA,

Could you perhaps give me a brief overview of your application that led you to these questions? I wonder if maybe we're going down a stray path here in troubleshooting an issue.

[Broken_Arrow]

pBerg,
It's not a troubleshooting issue, it's that I have had to recently describe how my code woks to low-level (hardware) engineers. When I say something like "Bytes at Port" they go ballistic. They proceed with "what the %#@& is Bytes at Port"? "Bytes in the UART FIFO?", "bytes in a predetermined software buffer"? "bytes in a dynamically allocated buffer?" Where is this buffer? Show it to me! etc, etc.

In typical NI fashion, like the link you provided, we get only very high level descriptions as to what's occurring when we use a function like the "Bytes at Port" property node.

Getting back to my UART example, a hardware engineer may have a hard time believing that software has the ability to pull less 1/4 of a 4/4 part UART FIFO because the FIFO register only has the ability to say he's full or not full.

In essence, there's an intermediate layer of intelligence missing between the hardware engineer describing how his FIFO works, and how VISA can tell him that there's exactly 2 bytes available to be read.

Thanks for looking!

[RavensFan]

I must say I've never heard of 1/4 vs. 4/4 of a UART buffer.

It sounds to me like the intermediate level of intelligence is missing between the ears of the hardware engineer.

You'd think if he knows that much about UART's at the hardware level, he'd have some clue about how most modern serial port drivers would communicate with them.  Much more so than software guys who know how to make LabVIEW or VB or C or whatever communicate with the driver and just trust and rely on the drivers that are well established and work properly.

[pBerg]

Howdy BA,

The mechanics differ for each UART. How we handle and the details of how UARTs work with our driver is something R&D has not given permission to release. I would just communicate to your engineers that the driver simply moves the data from the UART to a software buffer and that the Bytes at Port property returns the number of bytes sitting in the software buffer waiting to be read by something like a VISA Read.