| T O P I C R E V I E W |
| russg |
Posted - 12/12/2023 : 20:31:55
Hello All,
I am trying to communicate with my EMF 390v2 meter via the USB port. I can do this with any single command, but when I attempt multiple sequential commands I can't tell when the device is done responding and the buffer is ready to read, and I end up sending new commands before the device has responded. This typically locks up the device.
Some commands end with a CRLF; some have a fixed byte length. Some have neither (GETEMF, GETEF). How can I tell when the device is done responding?
I believe I'm missing something simple as I'm new to serial port programming. Any suggestions would be appreciated!
thanks- russg
I'm using
Baud: 115200
Data bit: 8
Parity: None
Stop bit: 1
Control: None
as per the GQ-RFC1701.txt document.
For example:
<GETVER>>
(read port) -> return version ok
<GETEF>>
(read port) -> returns empty
<GETEMF>>
(read port) -> returns empty
<GETXYZ>>
(read port) -> returns EF, delayed
|
| 3 L A T E S T R E P L I E S (Newest First) |
| russg |
Posted - 12/20/2023 : 20:58:02
Hi Dev,
In other words: the 390v2 looks for a ">>" to know the request is complete and it can can read the buffer. What does the computer use to know it can read the 390v2 is done writing data and it is ok to read the buffer?
Imagine the computer did NOT send a ">>" at the end of each request. How would the 390v2 know the request was complete? Exact same problem.
Solution can either be:
1) a HW handshake (not one that I can see)
2) a special character like the ">>" to denote the end of the data, or
3) a fixed length (for each message is fine).
But, if you have none of these, and if your computer is fast enough, eventually you will send data to the 390v2 fast enough it gets confused or over-writes itself.
This implies you have to put in a guessed at time delay and *hope* the 390v2 is done writing. You have no way of telling when the 390v2 is done responding. So instead of this:
(
computer requests data1
390v2 responds
computer reads data1
)
(
computer requests data2
390v2 responds
computer reads data 2
)
...
you do this:
(
computer requests data1
computer checks for data1 (but no way to know if complete)
computer sleeps for ??? seconds
computer checks for data1 again (and **hopes** delay was long enough)
)
(
computer requests data2
computer checks for data2 (but no way to know if complete)
computer sleeps for ??? seconds
computer checks for data2 again (and **hopes** delay was long enough)
)
....
The simplest solution would be to add a reserved character at the end of each 390v2 response, like a ">>". Best solution would be to add HW handshaking. Or fix the length of each response.
Make sense? |
| EmfDev |
Posted - 12/15/2023 : 16:49:49
Not sure how to produce the issue. The uart is using interrupt and should return back something as long as it is ready to send back. Usually you can get a response in less than 1 second. |
| russg |
Posted - 12/14/2023 : 20:32:47
I’m updating my own message. So, without any flow control, no end of response character, and variable response lengths, the only answer i can think off is to poll until i get ‘something’ in the read buffer and then ‘wait’ some interval long enough to let the device finish filling the buffer.
adding time dependencies is just BAD coding, but darned if i can see any other solution.
any thoughts from other folks trying serial port communications with the 390v2? |
|
|
