4 Mar
2014
4 Mar
'14
1:03 p.m.
On Mar 4, 2014, at 2:09 PM, Pontus Pihlgren <pontus at Update.UU.SE> wrote:
It is tempting at that price point.
With risk of increasing the price, wouldn't be nice to include Philipps
"OmniUSB" in the design? There is plenty of room for it.
Perhaps room for a daughterboard with an FPGA?
What I'm thinking is that if you are doing the effort to manufacture
the PCB and source the bus drivers you might as well plan ahead for
other goodies that can share the bus. Perhaps that is it, a "local"
Omnibus if possible?
Beware of premature optimization, it is the root of all evil. And
so is trying to start with a product that's something for everyone.
Get the thing working, THEN pile features onto the next spin or a
subsequent version so that people can at least have something to
play with while you work on it. Otherwise, in my experience, you
wind up an in infinite loop of "well, what if I add THIS?" and
never actually ship anything. It's my personal Achilles' heel,
and an urge that I have to constantly suppress (with varying
degrees of success).
As far as the bus transceivers, it looks like he's using 26S10
ICs, which are at least still actively sourced by TI. I don't have
any experience with Omnibus, but DEC generally had the same specs
electrically for most of their buses, and the 26S10 violates a few
of the Qbus rules, at least (threshold should be ~1.5v, transitions
are way too fast, leakage is pretty high), but as Philipp's board
has shown (at least anecdotally), you can violate the specs by a
fair margin and have it work in a lot of cases.
No one seems to manufacture a single transceiver IC these days that
complies with the DEC specs; the main tripping point seems to be
the threshold, followed closely by the transition times. You can
fix the former with some expensive ($1/gate or more) analog
comparators, and you can fix the latter by driving output with
selected transistors, but most people aren't going to invest the
money or board layout effort for that.
- Dave