The XFP application

Authors: Thiago Esteves (thiagocalori@gmail.com).

Note

The XFP application is dependent on GPROC library and the low level functions implemented at c_src/xfp_driver.c are just for test purposes (stubbed) and must be replace for the real accessors.

Introduction

The XFP is a transceiver for high-speed computer network and telecommunication links that use optical fiber. It is largely used in telecommunications equipment and the code here is an example of how Erlang language can be used to handle eletronic devices with a wrapper to the basic fucntions (i2c, uart, spi, etc).

The driver is using the polling format to read the presence pin every 1 second which means that it will take up to 1 second to detect any changes. Once the device is inserted, all the static information is read and saved in its state.

PS: This code is the same block code from (https://github.com/thiagoesteves/xfp) but using erlang state machines (gen_statem) t0 indicate presence or absence of xfp.

Compiling and Running

To compile and run for your machine just call the following command in the CLI:

$ make

Use case: Creating XFP devices

The user can create as many device as needed (the stub supports only 20, but with the real hardware there is no limitation):

1> rr(xfp).
[xfp_data]
2> xfp_sup:create_xfp(0).
{ok,<0.168.0>}
3> xfp:get_temperature(0).
{ok,6.25}
4> xfp:get_state(0).
#xfp_data{instance = 0,identifier = 6,
          vendor_name = "VENDOR NAME  XFP",cdr_sup = 0,
          vendor_oui = 32,part_number = "VENDOR PARTNUMBE",
          revision = "01",wavelength = 1310.0,
          vendor_serial = "VENDOR SERIALNUM",data_code = "DATACODE",
          diagnostic = 255,enhanced = 85,aux_monitoring = 255}
5> xfp:get_laser_state(0).
{ok,1}
6> xfp_sup:
create_xfp/1   init/1         module_info/0  module_info/1  remove_xfp/1
start_link/0
6> xfp_sup:remove_xfp(0).
ok

Stub: Emulating Insertion/Removal of the XFP

In order to test the capture of the insertion or the removal of the device you can write in the presence pin to simulate this condition as the example below:

1> xfp_sup:create_xfp(0).
{ok,<0.167.0>}
2> xfp:get_state(0).
#xfp_data{instance = 0,identifier = 6,
          vendor_name = "VENDOR NAME  XFP",cdr_sup = 0,
          vendor_oui = 32,part_number = "VENDOR PARTNUMBE",
          revision = "01",wavelength = 1310.0,
          vendor_serial = "VENDOR SERIALNUM",data_code = "DATACODE",
          diagnostic = 255,enhanced = 85,aux_monitoring = 255}
3> xfp_driver:write_pin(0,2,1).
{ok,0}
4> xfp:get_state(0).
#xfp_data{instance = 0,identifier = undefined,
          vendor_name = undefined,cdr_sup = undefined,
          vendor_oui = undefined,part_number = undefined,
          revision = undefined,wavelength = undefined,
          vendor_serial = undefined,data_code = undefined,
          diagnostic = undefined,enhanced = undefined,
          aux_monitoring = undefined}

Supervisor tree

The supervisor tree of all XFP's created can be easily viewed with the observer, try the sequence of commands below and have a look at the Applications->xfp.

1> xfp_sup:create_xfp(0).
{ok,<0.167.0>}
2> xfp_sup:create_xfp(1).
{ok,<0.169.0>}
3> xfp_sup:create_xfp(2).
{ok,<0.171.0>}
4> xfp_sup:create_xfp(3).
{ok,<0.173.0>}
5> xfp_sup:create_xfp(4).
{ok,<0.175.0>}
6> xfp_sup:create_xfp(5).
{ok,<0.177.0>}
7> observer:start().
ok

Erlang Code References

http://erlang.org/doc/tutorial/c_port.html http://erlang.org/doc/reference_manual/ports.html https://github.com/massemanet/inotify https://erlang.org/doc/design_principles/statem.html https://erlang.org/doc/man/gen_statem.html

XFP References

https://www.gigalight.com/downloads/standards/INF-8077i.pdf https://en.wikipedia.org/wiki/XFP_transceiver