> -----Original Message----- > From: Jan Kandziora [mailto:j...@gmx.de] > Sent: Wednesday, 2 August 2017 1:25 AM > To: owfs-developers@lists.sourceforge.net >> OWFS (One-wire file system) > discussion and help <owfs-developers@lists.sourceforge.net> > Subject: Re: [Owfs-developers] Many-port bus master > > 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.
Agreed, I work around this by using daughterboards for signal conditioning and hosting 8 port RJ45 sockets. These will be laid out into a 1RU compatible case. The schematics & board layouts are here if you're interested: https://github.com/InfernoEmbedded/onewire-softdevice/tree/master/devices/PiMultichannelMaster > And nearly no one would need 32 channels. The 8 channels the DS2482-800 > offers are already too much for most applications. > 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. It also means that a fault on the data line will only take a room, rather than the whole house. > 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! > Good idea, I didn't think of that. The raw TX & RX lines are indeed separated between the hat & daughterboards, so spinning a new isolated daughterboard in the future is definitely possible. > 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. > Definitely, that's also what I was thinking. I'll also offload multibyte read/write operations, so that things like firmware updates aren't too chatty. > > > 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? 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? > > 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. > Great, thanks to you & Paul for that tip, I'll look into it :) > > 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. > No worries, this would be a completely separate device. The other devices are shared as they have to maintain the same serial number when they drop to their bootloader for firmware update. I've separated the code, but for the compiler's sake, they are #included into a single amorphous blob to avoid leaking symbols. > > 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. > Ok, I'll retest over the next few days, thanks :) ------------------------------------------------------------------------------ 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
