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.
