how to save data from COM port to file?

[MoReese]

You can adjust the port buffer by using the Set I/O Buffer Size function in the Serial palette.  You can transfer as much as you want, but you will be limited in buffer size by your system.  You should not need a buffer 1G in size.  You can control the data transfer with your control characters (or proper handshaking), sending the data in segments, one segment at a time.

[LV_Enthu]

Using proper segments means, after every 256bytes, do I have to send any character from Labview into uC
To reinitiate transfer of data stream? this would act like a handshake signal in itself correct?
This would probably add up into system delay...

[MoReese]

Yes, you could use it that way.  Is there some reason you are limited to 256 bytes per data transfer?  Without handshaking, you will need some flag control like you have mentioned to control your packet transfers.  With this, you send out a packet with a start and end flag and wait for a response (acknowledge) from LV.  This can be another control character.  I am not sure what the maximum buffer size is for your PC, but the Set Buffer Size function defaults to 4096 bytes.  You may be able to up the baud rate on your serial port depending on what your uC can handle as well.  With 1G of info to transfer, push your Com port speed as fast as possible.

[LV_Enthu]

MoReese, i am not sure if i am following you completely... here is what is happening..

when i send 255 bytes from my uC to LV, LV completes the transfer successfully in like fraction of second, and the LV program stops ( i have programmed it that way, when an end of stream comes, 

stop data transfer).

however, when i send 256 bytes, the program keeps on running continously and the size of the datafile keeps on incrementing up to MEGA BYTES.... attached is the updated snapshot of vi

[LV_Enthu]

@all, i solved the problem.. the problem was in my uC code...

Edit: I will post the code... let me first check if everything is well...

i had declared the counter index in uC as unsigned char instead of unsigned int...

now i have to check what would be the problem when i try and transfer huge data sizes... up to 1GB...

[MoReese]

Can you post your code instead of just a screen shot?

Edit:  Never mind then.  Glad to hear it.

[LV_Enthu]

---

@Ravens Fan wrote:

If you are sending ASCII type of data, then using a special character such as a line feed (x0A) or a null (x00) is a good way to go.  If you are sending binary type of data where a byte could be any value, then you can't use a special character.  So the best way then is to setup up your messages so that the data is prepended with 1 or more bytes (always the same number) that reflects how many more bytes follow.  So you read a byte, let's say it is 32, then you keep reading until you receive 32 bytes.  If you want a full fledged protocol, you could also have special bytes that might be a start byte, end byte, a checksum, etc.  So a typical package of data might be Start byte, 2 bytes for number of bytes to follow, your data package, perhaps 2 bytes for CRC-16 checksum, then and ending byte.

---

@RavensFan, i think I am running into the problem you mentioned of sending binary data over UART... actually, i would be sending the hex values of some voltage readings from uC to PC. so there is a possibility that I might be sending the hex values of special characters as well.. like NULL (0x00) ...

Also, my length of data is also not fixed... it might be 1GB at a given instant or 100MB at second, so, how can i approach this problem?

thanks

[RavensFan · Accepted solution]

You would create a protocol just like I said in message 23.

You use some bytes that can help define the beginning and end of a message.  You can't rely on these completely, since it is binary data, your marker bytes could show up in the real data stream as well.  But they can help you figure out whether you are not at the beginning of a message packet.

But the important thing is a couple of bytes (or perhaps 4 bytes) that define how much data there is too follow.  Then you keep reading whatever data is available until you've received that many bytes.  Look at the examples for simple data client and simple data server in the Example Finder.  While that is for TCP/IP connections, it is a similar concept of what you want to do with your serial port.  Of course you can't read 1 GB of data all at once.  But you can keep collecting data and summing it up in a shift register until you've determined you read 1 billion bytes.