Adding esp-at-nal to supported crates
marius-meissner opened this issue · 6 comments
First, thank you for this great library. It was a pleasure for us to build on top. :)
We just released esp-at-nal today based on ATAT.
esp-at-nal is another network layer implementation/client for ESP-AT implementing embedded-nal with focus on no_std + good unit test coverage (already > 100 tests implemented).
We would be very happy to be added to the list of supported crates. Of course, we accept any decision and are open to feedback.
That is absolutely awesome work! I'd be happy to have it on the list.
Would you make a PR, adding it?
Also, i would be very interested in feedback on things you met during your implementation? Rough edge's, bad API or performance bottlenecks in ATAT.
We are currently looking at implementing an async version of ATAT aswell at my job.
Would you make a PR, adding it?
Sounds great, will create a PR soon.
Also, i would be very interested in feedback on things you met during your implementation?
In general, everything works quite well, especially the state handling (echo, promt, etc.) is very stable.
I ran a few benchmarks and did not notice anything negative in terms of performance. At least a throughput close to the UART bandwidth can be achieved. There are a few places that could be optimized for zero-copy, but that is more a thing for embedded-nal.
However, there are actually two points that I have noticed:
Parsing non CRLF terminated responses
It was not possible to parse the length terminated response of +CIPRECVDATA as response, as the data can contain CRLF.
Did I miss something, though? However, as an alternative, it was no problem to process the response using the URC parser, which is very universal in this respect.
Mocking of Client
As addressed already in #75 its currently quite challenging to mock the AtatClient trait. At least using mockall did not succeed. Although there has been progress regarding generic non-static arguments (asomers/mockall#408), the generic const LEN argument is still a problem.
That sounds great!
Parsing non CRLF terminated responses
Yeah, we are aware that this is currently not possible. If we were to implement this into the derive macros at some point, do you have a suggestion for syntax that would make sense? I mean, basically you would need to tell the command struct that "the argument at position 2 is the expected length of the argument at position 3", in some way.
Mocking of Client
Again, as you have already found, a known issue. Hope we can find a good way of doing this eventually.
I will mark this closed for now by #131. Feel free to open issues or PR's with suggestions, feedback or contributions! :)
This looks great! Just to make sure: This means I can use your crate for an ESP8266, making https://github.com/dbrgn/espresso obsolete, right?
If that's the case, I can happily throw away espresso. I always wanted to work on it more often, and planned to add embedded-nal support as well, but never found the time (or priorities) to really finish it.
Thank you for the praise and interest.
This means I can use your crate for an ESP8266
In fact, the crate was developed/tested with an ESP8266.
making https://github.com/dbrgn/espresso obsolete, right?
I had even tried espresso at first, but then discarded the idea when I realized that, for example, not only an older version of ATAT was supported. I must admit, however, that I have also incorporated some of the experience from espresso (e.g. passive receiving mode) into esp-at-nal.
I had a brief look, and it seems that esp-at-nal should cover a lot of the same features.
In general, I would be pleased if a future cooperation should arise.
@marius-meissner I'll certainly try it once I find time to do so. If there's something I'm missing or that I think can be improved, I'll open PRs.
If this fits my requirements, I'll archive the espresso project and will remove the mention from the atat README.