-
Notifications
You must be signed in to change notification settings - Fork 10
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
Siwx917 Wifi improvements #44
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -11,4 +11,5 @@ toolchain: | |
supported: | ||
- gpio | ||
- i2c | ||
- wifi | ||
vendor: silabs |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -21,6 +21,11 @@ config WIFI_SIWX917 | |
|
||
if WIFI_SIWX917 | ||
|
||
# WiseConnect create threads with realtime priority. Default (10kHz) clock tick | ||
# prevent proper use of the system with these threads. | ||
config SYS_CLOCK_TICKS_PER_SEC | ||
default 1024 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think 1000 would make more sense (most new WiseConnect examples are also using 1000). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That seems strange, considering a 32768 Hz clock divided by 32 would give 1024. Are they not running on a low frequency timer (we are not yet, but were planning to)? |
||
|
||
config NUM_PREEMPT_PRIORITIES | ||
default 56 | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just as a note for the future, twister supports multiple
--test
arguments, so we should likely just merge these into a singlewest twister --test ... --test ...
command. I've postponed doing it since we have several PRs open which would conflict with such a change.Another improvement would be to take advantage of GitHub workflow "matrix", so that GitHub would run in parallel the same workflow with different input parameters for each instance. The parameter could e.g. the a specific platform to build against, i.e. this becomes more relevant as we grow the list of platforms covered by our CI.
https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow