by support »
Hello,
I'm glad that you got the previous issue sorted out with two threads. I forgot to mention, that it could be two independent programs as well, but two threads is more elegant.
I don't know how you tell where the program gets stuck (debugger?), but I would put my money on readDeviceFileStream.read(bufGet).
The thing is like this: Once the write thread finishes, it closes the file, but this has no significance on the FPGA level, except that the user_w_write_8_open signal goes low.
The read thread, on the other hand, keeps reading on until it reaches an EOF. But that never happens, because the user_r_read_8_eof is held constantly low, I suppose. You could solve this in two possible ways:
(1) The quick hack: Kill the read thread a certain time period (500 ms?) after the write thread has finished, assuming that this time will be enough for the read thread to handle the incoming data. Ugly, can fail if the computer gets heavily loaded at the wrong moment, but sometimes good enough.
(2) The proper way: Issue an EOF. Note that *_eof signals must be asserted only on a clock cycle following a read cycle (the Xillybus FPGA Designer's Guide doc explains this), but there is an exception on the case when "empty" was already asserted. So you could go something like this in the logic, i.e the xillydemo module (example in Verilog):
assign user_r_read_8_eof = user_r_read_8_empty && !user_w_write_8_open;
If you go this way, you must make sure to open the write device file before the read file, or you'll get the EOF right away.
(3) The common variable: Count how much data you've written on the write thread, and count how much has arrived on the read thread. Have a common variable, say limit, and initialize it to -1. Before the write thread writes its last chunk of data, make it set limit to the total number of bytes. The read thread checks, before any attempt to read, if limit >= 0, and if so, if it has reached the total number of bytes. If so, it quits. Note that "limit" must be updated before the last write, and not after it. It's convenient to update it just before quitting the write thread, but that's not good enough: There is a possibility that the read thread will have read the data in the little time gap, so "limit" would be updated too late.
I would go for (2).
Regards,
Eli
Hello,
I'm glad that you got the previous issue sorted out with two threads. I forgot to mention, that it could be two independent programs as well, but two threads is more elegant.
I don't know how you tell where the program gets stuck (debugger?), but I would put my money on readDeviceFileStream.read(bufGet).
The thing is like this: Once the write thread finishes, it closes the file, but this has no significance on the FPGA level, except that the user_w_write_8_open signal goes low.
The read thread, on the other hand, keeps reading on until it reaches an EOF. But that never happens, because the user_r_read_8_eof is held constantly low, I suppose. You could solve this in two possible ways:
(1) The quick hack: Kill the read thread a certain time period (500 ms?) after the write thread has finished, assuming that this time will be enough for the read thread to handle the incoming data. Ugly, can fail if the computer gets heavily loaded at the wrong moment, but sometimes good enough.
(2) The proper way: Issue an EOF. Note that *_eof signals must be asserted only on a clock cycle following a read cycle (the Xillybus FPGA Designer's Guide doc explains this), but there is an exception on the case when "empty" was already asserted. So you could go something like this in the logic, i.e the xillydemo module (example in Verilog):
assign user_r_read_8_eof = user_r_read_8_empty && !user_w_write_8_open;
If you go this way, you must make sure to open the write device file before the read file, or you'll get the EOF right away.
(3) The common variable: Count how much data you've written on the write thread, and count how much has arrived on the read thread. Have a common variable, say limit, and initialize it to -1. Before the write thread writes its last chunk of data, make it set limit to the total number of bytes. The read thread checks, before any attempt to read, if limit >= 0, and if so, if it has reached the total number of bytes. If so, it quits. Note that "limit" must be updated before the last write, and not after it. It's convenient to update it just before quitting the write thread, but that's not good enough: There is a possibility that the read thread will have read the data in the little time gap, so "limit" would be updated too late.
I would go for (2).
Regards,
Eli