You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What do people think of having a crate (or crates?) for bits of code that's shared between crates. At the moment in particular, I'm thinking of the code that computes the value for the timing register in the i2c peripheral of many devices. This code is somewhat complex and sharing it would make it easier to fix bugs across multiple HALs. See this issue. The same bug seems to be present in many other HAL crates. The h7 crate has tests for the code and could serve as a basis for a shared crate.
Questions:
Should a shared crate limit its scope to just i2c timing (i.e. be a single function crate), or be more general? I'm not sure what other bits of complex code exist that are very similar or identical between HAL crates.
Should the crate avoid depending on cortex_m etc so that it can easily be tested without an STM32 connected? In the case of the i2c timing code, there's no need for cortex_m and the tests can run quite well on a desktop.
The text was updated successfully, but these errors were encountered:
What do people think of having a crate (or crates?) for bits of code that's shared between crates. At the moment in particular, I'm thinking of the code that computes the value for the timing register in the i2c peripheral of many devices. This code is somewhat complex and sharing it would make it easier to fix bugs across multiple HALs. See this issue. The same bug seems to be present in many other HAL crates. The h7 crate has tests for the code and could serve as a basis for a shared crate.
Questions:
The text was updated successfully, but these errors were encountered: