[Bug 1001453] CAN IO package: wider flags field, flag to report return to 'error active' mode

[bugzilla-daemon@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 #16 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-26 08:50:35 GMT ---
(In reply to comment #15)
> [snip]
> > LPC2XXX driver I'll patch without my other changes, so every driver
> > will be kept coherent with the CAN IO package.
> 
> I see. Sorry that you did not find volunteers that have the eCos CAN
> hardware.

Instead of updating the LPC2XXX CAN driver, I'll make a LPC17XX driver that can
still be compiled for LPC2XXX with a minimal amount of work. Anyway what stops
me to provide hardware drivers at this time is bug #1001456 since its solution
seems to be some API evolution regarding interrupt management, at least for
Cortex-M systems.

> By the way, we may on occasion remove all the warnings in builds of CAN
> tests. I found such annoying warnings (of course, they did exist before
> the patching):
> 
>   cc1: warning: command line option "-Woverloaded-virtual" is valid for
> C++/ObjC++ but not for C
> 
> Medicine: s/\$\(CFLAGS\)/$(ACTUAL_CFLAGS)/g for make rules in CAN config
> files
> 
>   io/can/current/cdl/io_can.cdl
>   devs/can/m68k/mcf52xx/current/cdl/can_mcf52xx.cdl
>   devs/can/arm/lpc2xxx/current/cdl/can_lpc2xxx.cdl
> 
> and may be this can be fixed in another patch-set. Your decision.

Why not wait after the release of the new toolchain? Maybe other compilation
flags will have to be updated in different places?

> 
> Bernard, your work looks great for me. In particular, thank you for
> updated documentation.  I understand (agree with) your arguments. I
> plan to accept all changes after further testing, if nobody objects.

There is still something missing: having the application to be able to get the
values of TXREC/RXREC but this means more modifications to all hw drivers and
I'm not sure how to do this properly. Ideally the counter values would be
provided in events having flags raised like ERR_ACTIVE/ERR_PASSIVE, or they
could be made available by a call to _get_config(). The first solution would
increase the event size (could be an option at the CAN IO package level), the
second solution returns values that are already obsolete by the time the
application get them. So I'll leave this to the next volunteer ;-)

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
>From ecos-bugs-return-8720-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Jan 26 09:05:31 2012
Return-Path: <ecos-bugs-return-8720-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 13823 invoked by alias); 26 Jan 2012 09:05:29 -0000
Received: (qmail 13816 invoked by uid 22791); 26 Jan 2012 09:05:29 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197)
    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Jan 2012 09:05:08 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 55C4B2F78006; Thu, 26 Jan 2012 09:05:07 +0000 (GMT)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001463] LPC17XX supplementary code/option patch
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Patches and contributions
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: bernard.fouche@kuantic.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
In-Reply-To: <bug-1001463-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001463-777@http.bugs.ecos.sourceware.org/>
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Date: Thu, 26 Jan 2012 09:05:00 -0000
Message-Id: <20120126090504.1BBEF2F78006@mail.ecoscentric.com>
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
X-SW-Source: 2012/txt/msg00149.txt.bz2
Content-length: 1775

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001463

--- Comment #3 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-26 09:05:01 GMT ---
(In reply to comment #2)
> Hi Bernard
> 
> Thank you for your contribution.
> 
> Past couple of days I have committed patches for Bug 1001395 (including bug
> 1001443) and Bug 1001432. You may need to synchronize your patches accordingly.

I've first updated my copy of ecos-cvs before making the patch. More exactly I
was waiting for you to commit to make my patch ;-)

> 
> I could see that some patches cover issues reported (by you) in other bugs. Can
> you submit them there (and obsolete some patches of my own of course)?
> Splitting patches will speed up check in for some of them.

You are probably referring to bug #1001407. Yes the proposed patch includes
changes similar to attachment 1481 (however I didn't use the word 'omplemented'
in the comments ;-)) but it adds many more hardware related definitions. Maybe
you commit your patch, and then I'll submit a new one that won't have the same
fixes? At the moment I have chosen to make my diff vs the ecos cvs repo and I
don't consider pending patches. Maybe I should do differently?

> 
> Also, on your initiative we have started some discussion on bit banding at Bug
> 1001442 so we can continue there with your patches.

So let's first decide how bitband is handled and afterwards I'll update the
proposed patch accordingly. Or I can remove the bitband macros in the proposed
patch.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
>From ecos-bugs-return-8721-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Jan 26 10:19:00 2012
Return-Path: <ecos-bugs-return-8721-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 24376 invoked by alias); 26 Jan 2012 10:18:58 -0000
Received: (qmail 24174 invoked by uid 22791); 26 Jan 2012 10:18:57 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197)
    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Jan 2012 10:18:45 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 2A4812F78005; Thu, 26 Jan 2012 10:18:44 +0000 (GMT)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001463] LPC17XX supplementary code/option patch
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Patches and contributions
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: ilijak@siva.com.mk
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
In-Reply-To: <bug-1001463-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001463-777@http.bugs.ecos.sourceware.org/>
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Date: Thu, 26 Jan 2012 10:18:00 -0000
Message-Id: <20120126101834.3811A2F78006@mail.ecoscentric.com>
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
X-SW-Source: 2012/txt/msg00150.txt.bz2
Content-length: 2655

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001463

--- Comment #4 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-26 10:18:32 GMT ---
(In reply to comment #3)
> (In reply to comment #2)
> > Hi Bernard
> >
> > Thank you for your contribution.
> >
> > Past couple of days I have committed patches for Bug 1001395 (including bug
> > 1001443) and Bug 1001432. You may need to synchronize your patches accordingly.
>
> I've first updated my copy of ecos-cvs before making the patch. More exactly I
> was waiting for you to commit to make my patch ;-)
>
> >
> > I could see that some patches cover issues reported (by you) in other bugs. Can
> > you submit them there (and obsolete some patches of my own of course)?
> > Splitting patches will speed up check in for some of them.
>
> You are probably referring to bug #1001407. Yes the proposed patch includes
> changes similar to attachment 1481 [details] (however I didn't use the word 'omplemented'
> in the comments ;-)) but it adds many more hardware related definitions. Maybe
> you commit your patch, and then I'll submit a new one that won't have the same
> fixes? At the moment I have chosen to make my diff vs the ecos cvs repo and I
> don't consider pending patches. Maybe I should do differently?

Since you have your focus on LPC17xx IMO you could do this fixes better than
me. When you reported the discrepancies I wasn't aware that you are submitting
copyright assignment, otherwise I would have asked you to propose patches.
Now I would ask you to merge the fixes related to missing/wrong #defines. IMO
the best place to submit this "super" patch is bug #1001407 since you can at
the same time obsolete my patch.

Also it will relief me from LPC17xx and shall give me more time for other jobs:
GCC, etc...

>
> >
> > Also, on your initiative we have started some discussion on bit banding at Bug
> > 1001442 so we can continue there with your patches.
>
> So let's first decide how bitband is handled and afterwards I'll update the
> proposed patch accordingly. Or I can remove the bitband macros in the proposed
> patch.

Your proposal could be a start point, sou you may re-submit macros at Bug
1001442. However, as I mentioned earlier, I would be happy with generic CORTEXM
(or CORTEX_M) macros (where applicable) on architectural level. The headline of
Bug 1001442 could be changed accordingly. Let's continue our discussion there.

Ilija

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.