Andrewi/97 canlink bringup

[AndrewI26]

#97 Added writer structs for json and ascii to handle file writing for tracer. Also added tests for both jsonWriter and asciiWriter. Changed tracer so that we write each frame to the trace file immediately after receiving the can frame through the socket. Added empty test for the tracer which just initializes the tracer, sleeps for 5 seconds, then closes the tracer. (Eventually we can add more robust testing for the tracer but just wanted to add this test for easy development. Just run the test then use cansend to ensure tracer is working)

[samparent97]

Hey Andrew, I have lots of studying to do until Tuesday. I'll be sure to have a look at your PR then.

[BlakeFreer]

Is the canlink/README up to date?

[AndrewI26]

Is the canlink/README up to date?

Still need to add documentation for CanClient and for the bus manager

[BlakeFreer]

I don't see where the Handler interface is, i.e. the pub-sub one which lets you attach behaviour to a CAN bus. The writers should implement this Handler interface. I don't think I should have to manually call writer.WriteFrameToFile. Shouldn't that be automatic when attached?

[BlakeFreer]

Looking really good.

@langei This PR now includes your can-broker branch. Where's that branch at? It looks like @AndrewI26 did a good job integrating his work with yours. Is there anything else you need to do before putting this in?

[BlakeFreer]

Can you mention the Handler class in the Readme? doesn't need any example code. Just mention it's purpose and how someone may use it

[AndrewI26]

If we only use it to Send messages, then let's just move that method to BusManager, completely get rid of CanClient, and not even worry about implementing it as a Handler

The bus manager already supports transmitting frames to the can bus/can socket in the processIncoming function. Every Handler receives a transmitChannel, which they can send frames to and the bus manager will transmit those frames to the can socket. Should Send be a public method on BusManager or should a Transmitter handler be implemented?

[BlakeFreer]

The bus manager already supports transmitting frames to the can bus/can socket in the processIncoming function. Every Handler receives a transmitChannel, which they can send frames to and the bus manager will transmit those frames to the can socket. Should Send be a public method on BusManager or should a Transmitter handler be implemented?

I think Send should be a public method on BusManager. Then do we need the incomingChan channel and processIncoming or can Send call transmitter.TransmitFrame directly?

I don't see any value in a Handler-style Transmitter class. What would it do besides pass the message to BusManager.Send()?

This project is pretty similar to Python's logging package. https://docs.python.org/3/howto/logging.html#logging-advanced-tutorial

Python logging	HIL canlink Equivalent
Logger	BusManager
Handler	Handler
Filter	Specific Handlers can implement a filter by discarding certain messages
Formatter	Tracer.Converter

In the logging module, you directly call .log() on a Logger. This is roughly like calling .Send() so I think it should be on the BusManager

[AndrewI26]

This is roughly like calling .Send() so I think it should be on the BusManager

I like this a lot, because then we can remove the incoming channel functionality. I will work on this. Makes the bus manager cleaner since we don't need o distribute the incoming frames channel.

I also like the idea of having handlers have the option to implement a filter function if they want to filter incoming frames. We could make a filter that acts like a canclient and drops frames if they are not contained within a specific dbc. I think this will work well I'm just not sure if it will be useful in the sil. I'll wait to code this. @BlakeFreer and @langei do you think this is useful or should we not even worry about implementing a filtering system.

[BlakeFreer]

Do you think this is useful or should we not even worry about implementing a filtering system.

The beauty of making Handler an interface is we don't need to decide on the behaviour now. In the future, when writing the SIL / HIL, if our Handler needs to filter messages then it can do that inside the Handle() method, so we don't need to do anything upfront.

[langei]

Looks really good, a few minor things. Did an initial review and will test it locally tomorrow.

[BlakeFreer]

I'm happy with this. I'll let @langei give the final approval when he is