andrerenaud / embeddedcli Goto Github PK

When you press ENTER (or RETURN) on a serial terminal, it generates a CR and not NL.

I noticed that the posix demo works because it doesn't use raw mode, and leaves the CR->NL translation turned on.

If you use screen under linux over a serial port, it sends a CR when you press ENTER, and the embedded CLI doesn't recognize it as an end of line.

Similarly, on the output side, the code currently only generates a NL at the end of the line, and it really needs to generate a CR NL.

I can work around these things by translating CR to NL on the input side and translate NL to CR NL on the putchar side, but I thought I would report it as an issue, since if it were fixed then it would work properly with most of the terminal programs out there. Yes most terminal programs have the option to do this translation for you, but my thinking is that you shouldn't need to rely on the terminal program.

Perhaps it should be a configuration option?

I'm happy to code up a PR for your consideration.

void embedded_cli_init(struct embedded_cli *cli, char *prompt,
                       void (*putchar)(void *data, char ch), void *cb_data)

The prompt argument to this function should be const.

Thank you for this clean and simple CLI library!

One thing I noticed while testing it, is that when EMBEDDED_CLI_MAX_LINE - 1 characters are typed into the CLI, the CLI is no longer able to process any further characters (including backspace or movement), putting it into an unrecoverable state.

The range checks in embedded_cli_insert_char() probably just need to account for characters that will not increase the usage of the buffer.

Hi,

It would be advantageous for the callback for putch to have a additional parameter that indicates whether the character is the last byte in the transmission.

As an example, the usage case where the transport is over USB, single byte transfers are an expensive operation. With an additional parameter that either tells us that this is the last byte allows flushing to be handled in the call-back directly without needing other solutions or the parameter saying "you can flush now" would make better use of the USB bus.