Am 01.08.2017 um 16:01 schrieb Alastair D'Silva: > Hi folks, > > I'm currently designing an open-hardware 32 port 1wire bus master for part > of my home automation system, and would like your input. > > The design is based around an STM32F412ZG microcontroller, with MOSFET > active pullups & drive transistors. It will present as a hat for the Orange > Pi Prime (other Pis may also fit). My plan is to connect over the serial > port, but I've also wired through I2C & SPI just in case. > A hat employing standard connectors is going to be more useful to average users. This limits the number of channels because of the size of the hat.
And nearly no one would need 32 channels. The 8 channels the DS2482-800 offers are already too much for most applications. What would be incredibly useful is a chip that does have separated RX and TX lines for each channel so one could use optocouples for totally isolated onewires. People using Onewire for building a weather station will love you for such a thing. Your hat should employ these, as well as an optional isolating DC-DC converter! What would be also useful is a device that offloads e.g. the search algorithm as the DS2490 does. That chip is now unavailable outside of the DS9490U device. > 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. > Option 1: Maintain an internal hashtable mapping devices to ports, and > present as a single bus master. This has the downside of limiting the > potential number of devices, as well as monopolising all the buses during > long events, such as a firmware update. This would be annoying, as my light > switches won't respond across the whole house if I have to update the > firmware on any device. > > Option 2: Present as a single multi-bus master. I'm not sure if OWlib has > such a concept, if not, there may be significant infrastructure work > required. If it does, great, as hopefully OWlib will keep track of which bus > a device belongs to. > Just look at the DS2482-800 host adapter code. > Option 3: Present as many bus-masters. I think this would be a reasonable > solution, as other buses should continue to operate even if one is > monopolised by a firmware update. In this situation, only a single room will > stop responding, rather than the whole house. > On the OWFS level? Better not, it would make the configuration awfully complicated and require an awful lot of work. > > PS. Would it be possible to get my current work reviewed? I'm not quite > ready to push it upstream, but it would be good to know early if there is > anything there that would prevent it from being merged. My repo is here: > https://github.com/InfernoEmbedded/owfs/tree/infernoembedded > Please do not use the same source file for both your upcoming host and your current LED controller and relay boards. If you are happy with your current devices **and have them tested against the current version of owfs**, prepare a patch and I will push it into master. You are the only one who can test it anyway as long noone else has this hardware. 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
