-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactoring this into *the* rust nmea parser #9
Comments
I don't think that there is need for this. If dependecy can compile with no_std that is enough, |
I'd assume the guy with the no dependency crate did it for size reasons of the resulting binaries but I agree, getting rid off a parsing library seems kinda overkill. |
May be better to add all related users to cc? |
Thanks for this. A few things:
Can you elaborate by "requirements"?
This is a difficult thing to assert, so I expect this to be fine in the initial few versions. At least there shouldn't be an explicit panic. |
Requirements / Dependencies so our resulting binary doesn't grow overly large Sounds good to me, of course we can take incremental steps towards these targets, question would just be what we are aiming at first. |
What a feature set and properties i expect from some "ideal" nmea parser as a developer of embedded device?
It will be nice to support additional vendor-specific protocol extensions. At least for widely used modern devices such as ublox. C API is a strange thing. C developers typically try to avoid external dependencies written not on C, even C++ often is not welcome there. P.S. My opinion based on many years of commercial embedded development. |
Two questions on this:
And for the C API, there is for example a team at my workplace that mainly does C/C++ dev on a very low level on x86 machines (writing drivers and such) and they were/are very interested in rust and some even commited a bunch of stuff to rustc to make it usable for their target so I think there are at least some people that might use this. Furthermore I do remember reading somewhere in the embedded-wg repos or websites or books that rust can be used as a more safe small part in bigger C code bases ideally so the devs don't have to completely rewrite their code base into rust but also not give up on Rust fully. But if you think it's a thing we don't need we don't have to do it of course. |
Hi all, I've been in need of a NMEA parser and was looking through my options, and figured I add something that hadn't been mentioned but is compelling to me personally: online parsing. Because UART is going to stream it, I want a "parse as you read" interface, rather than passing in pre-chunked sentences. This is something I found useful from the nmea0183 crate, using it's iteration interface. |
@hargoniX I think no_std for nmea parser is a must. No matter of what crate is: yours or any other. I've rarely seen std-like enviroment on embedded devices for example some minimalized version of libc. |
That's not exactly what I asked, I wanted to know wether, based on your opinion that only a bunch of sentences is used anyways, do you think merging in the variety of sentences yanp supports is even worth it or should we just not support them and instead focus on other stuff. |
Okay, lets see what sentences yanp is supported. Especially for sentences usable for aerospace :) Do not focus on that crap. May be if someone really needs that or you have a bunch of additional time. |
Alrighty, I'll look into no_std then! |
Is this PR close? |
@iamgabrielsoft This is not a PR but an issue. We've been working on a few of these points and completed them. For the rest of the people following the conversation, we're looking into:
I've also looked at NMEA 2000 to see if we can implement it but it seems that even getting the Appendix B Version (Database of Messages) is paid. I wonder what options we have apart from taking a look at other OSS libraries like https://github.com/ttlappalainen/NMEA2000 and replicating the parsing from it? CC @ttlappalainen as they might also be interested in this discussion. |
I got this as cc and quickly read through so I do not have complete idea about your library and use of it. As NMEA 2000 "specialist" I give some comments about it.
Feel free to ask, if you have more questions about NMEA 2000. I have worked with it about 7 years and last few years as profession so I think I know something about it. |
@ttlappalainen thanks for the response, I really appreciate it! If we decide to work on the 2000 implementation, we might look into other solutions like bindings for your C++ library, especially since you mentioned that it's "fully featured and certification ready". I'll make sure to reach out to you again when we start working on the 2000 implementation.
|
It would be nice if rust finally had a go to nmea parser that is used by as many people as possible. Considering NMEA is a kinda easy data format to parse / handle usually this shouldn't be too hard to unify reasonably for everyone either. As of now there are 7 nmea related crates on crates.io.
I believe that the core requirements for our NMEA parser should be that:
Should maintain API compatibility with the current crate so it is no hassle to upgrade for already existing users.@elpiel : We can break the API following semantic version and in the name of usability and idiomatic APIsIt seems to me like especially the point with no dependencies seems kinda hard to adopt, especially when looking at timestamp data because it might be nice to have a well known data structure the user can use in his program. Parsing could be done without dependencies as 3. shows, however I don't think this should be our first target to tackle as it seems like a quite huge effort, would definitely be nice to have in a final version though.
The text was updated successfully, but these errors were encountered: