Fix #219, #93, Add EVS port timestamp and simplify port selection

[skliper]

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I signed and emailed the appropriate Contributor License Agreement to GSFC-SoftwareRelease@mail.nasa.gov and copied cfs-program@lists.nasa.gov.

Describe the contribution

• Fix Clean up EVS ports implementation #93
• Fix add timestamps to EVS logging to stdout #219

Testing performed
CI and on local build with time stamp enabled

Expected behavior changes
Adds time stamp when configured to do so

System(s) tested on
CI, Ubuntu 20.04

Additional context
Related but doesn't address (although should make the change simpler):

• EVS "output ports" should be a function of the PSP #94

Third party code
None

Contributor Info - All information REQUIRED for consideration of pull request
Jacob Hageman - NASA/GSFC

[skliper]

Only failure is the overly restrictive commit message format check. Should there be a standard for commits that fix two issues?

[CDKnightNASA]

A couple comments:

1. YYYY/MM/DD HH:MM:SS.MMM adds a lot of bytes to the log, it may make sense to just use HH:MM:SS.MMM or even have a "epoch" at the top of the log then all reports are SS.MMM from T0.
2. The "ts" command for Unix adds timestamps to streams (surely not microsecond-accurate.)
3. Instead of compile-time optional, would it be helpful to have it be command-able?

[skliper]

1. YYYY/MM/DD HH:MM:SS.MMM adds a lot of bytes to the log, it may make sense to just use HH:MM:SS.MMM or even have a "epoch" at the top of the log then all reports are SS.MMM from T0.

I only need the format added. If someone requires additional formats they could address in a future issue.

2. The "ts" command for Unix adds timestamps to streams (surely not microsecond-accurate.)

I don't think this would help my specific need, wouldn't correlate to syslog timing or packet timestamps.

3. Instead of compile-time optional, would it be helpful to have it be command-able?

I only need it via config. If someone requires commandability they could address in a future issue.

Good suggestions, but given my current requirements this change is all I need. Hopefully the future work can be independent from this ?

[skliper]

I also want to get this week's award for addressing the oldest issue (2017!). So there's that :)

[skliper]

@dzbaker @dmknutsen - Is there a CCB action on this one or is it pending review?

[dzbaker]

@dzbaker @dmknutsen - Is there a CCB action on this one or is it pending review?

@jphickey is just giving it a quick review to make sure there are no conflicts with other stuff being developed. It should be merged in at the end of this week.

[jphickey]

A general comment, in CFE/CFS we have lots of configuration options - configuration option overload, possibly - to the point that we cannot feasibly test them all.

I'm trying to think why we can't just add the time here, and make it "always on"? Is there a use-case where this would break someone's environment somehow? I don't think anyone would rely on not having a timestamp in event text. If we can avoid having yet-another-option that we can't test/maintain both ways, I'd rather just make this the new standard.

[skliper]

... just add the time ...

I'll do it! Much preferred from my perspective.

[skliper]

@dmknutsen @jphickey - removed option to exclude timestamp in 43270f5

[dzbaker]

@jphickey @skliper @dmknutsen I can fast track this and include it in this next bundle if that makes sense?

[jphickey]

I like it....

[jphickey]

That being said, I dunno if this should close #93 ... The intent with that old idea is that EVS should call into the PSP for low level output. This is where you can make the 4 "output ports" go to different physical devices (depending on what the board has) and also attach different info per-port. That was the idea at least. Having 4 "output ports" in EVS without an mapping to the lower-level hardware seems to be an incomplete implementation of this, its been that way for years though.

[skliper]

This is the one to move to the PSP (at least how I interpret them):

• EVS "output ports" should be a function of the PSP #94

93 just cleans up how the bits are checked and paves the way for 94:

• Clean up EVS ports implementation #93

[jphickey]

This is the one to move to the PSP (at least how I interpret them):

* [EVS "output ports" should be a function of the PSP #94](https://github.com/nasa/cFE/issues/94)

93 just cleans up how the bits are checked and paves the way for 94:

* [Clean up EVS ports implementation #93](https://github.com/nasa/cFE/issues/93)

Thanks, yes this makes sense. I'm OK with this closing #93. Maybe someday will get to implement #94 too, I'd still like to see that done.