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
There are a number of peripheral drivers already implemented in the esp32-hal repository. Since this crate has been published, we aren't really able to release a new version until we've roughly reached feature-parity with the previous implementation. Because of this, we should begin working on porting this drivers.
These can either just be dumped in the esp32-hal package for now, making the required changes just to get things building, or can be re-written to be compatible across all supported chips. While the latter method is preferable, the prior is likely the more realistic path forward.
I'm not sure if this really should be a hard requirement for a potential release. Someone using the deprecated HAL can just pin the version and even more important even if we have all of those the new HAL isn't a drop-in replacement since many things are just different (for good reasons).
But certainly, it would be a good thing to cover all of those
We have support for timer - what we should do however is handling it similar to SYSTIMER and split each timer to make use of the three alarms. But I'd say that is a "nice-to-have" enhancement
I'm going to close this. Other than LEDC (which is in progress and hopefully will be merged in the coming weeks) there's not really anything left worth worrying about right now, I don't think.
There are a number of peripheral drivers already implemented in the esp32-hal repository. Since this crate has been published, we aren't really able to release a new version until we've roughly reached feature-parity with the previous implementation. Because of this, we should begin working on porting this drivers.
These can either just be dumped in the
esp32-hal
package for now, making the required changes just to get things building, or can be re-written to be compatible across all supported chips. While the latter method is preferable, the prior is likely the more realistic path forward.The existing drivers are:
analog/adc
analog/dac
clock_control
see We need a way to configure clock rates #44delay
dport
dprint
efuse
external_ram
gpio
i2c
interrupt
ledc
(in progress)mem
serial
spi
timer
(partially complete)The text was updated successfully, but these errors were encountered: