Project

General

Profile

RaspberryPi CAMAC

This article contains notes on how we're planning to convert the VME CAMAC front-ends to using RaspberryPis.

Architecture

Paul Kasley designed a CAMAC, slot-24 crate controller that interfaces with the RaspberryPi's GPIO bus. The crate controller doesn't support a CAMAC serial link (or block transfer link) because the communications with the outside world goes through the RaspberryPi and its Ethernet port. The FPGA that interfaces the GPIO with the CAMAC backplane also decodes TCLK. This makes each CAMAC crate able to be its own front-end.

ACNET Configuration

Since each crate is a front-end, they all need an ACNET node name. The proposed convention is CMCmcc where "m" is a single character representing the machine with which it's associated ("I" for main injector, "T" for Tevatron, etc.) The "cc" portion is the crate address it is replacing. So, for instance, when we upgrade crate $A0 in MI1, the ACNET node name would be CMCIA0. Switchyard's $E1 crate would become node CMCSE1.

SSDNs

Obviously we will attempt to keep the driver behavior as close as possible to the current behavior. However, SSDNs for MOOC-based front-ends are different than Erlang front-ends, so some modifications need to be done when moving devices to the new front-end. Adding to this that the crate parameter doesn't have to be part of the SSDN makes the translation a little more difficult.

Current SSDNs

The SSDN used by the MOOC-based CAMAC front-ends mostly follows this format:

/????/OOOO/CCSS/??NN/

where:
  OOOO      MOOC Object ID (OID)
  CC        Crate address
  SS        Slot Number
  NN        Channel number (if needed)

If a driver requires more information, the ?? fields can be used (for instance, ramp cards use every part of the SSDN!)

MADC devices have a slightly different layout:

/????/OOOO/MMNN/????/

where:
  OOOO      MOOC Object ID (OID)
  MM        MADC # (1 - 127)
  NN        MADC Channel # (not sure why we didn't just use the same channel field.)

Proposed SSDNs

The new SSDNs need to follow the ACSys front-end conventions. Plus, since each front-end only accesses one crate, we can remove that field from the SSDN. The new layout is:

/AAOO/IIII/????/??NN/

where:
  AA        "Attribute". Driver-specific value
  OO        Object ID. There will be 24 OIDs defined in every CAMAC
            front-end ranging from 16 to 39. The slot is determined
            by the OID.
  IIII      Module ID
  NN        Channel number (if needed)

Preserved Features

Some "features" of the old CAMAC system would be obsolete with the new system. However, there are features which are worth keeping:

Adding/Removing Cards Without Rebooting

Unlike the VME front-ends, the CAMAC front-ends have always provided an easy way to add hardware. VME systems usually need to be powered down when adding hardware1 and they need their start-up scripts to be modified, requiring a reboot. The CAMAC hardware is hot-swappable, so the front-end stays up and running. The system was designed to maintain minimal state in the drivers, so little to no start-up script modifications are necessary. Adding new hardware is, usually, installing the CAMAC module and DABBEL-ing the new device(s). We'd like to keep this ability.

CAMAC Diagnostic Tools

The hardware guys use applications like D20 and D21 to diagnose problems in a front-end. With the front-ends moving to Ethernet, all serial-link issues go away. However, D20 is still a useful application to test modules. The new front-ends will provide the CAMAC ACNET handle which supports (or improves) the UPLINK protocol. I also propose the following improvements to D21:

  • Rewrite in JavaScript and make it a Web app. With dozens, if not a hundred, new CAMAC front-ends, the pop-up menu system of CLIB would get klunky. We could also combine the remaining features of D20 and D21 into one application.
  • The UPLINK protocol can use ACNET service discovery to find the correct front-ends. The service discovery can be multicast to the CAMAC ACNET handle and contain an optional field which specifies with which machine the front-end is associated.

FE Configuration

All CAMAC front-ends will have a common device list in their sys.config file:

[{daq, [{device_list,
         [{16, camac_driver, auto},
          {17, camac_driver, auto},
          {18, camac_driver, auto},
          {19, camac_driver, auto},
          {10, camac_driver, auto},
          {11, camac_driver, auto},
          {12, camac_driver, auto},
          {13, camac_driver, auto},
          {14, camac_driver, auto},
          {15, camac_driver, auto},
          {16, camac_driver, auto},
          {17, camac_driver, auto},
          {18, camac_driver, auto},
          {19, camac_driver, auto},
          {10, camac_driver, auto},
          {11, camac_driver, auto},
          {12, camac_driver, auto},
          {13, camac_driver, auto},
          {14, camac_driver, auto},
          {15, camac_driver, auto},
          {16, camac_driver, auto},
          {17, camac_driver, auto},
          {18, camac_driver, auto}]}]}].

The camac_driver module is a "pass-through" driver; in the init/1 callback, it determines which module is installed in the associated slot and saves the respective driver module. Its init/1 callback looks something like this:

init(Slot) ->
    ModID = camac:command(Slot, 0, 6),
    DrvMod = lookup_driver(ModID),
    {ready, State, Attrs} = DrvMod:init(Slot),
    {ready, {DrvMod, State}, Attrs}.

1 VME systems using external field-busses, like ARCNET or Ethernet, can obviously stay up when hardware is added.