public inbox for ecos-bugs@sourceware.org help / color / mirror / Atom feed
From: bugzilla-daemon@bugs.ecos.sourceware.org To: unassigned@bugs.ecos.sourceware.org Subject: [Bug 1001453] CAN IO package: wider flags field, flag to report return to 'error active' mode Date: Sun, 15 Jan 2012 13:56:00 -0000 [thread overview] Message-ID: <20120115135616.612A82F7800F@mail.ecoscentric.com> (raw) In-Reply-To: <bug-1001453-777@http.bugs.ecos.sourceware.org/> Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001453 --- Comment #4 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-01-15 13:56:08 GMT --- (In reply to comment #3) > I also forgot to document the meaning of the added flag ;-) Of course, we need to keep in sync documentation and sources. > While thinking at other things I may have forgotten, I now see an > issue with the bitfield 'support_flags' in cyg_can_hdi. > > Here is cyg_can_hdi: > > typedef struct cyg_can_hdi_st > { > cyg_uint8 support_flags; > cyg_uint8 controller_type; > } cyg_can_hdi; > > The issue is a lack of description of the low level driver filtering > capabilities. > > The 'SW-Filt' flag has been replaced by 'autobaud' in the source code > (my patch fixes the doc about this). I've seen. Thank you for the catch. > Hence there is no more description of a hw driver filtering > capabilities while these capabilities are essential in a real world > CAN network. The 'software filtering' information was not very helpful > to user code anyway, I suppose that's why it has been removed and the > corresponding bit recycled. It seems so. > I suggest to use two reserved bits in 'support_flags': > > - a bit to describe identifier range filtering capability (0=no range > filtering, this keep compatibility with current code) > > - a bit to describe bitmask filtering capability (0=no bitmask > filtering). I think bitmask filtering is the most common and efficient > way to filter CAN frames. (While LPC17XX has range filtering > capabilities, the upcoming LPC18XX has bitmask filtering instead) Agreed. > The side effect is a need for more config keys, to declare filtering > information. IMO, it is not issue for eCos, more that default values would not break old flag's value. > The LPC2XXX driver provides identifier range filtering config keys (as > a cdl option), but since the CAN IO package does not support range > filtering (in terms of API convention), these supplementary config > keys can be obtained by user code only by including explicitly the > LPC2XXX specific header file. > > If these two new data bits in 'support_flags' are added, then the > config keys provided by the LPC2XXX driver can become the 'official' > config keys for identifier range filtering. Excellent coincidence. > And of course there is also a need for config keys related to bitmask > filtering. AFAIK, bitmask filtering is made by declaring an > identifier value and a bitmask, so the config keys related to bitmask > filtering would need 2 x 32 bits value for config data (like the > LPC2XXX range filtering key) > > Since the CAN IO package relay to the hardware layer the config keys > it does not handle itself, there would be no functional change in the > package, like the patch I proposed. Great. > If this is ok I'll provide an updated patch (using the diff option you > mention), and combine these changes. > > Or I can provide two patches, one to fix the patch I proposed, and > then I open a new bugzilla entry with a new patch related to > 'support_flags'. Bernard, thank you for your investigation. I think the patches can be submitted here to save full history of issue, but, if you prefer a separate Bugzilla report, please, create new one. One thing then. Now, all your enhancements need to get a copyright assignment from you as I see your "delta" won't be a-few-lines trivial patch. Could you, please, initiate a copyright assignments process? You can find more info here: http://ecos.sourceware.org/assign.html -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
next prev parent reply other threads:[~2012-01-15 13:56 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-01-13 16:16 [Bug 1001453] New: " bugzilla-daemon 2012-01-13 16:17 ` [Bug 1001453] " bugzilla-daemon 2012-01-14 22:40 ` bugzilla-daemon 2012-01-15 13:56 ` bugzilla-daemon [this message] 2012-01-15 22:30 ` bugzilla-daemon 2012-01-16 8:16 ` bugzilla-daemon 2012-01-18 21:48 ` bugzilla-daemon 2012-01-25 11:35 ` bugzilla-daemon 2012-01-26 8:51 ` bugzilla-daemon 2012-02-06 20:30 ` bugzilla-daemon 2012-02-07 6:13 ` bugzilla-daemon 2012-02-10 17:29 ` bugzilla-daemon 2012-02-11 4:16 ` bugzilla-daemon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20120115135616.612A82F7800F@mail.ecoscentric.com \ --to=bugzilla-daemon@bugs.ecos.sourceware.org \ --cc=unassigned@bugs.ecos.sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).