Quick Q regarding Ethernet

No. MII is a management interface that is used for status/control purposes. It does not transfer Ethernet packets.

--
Grant Edwards                   grante             Yow!  Oh, FISH sticks,
                                  at               CHEEZ WHIZ, GIN fizz,
                               visi.com            SHOW BIZ!!

MII = Media Independent Interface (or is it Interconnect?)

I'd chase this option first. Grant's memory may be better than mine, but IIRC, MII interfaces are intended for using an external PHY (e.g., fiber), and you may find its signaling more compatible for your interests. There should be some more details in the datasheet.

Some things to look into - at least Realtek's 10Mb chipset uses this as a multi-function interface, so you'll probably have to select it as MII mode. Also, see if activating this port comes at the expense of disabling anything else (like one of the other ports).

There's a possibility you could connect them together, creating a trunk between the 2 switches.

So, what particular failover scenario are you trying to achieve? Maybe there's a simpler path to your goal.

Oops. I mis-spoke. MII has two sets of signal lines, one for the serial management interface, the other for data-frames (it's a nibble-wide path, IIRC). I was thinking that MII referred to the management half and there was some other TLA for the data half, but MII is both.

--
Grant Edwards                   grante             Yow!  Thousands of days of
                                  at               civilians... have produced
                               visi.com            a... feeling for the
                                                   aesthetic modules --

Thanks for the info, you and Grant both. I'll have to look into the MII interface more, then, seeing as it's not neccessarily a non-starter!

The failover requirement is that we have a scheme that involves two independant LANs being carried from a subsea to shipboard enviroment. They are independant because under normal circumstances we will use one for high data rate monitoring from one transmitter on the seabed to one receiver on the surface, and the other for overall control of a number of subsea bits of equipment. We want no other data on the high speed link in normal operation.

However both links are vulnerable to disruption for one reason or another and if that happens we want to be able to route the two LANs together to bypass the break. There are several of these dual hubs between the deck and the last node, and any interconnect can be broken, so we need to be able to crosslink at any hub if required.

An alternative is that the local controller in each hub could act as an intelligent router if we fit them with two NICs, and we could tell them to route between LANs if required. There are advanteges and disadvantages in both approaches, though.

Cheers, Trev

--
Trevor Barton

A clever approach. Sounds reasonably resilient. I gather you're OK with using a microcontroller, just not to forward data between the switch chips?

This is actually a pretty slick chip! It'd be worth your time to study the datasheet - it's got some powerful features for a single-chip solution.

1) Check out the Power-down and Isolate features (section 7.1.1) - this is one easy way to handle what you want. Via an external MCU, just turn the failover ports on & off as needed. Query other status registers to decide when. 2) Even slicker - a one-chip solution. If you use the VLAN features of the switch (section 8.3.1) you can keep your 2 data channels separate while using a single switch chip. Simpler, higher-performance, much better failover ability.

E.g., under normal circumstances, ports 1 and 2 (downlinks) are in separate VLANs which only talk to ports 3 and 4 (uplinks), respectively. If any link fails, the MCU simply reconfigures ports to map a spare uplink or downlink cable into the failed VLAN (the two channels only need to be co-mingled as a last resort). This could yield

2 uplinks and 2 downlinks, plus 2 failover ports in each direction - you'd need to lose 3 uplink or downlink cables before you'd have to combine the channels into one VLAN.

The only exposure is using a single switch chip (and single MCU). Lastly, use the MII port for the MCU's Etherenet so it can report status remotely.

Yes, the microcontroller (actually a PC104 x86) controls video multiplexing and power distribution as well.

Thanks, Richard, a few good ideas to look into there. The VLAN idea sounds neat, but I think I'm going to run into problems with the number of ports anyway, because I actually need 9 per side although I think I cna squeeze it into 8. Direct connection to the controller sounds interesting, though.

Cheers, Trev

--
Trevor Barton