GHI Comms cape - no overlay file in /lib/firmware

GoogleGroups
1

We recently purchased the GHI Comms cape, in order to have a nice RS485 port available.
However, even the latest Debian image for the BeagleBone black does not have the required overlay dtbo file!
When the BeagleBone Black boots, I get this:
[ 1.493924] bone_capemgr bone_capemgr: loader: failed to load slot-2 BBORG_COMMS:00A2 (prio 0)

The cause is that the file BBORG_COMMMS-00A2.dtbo is missing.

And sure enough, there is no overlay written for this cape in:

https://github.com/beagleboard/bb.org-overlays

I am guessing that there is an alternative way to get this Cape up and running. I’m moderately OK with linux as a user and admin, but rather new to IoT.

Best,
Todd

2

We recently purchased the GHI Comms cape, in order to have a nice RS485 port available.
However, even the latest Debian image for the BeagleBone black does not have the required overlay dtbo file!
When the BeagleBone Black boots, I get this:
[ 1.493924] bone_capemgr bone_capemgr: loader: failed to load slot-2 BBORG_COMMS:00A2 (prio 0)

The cause is that the file BBORG_COMMMS-00A2.dtbo is missing.

And sure enough, there is no overlay written for this cape in:

https://github.com/beagleboard/bb.org-overlays

I just did a pull request to add it: https://github.com/beagleboard/bb.org-overlays/pull/122

I am guessing that there is an alternative way to get this Cape up and running. I’m moderately OK with linux as a user and admin, but rather new to IoT.

For the RS485, you just need
config-pin p9.11 uart
config-pin p9.13 uart

…and then use /dev/ttyS4

For the CAN, you just need
config-pin p9.24 can
config-pin p9.26 can
…and then you can use something like https://gist.github.com/jadonk/90d3462c8569d11fa3f7caf14f4769f1, but replace can0 with can1

For the 4-20mA loop, the ADC overlay should already be loaded and you can
cat /sys/bus/iio/devices/iio:device0/in_voltage5_raw

cat /sys/bus/iio/devices/iio:device0/in_voltage6_raw

…but you’ll need to do the voltage to data conversion

For the sink drivers, you can do:

Sink A

config-pin p9.15 gpio
echo out > /sys/class/gpio/gpio48/direction

echo 1 > /sys/class/gpio/gpio48/value

Sink B

config-pin p9.23 gpio

echo out > /sys/class/gpio/gpio49/direction

echo 1 > /sys/class/gpio/gpio49/value

…and that should turn them on.

3

Quick update:
SUCCESS!

I now have serial communication occurring through the Comms cape RS485 port. However, I need to reverse the lines:
A must go to B and B must go to A between the two devices.

The correct way to hook up RS485 devices is to daisy-chain all the A’s together and all the B’s. I believe that the Comms cape is simply mislabeled.
This may derive from a reversal in the schematic or something.

The latest Debian Linux version is able to accomplish this enabling of the Comms cape RS485 port, as long as the uEnv.txt file enables UART4 in the standard manner.
You can also use “config-pin” command to enable the pins, and it works.

-Todd

4

On Tue, 11 Jun 2019 10:33:58 -0700 (PDT),
tojala@gmail.com declaimed the following:

A must go to B and B must go to A between the two devices.

The correct way to hook up RS485 devices is to daisy-chain all the A's
together and all the B's. I believe that the Comms cape is simply
mislabeled.
This may derive from a reversal in the schematic or something.

  OR... from RS-485 - Wikipedia
"""
The truth tables of most popular devices, starting with the SN75176, show
the output signals inverted. This has caused much confusion since, with
most device manufacturers following the SN75176's lead.

These names are all in use on various equipment, but the actual standard
released by EIA only uses the names A and B. The B line is positive
(compared to A) when data is 1. However, due to the ambiguous standard
(which refers to the A line as "non-inverting"), there is much confusion
about which is which. The RS-485 signaling specification, confusingly, says
that signal A is the non-inverting pin and signal B is the inverting
pin.[14] This is in accordance with the A/B naming used, incorrectly, by
most differential transceiver manufacturers, including, among others:

    Texas Instruments, as seen in their application handbook on EIA-422/485
communications (A=non-inverting, B=inverting)
    Intersil, as seen in their data sheet for the ISL4489 transceiver[15]
    Maxim, as seen in their data sheet for the MAX483 transceiver[16]
    Linear Technology, as seen in their datasheet for the LTC2850, LTC2851,
LTC2852[17]
    Analog Devices, as seen in their datasheet for the ADM3483, ADM3485,
ADM3488, ADM3490, ADM3491[18]
    FTDI, as seen in their datasheet for the USB-RS485-WE-1800-BT[19]

These manufacturers are all incorrect (but consistent), and their practice
is in widespread use, so care must be taken when using A/B naming.
"""