Jump to content
43oh

spirilis

Members
  • Content Count

    3,399
  • Joined

  • Last visited

  • Days Won

    146

Posts posted by spirilis

  1. Looking up the datasheet for some of the SFP's I have laying around (potentially bad)-

     

    https://www.finisar.com/sites/default/files/downloads/finisar_ftlf8524p2xny_4.25gbs_rohs_compliant_short-wavelength_sfp_transceiver_product_specification_1.pdf

     

    Finisar FTLF8524P2BNV (from a 4Gbps Brocade ED-48000 fiberchannel switch)

     

    post-15991-0-64244600-1469559121_thumb.png

     

    Sounds like there are different speed-related modes that are switchable via I2C (OR a GPIO toggle) but there is no "Min" in the bitrate...

  2. Lol... Decided to take another look at this thread, as my boss and I were chatting about how many (potentially bad) SFPs we have laying around the office.

     

    So if I'm not mistaken, the SFP has an LVDS interface for the TX and RX side, and you just need an LVDS interface - something like http://www.ti.com/product/ds90lv011a (TX) and http://www.ti.com/product/ds90lv012a (RX) for example (a 400Mbps PHY available for ~$1 at mouser in single qty) - and boom, an LVDS interface you make?

     

    Per https://en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver - there are lines to disable TX, sense if TX is faulty, and sense if there is no optical RX present.  Sounds simple enough?  Does the transceiver not really give two craps about the speed of the LVDS PHY except for obvious issues that can emerge when you push it to its upper speed limits?  So you could just route the LVDS TTL in/out to the UART, and speak high speed UART over fiber?

    (High-speed differential traces of course respected for the LVDS stuff... luckily my favorite PCB CAD software, DipTrace, now has differential pair management in v3.0+)

     

    Also to make a hobby board out of this I'd need a suitable edge connector for the SFP's.  Unless SFF's are available cheap...

  3. Yeah my memory is rusty but from past deconstruction and reconstruction of the Energia Wire framework, what you're trying to do isn't possible since the handling of the reads happens within the ISR.  Obviously this is the case since there is no specific method within Wire to "end" the transfer, i.e. requestFrom is sufficient all by itself to execute the read operation, and it takes an upfront count argument for how many bytes to read, so it must handle the entire transfer from start to stop by itself, putting it in a temporary buffer that you read when you use Wire.read()

  4. A 0.8mm pitch TQFP is crazy easy to solder for those who are just getting into surface mount (SMD) soldering.  MSP430 doesn't come in any packages like that fwiw, usually 0.65mm (TSSOP) or 0.5mm (QFN) although there is an MSP430F5172 available in BGA (although pretty fine-pitch I think, called dsBGA) .... but Energia doesn't support that chip.

  5. One thing I've done in the past for state machines and command processors was to make the commands or the state variable the value of the function pointer itself, so there is no lookup table wasting space. Making the commands "human readable" in the code was simply creating readable #defines for each value. This wouldn't work great for a human to input commands, but two devices communicating with one another don't care that the "Reset" command is some random 32 bit integer.

    I guess that's an MCU's poor mans COM/OLE!

  6. The replies make good points, thank you. I am going to look into disabling the RX ISR while the command is being processed within the RX ISR. That fits within the use-cases for this app. hopefully the HC-05 BT module has enough buffering to hold any few characters that may come in while RX ISR is disabled.

     

    Another option is to place the commands in a queue to be processed "later" when not in the RX ISR.  Without an OS to support queueing, threading and scheduling issues that is just too much trouble, for this project on this little MCU (running out of code space anyway)

     

    Thank you for the replies,

    It is typically the case that your ISRs set a "signal semaphore" (global "volatile boolean" variable) and the main loop does the remaining processing.  Not all that hard to do with a while() loop as your make-shift "scheduler" - or just the loop() function in Energia's case.  There would be a set of conditions at the beginning of loop() that would determine whether it's safe to enter sleep() mode or whatever, and if any of those failed it would go through and check each one and run the handler.

  7. Yes the main problem is the I/O pins on most digital devices have ESD protection (electrostatic discharge) which is intended to "drain off" excess voltage above Vcc or below GND into the Vcc or GND planes where it can hopefully get absorbed by capacitors or shunted through the GND plane or whatever.... but those basically involve a pair of diodes reverse-biased. (wish I had a pic handy, too lazy to find one)

    edit:

    cypress-1.JPG

     

    The problem happens when you apply a legitimate (3.3V we'll say) signal to the I/O pin of a device whose Vcc is at GND potential (i.e. it's powered down).  The protection diodes faithfully do their job, shunting that "excess voltage" to the Vcc rail, which then powers the chip.  Oops!

     

    The answer is to use some sort of bus transceiver or Level Shifter to truly "disconnect" the powered-down device.  I have done this (using a TI TXB series level shifter) for SPI bus pins with great success.

  8. Maybe my math is off, but a millisecond is one/one-thousandth (1/1000) of a second. So, the aforementioned 0.00003051757812500000 seconds is 0.030517578125 milliseconds... not 30.517578125 milliseconds.

    Oh yeah duh... I was thinking microseconds :D

    Same problem anyhow.

×
×
  • Create New...