FPGA GPIO Bindings to BladeRF / Osmocom Library

[Koatman]

Hi,

It would be very nice to be able to control the GPIO pins on the XB200 from within GRC and other programs with the Osmocom library. I understand much work would be required to implement these calls, but the ability to remotely activate antenna relays, power amplifiers, and engage tuning motors would be Friggin' awesome.

Goatman

[jynik]

Just wanted to lay out the tasks here that need to be done from the bladeRF side of things before we continue on with gr-osmosdr bindings

1. Map out and document the pinouts <-> bit relationship on the XB200 and XB100. The pinouts are on the associated product pages, but I think it would be worthwhile to get a table up in the repo.
2. Introduce new API routines/wrappers to access the entire port, or to perform a RMW on single bits. With the new packet handler formats in FPGA v0.3.x, we can now specify a mask when doing GPIO accesses. This pushes the RMW operation into the NIOS II, alleviating the need for the user to worry about it.
3. Introduce macro definitions for each bit in terms of:
   • The base expansion connector
   • The XB-200
   • The XB-100
4. bladerf_expansion_attach() for the XB100 shall configure the I/O directions appropriately for the XB-200.
5. When the XB200 is attached, the GPIO access calls shall always mask off attempts to access GPIO pints that are used to control the XB-200. This will prevent users from accidentally changings RF switches, or configuring the I/O direction register incorrectly.

[jynik]

@Koatman, any idea how we should do this on the osmo side? Perhaps via message passing? I think it would be pretty simple to add a message handler with a pmt::pmt_t tuple or something to include the bitmask, operation, and value...

Have you bounced this off horizon at all yet?

[jynik]

@Koatman

I've added some convenience macros and routines that make use of masked writes. You can now do the following in the bladeRF-cli:

bladeRF> xb 200 enable

  Enabling XB-200 transverter board
  XB-200 Transverter board successfully enabled

bladeRF> print xb_gpio_dir

Usage: print xb_gpiodir <name>

<name> describes what to print. It may be one of the following:

  "all" - Print the register value and the state of
  individual pins. Note that the pin names shown
  is dependent upon which expansion board has been
  enabled.

  "reg" or "register" - Print the GPIO direction register value.

  "list" - Display available pins to print.

  One of the pin names from the aforementioned list.

bladeRF> print xb_gpio_dir all

  Expansion GPIO direction register: 0x3c00383e

        J7_1: input
        J7_2: input
        J7_6: input
       J13_1: input
       J13_2: input
       J16_1: input
       J16_2: input
       J16_3: input
       J16_4: input
       J16_5: input
       J16_6: input

bladeRF> print xb_gpio all

  Expansion GPIO register: 0xffffcfe9

        J7_1: 1
        J7_2: 1
        J7_6: 1
       J13_1: 1
       J13_2: 1
       J16_1: 1
       J16_2: 1
       J16_3: 1
       J16_4: 1
       J16_5: 1
       J16_6: 1

bladeRF> set xb_gpio_dir J7_1 output

        J7_1: output

bladeRF> set xb_gpio J7_1 0

        J7_1: 0

From the libbladeRF side of things, this is just done with the bladerf_expansion_gpio* routines and the macro defs.

As such, things are ready from the libbladeRF side of things. I'll likely close this issue, given that we don't track gr-osmosdr items here. Would you care to tackle submitting a patch go gr-osmosdr to use this?

[Koatman]

Nice!!! I never would have thought of using a mask... No formal study in CS. I’ll be working the hardware side of things with some optoisolators and SMA relays, see what I can get going. Thanks!!