This is the mail archive of the
mailing list for the eCos project.
[Bug 1001453] CAN IO package: wider flags field, flag to reportreturn to 'error active' mode
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: unassigned at bugs dot ecos dot sourceware dot org
- Date: Wed, 18 Jan 2012 21:48:37 +0000
- Subject: [Bug 1001453] CAN IO package: wider flags field, flag to reportreturn to 'error active' mode
- Auto-submitted: auto-generated
- References: <email@example.com/>
Please do not reply to this email. Use the web interface provided at:
--- Comment #7 from Bernard FouchÃ <firstname.lastname@example.org> 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
- 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
- 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: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.