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

[toj...@gmail.com]

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

[Jason Kridner]

On Thu, Jun 6, 2019 at 2:59 PM <toj...@gmail.com> wrote:

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.

Best,
Todd

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/12c383d2-80a0-45d5-b0d5-452eb2b49437%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

https://beagleboard.org/about - a 501c3 non-profit educating around open hardware computing

[toj...@gmail.com]

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

[Dennis Lee Bieber]

On Tue, 11 Jun 2019 10:33:58 -0700 (PDT),
toj...@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 https://en.wikipedia.org/wiki/RS-485
"""
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.
"""


--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/