app: Implement AT+IFC command handling#210
Conversation
mgolu
force-pushed
the
add_at_ifc_command
branch
2 times, most recently
from
5a48ddf to
b93cd7b
Compare
Adds the ability to turn hardware flow control on and off at runtime. Signed-off-by: Mariano Goluboff <mariano.goluboff@nordicsemi.no>
mgolu
force-pushed
the
add_at_ifc_command
branch
from
b93cd7b to
8172214
Compare
|
|
||
| return -SILENT_AT_COMMAND_RET; | ||
| } | ||
| SM_AT_CMD_CUSTOM(ifc, "AT+IFC", handle_at_ifc); |
There was a problem hiding this comment.
Hardware flow control is on by default, and it requires RTS and CTS pins to be used. Similarly, the buffer sizing for RX buffers is static and the sizing is not sufficient to operate without hardware flow control in all scenarios.
Can you elaborate what is the benefit of having this configurable in runtime?
There was a problem hiding this comment.
This is in case a customer wants to use only RX/TX hardware lines and not connect RTS/CTS.
Also this request: https://devzone.nordicsemi.com/f/nordic-q-a/127290/at-command-to-enable-disable-hw-flow-control-on-nrf9151
There was a problem hiding this comment.
This would leave RTS and CTS pins in place. CTS would have a pull-up, so not too damaging. But the buffer sizes would be an issue.
For production purposes, it would be way better to provide an overlays which would set sufficient buffer sizes. As for having such a command for testing purposes, perhaps.
@SeppoTakalo opinion?
There was a problem hiding this comment.
As we are using statically defined pin maps in the build-time, I really don't see the benefit or run-time configuring the CTS/RTS as compared to having them floating.
Not having flow-control pins on the UART have been a source of lots of issues in the past.
Hello-world applications work, but any serious data traffic causes random byte drops that are hard to find as they usually look like a data corruption.
There was a problem hiding this comment.
This is in case a customer wants to use only RX/TX hardware lines and not connect RTS/CTS.
Customers should be discouraged to not connect RTS/CTS lines. We cannot prevent them from doing so but it should be made clear that they are searching for random problems where any AT command or response, or PPP data can corrupt due to UART transmission issues.
According to our knowledge, AT+IFC doesn't change those issues in any way. We are checking that the Serial Modem would still work as well as possible when RTS/CTS were not connected, i.e., they would have pull-ups etc. correctly so that RX/TX would transfer data.
There was a problem hiding this comment.
We are checking that the Serial Modem would still work as well as possible when RTS/CTS were not connected, i.e., they would have pull-ups etc. correctly so that RX/TX would transfer data.
#219 allows the use of basic serial modem build without RTS and CTS lines being connected.
4 participants
Adds the ability to turn hardware flow control on and off at runtime.