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

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

Open
skliper opened this issue Sep 30, 2019 · 7 comments
Open

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

skliper opened this issue Sep 30, 2019 · 7 comments
Assignees

Comments

@skliper
Copy link
Contributor

skliper commented Sep 30, 2019

Currently the EVS has 4 "output ports" implemented as functions within EVS: {{{EVS_OutputPort1(), EVS_OutputPort2(), EVS_OutputPort3(), EVS_OutputPort4()}}}

These are all identically hard coded to {{{OS_printf()}}}

The premise here seems logical -- to have several different destinations that the message may be sent. But the current implementation does not allow for that to really happen.

The proposal is to change this to a PSP implementation:

{{{CFE_PSP_SendEventToPort(uint32 PortNum, const char *Message);}}}

This single API could be used for all ports, and the PSP could switch based on the "PortNum" value if needed, or simply call {{{OS_printf}}} for all messages as it does in the current code.

@skliper skliper added this to the 6.8.0 milestone Sep 30, 2019
@skliper skliper self-assigned this Sep 30, 2019
@skliper
Copy link
Contributor Author

skliper commented Sep 30, 2019

Imported from trac issue 63. Created by jphickey on 2015-06-04T12:43:35, last modified: 2019-07-03T12:58:32

@skliper
Copy link
Contributor Author

skliper commented Sep 30, 2019

Trac comment by jphickey on 2015-06-04 12:45:32:

Candidate for CCB discussion at some point.

@skliper
Copy link
Contributor Author

skliper commented Sep 30, 2019

Trac comment by jphickey on 2018-05-14 13:39:47:

I would like to see this revisited for the next CFE release. The event "output ports" feature has been sitting in its current state for quite some time, where it is there but not really useful in any meaningful way.

We should either allow deployments to actually make use of dynamic output possibilities by directing these through the PSP, or decide that it will only ever be printf and therefore remove this extra logic.

(In particular, on Linux systems it might be quite useful to direct these events to the syslog daemon. Leveraging the PSP could allow that to happen).

@skliper
Copy link
Contributor Author

skliper commented Sep 30, 2019

Trac comment by jhageman on 2019-04-03 17:47:39:

CCB 4/3/19 Discussion

  • PSP SendMessageToPort to take a char string and send out port. Services and apps can format the output however they want (EVS could format events however desired).
  • Clean up EVS to just format and send to PSP.

@skliper
Copy link
Contributor Author

skliper commented Sep 30, 2019

Trac comment by jhageman on 2019-04-03 17:48:13:

See also #93, coordinated solution suggested.

@skliper
Copy link
Contributor Author

skliper commented Sep 30, 2019

Trac comment by jhageman on 2019-07-03 12:58:32:

Moved unfinished 6.7.0 tickets to next release

@skliper
Copy link
Contributor Author

skliper commented Apr 16, 2023

Related requirement cEVS3017 and cEVS3109:

EVS: Control Message Port Routing,cEVS3017,"Upon receipt of Command the cFE shall enable/disable, as specified in the Command, the routing of all future Event Messages to the Command specified Event Message Port.","Event Message Output Ports may not be available or needed; therefore, the ability to configure sending to an Event Message Port is useful."

EVS: Message Port Routing,cEVS3109,"For each created Event Message, the cFE shall route the Event Message, formatted as an ASCII text string, to each enabled Event Message Output Port.",Debug ports are very useful for FSW development and maintenance.

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

No branches or pull requests

2 participants