Electronics > Microcontrollers

UART keep alive signal for SFP fiber

(1/6) > >>

Amper:
Hi,

im working on sending data between two STM32L via fiber over SFP modules, the link sort of works, one disadvantage is that the SFP trancievers seem to need a very symmetrical signal and have quite a long startup time. Even though i dont want to transmit a lot of data (high voltage insulation is the goal) i need a quite high baud and manchester encoding for the link to be reliable. After a transmission i have to wait several ms for the new packet to be unscrambled. That on the other hand is too slow for the transmission i want to do.

The solution that should work is to keep the link busy at all times. Is there some established way of doing this without using too much cpu time in the controller? The only way i could come up with rn is to put everything into something like 100 byte packages and as soon as the buffer of actual data is empty interrupt the program and send empty buffers filled with zeros or some preamble. It doesnt seem very elegant to me. also 100 bytes at 1MBaud would be an interrupt every 0.8ms which would be very inconvenient...

Maybe you guys have an idea :)

Siwastaja:
There seems to be a lot of mixups or weird questions.

What is this "SFP module"? What do you mean by "symmetrical", and seeing you mention manchester encoding later on, by symmetrical, do you mean free from DC bias? If so, MCU UART peripheral is probably unable to create manchester encoding, but you can try the SPI peripheral fed from DMA acting like an endless shift register. But, are you sure you need DC bias free signal? Because later on you talk about like you just have to send something. Specification to that "SFP module" would help sort this out. Even if you need DC bias removal, there are more efficient bit stuffing algorithms than manchester encoding.

What do you mean by "link busy"? All STM32 devices have DMA. You can keep the DMA feeding whatever data to UART with no CPU intervention. You can setup it in circular mode with, say, 1-byte long buffer, and just reconfigure it whenever you want to send something of value. Or, you can configure DMA into double buffered mode, and process (generate or parse) one of the buffers while other is being used by the peripheral.

What is this "unscrambling" which takes several ms?

Amper:
A bit of context was missing, you are right but you still got my question :)

https://de.wikipedia.org/wiki/Small_Form-factor_Pluggable

They are driven by lvds drivers, differential in, differential out, each line has its own dc block and as it seems also some internal auto gain or similar on the optical side that requires the signal to have not only no DC in absolute but also no dc over just a few bits. Just having two stopbits instead of one will cause glitches.

Manchester can be done in software before sending the modified bit order via the uart peripherals of the stm.

By "something" im taking about not having breaks in the transmission longer than two bits no not cause the auto gain of the reciever to missadjust and cause wrong bits upon the transmission resuming.

Your idea using just one byte via DMA sounds like what i wanted to do, my issue so far was mostly, how do i refill the TX buffer at a speed so it never overflows or runs empty, thats why i talked about the interrupt after sending.

The unscrambling (lack of a better word) means, the differential output with DC Block goes into a steady state with the lines close to each other after not seeing any signal for a while. Them being in undefined states makes the output just generate noise at a few GHz and the recovery from this state takes a few milliseconds after restarting transmission.

Siwastaja:
Thanks for clarifications, so you really do need Manchester or 8b/10b or similar.

What is the actual bitrate you need?

I mean, UARTs are pretty limited in speed (because of the internal x8 oversampling thing that runs at peripheral clock) anyway, so if it is working with UART, then, unless your algorithms are bloated, you can almost always do simple bit operations at maximum possible UART clock, with CPU to spare. Memory access being fast on MCUs, you could just even use large lookup tables to unscramble, so then it's just a dozen of CPU cycles per byte. Chances are, you could maybe do it even without DMA, on per-byte basis, in an ISR, but ISR entry and exit is some overhead (~ 20 cycles). If the UART has a FIFO, even just 4 bytes, then you are already much better off with reduced interrupt rate.

But double-buffered DMA where finishing one buffer triggers processing the other will have best performance. Alternative to the double buffering is one large buffer in circular mode, and usage of Half Transfer interrupt.

But getting the actual numbers, i.e. desired bitrate, MCU part number or even family (you just said STM32L; but between STM32L0 or STM32L4, big difference), and CPU clock speed would be helpful handwaving it more closely.

Amper:
Thanks :)

Yes, about the manchester im sure and i dont consider it an issue, thats something i already got going as long as i dedicate all cpu time to sending stuff.
Im sure i could do it with very little resources but wasting interrupts on something that happens so very regularly seems like a bad idea. Id like to not worry about it when doing other stuff.

For even more context: the original idea was just to have a way of making sensors and simple control stuff work over long distance and EMI resistant, remote sensing on hydroelectric powerstations, nothing critical infrastructure like but stuff like "filter two kilometers up hill behind a Forrest is clogged" or just temperatures and Waterlevels. So i took an open source board (https://gitea.osmocom.org/electronics/osmo-small-hardware/src/branch/master/sfp-breakout), quickly added space for the STM32L412C8T, some IO and an oled and got boards made. The next revision will have a sub-D as well and max232 because i realized it would be nice to connect the HP34970A isolated as well, so the goal changed to long range interface and RS232 tranciever via fiber.

The choice to use single mode fiber is because they are sort of cheap and very robust, also i have a splicer at home so i can make my own lines.

-> The datarate i need is very low, having 100kbaud would be plenty but since its the lowest limit the sfp hardware works ata and the controller doesnt seem to mind 1MBd im open to having more.


enough rambling around, put in fewer words, there are not really hard requirements i have to hit besides reliability and robustness, speed is not important, ease of use and keeping the controllers "mind" free of interrupts would be nice so i can use display and periphery without worrying about the communication failing.

EDIT: I guess ill try getting the DMA transmit working, that seems to be a good point to continue from no matter what the next step will be.

Navigation

[0] Message Index

[#] Next page