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

no_std support still depends on std #32

Open
simpkins opened this issue Apr 24, 2024 · 0 comments
Open

no_std support still depends on std #32

simpkins opened this issue Apr 24, 2024 · 0 comments

Comments

@simpkins
Copy link

esp-idf-part still appears to depend on the std crate even when used without the std feature.

The serde_plain dependency pulls in a dependency on std, as it depends on serde with the default features.
This could be made an optional dependency, but there are still other std dependency requirements: serde appears to only support untagged enums when the std feature is enabled, and this is used for the SubType enum. It probably would be possible to put all derive(Serialize, Deserialize) attributes behind a cfg_attr check.

All that said, given that PartitionTable::try_from_bytes() is only available with the std feature I don't think that no_std support is going to be useful for what I was hoping to do anyway. The dependency on deku seems to be the main hurdle to making try_from_bytes() work with no-std and no-alloc. For my use case I know my buffer will be aligned, so it's probably easiest for me to just declare my own #[repr(C)] PartitionTableEntry struct and just use bytemuck::from_bytes() to read the table entries through that structure.

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

No branches or pull requests

1 participant