BBB Comms Cape RS485 again, Debian 12

Here is the BBB Comms Cape unboxed and plugged into a BBB with latest Debian 12 IOT image.
What do I need to do to receive RS485 data on /dev/ttyS4, please??? Simple Python test script is here. How needs BBB configured by what, so it is permament?
Simple question I had thought.
There are some info here and there, some outdated, config-pin not found, no need to edit or need to edit uEnv.txt, A/B swapped or not, dtb, dto, dtsi, nothing seems to work.
dmesg shows can driver loaded, so the board seems to be recognized
ttyS0-5 shown, too, whatever it means
Please help, step by step.


I am not sure if the the locations of files are correct but look here:

  1. /dev/bone/
  2. If your channels are not located in that file system, I may be out for now.


P.S. I know DTC is an idea and making a device tree blob object probably needs to be done/made.

I had this issue too. I could not find config-pin nor could I get some of the Capes to detect automatically.

I think this is the way things are headed for now until someone figures out how to manage to get a .dtbo file and ports it to the BBB for cape usage.

For instance…

We can try. I do not own one. I have another type of Cape but it does not rely on RS485 communication.

Thanks for trying to help.
There are links in /dev/bone/, whatever they mean


Just to make sure , we are on

Linux alis-met 5.10.168-ti-r72 #1bookworm SMP PREEMPT Sat Sep 30 03:40:45 UTC 2023 armv7l GNU/Linux

Not that it seems, things were any bit easier before.

@aerilox ,

Those files are for UART peripherals that can be used. I think the COMMS Cape lost in people building around it. I am not 100% sure, though. As I have seen some Capes come and go, some stay w/ acceptance while others are being phased out.

No offense to the people for building Capes around their boards here but…

  1. I do not have the COMMS Cape
  2. I would purchase it to find suitable methods to handle communication to/from the Cape
  3. Hopefully, other Capes in the future will incorporate a protocol w/in their Spec. for firmware


P.S. I am not too familiar w/ RS485 communication. I can research some more but I am not sure what exact type of UART communications are needed to handle such a protocol.


Also…while reading a bit and searching throughout the fs on the BBB, I found counter in /dev/bone/.

I am not so sure that counter can be used but it may just be for this type of device. W/out further experimentation, I am at a loss here since I do not own a COMMS Cape for now. I received some knowledge from this site:

Thanks for trying to help.

Our company uses BBB since 10 years with 2000+ purchase per year for a single application with our own cape, that has never changed and still runs perfectly on Debian 8. BBB hardware is superior to all other micros that we tried. BUT: now there is, for the first time, a need to get SUPPORT. It seems this forum here is unmanaged and the docs are a mess, scattered over Github, Google groups and everywhere, if any. This COMMS board is supplied by major tech distributors for almost the price of a BBB. The doc inside the blister leads to nowhere. My intention is not to do research for hours and days, but cape must be plugged in and run. If there are things to do they belong inside the blister.

I was able to let a script called show-pins, that is inside opt/source/bbb-pin-utils, show that UART4 is enabled to 9.11 9.13 pins,

P9.11 28 fast rx 6 uart 4 rxd serial@481a8000 (pinmux_bb_uart4_pins)
P9.13 29 fast 6 uart 4 txd serial@481a8000 (pinmux_bb_uart4_pins)

by editing this simple line in uEnv.txt:

###Overide capes with eeprom

But there is more missing here. Rx data are not received at ttyS4. A/B swapped per something found somewhere does not help. WHAT NEXT?

Btw: RS485 is just a level description. It is not a protocol. It is the diffential version of RS232. The cape is just a level shifter from differential to chip voltages (at least for RS485).

Serial<id=0xb6a786a0, open=False>(port=‘/dev/ttyS4/’, baudrate=9600, bytesize=8, parity=‘N’, stopbits=1, timeout=None, xonxoff=False, rtscts=False, dsrdtr=False)

ok a couple of thoughts.

Firstly as the cape permanently enables receive, you should be able to read back what you transmit, no need to connect to anything, so no need to worry if A and B are the correct way round.

Don’t forget Linux numbers things from 0, this is not always the case in the devicetree files. So UART4 might be /dev/ttyS3 under Linux. I have seen this occasionally so worth checking /dev/ttyS3. I have also seen it change over time.

If you have access to a scope, I would connect it to the TX pin on the cape and see if you are getting data out. If not try other com ports.

Have you got the serial console log ? Is u-boot actually loading the overlay file ?

Are there any errors in the kernel boot log.

Look for pimux issues - something else may have grabbed those pins. Can’t remember the exact format of the error messages.

1 Like