Timeline for Low level C driver API
Current License: CC BY-SA 4.0
5 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jun 22, 2021 at 19:23 | comment | added | keyermoond | @Kaz this is precisely what I would like to avoid, I've seen several examples where there is a struct with 20 fields being passed around all functions in the driver. But on the other hand, keeping only stateful info in such a struct and keeping everything else as a seperate parameter seems reasonable to me. In the example you give the device handle may go into a struct, but say slave polarity or clock phase or w/e will have their own parameter fields I had difficulties trying to find any discussions on this specific topic, hard to formulate a good query that would result in anything useful | |
Jun 22, 2021 at 19:17 | comment | added | keyermoond | I am not sure what you mean by your second point. These kinds of structs usually contain stateful information only, for example - state of your GPIO bank direction configuration 8 bits indicating what's input/output. If there is a parameter that enables/disables power, it wouldn't be part of such a struct. If new chips are added that have different API then they require their own drivers? Why would it be reasonable to have one driver be able to service both types of chips? Approach #1 may fail here as well ie SPI_Init now also requires slave polarity or something | |
Jun 22, 2021 at 19:07 | comment | added | keyermoond | While I agree in principle to keep thing simple, it seems that approach #2 is indeed simple in many respects. It is often the case that a specific driver library exposes some sort of a control block structure anyway, this is because it is often the case that a driver encapsulating device operation is stateful, so you need to save state of the device somehow, and such control block structs provide an organized way of storing it. Since its already there, why not re-use it as a parameter? | |
Jun 22, 2021 at 0:36 | comment | added | Kaz |
eSTATUS spi_init(open_firmware_hell_t *device_tree_handle); Mouhahaha!
|
|
Jun 20, 2021 at 5:36 | history | answered | cwallach | CC BY-SA 4.0 |