Interface MCU to PC via fiber

Hi all, I have a MCU telemetry system which I need to connect to a PC for recording data and sending commands, but the connection has to be via fiber optic, preferably just two fibers. Distance is only about 10m, and the communication will happen in short bursts at up to 5mbps. As for the MCU, I have to stick with atmel chips I have experience with (AVR, xmega, and UC3 types. No experience with their ARM line, unfortunately).

So for that baud rate my options are USART or SPI, but my **broken link removed** will likely require something like 8/10b encoding to maintain good signal integrity. One option I'm considering would be to convert SPI to ethernet with a chip like the ENC28J60. But this would be quite a bit of coding get such simple functionality. I'm wondering if there are any simpler approaches to use, given my restrictions on the MCU and transceivers?

Hi,

We use Avago/Broadcomm POF HFBR for communication with PC to AVR.

Easy to use. Reliable. Relatively cheap.

***
But your given data is confusing.
"Short bursts with up to 5mbps:"
I assume you mean Mbps instead mbps (mega instead of milli).
But I see no chance with UART and AVR to achieve 5Mbps.

Does 8b/10b increase integrity? I thought it's main benefit is DC free data transmission with transformers....

How does SPI in combination with ENC28 relate to fiber?

Klaus

KlausST said:

Hi,

We use Avago/Broadcomm POF HFBR for communication with PC to AVR.
Easy to use. Reliable. Relatively cheap.

Click to expand...

I've also used the Versatile link/HFBR parts. Quite easy to use, but for this I may be forced to use the transceiver in the link I posted, which is meant to work with IEEE 1394b, so it will need DC-free encoding. I definitely don't want to touch firewire encoding, but I believe they would work with ethernet encoding as well, and there are widespread SPI <> Ethernet converters with lots of documentation.

Yes, I mean 5Mbps, or 5 megabaud. If I had to I could run an SPI clock up to 30MHz, and the ENC28J60 is specced to handle SPI clock rates up to 10MHz. I'm hoping that after accounting for overhead I can get an effective 5Mbps datarate.

Another option I've thought of is to just use one of the synchronous serial ports (either SPI or USART) from the MCU to drive the transceivers directly, and implement a DC eliminating encoding scheme in software. Then on the PC side I would need another MCU to decode it and convert it back to another serial stream to the PC. Also this option would require a third fiber for a clock.

Hi,

If I had to I could run an SPI clock up to 30MHz, and the ENC28J60 is specced to handle SPI clock rates up to 10MHz. I'm hoping that after accounting for overhead I can get an effective 5Mbps datarate.

Click to expand...

Even if the SPI clock is 10MHz, then I expect a data throughput of far, far, far below 1MBaud.
Maybe 0.1MBaud. But to be true I have no experience.

Klaus

That fiber transceiver you've spec'd has LVDS inputs, I'd wager your simple uC doesn't have any LVDS pins on it and you can't expect to drive LVDS with two 3.3V pins with opposite polarity, it just won't work (more likely will fry something).

Does 8b/10b increase integrity? I thought it's main benefit is DC free data transmission with transformers....

Click to expand...

It's other benefit is for clock recovery as it generates a guaranteed minimum number of transitions in the data stream regardless of the data sent. e.g. without encoding sending a serial stream of 1000 1's would be impossible to recover, but 8b10 will guarantee that the serial stream toggles between 1 and 0 allowing for recovering the data by recovering the transmission clock.

- - - Updated - - -

KlausST said:

Hi,

Even if the SPI clock is 10MHz, then I expect a data throughput of far, far, far below 1MBaud.
Maybe 0.1MBaud. But to be true I have no experience.

Klaus

Click to expand...

Hmmm, I can believe such low numbers if the uC has no SPI controller interfaces available and you have to bit-bang the SPI protocol across.

With DMA and a SPI controller I would expect that you could run a 10MHz SPI closer to 8Mbaud if you send large blocks of data or no address cycles at all. If you send only data and 8b10 encode it you'll need another 20% of your available bandwidth So it's more like 6Mbaud. But from what I saw on the datasheet for the transceiver it doesn't use SPI. Instead you supply a data stream (which can be 8b10 encoded) with an embedded protocol of your choosing.

KlausST said:

Even if the SPI clock is 10MHz, then I expect a data throughput of far, far, far below 1MBaud.
Maybe 0.1MBaud. But to be true I have no experience.

Click to expand...

SPI by itself has no overhead aside from the gaps between bytes/words/etc. Baud rate should be very near the SCLK frequency. Are you referring to overhead in the ENC28J60 interface?

- - - Updated - - -

ads-ee said:

That fiber transceiver you've spec'd has LVDS inputs, I'd wager your simple uC doesn't have any LVDS pins on it and you can't expect to drive LVDS with two 3.3V pins with opposite polarity, it just won't work (more likely will fry something).

Click to expand...

Translating the MCU levels to LVDS is fairly trivial.

But from what I saw on the datasheet for the transceiver it doesn't use SPI. Instead you supply a data stream (which can be 8b10 encoded) with an embedded protocol of your choosing.

Click to expand...

Right, that's what the ENC28J60 would be for. Alternatively I could try a similar thing in the MCU software. It's just a matter of which one has a better software/hardware/overhead tradeoff.

Hi,

Are you referring to overhead in the ENC28J60 interface?

Click to expand...

Yes, I meant the complete way from microcontroller - SPI - ENC28 - Ethernet - PC
For sure it will depend on packet size, setup...

Klaus

KlausST said:

Hi,



Yes, I meant the complete way from microcontroller - SPI - ENC28 - Ethernet - PC
For sure it will depend on packet size, setup...

Klaus

Click to expand...

I'm no expert on ethernet, but where do you presume such a bottleneck would be? I doubt it would be on my MCU's side, since it will be dedicating all of its time to just piping data from its IOs to the ENC28.