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.

Sign up for GitHub

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

Jump to bottom

Allow SCH_LAB to schedule faster than 1Hz #103

Closed
jphickey opened this issue Dec 3, 2021 · 1 comment · Fixed by #104 or #105
Closed

Allow SCH_LAB to schedule faster than 1Hz #103

jphickey opened this issue Dec 3, 2021 · 1 comment · Fixed by #104 or #105
Assignees
@jphickey
Labels
enhancement New feature or request
Milestone
Draco

Comments

@jphickey
Copy link
Contributor

jphickey commented Dec 3, 2021 •
edited
Loading

Is your feature request related to a problem? Please describe.
Some FSW apps require a wakeup event faster than 1Hz. When debugging these apps it is not ideal to be forced to deploy the full SCH, since its configuration is much more involved.

Describe the solution you'd like
Keep using SCH LAB which is intended for debugging apps, but be able to send wakeups faster than 1Hz.

Describe alternatives you've considered
Deploy full SCH (complicated, and a distraction from the real objective of debugging some other app).

Additional context
If CF is run at only 1Hz wakeup it would take a long time to transfer files.

Requester Info
Joseph Hickey, Vantage Systems, Inc.
@jphickey
Copy link
Contributor Author

jphickey commented Dec 3, 2021

This is rather easy to do, one just has to wait on an OSAL timer rather than the 1Hz message from CFE_TIME.

@skliper skliper added the enhancement New feature or request label Dec 3, 2021
jphickey added a commit to jphickey/sch_lab that referenced this issue Dec 6, 2021
@jphickey
Fix nasa#103, add option to configure base tick rate
6722cac 
SCH_LAB was fixed at 1Hz because it bound to the 1Hz tick from CFE_TIME.
This creates an OSAL timer instead, which posts a semaphore, and this
can serve as a much more flexible time source, with configurable rate.

This still binds to 1Hz and the SCH does not start its first message
until the first 1Hz is received, thereby keeping some form of 1Hz sync.
@jphickey jphickey self-assigned this Dec 6, 2021
@jphickey jphickey mentioned this issue Dec 6, 2021
Merged
jphickey added a commit to jphickey/sch_lab that referenced this issue Dec 6, 2021
@jphickey
Fix nasa#103, add option to configure base tick rate
0396089 
SCH_LAB was fixed at 1Hz because it bound to the 1Hz tick from CFE_TIME.
This creates an OSAL timer instead, which posts a semaphore, and this
can serve as a much more flexible time source, with configurable rate.

This still binds to 1Hz and the SCH does not start its first message
until the first 1Hz is received, thereby keeping some form of 1Hz sync.
@astrogeco astrogeco added this to the Draco milestone Jan 19, 2022
astrogeco added a commit that referenced this issue Jan 19, 2022
@astrogeco
Merge pull request #104 from jphickey/fix-103-faster-wakeup
64612ec 
Fix #103, add option to configure base tick rate
@astrogeco astrogeco mentioned this issue Jan 19, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jphickey jphickey

Labels
enhancement New feature or request
Projects
None yet
Milestone
Draco
3 participants
@jphickey @skliper @astrogeco