BBBrevC + LCD7 + CBB-Serial

Hi,
Has anyone worked yet with this setup?
BeagleBone Black vC
BeagleBone LCD7 CAPE,00A3,Beagleboardtoys,BB-BONE-LCD7-01

cape-CBB-Serial,r01,Logic Supply,cape-CBB-Serial

run $dmesg | grep capemgr.9 > ./capeload.txt

← snip →

[ 0.711338] bone-capemgr bone_capemgr.9: slot #0: Requesting part number/version based 'BB-BONE-LCD7-01-00A3.dtbo
[ 0.711355] bone-capemgr bone_capemgr.9: slot #0: Requesting firmware ‘BB-BONE-LCD7-01-00A3.dtbo’ for board-name ‘BeagleBone LCD7 CAPE’, version ‘00A3’
[ 0.711375] bone-capemgr bone_capemgr.9: slot #0: dtbo ‘BB-BONE-LCD7-01-00A3.dtbo’ loaded; converting to live tree
[ 0.711890] bone-capemgr bone_capemgr.9: slot #0: #4 overlays
[ 0.715812] bone-capemgr bone_capemgr.9: slot #0: Applied #4 overlays.
[ 0.715827] bone-capemgr bone_capemgr.9: loader: done slot-0 BB-BONE-LCD7-01:00A3 (prio 0)
[ 0.718821] bone-capemgr bone_capemgr.9: loader: after slot-3 cape-CBB-Serial:r01 (prio 0)
[ 0.718842] bone-capemgr bone_capemgr.9: slot #3: Requesting part number/version based 'cape-CBB-Serial-r01.dtbo
[ 0.718859] bone-capemgr bone_capemgr.9: slot #3: Requesting firmware ‘cape-CBB-Serial-r01.dtbo’ for board-name ‘cape-CBB-Serial’, version ‘r01’
[ 0.718889] bone-capemgr bone_capemgr.9: slot #3: dtbo ‘cape-CBB-Serial-r01.dtbo’ loaded; converting to live tree
[ 0.719204] bone-capemgr bone_capemgr.9: slot #3: cape-CBB-Serial conflict P9.15 (#0:BB-BONE-LCD7-01)
[ 0.728870] bone-capemgr bone_capemgr.9: slot #3: Failed verification
[ 0.735638] bone-capemgr bone_capemgr.9: loader: failed to load slot-3 cape-CBB-Serial:r01 (prio 0)

<–snip–>

Is this a hardware problem or one I can fix in software?

The lcd7 has two keys (P9.15/P9.21) that are needed by the serial cape..

As long as you don't care about the lcd key's this is easy to fix..

Now the hard part, 3.8.x or 4.1.x based kernel?

Regards,

<–snip–>

The lcd7 has two keys (P9.15/P9.21) that are needed by the serial cape…

As long as you don’t care about the lcd key’s this is easy to fix…

Now the hard part, 3.8.x or 4.1.x based kernel?

Regards,


Robert Nelson

Linux beaglebone 3.8-1-xenomai.beaglebone-omap #1 Debian 3.8.13-9 armv7l GNU/Linux

Ah that's the hard one the dtbo's are builtinto the kernel, well start
by grabbing the source and rebuildling.. Then patch the lcd7-a3.dts..

Regards,

That would be the Kernel or the lcd7-a3.dts?

see here for 3.8.3-bone77:

https://github.com/beagleboard/linux/blob/3.8/firmware/capes/BB-BONE-LCD7-01-00A3.dts#L104

but you'll need to find 3.8-1-xenomai.beaglebone-omap's source..

Regards,

I got it fixed.

I switched over to the 4.1.6 kernel.
Then:

git clone https:``//github.com/beagleboard/bb.org-overlays

Then edited the BB-BONE-LCD7-01-00A3.dts, removed all references for the key input pins.
Installed then rebooted.

[ 3.911349] bone_capemgr bone_capemgr: slot #3: dtbo ‘cape-CBB-Serial-r01.dtbo’ loaded; overlay id #1
[ 3.912324] bone_capemgr bone_capemgr: slot #0: dtbo ‘BB-BONE-LCD7-01-00A3.dtbo’ loaded; overlay id #0
Works!
Next on the list is Xenomai src.

Thank you for putting me onto the diff between 3.8 and 4.1 kernels.

I got it fixed.

I switched over to the 4.1.6 kernel.
Then:
git clone https://github.com/beagleboard/bb.org-overlays

Then edited the BB-BONE-LCD7-01-00A3.dts, removed all references for the key
input pins.
Installed then rebooted.

[ 3.911349] bone_capemgr bone_capemgr: slot #3: dtbo
'cape-CBB-Serial-r01.dtbo' loaded; overlay id #1
[ 3.912324] bone_capemgr bone_capemgr: slot #0: dtbo
'BB-BONE-LCD7-01-00A3.dtbo' loaded; overlay id #0
Works!

Awesome, yeah with v4.1.x i'm trying to make things way easier for
customizations..

Next on the list is Xenomai src.

I'm watching http://git.xenomai.org/ipipe.git/ like a hawk, i'd like
to push out a xenomai build for v4.1.x (normal, rt builds), then we
have everything to replace v3.14.x (normal, rt, xenomai builds)

Thank you for putting me onto the diff between 3.8 and 4.1 kernels.

Regards,

Linux beaglebone 4.1.6-ti-r16 #1 SMP PREEMPT Fri Sep 18 04:41:14 UTC 2015 armv7l GNU/Linux

This is the current kernel and now that I look at it. I’m not sure I really NEED a real time kernel.

All I need this to do is talk to a PIC-SERVO #KAE-T0V10-BDV1 board.

Linux beaglebone 4.1.6-ti-r16 #1 SMP PREEMPT Fri Sep 18 04:41:14 UTC 2015
armv7l GNU/Linux

This is the current kernel and now that I look at it. I'm not sure I really
NEED a real time kernel.

Well the normal RT kernel is available too, it mirrors the uname -r of
the standard build:

sudo apt-get install linux-image-4.1.6-ti-rt-r16

All I need this to do is talk to a PIC-SERVO #KAE-T0V10-BDV1 board.

Regards,

Robert, so what is the real difference between RT, and non RT ? I mean I know the scheduler should be faster / tighter, but has anyone bench marked this ?

Well there's a whole rt-test suite..

https://git.kernel.org/cgit/utils/rt-tests/rt-tests.git/

so it's gotta be good right?

I've never compared..

Regards,

Well there’s a whole rt-test suite…

https://git.kernel.org/cgit/utils/rt-tests/rt-tests.git/

so it’s gotta be good right?

I’ve never compared…

Well I was just reading the real time Linux wiki . . . man their documentation sucks . . . But there was some claim under “how to write real time applications” which by the way has NOTHING to do with writing RT apps . . . and under the miscellaneous header it makes a claim that 10uS latency should be permanent. But what it is referring to . . . your guess would be as good as mine.

There is also a ton of hoops one needs to jump through in order to achieve minimal latency. Booting with a USB stick for instance is said to increase latency to 500ms, but booting without, and inserting after boot is not a problem. Power management, and CPU on-demand CPU scaling are two thing the BBB uses by default that are supposedly detrimental to deterministic execution. Probably a lot more that I’m unaware of too, but basically anything that generates SMI’s or system calls are “bad”.

I think the best anyone can really hope for is to use the rt kernel image, and just be aware of the rest. I’m not so sure it is a good idea to disable power management, or one demand CPU scaling. . .

Marcus,

For what it is worth.
william@xanbustester:~$ cat /sys/devices/platform/bone_capemgr/slots
0: P—L- 1 cape-CBB-Serial,r01,Logic Supply,cape-CBB-Serial
1: PF---- -1
2: PF---- -1
3: PF---- -1

I’ve been using that same cape . . . with kernel 4.2.0* for about the last month or maybe two. I’m not sure what you had in mind,

But I’ve been reading a live CANBUS network using it @250k /s. The beaglebone, and the board are more than capable keeping up

without using a rt kernel. The actual CANBUS protocol is a proprietary NMEA 2000 fastpacket protocol, so I’ve been reading from the bus
in real time, while building variable length packets from the data - Using socketCAN.

Anyway, I would not recommend using the same kernel I am, but just wanted to give you some feedback as far as using a rt kernel.
Personally, I did want to experiment with a rt kernel, because I’m actually rebuilding fastpackets from multiple socketcan frames,

also in realtime, as well as putting that data out over ethernet to a web browser via websockets. As you might imagine, this is a ALOT

of work to get done on a single core 1Ghz. especially considering I’ve been tracking ~20 or so PGN, re-constructing them, and then putting

that data out over ethernet via a web server.

I’d be interested in hearing what you plan on doing with that CAN cape though ! Assuming you’re even going to use the CAN portion of
the cape :wink:

Oh, and those PGN’s happen every 500ms, so roughly 40 PGN’s a second are being re-constructed.

It does stall every so often. 1-2 times a minute.

William,
I’m building this to replace a Dynabend 3 backgauge controller on a Promecam brake press.
So I’m not sure which way I’ll go on talking to the pic-servo card, yet.

interesting reading here.
https://github.com/mhaberler/asciidoc-sandbox/wiki/Machinekit-Build-for-Multiple-RT-Operating-Systems#installation

And I see I need to put a post-it note on the face of the lcd7…

4GB ONLY!!! lol

root@beaglebone:~/linuxcnc/src# df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 10240 0 10240 0% /dev
tmpfs 99984 8572 91412 9% /run
/dev/mmcblk0p2 3553816 3447844 0 100% /
tmpfs 249960 4 249956 1% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 249960 0 249960 0% /sys/fs/cgroup
tmpfs 49992 0 49992 0% /run/user/1000

heh, well, depending on what you need. You can reduce that a lot probably. For instance, Robert’s barefs only takes up around 70-75M total. That’s a fully bootable system, with just a few utilities installed. With Nodejs installed on top of that. We’re talking ~160M.

I’m assuming you need X, and maybe QT because of the LCD screen. But I do not think it would be unheard of to trim that down to around to 1G or slightly less. Matter of fact, I seem to recall the LXDE + Debian FAQ stating 1G for an X install.

Once your application is done and working the way you want. You can remove a lot of things like build-essential, manpages, etc.

https://wiki.debian.org/ReduceDebian and https://wiki.ubuntu.com/ReducingDiskFootprint are both good reference resources to reduce both Debian, and Ubuntu.

That is to say: Both those links are applicable to both Ubuntu and Debian. Obviously some of the discussed material does not apply to beaglebones.