Subject: Re: Dallas semiconductor "one-wire" and envsys(4)
To: Jeff Rizzo <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 02/25/2006 10:01:37
In message <email@example.com>, Jeff Rizzo writes:
>(I debated whether this was more appropriate for current-users or
>tech-kern, and decided more potential _users_ would be reached on
>current-users. If more discussion of details is warranted, it should
>probably be had on tech-kern)
>I'm currently working on a driver for one-wire devices (such as the
>DS18B20 temperature sensor) which attaches to gpio(4), and I'm wondering
>if anyone else would find this useful - my intended usage is to hook up
>a bunch of these devices to a soekris 4511 to monitor various stuff
>around the house.
>It's not clear to me whether this would be something appropriate to
>bring in to NetBSD or not - these devices are not commonly built into
>motherboards, and the usual usage is with microcontrollers (PIC, AVR,
>etc) - the bus protocol is such that the driver I've written has
>DELAY()s of up to 450ms, and I don't see a way to get rid of them and
>still retain the correct timing for bitbanging the protocol. That said,
>the chips are fairly inexpensive (the DS18b20 is about US$5 in quantity
>1, the DS1822 less than US$4), and are easy to connect up for any
>moderately competent hobbyist.
>So, on to the questions.
>1) Are people interested in having this available in NetBSD? Is it
>2) Should I do the work to integrate the temperature sensor parts into
>the ensys(4) API? Right now, most of the actual work is done in
>userland, with the exception of the bus-scanning code to see what
>devices are connected. If people aren't interested in general (or think
>it's a bad idea), I'll probably just leave things this way, because I
>don't have particularly complex needs right now.
>3) Does anyone have any further suggestions? The code is currently
>"working", though I don't do much with it yet. If people are
>interested, I can clean it up and post it for testing. (It definitely
>needs work before I'm letting _anyone_ see it)
It strikes me as a useful thing to support.
As for your DELAY()s -- would a sleep in a high priority kernel process
do the trick?
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb