We’ve been going over a painstaking review of the various HAL APIs, to make sure we capture all the changes we want to include prior to merge.

Today, we looked at the driver framework, hal GPIO and SPI, here are the changes we discussed:

- GPIO needs to re-name the GPIO state enums to have an hal_* in the name

- Driver functions in adc_dev and elsewhere should be static const to save RAM.

- HAL GPIO: we should remove set/clear/toggle, and just have hal_gpio_write(pin, val)

- HAL GPIO: there should be a function hal_gpio_release() so that ports can be turned off when a pin is no longer used. - Q: should hal_gpio_init_in/out follow the more common config(), enable(), disable() paradigm in the rest of the HAL?

- HAL GPIO: hal_gpio_irq_enable() should by default clear any pending IRQs. We discussed having a bit to check if interrupts were pending, and clear them separately (or whether to make this optional), but couldn’t think of a case where you’d want to enable IRQs, but not clear pending interrupts.

- Discussion of enums versus #defines for various things (like SPI mode). No clear conclusion here. We all agree that enums for error codes are verboten, and that we should be consistent about usage of enums or defines. - Good points for enums: autocompletion in IDEs, debugger shows name vs value, type safety - Bad points for enums: unless packed, they take up a full integer. You need to look up the type of the parameter, which takes up just as much time as looking up the autocompleted value. - We’re kinda mixed, with nobody feeling particularly strongly. Whatever folks think, I think we’d be fine adhering too.

- OS device APIs are not doxygened, they need to be.

- HAL SPI: will/chris will respond with changes discussed here. they’ve also been looking at HAL SPI recently.



Reply via email to