Hi,
I tried using the audio cape with the LCD4 cape on a BBB, and
got a pin conflict because both have two LED that try to use
the same pin (P9.14). I simply deleted the LEDs from
BB-BONE-AUDI-01.dts, loaded the overlay manually and it
works (although sound is sometimes distorted, not sure why).
But what would be the ‘proper’ way to fix it? Could the
cape manager handle this sort of thing automatically?
There isn’t an automatic way to fix this sort of thing because the device tree has no idea of which pins are “critical” and which ones are “optional” (such as the LEDs). The proper way to fix it is just what you have done: modify either the base device tree that is loaded into memory by the bootloader or create a custom device tree overlay that maps just the pins that you need. If you are developing a custom embedded device with known, fixed hardware, you would modify the primary device tree. If you’ll be swapping around cape hardware a lot and prototyping, then the overlay is the way to go.
One thing that you might consider, since it is a super lower-cost approach, is to use a USB audio dongle. They are quite small when the casing is removed:
http://i.imgur.com/NQZzCok.jpg
This one cost me about $4 through Amazon. It is small enough that I can fit it between the LCD cape and the BBB. You’ll have to plug it into the USB host port, of course, but I found a small USB hub for under $10 that allows me to keep the LCD cape footprint. I just soldered the audio dongle directly to one of the USB ports:
http://i.imgur.com/Rokafoy.jpg
… and then I placed both the hub and dongle under the cape. I am using the LCD3 cape, though, which only uses about half of the P8 connector, so I was able to fit the audio dongle on top of the P8 without having it stick out from under the cape:
http://i.imgur.com/kvpLwvc.jpg
http://i.imgur.com/JHmStiF.jpg (Both speaker out and mic in are available)
http://i.imgur.com/cDbKrBW.jpg
You could get away with fitting this same dongle under the LCD4 cape if you unsoldered the male USB connector on the dongle to reduce its size.
The slight tilt to the LCD3 cape comes from the FTDI cable being plugged in, not the hub and dongle that I’ve crammed in under the cape. The host port on the end of the hub is still available for USB devices. In addition, using a nano form factor USB wifi is possible by plugging it into one of the side host ports on the USB hub (which leaves that one exposed host USB port next to the BBB’s host port). For the best signal strength, though, you should use the host port that is exposed at the edge of the BBB.
I have noticed that the USB audio has little skips in it and the occasional buffer underrun if something else is plugged into the hub and CPU usage exceeds 90% or so. My theory is that this is due to PIO being used for USB, rather than DMA. Changing the size of the audio buffer hasn’t had much impact on this. This experimentation is all part of my work to see just how portable I can make the BeagleSNES system:
http://i.imgur.com/3GEJs1P.jpg
Andrew
I tried using the audio cape with the LCD4 cape on a BBB, and
got a pin conflict because both have two LED that try to use
the same pin (P9.14). I simply deleted the LEDs from
BB-BONE-AUDI-01.dts, loaded the overlay manually and it
works (although sound is sometimes distorted, not sure why).But what would be the 'proper' way to fix it? Could the
cape manager handle this sort of thing automatically?There isn't an automatic way to fix this sort of thing because the device
tree has no idea of which pins are "critical" and which ones are "optional"
(such as the LEDs). The proper way to fix it is just what you have done:
modify either the base device tree that is loaded into memory by the
bootloader or create a custom device tree overlay that maps just the pins
that you need.
...
Thanks. Good to know I am on the right track 
One thing that you might consider, since it is a super lower-cost approach,
is to use a USB audio dongle. They are quite small when the casing is
removed:
I should probably try this, especially since the audio cape seems to somehow
mess with my WiFi dongle (RF interference?). Also booting even with only
two capes takes forever, not sure if that is due to EEPROM read times or
cape manager initialization time (my home-made curved FTDI connector is
a bit too tall and only fits the LCD cape, need to find something better).
Thanks for all your other suggestions too, I will try them out when I get
some time to get back to this. If you have time to publish some details
about the BBB-SNES, that would be best
BTW, I am trying to make a more-or-less complete Android device out
of the BBB, mostly for self-educational purposes.
Hi Nikolay. When you say “I simply deleted the LEDs from BB-BONE-AUDI-01.dts, loaded the overlay manually and it works” - I tried that process and it didn’t work. I commented out all mention of LED pins in the dts file and recompiled it using (example from this page):
dtc -O dtb -o BB-BONE-AUDI-01-00A0.dtbo -b 0 -@ BB-BONE-AUDI-01-00A0.dts
then
echo BB-BONE-AUDI-01 >/sys/devices/bone_capemgr*/slots
[ 2020.134118] bone-capemgr bone_capemgr.8: slot #9: BB-BONE-AUDI-01 conflict P9.14 (#0:BB-BONE-LCD4-01)
[ 2020.144084] bone-capemgr bone_capemgr.8: slot #9: Failed verification
-sh: echo: write error: File exists
but it made no difference - the cape manager still reported having a pin conflict and the audio cape wasn’t loaded. I’ve read that it might be required to make this change and recompile the whole kernel, which I’d rather not do if not necessary. I thought the whole point of the “dtc” command was to enable cape changes like this without kernel recompilation. Could you (or anyone else) give a bit more detail on how you accomplished this? Thanks.
This is basically what I did, but I don't have a detailed log. Make
sure your cape
is version 00A0, mine is 00A1 so I had to update the version in the dts file
as well. Also there is a way to specify the version explicitly, IIRC using
a semicolon + version, but check docs for details. Something like this:
$ echo BB-BONE-AUDI-01:00A1 >/sys/devices/bone_capemgr*/slots
I don't think I recompiled the kernel, but not 100% on this.
HTH
Is it possible that your DTC tool doesn’t support overlays? There is a patched version of DTC that does:
Give that a try.
Andrew
I’m not using an actual audio cape, just the same chipset the audio cape uses. Because I don’t have an EEPROM on my ‘cape’, I have capemgr.enable_partno=BB-BONE-AUDI-01 in my uEnv file. Would it still matter what version is in the dts file in my case?
I am using DTC as provided on the Beaglebone itself after a fresh 2013.07.31 image upgrade. dtc -v shows “Version: DTC 1.3.0-g27cdc1b1-dirty”. That command I posted seems to run and doesn’t give any errors or other output so I assumed it worked correctly. Am I not supposed to be doing the compilation on the beaglebone itself?
I only see one location with the dtbo and dts files (/lib/firmware/) and I was modifying the BB-BONE-AUDI-01.dts file from there. Will the DTC tool provided on the BBB itself work to compile that dts file and output it (dtbo) back to the /lib/firmware/ folder (assuming of course I cd to it first)? Will the BBB use the file from that location or are those merely backups or something? Thanks.
It looks like LCD4 cape firmware is not loaded from /lib/firmware at all. LCD loads successfully when I deleted BB-BONE-LCD4-00A1 dtbo. Maybe some capes are bundled with kernel directly? How Device tree handles pin conflicts remain a mystery. Here is a thread about using LCD4 with UART2 or SPI0 at the same time but no success.
