Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR implements a lightweight wrapper layer for message encoding that sits on top of the lower-level Ethernet/MQTT drivers. It's meant to provide a simple API that automatically handles encoding messages in the ServerData schema. This should ideally make it easier to set up Ethernet/MQTT/Protobuf in different repos.
The first function (technically a macro) in this API is
nx_protobuf_mqtt_message_create(topic, unit, ...), which returns a message of typeethernet_mqtt_message_t. This function allows you to pass in atopicstring literal, aunitstring literal, and however manyfloatdatapoints you want (provided it doesn't exceed the maximum allowed). The lengths of thetopicandunitstrings, as well as the number of datapoints you pass into..., are calculated automatically for you at compile time, so there's no risk of weird caller errors (i.e, forgetting to include a null terminator in the string size or something). The max/min length settings for the parameters (configured viaPB_MAX_TOPIC_LENGTH,PB_MAX_UNIT_LENGTH,PB_MIN_DATAPOINTS,PB_MAX_DATAPOINTS) are also validated at compile-time, so if you violate any of the settings there, you will get a nice_Static_assertcompiler error telling you exactly what rule you violated. TLDR the compiler will ensure you call this function correctly unless there's something I've forgotten about.The second function in this API is
nx_protobuf_mqtt_message_send(ethernet_mqtt_message_t* message), which dispatches aethernet_mqtt_message_tobject. If MQTT isn't connected, this function will try to reconnect indefinitely until MQTT has successfully been reconnected, either by this function directly or by another function/thread.The intended application-layer workflow for this API looks kinda like this:
First, create a queue:
Then, other threads can create messages and queue them, like this:
Some things of note:
ethernet_get_time()seemed to hang (right before thenx_ptp_client_time_get()call). The hanging did not occur for messages getting created invTest, but did for messages getting created invPeripherals. Kind of weird. I ended up commenting out the call toethernet_get_time()withinnx_protobuf_mqtt_message_create(), and just havetime_usset to 10 (random number I chose).