BBBrevC + LCD7 + CBB-Serial

[marcus...@gmail.com]

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?

[Robert Nelson]

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
https://rcn-ee.com/

[marcus...@gmail.com]

> <--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

 

[Robert Nelson]

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..

[Marcus A]

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/jUUKGAr4Dd8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Thu, Sep 24, 2015 at 10:35 AM, Marcus A <marcus...@gmail.com> wrote:
> 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..

[marcus...@gmail.com]

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.

[Robert Nelson]

On Thu, Sep 24, 2015 at 2:07 PM, <marcus...@gmail.com> wrote:
> 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.

[marcus...@gmail.com]

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.

[Robert Nelson]

On Thu, Sep 24, 2015 at 3:10 PM, <marcus...@gmail.com> wrote:
> 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.

[William Hermans]

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 ?

--
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.

[Robert Nelson]

On Thu, Sep 24, 2015 at 3:54 PM, William Hermans <yyr...@gmail.com> wrote:
> 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..

[William Hermans]

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. .  .

[William Hermans]

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 ;)

[William Hermans]

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.

[Marcus A]

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. 

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/jUUKGAr4Dd8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[marcus...@gmail.com]

interesting reading here.

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

[marcus...@gmail.com]

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

[William Hermans]

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.

[William Hermans]

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.

[mrdm...@gmail.com]

Hello Robert,

Could you please elaborate or point me to the instructions on "grabbing the source and rebuildling..  Then patch the lcd7-a3.dts.."?

I've managed to make a custom dtbo file for my 4D LCD7 in 4.1.15 kernel, but am struggling to get it to load on 3.8.13.

Should I get the kernel source for 3.8.13 and recompile it? Where would I have to put the customized *.dts to get my customized LCD7 dts to get built into the kernel?

Thanks in advance,


Diego

[Robert Nelson]

On Tue, Jan 26, 2016 at 6:23 PM, <mrdm...@gmail.com> wrote:
> Hello Robert,
>
> Could you please elaborate or point me to the instructions on "grabbing the
> source and rebuildling.. Then patch the lcd7-a3.dts.."?
>
> I've managed to make a custom dtbo file for my 4D LCD7 in 4.1.15 kernel, but
> am struggling to get it to load on 3.8.13.
>
> Should I get the kernel source for 3.8.13 and recompile it? Where would I
> have to put the customized *.dts to get my customized LCD7 dts to get built
> into the kernel?

Sorry, I'm done with 3.8.13..

What issue is preventing you from using 4.1.x?

[mrdm...@gmail.com]

I have a config running machinekit with the 3.8.13-xenomai kernel, it runs smooth, but I can't get it to work on 4.1.15, it gives me kernel panics...

So I can load the custom LCD7 cape on 4.1.15 but then machinekit won't run with that kernel...