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

Time Services need cleanup relative to requirements #302

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

Time Services need cleanup relative to requirements #302

skliper opened this issue Sep 30, 2019 · 9 comments

Comments

@skliper
Copy link
Contributor

skliper commented Sep 30, 2019

Per CCB on 3/27/19, Time Services goes way beyond it's requirements. Need to re-evaluate configuration options and reduce mission specific code.

As part of the cleanup, factor out duplicate code. Specifically referenced at code review in command handling.

@skliper skliper self-assigned this Sep 30, 2019
@skliper
Copy link
Contributor Author

skliper commented Sep 30, 2019

Imported from trac issue 271. Created by jhageman on 2019-04-01T09:44:50, last modified: 2019-05-23T16:43:54

@skliper skliper removed their assignment Sep 30, 2019
@skliper
Copy link
Contributor Author

skliper commented Feb 19, 2020

Suggestions - Explicitly define TAT pulse and 1Hz pulse, the system should handle various configurations (any combination of 'virtual/internal' and external/API, synced or not)

TAT pulse source selection (SetSource) should be generalized to 'virtual' or passed to PSP, or get triggered via API (generalize implementation of cTIME2010 which currently just does PRIMARY/SECONDARY)
1Hz pulse source selection (new) should be generalized to 'virtual' aka timer based or passed to PSP (expect trigger via API), or based off of Tone Pulse (synced, 1Hz loop triggered by Tone Pulse)
MET source selection (new) should be generalized to 'virtual' or passed to PSP, or passed in via API
1Hz pulse when external shall flywheel after mission config elapsed time without a pulse (missing requirement)

Really TIME ifdefs need to be removed, and TIME should just do what's requested when requested.

Note #518 will fix some of the requirements but not all, so revisit after that update.

@skliper
Copy link
Contributor Author

skliper commented Feb 19, 2020

See cTIME2013 - need to simplify configuration to adjust SCTF when requested (regardless of mode).

@skliper
Copy link
Contributor Author

skliper commented Feb 19, 2020

SetSourceCmd - not well defined requirement or implementation. Suggest updates per the 1Hz comment above (sort of tied 1Hz cycle to Tone but needs work).

@skliper
Copy link
Contributor Author

skliper commented May 5, 2020

CFE_TIME_Locaal1HzISR related design also needs cleanup and implementation is not consistent with CFE_TIME_Tone1HzISR. Wouldn't expect an "ISR" to be exposed in an API, Tone1HzISR has an ExternalTone API wrapper, etc. See also #551 which only fixed the duplicate prototype, but bigger issues should be addressed as part of refactor.

@skliper
Copy link
Contributor Author

skliper commented May 11, 2021

Also noted in code review, inconsistent parameter names used in the APIs (Time1/2, TimeA/B). Improve consistency.

@skliper skliper added the CFS-43 label May 11, 2021
@skliper
Copy link
Contributor Author

skliper commented May 11, 2021

Also noted in code review, consider merge of external events (CFE_TIME_ExternalMET, CFE_TIME_ExternalGPS, CFE_TIME_ExternalTime). Although might be simpler to just include all three and support selection (internal/virtual/external MET, OS/GPS/Time (and relation to tone), etc) instead of #ifdefs all over. They are APIs, you don't have to use them.

@thnkslprpt
Copy link
Contributor

Per CCB on 3/27/19, Time Services goes way beyond it's requirements. Need to re-evaluate configuration options and reduce mission specific code.

As part of the cleanup, factor out duplicate code. Specifically referenced at code review in command handling.

  • CFE_TIME_SetTimeCmd, CFE_TIME_SetMETCmd, CFE_TIME_SetStcfCmd, and CFE_TIME_SetLeapSeconds are all basically the same logic, etc.
    ...

This first point is addressed here (excl. CFE_TIME_SetLeapSeconds() which does not have enough common logic to justify being included):

@thnkslprpt
Copy link
Contributor

Also noted in code review, inconsistent parameter names used in the APIs (Time1/2, TimeA/B). Improve consistency.

This is addressed here:

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