DRAFT: Add onewire driver #18051
DRAFT: Add onewire driver #18051
Conversation
|
I you use a high-level timer like xtimer your timings will not be very accurate and the periods will have jitter. |
| typedef struct { | ||
| gpio_t pin; /**< Pin the sensor is connected to */ | ||
| gpio_mode_t out_mode; /**< Pin output mode */ | ||
| gpio_mode_t in_mode; /**< Pin input mode (usually deduced from output mode) */ |
There was a problem hiding this comment.
?? never set but used ??
i remember to have seen this in #14897 and there i wrote: "if it is deduced from omode there is no need to save it"
There was a problem hiding this comment.
Well shoot. I didn't realize somebody had already attempted this. It looks like #14897 is further along than mine. Would it make more since to re-open the older one and close this PR? I'd be happy to work on resolving the issues in the older PR.
There was a problem hiding this comment.
I used a copy of the ds18 as my starting point. I agree this is not as it should be. Up until now, I've mostly concerned myself with the API and not the implementation, since I knew the implementation was at least mature. I'll make sure this gets cleaned up.
Thanks, I'll take a look. |
|
+1 for using |
|
Contribution description
This is an early draft of a 1-wire driver for RIOT. I began with the existing ds18 driver. For those that don't know, 1-wire can support multiple devices on a single bus (called multi-drop in 1-wire terms). The existing ds18 driver did not support this.
I'm seeking advice on what the API might look like to support multi-drop. Originally I was going to add a parameter to
onewire_aquire()to point to a byte array containing the device serial number of the desired device on the bus. If the pointer wasNULLI was going to treat the bus as a single-drop bus and skip address matching. This isn't great though since the device lock (mutex) is acquired in this same function. I think locking and addressing might be better if separated, but I don't want to complicate the API too much. Also sometimes on a multi-drop bus the address is skipped, for example, when broadcasting a request on a bus of multiple ds18 temperature sensors, for their alarm state.Another issue I'm requesting feedback on, is how to handle updating
ds18_params_tif updating it to use the newonewiredriver. Ideally, it's params struct would contain a pointer to aonewire_t, but that means that aonewire_tmust exist somewhere. Should each board be updated to have an array of onewire buses similar to how i2c and spi is handled?Finally, I'm not certain how to handle the copywrite notices at the top of the files I have copied from the ds18 driver. Should I leave them?
Testing procedure
TBD
Issues/PRs references
previously requested in issue #10236