Hi Marko,
That sounds sensible to me, with timer+GPIO beind the sensible place to
start in my opinion with UART an interesting second option if you have a
free UART HW block available.
I'm happy to contribute one or two drivers for common 1-wire sensors or
devices, and help out implementing/testing some of the common glue code,
but in order to remain consistent with the rest of the Mynewt APIs and
goals I'd prefer to defer the implementation decisions about the common
API to the larger community who are more active in mynewt-core and I can
design some drivers around that to test it out with real HW.
Happy to help in any capacity, though!
K.
On 03/07/18 14:44, marko kiiskila wrote:
Hi Kevin,
I was thinking separate packages for different implementations, and
then syscfg knobs inside the respective ones. E.g. GPIO/timer and UART
selection.
These packages would implement the ‘1-wire’ API, and chip drivers would then
depend on that API.
The PJRC API is simple, which I like. Seems like a good starting point.
On Jul 3, 2018, at 3:31 PM, Kevin Townsend <[email protected]> wrote:
Hi Marko,
IMHO, The PJRC lib is a sensible basis for a Mynewt 1-Wire package since it's
seen a fair amount of real-world use, and the underlying implementation could
be configured via the syscfg.yml file (timer+GPIO or something else like UART
if you have one free)?
Kevin
On 03/07/18 12:07, marko kiiskila wrote:
Sounds like a candidate for driver interface, not HAL. I agree with Miguel.
User could pick the implementation which uses UART, or one which
uses hal_timer with hal_gpio.
However; Sam, you don’t think a generic driver interface makes sense?
If you had driver package which implemented an API similar to this:
One-Wire Library, https://www.pjrc.com/teensy/td_libs_OneWire.html
<https://www.pjrc.com/teensy/td_libs_OneWire.html>,
would you have been able to use it?
On Jul 3, 2018, at 3:11 AM, Sam Lewis <[email protected]> wrote:
It might be more difficult to make a generic driver for but I've had some
great success using a UART peripheral to read/write 1 wire devices. There's
a good writeup of how this works in this app note:
https://www.maximintegrated.com/en/app-notes/index.mvp/id/214
The benefit is less CPU time needed for bit banging but you need to make
sure your 1 wire device fits the timing constraints of your UART peripheral.
Just thought it was worth mentioning, might be something to consider.
Sam
On Tue., 3 Jul. 2018, 6:11 am Kevin Townsend, <[email protected]>
wrote:
Hi Miguel,
Good to hear!
Yeah, GPIO is the only way I've ever implemented this and I think a
simple SW implementation is the way to go here.
K.
On 02/07/18 21:39, Miguel Azevedo wrote:
Hi Kevin,
I actually do have some code for 1-wire I implemented a few days ago.
AFAIK most MCUs we support don't have 1-wire specific hardware, so why
not have a general implementation(using hal_timer) instead of one
implementation per MCU?
Thanks,
Miguel
On Mon, Jul 2, 2018 at 8:10 PM Kevin Townsend
<[email protected]> wrote:
Is there any interest is discussing how to add Dallas 1-Wire support to
the HAL? https://en.wikipedia.org/wiki/1-Wire
It's a bit of a niche item, but an interesting protocol (you can power
some devices from the single GPIO line) and there are some very common
and cheap waterproof temp sensors and a few other common items that are
only available in 1 wire.
I'm happy to put one or two test drivers together for common items like
the DS18B20 (https://www.adafruit.com/product/381) ... but the HAL
implementation is something that should probably be discussed with the
wider community first.
Kevin
