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.
On Fri, Sep 25, 2015 at 12:10 AM, William Hermans <[email protected]> wrote: > 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 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 > [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.
