Wikipedia has some good articles on the DVI and VGA pinouts, and
what the electrical signals are. It turns out that DDC uses only two
signals, SCL and SDA, accompanied by digital ground. In DVI there is also a
+5V line, in VGA there isn't. In BNC video cables none of these signals are
present.
With that information in hand, it's clear that a competent video
cable supplier could make a breakout cable for DVI to any of these
standards. I've located a supplier who's willing to quote.
The next step is to decide on a connector and pinout for the DDC
breakout branch.
As a connector, I propose the DE-9S. Its virtues are that it has a
metal shell with 360 degree grounding, so it can be used with shielded cable
to divert ESD and interference to the chassis and keep it out of the
computer; it fits the same standard rear-panel cutout as a 9-pin RS-232
cable but is the opposite sex; there are versions for ribbon cable,
individual wires, and PC boards; and good quality shielded straight-through
extension cables are available off-the-shelf.
So: the same connector and pinout could be used as either a branch
of a DVI breakout cable, or as a rear-panel extension cable for a header on
the OGC1. That means we can specify a single connector type and pinout to
accept all of our external tools, no matter how they connect to the OGC1.
Since the complete set of DDC signals (SCL, SDA, GND, +5V) takes
only 4 pins, and the connector has 9, there are 5 pins available for SPI.
That would allow for the three basic signals SCLK, MOSI, MISO and two device
select signals, one of which might also act as NOT SS in some protocols.
Depending on implementation decisions, it's also possible that the DDC pins
might be dynamically re-purposed as additional SPI device enables, when
configured that way by EEPROM configuration data or other software.
OGC1 would connect to the ribbon cable extension by providing a
10-pin male header; this is the same 10-pin header a motherboard uses to
accept the 9-pin RS-232 rear panel extension cable. (It wouldn't be
possible to just use 10 neighboring pins of a long header, because ribbon
cable connector bodies have some extra length at the ends that would
interfere mechanically with the neighboring pins. This doesn't concern us
for OGD1, because OGD1's production volume is small, and we can make up a
cable using individual wires to plug into the correct pins of the OGD1's
accessory header.)
Both versions of the pinout, DVI breakout cable (with DDC signals
only) and rear panel connector (with DDC and SPI), include ground and +5V.
That means they can both power an external tool. So no wall warts or
batteries would be needed for any OGP tool. When we specify the maximum
current load on the +5V pin, it should be adequate to power a tool
containing a decent-sized embedded microcontroller and an RS-232 interface.
Off the top of the head, I think 100 mA would be sufficient, but we should
do power budgets for a few designs. I would hope OGD1 or OGC1 has that much
power to spare.
Here's a tentative pinout for an "Open Graphics Tool Connector":
Ribbon DE9 Signal name
cable pin
pin
______ ___ ___________
1 1 DDC SDA
2 6 DDC SCL
3 2 +5V
4 7 GND
5 3 SPI SCLK
6 8 SPI MOSI
7 4 SPI MISO
8 9 SPI NOT CS1 (Ext EEPROM select)
9 5 SPI NOT CS2 (Ext shift register device select??)
or SPI NOT SS (Slave Select)
If this meets with the project's approval after discussion, I'll
write it up as a Wiki page, to serve as a reference document. It should
eventually be absorbed into the OGA-1 standards.
I'll also write up a preliminary cable spec for SI to quote on. It
would be a variant of their stock DVI cables, with a side branch carrying an
OGT connector. SCL and SDA would go only to the OGTC; what do we do with
hotplug detect? Does +5V still need to go to the monitor, or only to OGTC?
How does half a meter sound as a branch length? In any case, we wouldn't
release a drawing or order special cables until OGA1 firms up some more.
BTW, one thing this doesn't provide is a dedicated select pin for
the on-board EEPROM. If we want the external SPI tool to be able to serve
as a rescue device to restore a corrupted EEPROM, we would need to plan for
a method of selecting it when the tool is driving the SPI lines. There are
several possibilities. Whatever is simplest for the ASIC would be the
preferred solution; we just need to look ahead a little.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
