Am 02.08.2017 um 01:41 schrieb Alastair D'Silva: > > My situation is a bit special - all the lighting, roller shutters, > fans, etc will be controlled by the bus. By splitting out as many > ports as I can fit on the microcontroller, it means that I can have > many independent buses with only a few devices on each. This keeps > the weight of bus down, and speeds up search/alarm search times. > While I totally agree on unconditional searches, I disagree on conditional (alarm) searches. That is because there usually is either none or one device signalling an alarm. Searching for alarmed devices every second or so, then clearing that alarm condition works very quickly.
> It also means that a fault on the data line will only take a room, > rather than the whole house. > You need an access panel for the room's functions anyway. That's your Pi. One per room. So … you only need one bus per Pi, don't you? Ten years ago, I had agreed on having only one central computer. But nowadays that stuff is sooooo cheap people want to have an access panel in any room. (And no, a smartphone is as bad as the remote you always forget where it is.) >> >>> I'm currently considering how the device should present to >>> OWlib: >>> >> I found it most useful if you wrote a w1 kernel driver for it >> instead, so one could also use the DS28E17 Onewire-to-I²C bridge >> with your chip. > > Are there any downsides to presenting as a kernel driver rather than > an OWlib driver? > If it is an I²C or SPI device, no. An RS232 device needs some thought, as the TTY subsystem needs to be aware this port isn't a TTY anymore. You need to define a "serial line disclipine" defining the protocol as for RS232 connected mice, touchscreens and so on. > When we say "poor performance" on > http://owfs.org/index.php?page=w1-project , what exactly do we mean? > > I plan on doing alarmed searches on some ports at ~10Hz so that my > light switches respond with reasonably low latency. Would this be > achievable with a W1 driver? > If you offload the search into the chip, sure. Doing it on the main CPU requires playing with scheduler settings as the 15ms required for searching one alarmed device is a very long time for a process to run continously. Real-time priority required or the process gets a very low dynamic priority and is slowed down. This is both for a OWFS only driver and a w1 kernel driver, as the latter acts on behalf of the calling process during alarm searches. Withbout scheduler tricks, I was able to get down to 250ms per loop. Kind regards Jan ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
