-
Notifications
You must be signed in to change notification settings - Fork 123
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
Improve code generation. #76
Changes from all commits
22c69e8
b1073ba
94a7b59
4ca7f62
49dc87d
96ea334
1fdd1e0
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 |
---|---|---|
|
@@ -2,8 +2,6 @@ name: CI | |
|
||
on: | ||
push: | ||
branches: | ||
- master | ||
pull_request: | ||
schedule: | ||
- cron: '50 4 * * *' | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
use crate::bindings::*; | ||
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. Why would we want to do this here and not in 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. You cannot implement 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. No I mean given that we have a type-safe wrapper for Wifi already, why would you need these defaults here? Or do you plan on implementing another set of type-safe wrappers besides One more point: we have discussed with Espressif, that the best possible solution is to have ESP-IDF expose C functions that implement these defaults and that we can consume - in addition to their C macros available today that we cannot consume. Timelines unclear though. 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 have implemented a different wrapper in one of my projects which used my own
I will try to have a more detailed look at the 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. Ok so I'm all for switching to Rust enums if you can make it work in esp idf svc and esp idf hal. As for the default method, in light of the above idea of having it centralized in ESP IDF and consumable via CAPI call, perhaps we should wait with it a bit? 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. By the way, 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 don't think it makes a difference.
I'm also not sure. As I said, I implemented my wrapper before these crates existed, so I have also not yet reviewed in detail how |
||
|
||
impl Default for wifi_init_config_t { | ||
fn default() -> Self { | ||
Self { | ||
event_handler: Some(esp_event_send_internal), | ||
osi_funcs: unsafe { &mut g_wifi_osi_funcs }, | ||
wpa_crypto_funcs: unsafe { g_wifi_default_wpa_crypto_funcs }, | ||
static_rx_buf_num: CONFIG_ESP32_WIFI_STATIC_RX_BUFFER_NUM as _, | ||
dynamic_rx_buf_num: CONFIG_ESP32_WIFI_DYNAMIC_RX_BUFFER_NUM as _, | ||
tx_buf_type: CONFIG_ESP32_WIFI_TX_BUFFER_TYPE as _, | ||
static_tx_buf_num: WIFI_STATIC_TX_BUFFER_NUM as _, | ||
dynamic_tx_buf_num: WIFI_DYNAMIC_TX_BUFFER_NUM as _, | ||
cache_tx_buf_num: WIFI_CACHE_TX_BUFFER_NUM as _, | ||
csi_enable: WIFI_CSI_ENABLED as _, | ||
ampdu_rx_enable: WIFI_AMPDU_RX_ENABLED as _, | ||
ampdu_tx_enable: WIFI_AMPDU_TX_ENABLED as _, | ||
amsdu_tx_enable: WIFI_AMSDU_TX_ENABLED as _, | ||
nvs_enable: WIFI_NVS_ENABLED as _, | ||
nano_enable: WIFI_NANO_FORMAT_ENABLED as _, | ||
rx_ba_win: WIFI_DEFAULT_RX_BA_WIN as _, | ||
wifi_task_core_id: WIFI_TASK_CORE_ID as _, | ||
beacon_max_len: WIFI_SOFTAP_BEACON_MAX_LEN as _, | ||
mgmt_sbuf_num: WIFI_MGMT_SBUF_NUM as _, | ||
feature_caps: unsafe { g_wifi_feature_caps }, | ||
sta_disconnected_pm: WIFI_STA_DISCONNECTED_PM_ENABLED != 0, | ||
magic: WIFI_INIT_CONFIG_MAGIC as _, | ||
} | ||
} | ||
} | ||
|
||
impl Default for esp_log_level_t { | ||
fn default() -> Self { | ||
esp_log_level_t(CONFIG_LOG_DEFAULT_LEVEL) | ||
} | ||
} |
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.
How would that affect
esp-idf-hal
andesp-idf-svc
? Would these continue to compile just fine after these changes, or do we need a PR for each of those to fix any compilation errors?Also: why do we want Rust enums?
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.
I guess there will need to be some changes to those crates. I can have a look at that of course.
They are more ergonomic to use and the compiler will check if all variants are handled.
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.
Would appreciate that. :)
I think I tried this once, but then for some reason abandoned it. Perhaps once you try to adjust
esp-idf-svc
andesp-idf-hal
to work with the new enum-based constants, the problem (if there was a real one) will resurface itself.