Driving An SFP Module with Protocols Other Than Ethernet

[ajb]

Using SPI instead of UART could be more flexible.  Some MCUs directly support word oddball SPI word sizes, including some STM32s, and a 256x2 byte lookup table of pre-encoded 10-bit words wouldn't be too bad.  It's a little bit of memory overhead to trade against transmission overhead on the wire verses an 8->16 bit encoding (or 8->18 by the time you account for UART start/stop bits ). 

Using a little greenpak device for encoding/decoding could be worth exploring as well--could be neat to build a dumb but very flexible adapter module that way. 

[David Hess]

I'm pretty sure we did something at work a few years back where we got DC equalisation on UART at low processing overhead by repeating every byte inverted, but I can't remember how we avoided DC from the start and stop bits. Obviously it's inefficient, but when the channel is wide enough it doesn't matter. Gave us some redundancy for free too.

As long as you're sending continuously with no gaps, the start and stop bits will cancel each other out

I just noticed that; the start and stop bits have opposite polarity because the stop bit sets up detection of the edge of the following start bit.  All that is required now is continuous transmission to prevent a stop bit which is longer than one bit duration, and DC balancing of the 8 data bits.

If 8 (actually 9) zeros or ones in a row cannot be tolerated, then the data can be split into nibbles and odd or even bits used to maintain DC balance over 2 bit periods.  This could conceivably be Manchester encoding of 4 data bits into 8 RS-232 bits with start and stop bits for asynchronous operation rather than regenerating the clock from the Manchester encoding.  I guess that leaves one of the unused codes as an idle code, but now DC balance has to be over 4 bit periods but maybe that is acceptable.  The more complex this gets, the more 8b10b encoding becomes reasonable.

[jbb]

Next step; using Ethernet

[Nominal Animal]

Next step; using Ethernet

In a different thread, I mentioned that one could use raw Ethernet frames (layer 1 frames) to transmit RS-232 data between endpoints if using a small FPGA (with a sufficient SERDES), making it routable within a single local area network segment using standard switches.  You could even wrap the data within UDP/IP frames with configurable source and destination IP addresses and UDP port numbers, making the traffic ordinary UDP/IP.

The point there was, wrapping the datagrams in an Ethernet frame does not actually cost that much; you definitely don't need a full IP stack at all.  Only the 32-bit checksum (0x82608EDB, x³²+x²⁶+x²³+x²²+x¹⁶+x¹²+x¹¹+x¹⁰+x⁸+x⁷+x⁵+x⁴+x²+x+1) at the end (but before the interpacket gap) needs computation.

To drive the SFP module, one could use e.g. Microchip LAN9250 Ethernet controller (7€ to 9€ in singles at Mouser), communicating with it via 8 or 16-bit data bus and SPI from basically any microcontroller.

I do realize OP asked explicitly about other than Ethernet, but my point is that you can easily offload or use Ethernet on the wire, without specifically targeting Ethernet in your MCU.  If you look at the Microchip EVB-LAN9250 SFP interface (FTLF1217P2 on page 6), you only need four pull-up resistors (2×82Ω + 2×49.9Ω), two pull-down resistors (2×130Ω), four 100nF capacitors in series with the four data lines, plus some 3.3V supply filtering and mode strap resistors for the SFP module that will depend on the exact SFP module used.  In particular, one might use a separate slave microcontroller between the main microcontroller/device and the LAN9250 chip, converting the data from/to the custom format or data stream, to Ethernet packets; a kind of a custom-protocol to Ethernet + SFP driver module.  Replacing that module you can switch to a different interconnect, without chaning the main data stream format at all.

TL;DR: Having your main device know nothing about Ethernet or the interconnect used, it would only cost about 20€ in parts in singles from Mouser to implement an Ethernet-over-SFP interconnect using 100Base-FX (like the Broadcom AFBR-57E6APZ-HT SFP module OP linked to), if you use a translating/buffering microcontroller and e.g. LAN9250 industrial 100Base-FX ethernet controller.  To switch to a different interconnect fabric, you just replace the microcontroller + LAN9250 + SFP module, with no changes to the original device, maximizing upgrade path and long-term maintenance opportunities.

[Echo88]

Going with a suitable 100BASE-FX controller would of course be the most cost effective way to go for direct SFP ethernet usage and id go that way if there were arduino libraries that would use the LAN9XXX transceivers.
In my case id like to use the existing arduino ethernet libraríes which use e.g. a W5500 (or ESP32 + LAN8720) and just add a medium converter IC to get SFP connection.
However, im unsure if i can connect the medium converters ethernet input pins directly to the W5500 output or if the underlying 100BASE-TX stuff like baseline wander correction necessitates a magnetics path? The RTL8213B datasheet is rather sparse on specs.
I attached a schematic showing the intended connection scheme USB -> CP2102N -> ESP32 -> W5500 -> RTL8213B -> SFP.
Any thoughts?

[Echo88]

Attached is an alternative version doing what was intended by OP in the first place: using SFP modules without resorting to Ethernet.
It uses the already mentioned FSK-modulation idea and should be suitable to achieve <=1MBit (yet untested).
Since this is my first time using the 74HCT4046A it would be nice if more experienced users could point to obvious errors in the schematic or add improvements, before i produce a pcb to test it.

Thanks.