Fix AT driver #180
Fix AT driver #180
Conversation
There was a problem hiding this comment.
Partially writing is not related to this change completely. That's because fopen() produces a buffered IO. The case and solution have been discussed at #167
| @@ -55,7 +55,7 @@ static int apdu_interface_connect(struct euicc_ctx *ctx) | |||
| device = "/dev/ttyUSB0"; | |||
| } | |||
|
|
|||
| fuart = fopen(device, "r+"); | |||
There was a problem hiding this comment.
It's strange. The "b" flag is a no-op on the POSIX system. It only affects Windows and lets it disable special handling of '\n' and '\x1A'.
There was a problem hiding this comment.
Although I am unfamiliar with inner workings of the fopen/fread family of functions, this solved the communication issues in my case on Linux. Might've been just luck or some other side effect fixing it. Feel free to close this PR if you don't think this is the real fix.
There was a problem hiding this comment.
The "b" flag is a no-op on the POSIX system because POSIX has no special handling of '\n' and '\x1A' like Windows. It always behaves like Windows with a "b" flag.
https://github.com/bminor/glibc/blob/c2567b18fd77da9d4a270b20232f12616763bf76/libio/fileops.c#L262-L264
Adding setbuf(fuart, NULL) after fopen() should fix this problem. You can try it and update the PR.
The AT driver was very unreliable, sending only partial commands on Quectel devices. This patch seems to fix it for the most part.