too many versions of this code

[carandraug]

There's too many versions of the code lying around on our different
RedPitays plus the different branches. Here's what I have found on github:

• MicronOxford/master: this was branched from what Tom finished after
  his summer project in 2015. Since then, it has had changes from me
  to use GNU autotools for building and to support Python 3, some
  documentation notes from Tiago, and changes from Mick to support
  newer Pyro4 and options to specify IP address and port.

• MicronOxford/tom-december-changes: this was branched off from
  MicronOxford/master some time ago. It includes Tom's work during
  December 2015. Among changes to the code, this branch adds the
  Xilinx license which is not free software (despite Tom calling it
  Xilinx permissive license).

• tiago/master: branched off from Tom's summer work. It's only
  includes addition of the GPLv3 license with Tom's permission.

• tiago/redpitaya and tiago/raspberry: both of these two branches
  forked out from Tom's work. They have common ancestors but at some
  point diverge with specifics to each board.

• tiago/testing: this branch seems mostly an history editing accident.

[mickp]

I've taken a look at the latest API that is shipped with the RedPitaya. They now offer functions in a library that do direct reads/writes to the ports we're interested in. I think we should use these where possible, so if they change their mapping in future, we don't have to worry about it. We still need to use /dev/mem to access the global timer: this is part of the ARM spec rather than a RedPitaya feature so RP's API doesn't expose it, but the address is unlikely to change.

I think we should use C-level code for the timing loop, as we are currently, but we should use the library functions for reads/writes. They resolve to direct reads/writes using addresses stored in structures in the library. Where we need access python-side, we can wrap the library functions with ctypes.

The library isn't usually on the LD_LIBRARY_PATH - it's not clear whether it's statically linked in their code, or whatever environment the API-derived apps run in set this up. It can easily be made available to python by adding a file to /etc/ld.so.conf.d/ with the contents:

/opt/redpitaya/lib

Our code needs to do the following:

• cat /opt/redpitaya/fpga/<latest image> > /dev/xdevcfg to configure the FPGA so that pins are hooked up correctly

• ctypes.CDLL("/opt/redpitaya/librp.so")

• Call rp_Init() to initialise the library.

• Do whatever we need with the functions listed below.

• Call rp_Release() to free resources on exit.

The following functions do direct reads/writes to the ports we're interested in.

Digital bin block ops:
int rp_LEDSetState(uint32_t state)
int rp_LEDGetState(uint32_t *state)
int rp_GPIO[n,p]GetDirection(uint32_t *direction)
int rp_GPIO[n,p]SetDirection(uint32_t direction)
int rp_GPIO[n,p]SetState(uint32_t state)
int rp_GPIO[n,p]GetState(uint32_t *state)

Individual digital pin ops:
int rp_DpinGetDirection(rp_dpin_t pin, rp_pinDirection_t* direction)
int rp_DpinSetDirection(rp_dpin_t pin, rp_pinDirection_t direction)
int rp_DpinSetState(rp_dpin_t pin, rp_pinState_t state)
int rp_DpinGetState(rp_dpin_t pin, rp_pinState_t* state)
rp_dpin_t is an enum running as follows: [LED 0..7], [DIO 0..7 P], [DIO 0..7 N]

Analog pin ops:
int rp_ApinReset()
int rp_ApinGetValue(rp_apin_t pin, float* value)
int rp_ApinGetValueRaw(rp_apin_t pin, uint32_t* value)
int rp_ApinSetValue(rp_apin_t pin, float value)
int rp_ApinSetValueRaw(rp_apin_t pin, uint32_t value)
[Get,Set]Value uses units of Volts.
[Get,Set]RawValue presumably uses DAC units.

[iandobbie]

I just added to this problem with the current running code as a new branch.Are there any other running branches? If not we should just make that the master and then worry about merging stuff into that. As far as I know this version is running on DeepSIM, Zaber, my picam test setup and Oxford cryoSIM. I hope to also get it running at Diamond so we can retire the DSP there as it has been giving us problems.

[iandobbie]

I have further added to this issue by adding the current running code as "running". This code should be identical between Zaber, DeepSIM, CryoSIM and Danny's setup.

[iandobbie]

The ian-working lacks the lates updates to allow 16 digital lines and the forking so that the control returns to cockpit on starting an experiment. So I am just going to remove it.

[iandobbie]

Working branch just has a couple of additional diagnostic prints so removing that branch as well.