Many-port bus master

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Many-port bus master

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.

I'm currently considering how the device should present to OWlib:
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.

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.

I'm open to any suggestions too.

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

Cheers,

--
Alastair D'Silva           mob: 0423 762 819
skype: alastair_dsilva     msn: [hidden email]
blog: http://alastair.d-silva.org    Twitter: @EvilDeece




------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Many-port bus master

Jan Kandziora
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Many-port bus master

Paul Alfille-2
owlib does have support for that kind of device -- (multiple buses) -- The DS2482-800 is a good example. It has one "port" and multiple buses. The port gets locked for just the message (e.g. serial communication) and the individual 1-wire bus and slave gets locked for the 1-wire "conversation". Each of those buses can have independent conversations (e.g. do temperature conversions independently).

On Tue, Aug 1, 2017 at 11:24 AM, Jan Kandziora <[hidden email]> wrote:
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Many-port bus master

Alastair D'Silva
In reply to this post by Jan Kandziora
> -----Original Message-----
> From: Jan Kandziora [mailto:[hidden email]]
> Sent: Wednesday, 2 August 2017 1:25 AM
> To: [hidden email] >> OWFS (One-wire file system)
> discussion and help <[hidden email]>
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Many-port bus master

Jan Kandziora
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers