Thanks, Jacob. I did it, it shows the following message:
error data not available after select: No such file or directory
I think that I've found something similar in the flow.c file at line 232 https://github.com/jodersky/flow/blob/f791debe0c44f7bf420df37725e52b724c19660d/flow-native/src/platform/posix/flow.c#L232. For version 2.6.0 I've found here https://github.com/jodersky/flow/blob/v2.6.0/flow-native/src/platform/posix/flow.c#L218
Any ideas? Thanks!
I don't change the baud rate during a connection. I'm using the following values but never change:
val settings = SerialSettings(
baud = 9600,
characterSize = 8,
twoStopBits = false,
parity = Parity.None
)I'm sending AT commands like ATE0, ATV1 and ATQ0 before the ATD command. That's all.
My assumption is that somehow the connection is reset while the reader thread is waiting on a select. Instead of returning an error, the call to
read returns 0 bytes corresponding to an end-of-file. Flow, incorrectly, assumes that data will always be available after a select: int r = read(port, buffer, size);
//treat 0 bytes read as an error to avoid problems on disconnect
//anyway, after a poll there should be more than 0 bytes available to read
if (r <= 0) {
DEBUG(perror("error data not available after select"););
return E_IO;
}
return r;
I can't remember the reasoning behind my comment, on why there would be issues on a disconnect, but it seems flawed anyway. The code should treat r < 0 and r == 0 differently
I think I recall the reasoning now. When a serial connection is unexpectedly closed, usually
read returns -1 and sets errno to a specific error code. serial_read should never return and empty message, since this has no meaning in combination with a select (the whole point of select is to ensure that data is available before returning)
What I did not consider is that
read can actually return 0, even after a select. I would argue however that a read of zero bytes, equivalent to an end-of-file, is also a kind of error message: the remote end closed the connection while you were trying to read => you did not respect the protocol.
It is a less sever error however, more like an unexpected close from the remote in a TCP connection
The error message is very bad however, and should distinguish cases of r == 0 and an actual error
Btw, I've changed version to 3.0.1
Hi all, does anyone know why the snippet below doesn't typecheck?
type LiteralA = "LiteralTypeA";
type LiteralB = "LiteralTypeB";
type UnionAB = LiteralA | LiteralB;
const isLiteralA = (u : LiteralA) =>
u == "LiteralTypeA";
const unionIsLiteralA = (u : UnionAB) =>
isLiteralA(u); 12: isLiteralA(u);
^^^^^^^^^^^^^ function call
12: isLiteralA(u);
^ string literal `LiteralTypeB`. Expected string literal `LiteralTypeA`, got `LiteralTypeB` instead
8: const isLiteralA = (u : LiteralA) =>
^^^^^^^^ string literal `LiteralTypeA`y
IO(Serial) ! Serial.Open(port, settings)
check out the documentation here http://www.jodersky.ch/flow/documentation/3.0/manual#opening-a-port
also, for more details about the protocol messages refer to the API docs http://www.jodersky.ch/flow/documentation/3.0/api/ch/jodersky/flow/Serial$.html
@/all The project has been renamed to "akka-serial". The new chat room is https://gitter.im/jodersky/akka-serial.