Skip to content
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

Add and use AP_NMEA_Input #17153

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

peterbarker
Copy link
Contributor

This factors out the NMEA parsing code from AP_Windvane_NMEA, in an attempt to reduce the number of NMEA parsers we have in our code.

Anything that wants to parse NMEA inherits from AP_NMEA_Input (multiple inheritance, typically, yech, but...) and implements these methods:

    // called when we're just about to start parsing a sentence:
    virtual void reset_at_sentence_begin() = 0;

    // called when the sentence type has been determined; should
    // return true if this sentence should be fully decoded
    virtual bool start_sentence_type(const char *term_type) = 0;

    // called as every term is decoded in a handled sentence.
    // Sentence may yet be invalid - handle_decode_success will be
    // called if the term should *actually* be used.  Should return
    // false if the value in this term makes the sentence invalid.
    virtual bool handle_term(uint8_t term_number, const char *term) = 0;

    // called when a complete sentence has been decoded and passed checksum:
    virtual void handle_decode_success() = 0;

Tested only as far as "it compiles" (and whatever is in autotest, now :-) )

@IamPete1

@peterbarker
Copy link
Contributor Author

I should note that if we didn't want to do the multiple-inheritance thing then we could do something like

parser = new NMEAParser(protocol, protocol_instance, functor_reset, functor_good_sentence_type, functor_term, functor_decode_complete);

Pete Hall also tried this here: #12289

@rmackay9
Copy link
Contributor

By the way, I'm planning to add consumption of temperature to the rangefinder library's NMEA driver which is normally used for depth sounders. A number of users have asked to be able to retrieve and log the water temperature.

If you wanted me to try and modify the RangeFinder library to try and use this I perhaps could.

@IamPete1
Copy link
Member

IamPete1 commented Apr 13, 2021

@rmackay9 We can already read the MTW temp sentence via the airspeed lib (#14852). The hack is just to connect two serial port rx pins to the NMEA tx. Does require taking up two serial ports tho, but there is not really any other way to get round it for sensors that can do depth and temp and water speed, unless we add virtual serial ports or something complicated.

@rmackay9
Copy link
Contributor

rmackay9 commented Apr 13, 2021

@IamPete1,

I was going to basically duplicate that consumption of the MTW sentence in the AP_RangeFinder_NMEA driver.. and then make it accessible with a method that returns a bool on success. It would only ever be called when we go to log the DPTH message.

@peterbarker
Copy link
Contributor Author

@rmackay9 sounds good - I'll probably try to convert AP_GPS_NMEA - happen to have a GPS that produces that on my desk ATM.

@Ryanf55
Copy link
Collaborator

Ryanf55 commented May 10, 2024

Nice, seems like a lot less code duplication. Were you able to run the size compare?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants