public inbox for
 help / color / mirror / Atom feed
Subject: [Bug 1001453] CAN IO package: wider flags field, flag to report return to 'error active' mode
Date: Wed, 18 Jan 2012 21:48:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Please do not reply to this email. Use the web interface provided at:

--- Comment #7 from Bernard Fouché <> 2012-01-18 21:48:30 GMT ---
Yet more needed change:

- since flags will be 32 bits wide, then the flag_mask field in
cyg_can_callback_cfg_st must be expanded too. Must do a typedef (or a #define?)
for flags instead of using cyg_uint32, I missed the flag_mask expansion because
of this.

- in can_callbacks_t, describing the function pointers accessible to the low
level drivers, xmt_msg is today:

void (*xmt_msg)(can_channel *chan, void *pdata)

I'd like to have instead:

cyg_bool (*xmt_msg)(can_channel *chan, void *pdata)

This is because when the low level driver knows that it can send more than one
message, it has no way to know if high level Tx queue is empty or not. For
instance the driver I test now uses the 3 TX buffers of the LPC17XX. When X
buffers are free, the driver can just call X times xmt_msg, even if no message
is queued. Proposed changed is to have xmt_msg to report is a message was sent
when it was called. If yes, then call again xmt_msg if there are still free Tx
buffers. If no, stop calling since it's useless. On hardware supporting many
Message Objects this need will arise anyway. The only other possibility is to
use a global variable in the low level driver: reset the variable, call
xmt_msg() that calls driver _putmsg(), set variable there, go back to DSR, test
variable. Seems ugly an inefficient.

There are other issues:

- autobaud is said to be potentially supported by the CAN IO package, but there
is no infrastructure to manage it. I hardly see how it could without some
parameters defining the set of speeds to try, how long to wait for a
timeout,and how to warn the upper layer that autobaud found some speed (no
event like CYGNUM_CAN_EVENT_AUTOBAUD_END exists). No start/stop autobaud config
keys exist.   

- LPC2XXX driver supports listen-only mode also by providing unofficial config
keys. IMHO they should be made mainstream since this feature is more and more
available and is very handy, for instance to make a non-intrusive network
monitor (and eventually autobaud...). 

- the application can't know the current values of TX/RX Rec while these are
important to diagnose a bus. A _get_config() key seems appropriate.

BTW I start tomorrow a few days of field tests, I'll try to make an updated
patch next week.


Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

  parent reply	other threads:[~2012-01-18 21:48 UTC|newest]

Thread overview: 24+ 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 18:51 ` bugzilla-daemon
2012-01-14 22:40 ` bugzilla-daemon
2012-01-15 13:56 ` bugzilla-daemon
2012-01-15 22:30 ` bugzilla-daemon
2012-01-16  8:16 ` bugzilla-daemon
2012-01-18 21:48 ` bugzilla-daemon [this message]
2012-01-19 20:46 ` bugzilla-daemon
2012-01-24 19:25 ` bugzilla-daemon
2012-01-25 11:35 ` bugzilla-daemon
2012-01-25 11:39 ` bugzilla-daemon
2012-01-25 11:44 ` bugzilla-daemon
2012-01-25 11:45 ` bugzilla-daemon
2012-01-25 13:59 ` bugzilla-daemon
2012-01-25 20:07 ` bugzilla-daemon
2012-01-26  8:51 ` bugzilla-daemon
2012-02-06 10:00 ` bugzilla-daemon
2012-02-06 15:57 ` bugzilla-daemon
2012-02-06 20:30 ` bugzilla-daemon
2012-02-07  6:13 ` bugzilla-daemon
2012-02-09 21:46 ` bugzilla-daemon
2012-02-10 17:28 ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be 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).