[RP]: Remove internal static pgn request protocol list

[GwnDaan]

Like with the DiagnosticProtocol's static list removal in #281, this PR removes the static list in the ParameterGroupNumberRequestProtocol and instead let the application handle the objects themselves.

Though a drawback of this approach I found, is that every other interface that requires "pgn requests" support (e.g. the LanguageInterface/DiagnosticProtocol) need to be fed with a shared_ptr to a ParameterGroupNumberRequestProtocol object. We could instead house the list of ParameterGroupNumberRequestProtocol inside the CANNetworkManager or assign to each InternalControlFunction an optionally dedicated ParameterGroupNumberRequestProtocol object (that get's automatically constructed/deconstructed when needed)?

On the other hand, we can also just leave it as is, but then we keep a difference between the interfaces/protocols. Any thoughts on all this are more than welcome

[ad3154]

Apologies for my lateness on reviewing this - I will try to review this weekend!

[ad3154]

I have a few thoughts after reading this, let me know what you think.

PGN requests are a very important part of participating on both an ISO11783 and J1939 bus, and the standards are very strongly worded with such things like:

• A NACK is required if the PGN is not supported.
• A response is always required from a specified destination

And since we have to send messages as responses, even if the user of the stack doesn't do any PGN requests themselves, I think we have some opportunities here to make this whole thing less weird and more automatic.

My initial thinking is that maybe each Internal Control function should create a dedicated PGN request object, and we could just have a getter on the ICF to retrieve it (maybe a weak ptr makes the most sense here? It will only rarely be accessed by those other objects like Diagnostic Protocol...)

I think this might make the most sense, as then all those other objects that need it can simply get it from the ICF that is passed into them at construction time, and it ensures all ICFs will respond properly without the user configuring it. It also continues to allow the network manager access to them to call update via the internalControlFunctions list.

Does that make sense? Looking forward to your/anyone's opinion.

[GwnDaan]

I agree I think housing it inside the internal control function makes the most sense as well, I'll go ahead and make that change

[GwnDaan]

What do you think about this f705d28 @ad3154?

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
3 Code Smells

68.2% Coverage
0.0% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[ad3154]

Yeah, looking good I think. I'd like to test a on a real bus but it looks like it'll work.

I'll try an run a couple manual tests and as long as they work I'll merge!