messing with the gas / tank handling

Linus Torvalds torvalds at linux-foundation.org
Tue Oct 28 16:00:05 PDT 2014


On Tue, Oct 28, 2014 at 3:38 PM, Anton Lundin <glance at acc.umu.se> wrote:
>
> Multiple sensor support feels way better than the current separate
> "diluent-sensor" code we currently carry for the Mk6.

I think Dirk has another EON Steel with pressure sensor coming once
they are public, so then we can finally test the whole "two
independent and concurrent pressure sensors" from a dive computer that
supports it.

They've been around before, but we haven't had access to any real
data. And even some that are around don't seem to really report
multiple pressures (ie they'll switch on gas switch events, or they
support showing buddy pressures, but don't log them). It's possible
the EON Steel does the "switch on gas switch events" thing too, but
judging by the encoding, I *think* it will actually log pressures from
all the cylinders in parallel. We'll have to wait and see.

It's going to be somewhat painful. Going to *two* sensors wouldn't be
an issue: it doesn't take much more room than our current "sensor
index + pressure" for our single sensor model, and in fact if we
re-use one of the cylinders for diluent, we'd actually be shrinking
our data structures. But our MAX_CYLINDERS value is currently 8, and
it feels a bit wrong to make "cylinderpressure" an array of eight.

But I suspect that's what we'll have to do. Anything more complicated
would not just increase confusion, but on 64-bit machines even just
carrying a pointer to sensor data around takes up the space of two of
the pressures, so it's hard to make it much denser with extra
indirection or something.

I guess 32 bytes per sample just for sensor data isn't really all that
excessive in the end. It's not like people are likely to run this on
really old machines.

                 Linus


More information about the subsurface mailing list