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. On Thu, Sep 24, 2015 at 10:07 PM, William Hermans <[email protected]> wrote: > 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 ;) > > > > On Thu, Sep 24, 2015 at 2:40 PM, William Hermans <[email protected]> > wrote: > >> *Well there's a whole rt-test suite..* >>> >>> *https://git.kernel.org/cgit/utils/rt-tests/rt-tests.git/ >>> <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. . . >> >> On Thu, Sep 24, 2015 at 2:06 PM, Robert Nelson <[email protected]> >> wrote: >> >>> On Thu, Sep 24, 2015 at 3:54 PM, William Hermans <[email protected]> >>> 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.. >>> >>> Regards, >>> >>> -- >>> Robert Nelson >>> https://rcn-ee.com/ >>> >>> -- >>> 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 [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
