From MAILER-DAEMON Mon Sep 21 12:17:37 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mpla4-0005cK-V2 for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 12:17:36 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MplN2-0006sI-MG for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 12:04:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MplMy-0006qi-6J for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 12:04:08 -0400 Received: from [199.232.76.173] (port=59238 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MplMt-0006oX-52; Mon, 21 Sep 2009 12:03:59 -0400 Received: from newsmtp5.atmel.com ([204.2.163.5]:53241 helo=sjogate2.atmel.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MplMs-00079z-Ge; Mon, 21 Sep 2009 12:03:58 -0400 Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id n8LG1Hd7000364; Mon, 21 Sep 2009 09:01:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Sep 2009 10:02:50 -0600 Message-ID: <258DDD1F44B6ED4AAFD4370847CF58D508102E89@csomb01.corp.atmel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Corelib mailing list Thread-Index: Aco61PgMLjvlQjjERJKSmk6p/MOl5Q== From: "Weddington, Eric" To: , X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-Mailman-Approved-At: Mon, 21 Sep 2009 12:17:36 -0400 Cc: Jan Waclawek , Ron Kreymborg , =?iso-8859-1?Q?Fr=E9d=E9ric_Nadeau?= , Ruddick Lawrence , wutje , Joerg Wunsch , Ruud Vlaming , Mike Perks , David Brown Subject: [Avr-libc-corelib] Corelib mailing list X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 16:04:08 -0000 Hi All, There is a new mailing list dedicated to discussion of the new Core = Library. Subscription information can be found here: http://lists.nongnu.org/mailman/listinfo/avr-libc-corelib All discussions regarding this new library should be moved over to that = mailing list and new threads started. Thanks, Eric Weddington From MAILER-DAEMON Mon Sep 21 13:06:09 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MpmL3-00011B-Q7 for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 13:06:09 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mpm7R-0002O0-B8 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 12:52:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mpm7L-0002Nj-09 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 12:52:03 -0400 Received: from [199.232.76.173] (port=60174 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mpm7K-0002Ng-Qg for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 12:51:58 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:37530) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mpm7K-0007Qt-7n for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 12:51:58 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8LGniM5016313 for ; Mon, 21 Sep 2009 10:49:44 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8LGpuJh240026 for ; Mon, 21 Sep 2009 10:51:56 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8LGpuZE022639 for ; Mon, 21 Sep 2009 10:51:56 -0600 Received: from [127.0.0.1] (dyn780018.austin.ibm.com [9.41.103.141]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8LGprdc022491 for ; Mon, 21 Sep 2009 10:51:56 -0600 Message-ID: <4AB7AF1F.60801@oakmicros.com> Date: Mon, 21 Sep 2009 11:51:43 -0500 From: Mike Perks User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: avr-libc-corelib@nongnu.org References: <604fcf830909170004w208950b8o71349e20b9ad6947@mail.gmail.com><4AB72DDC.9090402@westcontrol.com> <4AB785C1.60908@oakmicros.com> <258DDD1F44B6ED4AAFD4370847CF58D508102D89@csomb01.corp.atmel.com> In-Reply-To: <258DDD1F44B6ED4AAFD4370847CF58D508102D89@csomb01.corp.atmel.com> Content-Type: multipart/alternative; boundary="------------030907050905010807040406" X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Mailman-Approved-At: Mon, 21 Sep 2009 13:06:08 -0400 Subject: [Avr-libc-corelib] Library Design Questions X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 16:52:05 -0000 This is a multi-part message in MIME format. --------------030907050905010807040406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Weddington, Eric wrote: >> 1. Do we handle devices with no RAM? >> > This is pretty much a C language based library. Devices with no RAM are not easily supported by the C compiler. So IMO, no we do not support RAM-less devices. There aren't that many to begin with, and they're all legacy devices now anyway, so it's not that big of a loss. > Agree. Just want to make sure as this is a pre-req for some of the other design questions. >> 2. Are APIs stateful or stateless. Stateful implies using some number of "magic number" or "handle" to the current state and "instance". C++ >> would probably use an object instance. >> > I would imagine that if something is "stateful" that it does require some amount of RAM to support saving the state. In principle, I think we should strive for the smallest footprint as possible, especially in RAM usage as RAM is a scarce resource for practically all AVR devices. If we can design a driver with no RAM usage (stateless), that would be the best. If the driver requires saving state, then we should do so in the minimum possible way that can be achieved. I also have no objection to having 2 or more kinds of drivers for a particular peripheral. I do not think that one particular style will meet everyone's needs. But with that, we should also be aware that the purpose of the library is for convenience. It cannot be all things to all people, ever. Otherwise it will never get finished. > > >> 3. Do we provide support for software emulation of things like USARTs and bit-banged SPI? If we do then this leads to internal data structures >> and bus numbers or channel numbers. I believe software emulation has to be a stateful API in all cases. >> > While I have no objection to including these eventually (I have a bit-banged SPI driver I can contribute), we should probably focus on the on-board peripherals first, and then branch out from there. > The reason for asking this question is that it has impacts on RAM. and also on the API. For example we should at least think about software emulation otherwise we may find ourselves changing the API later. Better to design a little more up front first even if we do a staged implementation and not everything is available on day one. >> 4. How do we handle devices with 1 of something versus multiple e.g. >> USARTs and SPI buses? Most devices except xmega have only one >> I2C port. >> > > Good question. There are a lot of ways to do it. Let's discuss it after we can agree on which project to host with and we have a separate mailing list. ;-) > So now is the time? Probably should start a separate thread on this one (and for that matter some of the other open questions on this list. >> 5. Do we have a one-size fits all approach that dynamically adds support for multiple SPI buses for example, or are there several different flavors? >> > > In my experience, one-size generally does not fit all. I'm ok with several different flavors. > No but you could have #defines that add additional features/functions e.g. #define MULTI_SPI_SUPPORT. >> 6. Is the library simply header files with macros and inline >> functions >> or is there a library file to link with, or a mixture of both? The >> answer to the previous question may affect the answer to this >> question. >> > > Why impose an artificial limitation on the implementation. My experience has been that one has generally a mixture of both, header files with macros and library functions. It probably depends on how complex the API implementation is. > I wasn't trying to - just asking a question. My guess is that a lot of the code will be conditionally compiled and very little will be in a library archive per se. >> 7. What non-device functions do we support e.g. multi-tasking of some kind? Do we add time of day/date/clock tick functions that gets allocated to a specific timer at compile or runtime? >> > We are not developing an RTOS. > > No objection to adding support for date functions, but let's do that down the road (unless you have some code you can contribute). > Date functions affect allocation of timers and need one reserved to keep track of ticks. We might have defines like the following: #define ENABLE_TIME_OF_DAY 1 #define TIME_OF_DAY_TIMER 3 which enables a timer3 ISR for timer ticks and a #define such as #define TIMER3_ALLOCATED 1. Other code would check for TIMER#_ALLOCATED to avoid using these registers. This is why I think we need to do some design up front for a staged implementation. >> 8. What naming convention do we use? (has been discussed and I think a consensus reached to use underscores - just needs to be written down in the design document) >> > Agreed. > Who is creating a design document and where will that reside? I don't yet see a project on http://savannah.nongnu.org. Mike Perks Oak Micros (oakmicros.com) --------------030907050905010807040406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Weddington, Eric wrote:
1. Do we handle devices with no RAM?
    
This is pretty much a C language based library. Devices with no RAM are not easily supported by the C compiler. So IMO, no we do not support RAM-less devices. There aren't that many to begin with, and they're all legacy devices now anyway, so it's not that big of a loss.
  
Agree. Just want to make sure as this is a pre-req for some of the other design questions.
2. Are APIs stateful or stateless. Stateful implies using some number of "magic number" or "handle" to the current state and "instance". C++ 
would probably use an object instance.
    
I would imagine that if something is "stateful" that it does require some amount of RAM to support saving the state. In principle, I think we should strive for the smallest footprint as possible, especially in RAM usage as RAM is a scarce resource for practically all AVR devices. If we can design a driver with no RAM usage (stateless), that would be the best. If the driver requires saving state, then we should do so in the minimum possible way that can be achieved. I also have no objection to having 2 or more kinds of drivers for a particular peripheral. I do not think that one particular style will meet everyone's needs. But with that, we should also be aware that the purpose of the library is for convenience. It cannot be all things to all people, ever. Otherwise it will never get finished.

  
3. Do we provide support for software emulation of things like USARTs and bit-banged SPI? If we do then this leads to internal data structures 
and bus numbers or channel numbers. I believe software emulation has to be a stateful API in all cases.
    
While I have no objection to including these eventually (I have a bit-banged SPI driver I can contribute), we should probably focus on the on-board peripherals first, and then branch out from there.
  
The reason for asking this question is that it has impacts on RAM. and also on the API. For example we should at least think about software emulation otherwise we may find ourselves changing the API later. Better to design a little more up front first even if we do a staged implementation and not everything is available on day one.
4. How do we handle devices with 1 of something versus multiple e.g. 
USARTs and SPI buses? Most devices except xmega have only one 
I2C port.
    

Good question. There are a lot of ways to do it. Let's discuss it after we can agree on which project to host with and we have a separate mailing list. ;-)
  
So now is the time? Probably should start a separate thread on this one (and for that matter some of the other open questions on this list.
5. Do we have a one-size fits all approach that dynamically adds support for multiple SPI buses for example, or are there several different flavors?
    

In my experience, one-size generally does not fit all. I'm ok with several different flavors.
  
No but you could have #defines that add additional features/functions e.g. #define MULTI_SPI_SUPPORT.
6. Is the library simply header files with macros and inline 
functions 
or is there a library file to link with, or a mixture of both? The 
answer to the previous question may affect the answer to this 
question.
    

Why impose an artificial limitation on the implementation. My experience has been that one has generally a mixture of both, header files with macros and library functions. It probably depends on how complex the API implementation is.
  
I wasn't trying to - just asking a question. My guess is that a lot of the code will be conditionally compiled and very little will be in a library archive per se.
7. What non-device functions do we support e.g. multi-tasking of some  kind? Do we add time of day/date/clock tick functions that gets allocated to a specific timer at compile or runtime?
    
We are not developing an RTOS.

No objection to adding support for date functions, but let's do that down the road (unless you have some code you can contribute).
  
Date functions affect allocation of timers and need one reserved to keep track of ticks. We might have defines like the following:
#define ENABLE_TIME_OF_DAY 1
#define TIME_OF_DAY_TIMER   3
which enables a timer3 ISR for timer ticks and a #define such as #define TIMER3_ALLOCATED 1. Other code would check for TIMER#_ALLOCATED to avoid using these registers.

This is why I think we need to do some design up front for a staged implementation.
8. What naming convention do we use? (has been discussed and I think a consensus reached to use underscores - just needs to be  written down in the design document)
    
Agreed.
  
Who is creating a design document and where will that reside? I don't yet see a project on http://savannah.nongnu.org.

Mike Perks
Oak Micros (oakmicros.com)
--------------030907050905010807040406-- From MAILER-DAEMON Mon Sep 21 13:17:09 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MpmVh-0004Jg-35 for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 13:17:09 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MpmVf-0004JC-Af for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 13:17:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MpmVa-0004Gy-N2 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 13:17:06 -0400 Received: from [199.232.76.173] (port=45407 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MpmVa-0004Gp-8h for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 13:17:02 -0400 Received: from newsmtp5.atmel.com ([204.2.163.5]:55504 helo=sjogate2.atmel.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MpmVZ-0003MY-27 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 13:17:01 -0400 Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id n8LHFEK7007518; Mon, 21 Sep 2009 10:15:15 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Avr-libc-corelib] Library Design Questions Date: Mon, 21 Sep 2009 11:16:47 -0600 Message-ID: <258DDD1F44B6ED4AAFD4370847CF58D508102F48@csomb01.corp.atmel.com> In-Reply-To: <4AB7AF1F.60801@oakmicros.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Avr-libc-corelib] Library Design Questions Thread-Index: Aco63dgny0u9d3fDSaGAmx1kEMPY6gAAF3xw References: <604fcf830909170004w208950b8o71349e20b9ad6947@mail.gmail.com><4AB72DDC.9090402@westcontrol.com><4AB785C1.60908@oakmicros.com><258DDD1F44B6ED4AAFD4370847CF58D508102D89@csomb01.corp.atmel.com> <4AB7AF1F.60801@oakmicros.com> From: "Weddington, Eric" To: "Mike Perks" , X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 17:17:07 -0000 =20 > -----Original Message----- > From:=20 > avr-libc-corelib-bounces+eric.weddington=3Datmel.com@nongnu.org=20 > [mailto:avr-libc-corelib-bounces+eric.weddington=3Datmel.com@non > gnu.org] On Behalf Of Mike Perks > Sent: Monday, September 21, 2009 10:52 AM > To: avr-libc-corelib@nongnu.org > Subject: [Avr-libc-corelib] Library Design Questions=20 >=20 >=20 > The reason for asking this question is that it has impacts on=20 > RAM. and also on the API. For example we should at least=20 > think about software emulation otherwise we may find=20 > ourselves changing the API later. Better to design a little=20 > more up front first even if we do a staged implementation and=20 > not everything is available on day one. Sounds like a good plan to me. =20 >=20 > 4. How do we handle devices with 1 of something=20 > versus multiple e.g.=20 > USARTs and SPI buses? Most devices except xmega=20 > have only one=20 > I2C port. > =20 >=20 > =09 > Good question. There are a lot of ways to do it. Let's=20 > discuss it after we can agree on which project to host with=20 > and we have a separate mailing list. ;-) > =20 >=20 > So now is the time? Probably should start a separate thread=20 > on this one (and for that matter some of the other open=20 > questions on this list. Yes. Separate threads. =20 > 5. Do we have a one-size fits all approach that=20 > dynamically adds support for multiple SPI buses for example,=20 > or are there several different flavors? > =20 >=20 > =09 > In my experience, one-size generally does not fit all.=20 > I'm ok with several different flavors. > =20 >=20 > No but you could have #defines that add additional=20 > features/functions e.g. #define MULTI_SPI_SUPPORT.=20 I'd have to see more about a specific implementation before agreeing one = way or the other. =20 > 6. Is the library simply header files with=20 > macros and inline=20 > functions=20 > or is there a library file to link with, or a=20 > mixture of both? The=20 > answer to the previous question may affect the=20 > answer to this=20 > question. > =20 >=20 > =09 > Why impose an artificial limitation on the=20 > implementation. My experience has been that one has generally=20 > a mixture of both, header files with macros and library=20 > functions. It probably depends on how complex the API=20 > implementation is. > =20 >=20 > I wasn't trying to - just asking a question. My guess is that=20 > a lot of the code will be conditionally compiled and very=20 > little will be in a library archive per se. Again, I think it depends on the implementation. I'd like to follow the = KISS rule where possible, which means from my perspective that I would = rather have simple drivers and limited functionality (but tested), than = have a driver that has a lot of functionality but is very complex to = use. So I think that it would be better to have as one of the design = goals: simple to use. I think the target audience here is beginner and = intermediate users. For advanced users who need to have the complexity, = they can use the source code (freely available) as a starting point and = modify it as they see fit. =20 > This is why I think we need to do some design up front for a=20 > staged implementation. No argument here. :-) >=20 > Who is creating a design document and where will that reside?=20 > I don't yet see a project on http://savannah.nongnu.org. Well this mailing list is a part of the avr-libc project on Savannah. We = can keep a design document on the avr-libc project. However, a design = document has not been started. If you start one, then I would suggest = doing it in a simple text file, as we have Linux and FreeBSD users here = so avoid any MS format documents. From MAILER-DAEMON Mon Sep 21 13:43:25 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mpmv7-0008KH-Jf for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 13:43:25 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mpmv6-0008K0-9z for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 13:43:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mpmv1-0008IB-FW for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 13:43:23 -0400 Received: from [199.232.76.173] (port=49575 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mpmv1-0008I6-70 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 13:43:19 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:46509) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mpmv0-00082v-Nu for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 13:43:18 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8LHcbKl021977 for ; Mon, 21 Sep 2009 11:38:37 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8LHh8sB078574 for ; Mon, 21 Sep 2009 11:43:09 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8LHh8rd004349 for ; Mon, 21 Sep 2009 11:43:08 -0600 Received: from [127.0.0.1] (dyn780018.austin.ibm.com [9.41.103.141]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8LHh6jg004222 for ; Mon, 21 Sep 2009 11:43:08 -0600 Message-ID: <4AB7BB20.4050907@oakmicros.com> Date: Mon, 21 Sep 2009 12:42:56 -0500 From: Mike Perks User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: avr-libc-corelib@nongnu.org References: <604fcf830909170004w208950b8o71349e20b9ad6947@mail.gmail.com><4AB72DDC.9090402@westcontrol.com><4AB785C1.60908@oakmicros.com><258DDD1F44B6ED4AAFD4370847CF58D508102D89@csomb01.corp.atmel.com> <4AB7AF1F.60801@oakmicros.com> <258DDD1F44B6ED4AAFD4370847CF58D508102F48@csomb01.corp.atmel.com> In-Reply-To: <258DDD1F44B6ED4AAFD4370847CF58D508102F48@csomb01.corp.atmel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: [Avr-libc-corelib] Design Document Format (was Library Design Questions) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 17:43:24 -0000 Eric Weddington wrote: > Well this mailing list is a part of the avr-libc project on Savannah. We can keep a design document on the avr-libc project. However, a design document has not been started. If you start one, then I would suggest doing it in a simple text file, as we have Linux and FreeBSD users here so avoid any MS format documents. > How about OpenOffice saved in Microsoft Office file formats? Doesn't everyone on Linux have OpenOffice by now :) I find plain text files hard to read except for short README style files. The other alternative is HTML. The possible advantage of HTML is that the design document can morph into the library documentation. Regards, Mike From MAILER-DAEMON Mon Sep 21 14:19:31 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MpnU3-0000AP-7t for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 14:19:31 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MpnU0-0000A5-Rg for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 14:19:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MpnTv-00009l-LN for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 14:19:27 -0400 Received: from [199.232.76.173] (port=60976 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MpnTv-00009i-JC for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 14:19:23 -0400 Received: from newsmtp5.atmel.com ([204.2.163.5]:57537 helo=sjogate2.atmel.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MpnTv-0007wd-6Z for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 14:19:23 -0400 Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id n8LIHNOt012812; Mon, 21 Sep 2009 11:17:23 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Avr-libc-corelib] Design Document Format (was Library DesignQuestions) Date: Mon, 21 Sep 2009 12:18:56 -0600 Message-ID: <258DDD1F44B6ED4AAFD4370847CF58D508102FC2@csomb01.corp.atmel.com> In-Reply-To: <4AB7BB20.4050907@oakmicros.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Avr-libc-corelib] Design Document Format (was Library DesignQuestions) Thread-Index: Aco64xYt6Bf3hJzGRtmKKIES1iXkbwABKdjw References: <604fcf830909170004w208950b8o71349e20b9ad6947@mail.gmail.com><4AB72DDC.9090402@westcontrol.com><4AB785C1.60908@oakmicros.com><258DDD1F44B6ED4AAFD4370847CF58D508102D89@csomb01.corp.atmel.com><4AB7AF1F.60801@oakmicros.com><258DDD1F44B6ED4AAFD4370847CF58D508102F48@csomb01.corp.atmel.com> <4AB7BB20.4050907@oakmicros.com> From: "Weddington, Eric" To: "Mike Perks" , X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:19:29 -0000 =20 > -----Original Message----- > From:=20 > avr-libc-corelib-bounces+eric.weddington=3Datmel.com@nongnu.org=20 > [mailto:avr-libc-corelib-bounces+eric.weddington=3Datmel.com@non > gnu.org] On Behalf Of Mike Perks > Sent: Monday, September 21, 2009 11:43 AM > To: avr-libc-corelib@nongnu.org > Subject: [Avr-libc-corelib] Design Document Format (was=20 > Library DesignQuestions) >=20 > Eric Weddington wrote: > > Well this mailing list is a part of the avr-libc project on=20 > Savannah. We can keep a design document on the avr-libc=20 > project. However, a design document has not been started. If=20 > you start one, then I would suggest doing it in a simple text=20 > file, as we have Linux and FreeBSD users here so avoid any MS=20 > format documents. > > =20 > How about OpenOffice saved in Microsoft Office file formats? Doesn't=20 > everyone on Linux have OpenOffice by now :) >=20 > I find plain text files hard to read except for short README style=20 > files. The other alternative is HTML. The possible advantage=20 > of HTML is=20 > that the design document can morph into the library documentation. Well you bring up a good point: If this will eventually morph into = library documentation, then I suggest doing it in a text file. The = avr-libc project uses doxygen as it's documentation generation tool, and = there are a number of independent document pages (i.e. not associated = with code itself). Doxygen read comments in source code, so moving a = text file over to doxygen is not that difficult. At this point, I think content matters more than format. ;-) From MAILER-DAEMON Mon Sep 21 15:10:29 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MpoHN-0003To-63 for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 15:10:29 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MpnWd-0000Ov-MZ for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 14:22:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MpnWZ-0000O9-Bk for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 14:22:11 -0400 Received: from [199.232.76.173] (port=32781 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MpnWZ-0000O6-66 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 14:22:07 -0400 Received: from mail-ew0-f221.google.com ([209.85.219.221]:59605) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MpnWY-0008Kv-TA for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 14:22:07 -0400 Received: by ewy21 with SMTP id 21so2213901ewy.8 for ; Mon, 21 Sep 2009 11:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=ZCY2jTOqbdc/p2L/9AnKM96wEEjvKKIaAa+j0FrLrP0=; b=A3lhH2I0M+ZlLNYGBd43TQsmpsbTUWf4UtpxRT8bSllDN+bKQ+9cn3IwrZd1AINv9A iqqBDvM0I7Xi0dqXinLUzLtlR4lAZlvhPcbH7Ume/WW0VKP/MDaKE7pBXy6sGRJz8X4E +Hlr4INF5EFRB9ZhkFBubOkSq7PFUiprop1GI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=gO9C6Mw01XgrWiiBBsMEswmlKC/mB+D147XBLMlgWuUc3dnmwhxoKT4waEgpzAX5Tn neY7ZrGGxzjmWoLx5C216Us2FJIPrdWEymO08DPzul0p8GwuR6cKN0ahZprX3UXbBeII 0K5D024syO7lIwrJP1xQ5oGCnwOzM4ovryKgo= MIME-Version: 1.0 Received: by 10.211.147.10 with SMTP id z10mr3303275ebn.28.1253557325061; Mon, 21 Sep 2009 11:22:05 -0700 (PDT) Date: Mon, 21 Sep 2009 14:22:05 -0400 Message-ID: <93ef05bc0909211122k4e7d5466he2cd7b23b82291a7@mail.gmail.com> Subject: RE: [Avr-libc-corelib] Library Design Questions From: =?ISO-8859-1?Q?Fr=E9d=E9ric_Nadeau?= To: avr-libc-corelib@nongnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Mon, 21 Sep 2009 15:10:28 -0400 X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:22:11 -0000 > 5. Do we have a one-size fits all approach that > dynamically adds support for multiple SPI buses for example, > or are there several different flavors? My opinion is the following: use a API like this int spi_init(a,b,c,d) Have two or more function like: int spi_single_init(b,c,d) and int spi_multi_init(a,b,c,d) Where argument 'a' is kind of port select in the spi.h have something like #if device support more than 1 SPI #define spi_init(a,b,c,d) spi_multi_init(a,b,c,d) #else define spi_init(a,b,c,d) spi_single_init(b,c,d) The use is of course not aware of the spi_single/multi. When used properly, this could allow code to be ported from a device with one SPI to a device with two SPI in a snip. Of course same would apply to USART, USI and TWI --=20 Fr=E9d=E9ric Nadeau ing. jr From MAILER-DAEMON Mon Sep 21 16:28:59 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MppVL-0005eo-Oc for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 16:28:59 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MpowM-00078l-O0 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 15:52:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MpowI-00078R-PH for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 15:52:49 -0400 Received: from [199.232.76.173] (port=42789 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MpowI-00078O-L4 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 15:52:46 -0400 Received: from fmailhost03.isp.att.net ([204.127.217.103]:53703) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MpowI-0007dy-8F for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 15:52:46 -0400 Received: from joelaptop (adsl-153-107-220.tys.bellsouth.net[70.153.107.220]) by isp.att.net (frfwmhc03) with SMTP id <20090921195242H0300s41tpe>; Mon, 21 Sep 2009 19:52:42 +0000 X-Originating-IP: [70.153.107.220] Message-ID: <46A68F827C0447238E85FBACE0E3E77D@JoeLaptop> From: "Joe Pardue" To: Date: Mon, 21 Sep 2009 15:52:30 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01CA3AD3.869B5E00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-Mailman-Approved-At: Mon, 21 Sep 2009 16:28:57 -0400 Subject: [Avr-libc-corelib] I want to participate X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 19:52:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002A_01CA3AD3.869B5E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I just read the nabble archive of the activity over the past several = days and while I'm a bit overwhelmed, I would like to participate. I got = Eric's link to the CVS book and there is a slight possibility that I = still have enough brain cells intact to get up to speed on this. I'll = probably need to reread the archive before really getting started.=20 Joe ------=_NextPart_000_002A_01CA3AD3.869B5E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I just read the nabble archive of the = activity over=20 the past several days and while I'm a bit overwhelmed, I would like to=20 participate. I got Eric's link to the CVS book and there is a slight = possibility=20 that I still have enough brain cells intact to get up to speed on this. = I'll=20 probably need to reread the archive before really getting started. =
 
Joe
------=_NextPart_000_002A_01CA3AD3.869B5E00-- From MAILER-DAEMON Mon Sep 21 16:56:57 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MppwP-0000xV-9u for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 16:56:57 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MppsN-0007wz-9F for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 16:52:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MppsI-0007wn-No for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 16:52:46 -0400 Received: from [199.232.76.173] (port=49403 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MppsI-0007wk-GB for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 16:52:42 -0400 Received: from fmailhost04.isp.att.net ([207.115.11.54]:46259) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MppsH-00086A-W6 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 16:52:42 -0400 Received: from joelaptop (adsl-153-107-220.tys.bellsouth.net[70.153.107.220]) by isp.att.net (frfwmhc04) with SMTP id <20090921205238H0400icvufe>; Mon, 21 Sep 2009 20:52:39 +0000 X-Originating-IP: [70.153.107.220] Message-ID: From: "Joe Pardue" To: Date: Mon, 21 Sep 2009 16:52:26 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01CA3ADB.E6398AA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-Mailman-Approved-At: Mon, 21 Sep 2009 16:56:56 -0400 Subject: [Avr-libc-corelib] Test - trying to get subscribed to the mailing list X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 20:52:47 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002A_01CA3ADB.E6398AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a test, sorry for the inconvenience. Joe ------=_NextPart_000_002A_01CA3ADB.E6398AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is a test, sorry for the=20 inconvenience.
 
Joe
------=_NextPart_000_002A_01CA3ADB.E6398AA0-- From MAILER-DAEMON Mon Sep 21 16:59:59 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MppzL-0001T8-R8 for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 16:59:59 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MppzJ-0001Sg-VK for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 16:59:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MppzE-0001SS-Jb for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 16:59:56 -0400 Received: from [199.232.76.173] (port=57096 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MppzE-0001SP-BB for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 16:59:52 -0400 Received: from mx20.gnu.org ([199.232.41.8]:21072) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MppzD-0001lW-UJ for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 16:59:52 -0400 Received: from newsmtp5.atmel.com ([204.2.163.5] helo=sjogate2.atmel.com) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mppz6-0005kW-M6 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 16:59:44 -0400 Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id n8LKvpdH026692; Mon, 21 Sep 2009 13:57:51 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Avr-libc-corelib] Test - trying to get subscribed to the mailinglist Date: Mon, 21 Sep 2009 14:59:23 -0600 Message-ID: <258DDD1F44B6ED4AAFD4370847CF58D508103134@csomb01.corp.atmel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Avr-libc-corelib] Test - trying to get subscribed to the mailinglist Thread-Index: Aco6/hVx3JkKp8pXSAeccqk3KabvoQAAEcfQ References: From: "Weddington, Eric" To: "Joe Pardue" , X-detected-operating-system: by mx20.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 20:59:58 -0000 =20 > -----Original Message----- > From:=20 > avr-libc-corelib-bounces+eric.weddington=3Datmel.com@nongnu.org=20 > [mailto:avr-libc-corelib-bounces+eric.weddington=3Datmel.com@non > gnu.org] On Behalf Of Joe Pardue > Sent: Monday, September 21, 2009 2:52 PM > To: avr-libc-corelib@nongnu.org > Subject: [Avr-libc-corelib] Test - trying to get subscribed=20 > to the mailinglist >=20 > This is a test, sorry for the inconvenience. > =20 > Joe > You're good from here. ;-)=20 From MAILER-DAEMON Mon Sep 21 17:07:00 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mpq68-0005DU-DZ for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 17:07:00 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mpq66-0005DO-LB for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 17:06:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mpq62-0005Cz-S5 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 17:06:58 -0400 Received: from [199.232.76.173] (port=37371 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mpq62-0005Cw-NO for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 17:06:54 -0400 Received: from newsmtp5.atmel.com ([204.2.163.5]:63057 helo=sjogate2.atmel.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mpq61-0003uX-VS for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 17:06:54 -0400 Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id n8LL5I6E027476; Mon, 21 Sep 2009 14:05:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Avr-libc-corelib] I want to participate Date: Mon, 21 Sep 2009 15:06:51 -0600 Message-ID: <258DDD1F44B6ED4AAFD4370847CF58D508103143@csomb01.corp.atmel.com> In-Reply-To: <46A68F827C0447238E85FBACE0E3E77D@JoeLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Avr-libc-corelib] I want to participate Thread-Index: Aco6+jFLrq4sAJRmQxSCZT9uhHbYYAABK2YQ References: <46A68F827C0447238E85FBACE0E3E77D@JoeLaptop> From: "Weddington, Eric" To: "Joe Pardue" , X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:06:59 -0000 =20 > -----Original Message----- > From:=20 > avr-libc-corelib-bounces+eric.weddington=3Datmel.com@nongnu.org=20 > [mailto:avr-libc-corelib-bounces+eric.weddington=3Datmel.com@non > gnu.org] On Behalf Of Joe Pardue > Sent: Monday, September 21, 2009 1:53 PM > To: avr-libc-corelib@nongnu.org > Subject: [Avr-libc-corelib] I want to participate >=20 > I just read the nabble archive of the activity over the past=20 > several days and while I'm a bit overwhelmed, I would like to=20 > participate. I got Eric's link to the CVS book and there is a=20 > slight possibility that I still have enough brain cells=20 > intact to get up to speed on this. I'll probably need to=20 > reread the archive before really getting started.=20 > =20 Learning CVS is a good thing. But before learning CVS, there is another = skill that is more important, and that is learning how to use the 'diff' = and 'patch' utilities to create patches and to use these patches. These = utilities are collectively called 'diffutils', and here's the GNU manual = for these: CVS also uses the patch concept, so if you understand this part, then it = will help you learning CVS. If you learn how to create patches, then you = can effectively participate and contribute to an open source project, = without having to learn CVS first. ;-) From MAILER-DAEMON Mon Sep 21 17:59:34 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mpqv0-0005lc-Ku for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 17:59:34 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MpqNA-0004eM-6l for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 17:24:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MpqN4-0004dy-Gb for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 17:24:34 -0400 Received: from [199.232.76.173] (port=43127 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MpqN4-0004dv-Ap for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 17:24:30 -0400 Received: from mail1.freeserver.sk ([217.67.30.194]:60018) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MpqN3-0007Fp-Tq for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 17:24:30 -0400 Received: from [195.91.86.171] (helo=eeepc-wek) by mail1.freeserver.sk with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MpqN8-000IXq-J5 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 23:24:34 +0200 Date: Mon, 21 Sep 2009 23:27:48 +0200 From: Jan Waclawek To: avr-libc-corelib@nongnu.org Message-Id: <20090921232748.3492d234.konfera@efton.sk> X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-Mailman-Approved-At: Mon, 21 Sep 2009 17:59:32 -0400 Subject: [Avr-libc-corelib] Error handling X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:24:36 -0000 Error handling is always a topic a typical programmer wishes to avoid or to postpone as far as it gets. Moreover, as in typical embedded systems there's usually little or no user interaction, it's always a question, what exactly can we do in case of a run-time error. A library-maker has a slightly better position. The easiest thing to do in a library - besides ignoring them, of course :-) - is to throw them to the caller's head. This is most probably what we are going to do here, so this makes errors an inevitable part of the API, isn't it. And, as errors may occur maybe within every module of a library, it might be worth to establish a common policy how to handle them. A common thing to do is to return an error flag if a function fails to perform as intended. This seems to be fine and consistent, but... 1. often, the programmer implicitly assures that error won't occur (e.g. communication is throttled by the other party well enough to prevent buffer overflow), so he ignores the returned error; 2. maybe even more often the returned error is ignored even if it is not quite kosher to ignore it, simply for lack of any reasonable action to take in case of error; 3. if the function is called for example from an ISR, there's really nothing to do with an error but to store it for further use - which is what the called function might have done straight away; 4. some of the functions have better information to return than an error code. Ergo, IMHO it's a pure waste to return runtime error codes, and I suggest to establish a single variable, core_lib_error or such, where functions could store an appropriate code when error occurs, and leave it upon the user how does he wish to use or ignore it. We can also define a "first wins" or "last wins" strategy, a set of standardized error codes and a header full of predefined strings to spit out in case an appropriate output device is available; but those are only less significant details. Comments? JW From MAILER-DAEMON Mon Sep 21 17:59:35 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mpqv1-0005m6-5H for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 17:59:35 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MpqT7-0007OD-Ir for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 17:30:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MpqT3-0007Nn-9D for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 17:30:45 -0400 Received: from [199.232.76.173] (port=49433 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MpqT3-0007Nk-12 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 17:30:41 -0400 Received: from mail1.freeserver.sk ([217.67.30.194]:56943) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MpqT2-0007zk-Lh for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 17:30:40 -0400 Received: from [195.91.86.171] (helo=eeepc-wek) by mail1.freeserver.sk with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MpqT1-000IfC-No; Mon, 21 Sep 2009 23:30:39 +0200 Date: Mon, 21 Sep 2009 23:33:54 +0200 From: Jan Waclawek To: "Weddington, Eric" Subject: Re: [Avr-libc-corelib] I want to participate Message-Id: <20090921233354.9b59abc7.konfera@efton.sk> In-Reply-To: <258DDD1F44B6ED4AAFD4370847CF58D508103143@csomb01.corp.atmel.com> References: <46A68F827C0447238E85FBACE0E3E77D@JoeLaptop> <258DDD1F44B6ED4AAFD4370847CF58D508103143@csomb01.corp.atmel.com> X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-Mailman-Approved-At: Mon, 21 Sep 2009 17:59:32 -0400 Cc: Joe Pardue , avr-libc-corelib@nongnu.org X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:30:45 -0000 On Mon, 21 Sep 2009 15:06:51 -0600 "Weddington, Eric" wrote: > > > > -----Original Message----- > > From: > > avr-libc-corelib-bounces+eric.weddington=atmel.com@nongnu.org > > [mailto:avr-libc-corelib-bounces+eric.weddington=atmel.com@non > > gnu.org] On Behalf Of Joe Pardue > > Sent: Monday, September 21, 2009 1:53 PM > > To: avr-libc-corelib@nongnu.org > > Subject: [Avr-libc-corelib] I want to participate > > > > I just read the nabble archive of the activity over the past > > several days and while I'm a bit overwhelmed, I would like to > > participate. I got Eric's link to the CVS book and there is a > > slight possibility that I still have enough brain cells > > intact to get up to speed on this. I'll probably need to > > reread the archive before really getting started. > > > > Learning CVS is a good thing. But before learning CVS, there is another skill that is more important, and that is learning how to use the 'diff' and 'patch' utilities to create patches and to use these patches. These utilities are collectively called 'diffutils', and here's the GNU manual for these: > > > CVS also uses the patch concept, so if you understand this part, then it will help you learning CVS. If you learn how to create patches, then you can effectively participate and contribute to an open source project, without having to learn CVS first. ;-) > > OK, and couldn't we the stupider part of the world simply skip CVS completely once we learn to use diff and patch? JW PS. Couldn't this particular forum please be set to the normal way of things, namely that plain Re: would reply to the forum rather than the original poster? Otherwise you will permanently receive personal messages from me - as you might've noted, I *am* that exceptionally dumb. From MAILER-DAEMON Mon Sep 21 18:04:16 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MpqzY-0000So-9h for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 18:04:16 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MpqzW-0000Qn-H3 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 18:04:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MpqzR-0000Of-O6 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 18:04:14 -0400 Received: from [199.232.76.173] (port=41060 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MpqzR-0000Oa-Iz for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 18:04:09 -0400 Received: from newsmtp5.atmel.com ([204.2.163.5]:65201 helo=sjogate2.atmel.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MpqzQ-0004gj-TC for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 18:04:09 -0400 Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id n8LM2STl003633; Mon, 21 Sep 2009 15:02:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Avr-libc-corelib] I want to participate Date: Mon, 21 Sep 2009 16:04:01 -0600 Message-ID: <258DDD1F44B6ED4AAFD4370847CF58D5081031BC@csomb01.corp.atmel.com> In-Reply-To: <20090921233354.9b59abc7.konfera@efton.sk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Avr-libc-corelib] I want to participate Thread-Index: Aco7AsS4SPOD3bqLRNqa+kcCuT4jzwABCRmA References: <46A68F827C0447238E85FBACE0E3E77D@JoeLaptop><258DDD1F44B6ED4AAFD4370847CF58D508103143@csomb01.corp.atmel.com> <20090921233354.9b59abc7.konfera@efton.sk> From: "Weddington, Eric" To: "Jan Waclawek" X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: Joe Pardue , avr-libc-corelib@nongnu.org X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:04:15 -0000 =20 > -----Original Message----- > From: Jan Waclawek [mailto:konfera@efton.sk]=20 > Sent: Monday, September 21, 2009 3:34 PM > To: Weddington, Eric > Cc: Joe Pardue; avr-libc-corelib@nongnu.org > Subject: Re: [Avr-libc-corelib] I want to participate >=20 > On Mon, 21 Sep 2009 15:06:51 -0600 > "Weddington, Eric" wrote: >=20 > > Learning CVS is a good thing. But before learning CVS,=20 > there is another skill that is more important, and that is=20 > learning how to use the 'diff' and 'patch' utilities to=20 > create patches and to use these patches. These utilities are=20 > collectively called 'diffutils', and here's the GNU manual for these: > > > >=20 > > CVS also uses the patch concept, so if you understand this=20 > part, then it will help you learning CVS. If you learn how to=20 > create patches, then you can effectively participate and=20 > contribute to an open source project, without having to learn=20 > CVS first. ;-) > >=20 > >=20 >=20 > OK, and couldn't we the stupider part of the world simply=20 > skip CVS completely once we learn to use diff and patch? >=20 Learning CVS is a very good skill to learn for any kind of software = engineering. ;-) I would still encourage you to learn it because it is = still the best way to participate in an open source project. > PS. Couldn't this particular forum please be set to the=20 > normal way of things, namely that plain Re: would reply to=20 > the forum rather than the original poster? Otherwise you will=20 > permanently receive personal messages from me - as you=20 > might've noted, I *am* that exceptionally dumb. Just learn to press "Reply All" on email client. ;-) From MAILER-DAEMON Mon Sep 21 18:07:15 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mpr2R-0001LQ-Er for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 18:07:15 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mpr2Q-0001KV-2P for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 18:07:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mpr2K-0001IQ-G3 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 18:07:13 -0400 Received: from [199.232.76.173] (port=41132 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mpr2K-0001IM-Bc for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 18:07:08 -0400 Received: from newsmtp5.atmel.com ([204.2.163.5]:65318 helo=sjogate2.atmel.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mpr2J-0005CS-QC for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 18:07:08 -0400 Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id n8LM5Qel003865; Mon, 21 Sep 2009 15:05:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Avr-libc-corelib] Error handling Date: Mon, 21 Sep 2009 16:06:59 -0600 Message-ID: <258DDD1F44B6ED4AAFD4370847CF58D5081031C1@csomb01.corp.atmel.com> In-Reply-To: <20090921232748.3492d234.konfera@efton.sk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Avr-libc-corelib] Error handling Thread-Index: Aco7Bt9xqnISGrqUTXG3c2yQ+Y2UiwAALmxQ References: <20090921232748.3492d234.konfera@efton.sk> From: "Weddington, Eric" To: "Jan Waclawek" , X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:07:14 -0000 =20 > -----Original Message----- > From:=20 > avr-libc-corelib-bounces+eric.weddington=3Datmel.com@nongnu.org=20 > [mailto:avr-libc-corelib-bounces+eric.weddington=3Datmel.com@non > gnu.org] On Behalf Of Jan Waclawek > Sent: Monday, September 21, 2009 3:28 PM > To: avr-libc-corelib@nongnu.org > Subject: [Avr-libc-corelib] Error handling >=20 > Error handling is always a topic a typical programmer wishes=20 > to avoid or to postpone as far as it gets.=20 =20 > Comments? This is fairly broad, which may or may not apply to actual drivers. Can = you provide a real-world examples? From MAILER-DAEMON Mon Sep 21 18:43:41 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mprbh-0008PP-Af for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 18:43:41 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mprbf-0008Oe-2d for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 18:43:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mprba-0008MB-7p for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 18:43:38 -0400 Received: from [199.232.76.173] (port=35430 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mprba-0008Lx-5E for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 18:43:34 -0400 Received: from mail1.freeserver.sk ([217.67.30.194]:49636) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MprbZ-0001z3-LE for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 18:43:33 -0400 Received: from [195.91.86.171] (helo=eeepc-wek) by mail1.freeserver.sk with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MprbX-000MQI-Cx; Tue, 22 Sep 2009 00:43:31 +0200 Date: Tue, 22 Sep 2009 00:46:55 +0200 From: Jan Waclawek To: "Weddington, Eric" Subject: Re: [Avr-libc-corelib] Error handling Message-Id: <20090922004655.db8fa6fa.konfera@efton.sk> In-Reply-To: <258DDD1F44B6ED4AAFD4370847CF58D5081031C1@csomb01.corp.atmel.com> References: <20090921232748.3492d234.konfera@efton.sk> <258DDD1F44B6ED4AAFD4370847CF58D5081031C1@csomb01.corp.atmel.com> X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: avr-libc-corelib@nongnu.org X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:43:39 -0000 You mean, from an existing widely used library, or shall I make up one -- for example modifying the code you provided, perhaps? JW > > > > Comments? > > This is fairly broad, which may or may not apply to actual drivers. Can you provide a real-world examples? From MAILER-DAEMON Mon Sep 21 19:16:08 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mps76-0007Ku-AR for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 19:16:08 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mps44-0006Bf-BH for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 19:13:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mps3w-0006BL-G8 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 19:12:59 -0400 Received: from [199.232.76.173] (port=37530 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mps3w-0006BI-Ce for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 19:12:52 -0400 Received: from [217.21.148.66] (port=53489 helo=xeon.firstbase.nl) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mps3w-0006fk-0i for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 19:12:52 -0400 Received: from octy.betaresearch.nl (212-127-153-50.cable.quicknet.nl [212.127.153.50]) by xeon.firstbase.nl (Postfix) with ESMTP id 58E556C026 for ; Tue, 22 Sep 2009 00:52:20 +0200 (CEST) From: Ruud Vlaming Organization: Beta Research To: avr-libc-corelib@nongnu.org Subject: Re: [Avr-libc-corelib] Error handling Date: Tue, 22 Sep 2009 00:52:02 +0200 User-Agent: KMail/1.9.1 References: <20090921232748.3492d234.konfera@efton.sk> In-Reply-To: <20090921232748.3492d234.konfera@efton.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909220052.02610.ruud@betaresearch.nl> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-Greylist: delayed 1228 seconds by postgrey-1.27 at monty-python; Mon, 21 Sep 2009 19:12:51 EDT X-Mailman-Approved-At: Mon, 21 Sep 2009 19:16:06 -0400 X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 23:13:00 -0000 On Monday 21 September 2009 23:27, Jan Waclawek wrote: > A common thing to do is to return an error flag if a function fails to perform as intended..... Although common, i usually find it a waste of the costly return variable, which, as you correcty point out is usually ignored. (If that is wise is an other matter ... ) > Ergo, IMHO it's a pure waste to return runtime error codes, and I suggest to establish a single variable, > core_lib_error or such, where functions could store an appropriate code when error occurs, and > leave it upon the user how does he wish to use or ignore it. Allthough i agree that mostly error codes are a waste (if they do not provide specific information) i strongly oppose the use of a single error variable. This makes concurrent use of the library virtually impossible. Lets make all code reentrant, or at least up to the point where the hardware dictates otherwise. But i think we don't have 'errors' in the classical way. An 'error' is a situation that the called function cannot handle. But i would say, that should not happen, or at least, since our state space of the functions is usually very small, the 'error' should be a natural part of the returned information, thus, no generic error handling. Ruud. From MAILER-DAEMON Mon Sep 21 19:41:57 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MpsW5-0003Xf-50 for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 19:41:57 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MpsW3-0003XW-8Y for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 19:41:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MpsVy-0003XA-R9 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 19:41:55 -0400 Received: from [199.232.76.173] (port=33217 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MpsVy-0003X7-OH for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 19:41:50 -0400 Received: from mail-ew0-f221.google.com ([209.85.219.221]:59368) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MpsVy-00062c-Ax for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 19:41:50 -0400 Received: by ewy21 with SMTP id 21so2451651ewy.8 for ; Mon, 21 Sep 2009 16:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=VdZE83T/MtV1pq2y35LqNyu+nrVzzyldWnrjONbpf/0=; b=AkPbZZNaTa4G81OtkDpBKxfsd2PdZkQdYSFQVhO/88iy1PE1RCf4YN1CWZicIsk/L4 m3w+J2VfAeXVg4kISFU3jmfpAyY2b+oXc5MsmYp/aUQb6yeCBfM7DTcXrypiEf/6xn/z 0brxq00d6A/fw/rRAdkfaJmTdPBfSkl30H1qY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=KjipZn+wwTr8ZbBv2f+YC0m8oq6OZ85F7EGy8AyPfllKxKxaqY+urqSVQ7+vk2GbjA SinilpnyyCDKAXr4kotl0RXU73OMDr170fwyTY/uH8lYdsM2A3x6FW0uvrYynMXj31EN aDy76QFzH4EoL7LxgruRflanEx9JNV7phrQsY= MIME-Version: 1.0 Received: by 10.211.130.13 with SMTP id h13mr3491901ebn.81.1253576509597; Mon, 21 Sep 2009 16:41:49 -0700 (PDT) In-Reply-To: <258DDD1F44B6ED4AAFD4370847CF58D5081031C1@csomb01.corp.atmel.com> References: <20090921232748.3492d234.konfera@efton.sk> <258DDD1F44B6ED4AAFD4370847CF58D5081031C1@csomb01.corp.atmel.com> Date: Mon, 21 Sep 2009 19:41:49 -0400 Message-ID: <93ef05bc0909211641r107e0437u5df45490055daf3c@mail.gmail.com> Subject: Re: [Avr-libc-corelib] Error handling From: =?ISO-8859-1?Q?Fr=E9d=E9ric_Nadeau?= To: avr-libc-corelib@nongnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 23:41:55 -0000 On Mon, Sep 21, 2009 at 6:06 PM, Weddington, Eric wrote: > > This is fairly broad, which may or may not apply to actual drivers. Can y= ou provide a real-world examples? > Example spi_write.... spi is not enabled spi_write_non_blocking..... spi transfer already in progress usart_setBaudrate(target_baudrate,pourcentageError).... target baud rate not attainable with specified pourcentage error) and so on.. I would rather use errno than an new errno_corelib. With RTOS, one has to save errono for eatch context, thus with errno_corelib, one more integer(four bytes) on the stack. --=20 Fr=E9d=E9ric Nadeau ing. jr From MAILER-DAEMON Mon Sep 21 20:10:26 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mpsxe-0006LQ-CX for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 20:10:26 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mpsxd-0006LL-1k for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 20:10:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MpsxY-0006II-Ig for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 20:10:24 -0400 Received: from [199.232.76.173] (port=37263 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MpsxY-0006IB-Fp for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 20:10:20 -0400 Received: from newsmtp5.atmel.com ([204.2.163.5]:4801 helo=sjogate2.atmel.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MpsxY-0001nG-25 for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 20:10:20 -0400 Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id n8M08g4w013566; Mon, 21 Sep 2009 17:08:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Avr-libc-corelib] Error handling Date: Mon, 21 Sep 2009 18:10:14 -0600 Message-ID: <258DDD1F44B6ED4AAFD4370847CF58D508103262@csomb01.corp.atmel.com> In-Reply-To: <200909220052.02610.ruud@betaresearch.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Avr-libc-corelib] Error handling Thread-Index: Aco7EYvDGBZhkvFuQKCpRm6p6cyzTwABzlag References: <20090921232748.3492d234.konfera@efton.sk> <200909220052.02610.ruud@betaresearch.nl> From: "Weddington, Eric" To: "Ruud Vlaming" , X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 00:10:25 -0000 =20 > -----Original Message----- > From:=20 > avr-libc-corelib-bounces+eric.weddington=3Datmel.com@nongnu.org=20 > [mailto:avr-libc-corelib-bounces+eric.weddington=3Datmel.com@non > gnu.org] On Behalf Of Ruud Vlaming > Sent: Monday, September 21, 2009 4:52 PM > To: avr-libc-corelib@nongnu.org > Subject: Re: [Avr-libc-corelib] Error handling >=20 > On Monday 21 September 2009 23:27, Jan Waclawek wrote: >=20 > Allthough i agree that mostly error codes are a waste (if=20 > they do not provide specific information) > i strongly oppose the use of a single error variable. This=20 > makes concurrent use of the library > virtually impossible. Lets make all code reentrant, or at=20 > least up to the point where > the hardware dictates otherwise. >=20 > But i think we don't have 'errors' in the classical way. An=20 > 'error' is a situation that the called > function cannot handle. But i would say, that should not=20 > happen, or at least, since our > state space of the functions is usually very small, the=20 > 'error' should be a natural part=20 > of the returned information, thus, no generic error handling.=20 Well said. I agree with you on all your points. I won't rule out having a generic error variable, but I think it depends = on the requirements of the implementation. It is certainly easier to = implement without a generic error variable, if it can be done. From MAILER-DAEMON Mon Sep 21 21:46:05 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MpuSD-0000dZ-9k for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 21:46:05 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mpttp-00041U-RT for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 21:10:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mpttl-00041I-FK for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 21:10:32 -0400 Received: from [199.232.76.173] (port=58931 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mpttl-00041F-AC for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 21:10:29 -0400 Received: from fmailhost03.isp.att.net ([204.127.217.103]:62227) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mpttk-0007H7-Uc for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 21:10:29 -0400 Received: from joelaptop (adsl-153-107-220.tys.bellsouth.net[70.153.107.220]) by isp.att.net (frfwmhc03) with SMTP id <20090922011025H0300s3rk8e>; Tue, 22 Sep 2009 01:10:25 +0000 X-Originating-IP: [70.153.107.220] Message-ID: <3E572F9E45F148A3812D12C195479B80@JoeLaptop> From: "Joe Pardue" To: Date: Mon, 21 Sep 2009 21:10:12 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CA3AFF.E868BC50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-Mailman-Approved-At: Mon, 21 Sep 2009 21:46:04 -0400 Subject: [Avr-libc-corelib] Reuse of Procyon X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 01:10:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01CA3AFF.E868BC50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've tried off and on for over a year to get in touch with Pascal Stang = and though I'm used to being ignored, I'm thinking maybe something else = is going on with him relating to Procyon. I assume from some of the = comments that other folks have had similar difficulties?=20 So my question is: how much of the Procyon library can we reuse as is = without getting anybody too excited? Do we have to go entirely = clean-room? If not where would we draw the line at copy and pasting the = code? It seems silly to rewrite things if the code is truly abandoned, = but then again it seems kind of like theft of IP if he is still around = and pops up a year down the road to protest.=20 It seems silly to reinvent the wheel when that code could be a good = starting base for the avr-libc-corelib, but I don't know what the ethics = of this would be. Personally, I'd be happy to copy and paste the whole thing with a = disclaimer at the beginning, but I'm sure the GPL vs BSD license folks = wouldn't be happy, so is there a guideline on what constitutes = 'appropriate reuse' and when that phrase just means 'stealing'? Joe ------=_NextPart_000_0010_01CA3AFF.E868BC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I've tried off and on for over a year = to get in=20 touch with Pascal Stang and though I'm used to being ignored, I'm = thinking maybe=20 something else is going on with him relating to Procyon. I assume from = some of=20 the comments that other folks have had similar difficulties? =
 
So my question is: how much of the = Procyon library=20 can we reuse as is without getting anybody too excited? Do we have to go = entirely clean-room? If not where would we draw the line at copy and = pasting the=20 code? It seems silly to rewrite things if the code is truly abandoned, = but then=20 again it seems kind of like theft of IP if he is still around and pops = up a year=20 down the road to protest.
 
It seems silly to reinvent the wheel = when that code=20 could be a good starting base for the avr-libc-corelib, but I don't know = what=20 the ethics of this would be.
 
Personally, I'd be happy to copy and = paste the=20 whole thing with a disclaimer at the beginning, but I'm sure the GPL vs = BSD=20 license folks wouldn't be happy, so is there a guideline on what = constitutes=20 'appropriate reuse' and when that phrase just means = 'stealing'?
 
Joe
------=_NextPart_000_0010_01CA3AFF.E868BC50-- From MAILER-DAEMON Mon Sep 21 22:01:31 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mpuh9-0005Pv-9i for mharc-avr-libc-corelib@gnu.org; Mon, 21 Sep 2009 22:01:31 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mpuh7-0005PP-Pw for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 22:01:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mpuh3-0005OJ-3A for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 22:01:29 -0400 Received: from [199.232.76.173] (port=44906 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mpuh2-0005OG-VM for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 22:01:24 -0400 Received: from newsmtp5.atmel.com ([204.2.163.5]:8448 helo=sjogate2.atmel.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mpuh2-00089Y-CP for avr-libc-corelib@nongnu.org; Mon, 21 Sep 2009 22:01:24 -0400 Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id n8M1xYB7021546; Mon, 21 Sep 2009 18:59:35 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Avr-libc-corelib] Reuse of Procyon Date: Mon, 21 Sep 2009 20:01:07 -0600 Message-ID: <258DDD1F44B6ED4AAFD4370847CF58D50810328B@csomb01.corp.atmel.com> In-Reply-To: <3E572F9E45F148A3812D12C195479B80@JoeLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Avr-libc-corelib] Reuse of Procyon Thread-Index: Aco7JotCLzzOqPivRIapX0hvx5nmsAAAXTKw References: <3E572F9E45F148A3812D12C195479B80@JoeLaptop> From: "Weddington, Eric" To: "Joe Pardue" , X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 02:01:30 -0000 =20 > -----Original Message----- > From:=20 > avr-libc-corelib-bounces+eric.weddington=3Datmel.com@nongnu.org=20 > [mailto:avr-libc-corelib-bounces+eric.weddington=3Datmel.com@non > gnu.org] On Behalf Of Joe Pardue > Sent: Monday, September 21, 2009 7:10 PM > To: avr-libc-corelib@nongnu.org > Subject: [Avr-libc-corelib] Reuse of Procyon >=20 > I've tried off and on for over a year to get in touch with=20 > Pascal Stang and though I'm used to being ignored, I'm=20 > thinking maybe something else is going on with him relating=20 > to Procyon. I assume from some of the comments that other=20 > folks have had similar difficulties?=20 > =20 > So my question is: how much of the Procyon library can we=20 > reuse as is without getting anybody too excited? None, because of licensing issues. The Procyon library is licensed with = the GPL. If we copy and paste anything, and try to put a different = license on it, then we violate the GPL license. > Do we have=20 > to go entirely clean-room? If not where would we draw the=20 > line at copy and pasting the code? It seems silly to rewrite=20 > things if the code is truly abandoned, but then again it=20 > seems kind of like theft of IP if he is still around and pops=20 > up a year down the road to protest.=20 > =20 > It seems silly to reinvent the wheel when that code could be=20 > a good starting base for the avr-libc-corelib, but I don't=20 > know what the ethics of this would be. > =20 > Personally, I'd be happy to copy and paste the whole thing=20 > with a disclaimer at the beginning, but I'm sure the GPL vs=20 > BSD license folks wouldn't be happy, so is there a guideline=20 > on what constitutes 'appropriate reuse' and when that phrase=20 > just means 'stealing'? You really need to go read the GPL license and the BSD license to = understand these issues. There is no 'appropriate reuse' if we intend to = license with BSD. We would be violating the GPL license of the Procyon = library. As other have said, we should be fine if we use the same interface = (function names, parameters, return values), but the implementation has = to be all new. There cannot be any wholesale copying of anything. From MAILER-DAEMON Tue Sep 22 04:36:00 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mq0qu-0004a0-Gc for mharc-avr-libc-corelib@gnu.org; Tue, 22 Sep 2009 04:36:00 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mq0qs-0004Xv-Fv for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 04:35:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mq0qo-0004UX-VE for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 04:35:58 -0400 Received: from [199.232.76.173] (port=45990 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mq0qo-0004UC-Oj for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 04:35:54 -0400 Received: from mail1.freeserver.sk ([217.67.30.194]:58616) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mq0qo-0004kS-C6 for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 04:35:54 -0400 Received: from [91.127.72.181] (helo=TEST) by mail1.freeserver.sk with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mq0qn-00083B-9Z; Tue, 22 Sep 2009 10:35:56 +0200 Message-ID: X-Mailer: Ultrafunk Popcorn 1.77 (19-July-2007) X-Priority: 3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Date: Tue, 22 Sep 2009 10:35:46 +0200 From: Jan Waclawek To: Frédéric Nadeau , avr-libc-corelib@nongnu.org Subject: Re: [Avr-libc-corelib] Error handling In-Reply-To: <93ef05bc0909211641r107e0437u5df45490055daf3c@mail.gmail.com> X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 08:35:59 -0000 >I would rather use errno than an new errno_corelib. With RTOS, one has >to save errono for eatch context, thus with errno_corelib, one more >integer(four bytes) on the stack. Eh, pardon? Are we still talking AVRs, you know, 8-bit microcontrollers (stress on 'micro')? And avr-gcc, where int is - naturally - 2 bytes? Even so - and regardless of what I think of appropriateness of an RTOS in 8-bitters - I would never assign to an error flag more than a single byte. And, I would assign a single byte for the WHOLE library, not a separate one for each of the "devices". The rationale is, that errors should NOT happen. >usart_setBaudrate(target_baudrate,pourcentageError).... target baud >rate not attainable with specified pourcentage error) >and so on.. Well, not quite so. If you write a function, which is of one-off character (usually happens at startup and not regularly during runtime) and its functionality expressly includes range-checking and similar (e.g. that's the purpose of specifying percentage error, isn't it), you anticipate it will return some indicator that the input values don't match the required constraint. That's not really what a run-time error constututes. In fact, if one of the purposes of such function is to check constraints, I would not call the returning value an "error" at all. And, I would separate this checking functionality from the actual setting of baudrate anyway, but that's my personal choice. >Example spi_write.... spi is not enabled >spi_write_non_blocking..... spi transfer already in progress Well, maybe, but not quite. These again constitute more of a programmer's error, which should be avoided at compile time, rather than a "vis major" which must be checked and resolved runtime. If these things might happen - e.g. in the latter one, if spi write is not driven by interrupt - then the programmer shall test for spi idle before calling the spi_write, etc. Think rather of buffer overflows (which still is a programmer's fault but sometimes hard to avoid), or framing error in UART reception (which is a true vis major). The user doesn't want an error to happen, and he might make conscious choices in the design to avoid it - but it still might happen, occasionally, maybe beyond of his control, or because of complexity of the program prevents him to exactly predict all possible timing constraints. But, checking for this error every time a function is called is usually superfluous, hence wasteful. I explained this in my first post. Think a try-catch construction. Or a hardware error exception mechanism in processors. Or the "IOResult" function in BorlandPascal and its successors. ---- Okay, some quick examples in pseudo-code. There's one, single, global, one-byte error variable corelib_errno, zeroed (or set to any other convenien default value meaning "no error") at startup. void push_to_circular_buffer(value) { buffer[head] = value; advance(head); if (head == tail) { undo_advance(head); corelib_errno = ERROR_BUFFER_OVERFLOW; } } uint8_t receive_byte_from_uart(void) { // called when we already know there's a byte in UDR - either by checking for appropriate flag or this is used in interrupt if (framing_error) { corelib_errno = ERROR_UART_FRAMING_ERROR; } else if (overrun_error) { corelib_errno = ERROR_UART_OVERRUN_ERROR; } return UDR; } This results in the smallest possible code - a simple write to memory - and the smallest execution time - as it will execute only rarely, when the error happens - in contrast with returning an error value upon each call. --- Now somebody might argue that this is too restrictive, and he might want to have a separate error variable for a module where he expects an error to occur regularly. We can provide both this and the default common one with something like: 1. in all files of some_module replace corelib_errno by SOME_MODULE_ERRNO 2. in some_module.h: #if defined(SOME_MODULE_ERRNO) extern uint8_t SOME_MODULE_ERRNO #else #define SOME_MODULE_ERRNO corelib_errno #endif 3. instruct the user to define the custom error variable as a uint8_t and #define SOME_MODULE_ERRNO to this variable BEFORE #including some_module.h. --- Just ideas. JW From MAILER-DAEMON Tue Sep 22 07:41:57 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mq3kp-0000bh-Ki for mharc-avr-libc-corelib@gnu.org; Tue, 22 Sep 2009 07:41:57 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mq1Ue-0002os-AZ for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 05:17:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mq1UZ-0002nc-FB for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 05:17:03 -0400 Received: from [199.232.76.173] (port=47867 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mq1UZ-0002nV-3s for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 05:16:59 -0400 Received: from gw.kuantic.com ([213.244.28.44]:44271) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mq1UY-0005jY-MH for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 05:16:58 -0400 Received: from [10.0.0.4] (pcbernard.kuantic.com [10.0.0.4]) by gw.kuantic.com (8.14.2/8.14.1) with ESMTP id n8M9GuAU012809 for ; Tue, 22 Sep 2009 11:16:56 +0200 Message-ID: <4AB895F6.6050606@kuantic.com> Date: Tue, 22 Sep 2009 11:16:38 +0200 From: =?ISO-8859-1?Q?Bernard_Fouch=E9?= Organization: Kuantic User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: avr-libc-corelib@nongnu.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (gw.kuantic.com [213.244.28.44]); Tue, 22 Sep 2009 11:16:56 +0200 (CEST) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Tue, 22 Sep 2009 07:41:50 -0400 Subject: [Avr-libc-corelib] Why not consider also other libs than Procyon? X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 09:17:04 -0000 Hi List. A while back, I asked Harald Kipp (NutOS maintainer) if it would be possible to take some code from NutOS and include it in avr-libc. His answer was 'yes'. At that time I was mainly considering time related functions and not drivers (and had no time to do the job :-( ). NutOS already has good drivers (for instance a good I2C driver interrupt driven), Harald answers to emails and licensing should not be an issue. Unfortunately I don't have any time to spare for this new 'corelib', so if someone of the 'corelib' project wants to contact Harald things could go faster than staying focused only on Procyon. Other sources could be Arduino (however I never used this project, so I don't know about drivers) and TinyOS. (BTW, I reworked a few month ago John Regehr's stack.pl script (from TinyOS) to calculate stack usage of an application compiled with gcc-4.X, however John and I had also no time to perform more tests with the updated script (but in my opinion it works rather well and correctly locates patterns produced by the compiler). Could this be part of a set of tools provided with 'corelib'? If someone wants the updated script...) Regards, Bernard From MAILER-DAEMON Tue Sep 22 07:41:59 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mq3ks-0000d8-FC for mharc-avr-libc-corelib@gnu.org; Tue, 22 Sep 2009 07:41:58 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mpyts-0008Dw-2U for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 02:30:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mpytm-0008Dh-Ta for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 02:30:55 -0400 Received: from [199.232.76.173] (port=41204 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mpytm-0008De-OE for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 02:30:50 -0400 Received: from sid6170.sslaccess.com ([202.125.37.67]:59825) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mpytl-0004De-Jk for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 02:30:50 -0400 Received: (qmail 20262 invoked from network); 22 Sep 2009 16:30:43 +1000 Received: from 202.63.38.189.static.rev.aanet.com.au (HELO DEVELOPMENT) (202.63.38.189) by sid6170.sslaccess.com with SMTP; 22 Sep 2009 16:30:42 +1000 From: "Ron Kreymborg" To: Date: Tue, 22 Sep 2009 16:30:13 +1000 Message-ID: <000001ca3b4e$36838fc0$a38aaf40$@com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aco7TiLO8WVvqT/ESXeJsuM+4lZCtg== Content-Language: en-au X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-Mailman-Approved-At: Tue, 22 Sep 2009 07:41:50 -0400 Subject: [Avr-libc-corelib] The SPI implementation X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 06:30:56 -0000 Some suggestions for a SPI api. This is more a discussion paper that a specification. Comments welcome. =========== The Slave. An whole AVR acting as a slave is not going to be idly spinning on SPIF, and as a master message may arrive while it's doing something else, we need a receive interrupt. The library can make no assumptions about the master message contents, so the slave receive interrupt uses a call-back to the user code with the received byte as parameter: int SpiSlaveReceive(int data); By the way, we can have camels and underscores together at the cost of one line, so use what you prefer: #define spi_slave_receive SpiSlaveReceive This function is called from within the slave receive interrupt function, so keep that in mind. It can initiate whatever is required, typically based on the content of the first byte received. Where the AVR was maintaining some status in the SPDR while idle, it can indicate the master has taken that status. It could also specify a request for a particular message from a set of perhaps multi-byte messages the slave is responsible for. The function can choose to return a value that will be immediately written to the SPDR. Bit 15 must be set in the returned value for this to occur. Alternatively, events signalled from within this interrupt can initiate other user code to update the SPDR using the SPI_RET SpiSetSlave(int data); If there are no error returns this has simply copied the byte to the SPDR. Included in the master SpiMasterSend (see below) is a delay parameter that specifies in uSecs (including zero) the delay the master must use between bytes. For a particular system this allows the slave time between receive events to prepare the next byte to return. This may require interpretation of previously received bytes or collection of data and hence processing time. For a more dynamic system, the SPDR idle byte itself could specify the setup delay the slave needs to prepare valid data. ========== The Master The master send function is: SPI_RET SpiMasterSend(int count, uint8* dataOut, uint8* dataIn, int delay); This can return various error codes. The parameters consist of a count of the number of bytes involved in this transaction, a pointer to an array of at least bytes that will be sent, a pointer to an array of bytes of at least bytes that will receive the slave reply, and a delay the send code will insert between bytes. On return the app should examine the returned value for any errors. This can include the sender is busy. It is entirely up to the application as to what is sends and/or does with what it receives. All the library will do is transmit and receive that many bytes. The library manages the sending of the entire message. Like the slave it uses the SPIE interrupt so there is no busy-waiting. The app must guarantee the send buffer integrity during the transmission. A callback function called void SpiSendDone(int flags); is called once the last byte has been sent/received or some error has occurred (timeout, etc). The parameter will define errors. User code defines what this function does. It need do nothing. A function to query the sender for state is: SPI_STATE spi_get_master_state(void); This will return at least that the sender is busy. It could be called SpiIsMasterBusy but there will probably be additional state as we progress. ========== Initialisation There is a philosophical question here: Do we just send the required contents of the SPCR and SPSR registers, or do we make it more formal? The former is easy and not too hard for SPI, but for more complex devices I think a formal init is safer as the init code can detect bit combinations that may be illegal or dangerous. So let's do formal here: typedef enum { SPI_CLK_POL_RISING = 1, // comments here... SPI_CLK_POL_FALLING } SPI_CLOCK_POL; typedef enum { SPI_PHASE_LEADING = 1, SPI_PHASE_TRAILING } SPI_PHASE; typedef enum { SPI_CLK4 = 1; SPI_CLK8, SPI_CLK16, SPI_CLK32, SPI_CLK64, SPI_CLK128 } SPI_CLOCK; SPI_RET SpiInitMaster(SPI_CLOCK speed, SPI_PHASE phase, SPI_CLOCK_POL polarity, bool multi); The first three are obvious, while the last if true will causes a call to the call-back below immediately prior to initiating a transmission: SPI_RET spi_set_address(void); The application can use this to manage outputs for selecting different slaves. An error return will abort the transfer. If is false then this call-back is never called and the library will manage the SS pin. My opinion is that, if you are implementing a multi-master system then you had better roll you own. Thus the SS pin is initialised as, and should always remains as, an output. Note that SpiSetAddress can use SS if required - the library won't touch when is true. While awkward, the init call can be re-called for situations where multiple slaves have different clock requirements. The slave init call is as you would expect: SPI_RET SpiInitSlave(SPI_CLOCK speed, SPI_PHASE phase, SPI_CLOCK_POL polarity); The error returns are still to be defined and will be defined in the SPI_ERR enum. ========== Summary The calls are: SPI_RET SpiInitMaster(SPI_CLOCK speed, SPI_PHASE phase, SPI_CLOCK_POL polarity, bool multi); SPI_RET SpiInitSlave(SPI_CLOCK speed, SPI_PHASE phase, SPI_CLOCK_POL polarity); SPI_RET SpiMasterSend(int count, uint8* dataOut, uint8* dataIn, int delay); SPI_RET SpiSetSlave(int data); SPI_STATE SpiGetMasterState(void); The call-backs are: int SpiSlaveReceive(int data); void SpiSendDone(int flags); SPI_RET SpiSetAddress(void); A first draft, so no guarantees I have not missed something Ron From MAILER-DAEMON Tue Sep 22 07:59:40 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mq41z-0008Nk-Ru for mharc-avr-libc-corelib@gnu.org; Tue, 22 Sep 2009 07:59:39 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mq41y-0008MZ-EV for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 07:59:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mq41t-0008Lw-LX for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 07:59:38 -0400 Received: from [199.232.76.173] (port=39063 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mq41s-0008Lo-Vv for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 07:59:33 -0400 Received: from newsmtp5.atmel.com ([204.2.163.5]:24930 helo=sjogate2.atmel.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mq41s-0007Ma-CH for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 07:59:32 -0400 Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id n8MBvd0B025924; Tue, 22 Sep 2009 04:57:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Avr-libc-corelib] Why not consider also other libs than Procyon? Date: Tue, 22 Sep 2009 05:59:12 -0600 Message-ID: <258DDD1F44B6ED4AAFD4370847CF58D5081032BB@csomb01.corp.atmel.com> In-Reply-To: <4AB895F6.6050606@kuantic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Avr-libc-corelib] Why not consider also other libs than Procyon? Thread-Index: Aco7eu7h+fpGF1X4RnWst/F6yw+KWAAAKzew References: <4AB895F6.6050606@kuantic.com> From: "Weddington, Eric" To: =?iso-8859-1?Q?Bernard_Fouch=E9?= , X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 11:59:38 -0000 =20 > -----Original Message----- > From:=20 > avr-libc-corelib-bounces+eric.weddington=3Datmel.com@nongnu.org=20 > [mailto:avr-libc-corelib-bounces+eric.weddington=3Datmel.com@non > gnu.org] On Behalf Of Bernard Fouch=E9 > Sent: Tuesday, September 22, 2009 3:17 AM > To: avr-libc-corelib@nongnu.org > Subject: [Avr-libc-corelib] Why not consider also other libs=20 > than Procyon? >=20 > Hi List. >=20 > A while back, I asked Harald Kipp (NutOS maintainer) if it would be=20 > possible to take some code from NutOS and include it in avr-libc. His=20 > answer was 'yes'. At that time I was mainly considering time related=20 > functions and not drivers (and had no time to do the job :-( ). NutOS=20 > already has good drivers (for instance a good I2C driver interrupt=20 > driven), Harald answers to emails and licensing should not be=20 > an issue.=20 > Unfortunately I don't have any time to spare for this new=20 > 'corelib', so=20 > if someone of the 'corelib' project wants to contact Harald=20 > things could=20 > go faster than staying focused only on Procyon. Sure, I'll talk to Harald. Hopefully the licensing won't be an issue. =20 > Other sources could be Arduino (however I never used this=20 > project, so I=20 > don't know about drivers) and TinyOS. =20 No on TinyOS. They program in NestC which is their own C dialect. I = don't want this lib to be just for Arduino types. > (BTW, I reworked a few month ago John Regehr's stack.pl script (from=20 > TinyOS) to calculate stack usage of an application compiled with=20 > gcc-4.X, however John and I had also no time to perform more=20 > tests with=20 > the updated script (but in my opinion it works rather well=20 > and correctly=20 > locates patterns produced by the compiler). Could this be=20 > part of a set=20 > of tools provided with 'corelib'? If someone wants the=20 > updated script...) Well this is a bit off-topic, but: stacktool would not be a part of = corelib, it is its own tool, which I have been wanting to incorporate = into WinAVR. John Regehr and I know each other very well and communicate = on a semi-regular basis. His stacktool project needs more work before it = can be included in WinAVR. From MAILER-DAEMON Tue Sep 22 08:29:43 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mq4V4-0005KW-QJ for mharc-avr-libc-corelib@gnu.org; Tue, 22 Sep 2009 08:29:42 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mq4V2-0005IZ-HU for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 08:29:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mq4Uy-0005En-05 for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 08:29:40 -0400 Received: from [199.232.76.173] (port=37698 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mq4Ux-0005ET-M8 for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 08:29:35 -0400 Received: from mail1.freeserver.sk ([217.67.30.194]:61903) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mq4Ux-0003iY-9I for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 08:29:35 -0400 Received: from [91.127.72.181] (helo=TEST) by mail1.freeserver.sk with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mq4V0-000HYc-Hk; Tue, 22 Sep 2009 14:29:39 +0200 Message-ID: X-Mailer: Ultrafunk Popcorn 1.77 (19-July-2007) X-Priority: 3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Date: Tue, 22 Sep 2009 14:29:31 +0200 From: Jan Waclawek To: "Ron Kreymborg" , Subject: Re: [Avr-libc-corelib] The SPI implementation In-Reply-To: <000001ca3b4e$36838fc0$a38aaf40$@com.au> X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 12:29:40 -0000 >SPI_RET SpiMasterSend(int count, uint8* dataOut, uint8* dataIn, int delay); > [etc.] 1. we should use types defined in stdint.h, i.e. uint8_t for byte 2. int is inadequate for most purposes in 8-bitters JW From MAILER-DAEMON Tue Sep 22 08:59:38 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mq4y2-0000ly-GK for mharc-avr-libc-corelib@gnu.org; Tue, 22 Sep 2009 08:59:38 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mq4xz-0000kv-Q3 for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 08:59:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mq4xz-0000kH-9p for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 08:59:35 -0400 Received: from [199.232.76.173] (port=57430 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mq4xy-0000k7-Sr for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 08:59:35 -0400 Received: from ey-out-1920.google.com ([74.125.78.145]:21236) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mq4xy-0002UP-EL for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 08:59:34 -0400 Received: by ey-out-1920.google.com with SMTP id 13so923683eye.14 for ; Tue, 22 Sep 2009 05:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=erPSIAhZTWpxKZLgRZCCkPgrqeZgu7OQ5zJL1wxUuGk=; b=W3rmX2a3fdUAEF1Q/BQk+N8mz9j3Ut7v0js0rVJBkHm+ROX90CNKxFXvpUJcZzLcob iViXFz7OEMfRxad1qWrcrfCuEx4oet2YrSWArud3f9JG3So4TWHSfHLeKJ8CCgIpQry1 S4Ux3UyFIgUbM856YXQ64MxGFVq+O4qQ/5AhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=dfNLE0rt7qyirmhk3GyRQDrReM7mwl8+tWVUFZ0OV5NHxnxFGqiYK9EJ3wdipePIOj jckMxaSbZhRB5p2eAdLkE24JVMuIURXEzhBPoxrC/nrQp57TWBknQLcuVnGpVhAeVCjF 57XpqNiWy8wqhvX0qOmWpCMFWNKgYJT8wYvwA= MIME-Version: 1.0 Received: by 10.211.155.20 with SMTP id h20mr4551160ebo.44.1253624373269; Tue, 22 Sep 2009 05:59:33 -0700 (PDT) In-Reply-To: <000001ca3b4e$36838fc0$a38aaf40$@com.au> References: <000001ca3b4e$36838fc0$a38aaf40$@com.au> Date: Tue, 22 Sep 2009 08:59:33 -0400 Message-ID: <93ef05bc0909220559t2fa8be06q9d83dc6d32b1009c@mail.gmail.com> Subject: Re: [Avr-libc-corelib] The SPI implementation From: =?ISO-8859-1?Q?Fr=E9d=E9ric_Nadeau?= To: avr-libc-corelib@nongnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 12:59:36 -0000 Few comments: I would rather have spi_init(mode,CLOCK speed, SPI_PHASE phase, SPI_CLOCK_P= OL polarity); Than having two seperate init block that do most of the same thing, Missed SPI_CLK2 =3D 1, may not be available to all device though. But of course it can't be used if you just pass the value to the register. The rest I find great. I wrote a SPI device at, maybe one would want to steel something from there= . http://code.google.com/p/avr-drv/source/browse/trunk/SPI/spiDef.h http://code.google.com/p/avr-drv/source/browse/trunk/SPI/spi.h http://code.google.com/p/avr-drv/source/browse/trunk/SPI/spi.c but who as not writen one. --=20 Fr=E9d=E9ric Nadeau ing. jr From MAILER-DAEMON Tue Sep 22 21:44:11 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqGtv-0001EF-8R for mharc-avr-libc-corelib@gnu.org; Tue, 22 Sep 2009 21:44:11 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqFeg-000064-Te for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 20:24:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqFec-00005l-88 for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 20:24:22 -0400 Received: from [199.232.76.173] (port=49410 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqFec-00005i-2E for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 20:24:18 -0400 Received: from smtp-roam2.stanford.edu ([171.67.219.89]:55203 helo=smtp-roam.stanford.edu) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqFeb-00076J-Dj for avr-libc-corelib@nongnu.org; Tue, 22 Sep 2009 20:24:17 -0400 Received: from smtp-roam.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D45437798D for ; Tue, 22 Sep 2009 17:24:14 -0700 (PDT) Received: from mail-gx0-f225.google.com (mail-gx0-f225.google.com [209.85.217.225]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ruddick) by smtp-roam.stanford.edu (Postfix) with ESMTPSA id 1F5AC77984 for ; Tue, 22 Sep 2009 17:24:14 -0700 (PDT) Received: by gxk25 with SMTP id 25so28932gxk.16 for ; Tue, 22 Sep 2009 17:24:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.41.29 with SMTP id o29mr738800ago.101.1253665453136; Tue, 22 Sep 2009 17:24:13 -0700 (PDT) From: Ruddick Lawrence Date: Tue, 22 Sep 2009 17:23:53 -0700 Message-ID: <604fcf830909221723n19fa6cb6ic652efbeaa7a5a29@mail.gmail.com> To: avr-libc-corelib@nongnu.org Content-Type: multipart/alternative; boundary=0016361e83da005db4047433bc35 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Tue, 22 Sep 2009 21:44:10 -0400 Subject: [Avr-libc-corelib] proposed corelib style guide X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 00:24:23 -0000 --0016361e83da005db4047433bc35 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Based on the recent discussion, and some things that I find sensical, I have put together this proposed style guide. Please respond to the list with comments and additions. Certain stylistic decisions are just a matter of taste, so try to be aware of this when responding. Some decisions are to try to keep the code consistent with avr-libc code (speaking of which, is there already a style guide created for that?). Some of the following style doesn't make sense yet, or may change once we have a more detailed definition of the structure, but I always find it's easier to edit than to create, so this gives a starting point. My commentary is in square brackets. Ruddick =============== MODULES -Each module will have a short designation that is unique in corelib (ie, uart, timer, pwm) -The public API for each module should be in a single header file named after the module (ie, uart.h) [is this too restrictive?] FILES -File names should be lower-cased with words separated by underscores. -All files in a module should have the module name at the beginning of the filename (ie, uart.c, uart_calculations.h). -All files should have a standard header [which will be defined, probably with the BSD, contributors, etc] COMMENTS -Comments should conform to the Doxygen style [I think there's one already for avr-libc] -All functions should have a description of the arguments they take and the values they return FUNCTIONS -Function names should be lower-cased with words separated by underscores. -All public functions in a module should have the module name at the beginning of the filename (ie, uart_init(), spi_send()). -Private functions should be declared as static. [Do we want to prepend private functions with an underscore (ie, _my_private_function())?] VARIABLES -Variable names should be lower-cased with words separated by underscores. -Private variables should be declared as static. -No global variables [this was always hammered into me. Is it actually a good policy?] [Do we want to prepend private variables with an underscore (ie, _my_private_var)?] CONSTANTS -Constant names should be all upper-cased with words separated by underscores (ie, CONSTANT_DEFINITION) -Constant names should have the module name at the beginning (ie, UART_BAUD) [Do we actually want this?] [Do we want to specify when to use #define's and when to use enums? How about const?] DATA STRUCTURES -Data typedefs should be in camel case, with the first letter capitalized (ie, CamelCase) [This is pretty subjective, but I feel it distinguishes between a data type and an instance] -Data typedefs should end in _t (ie, LongTimer_t) -Any member variables should follow the rules specified above, under VARIABLES. --0016361e83da005db4047433bc35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Based on the recent discussion, and some things that I find = sensical, I have put together this proposed style guide. Please respond to = the list with comments and additions. Certain stylistic decisions are just = a matter of taste, so try to be aware of this when responding. Some decisio= ns are to try to keep the code consistent with avr-libc code (speaking of w= hich, is there already a style guide created for that?).

Some of the following style doesn't make sense yet, or may change o= nce we have a more detailed definition of the structure, but I always find = it's easier to edit than to create, so this gives a starting point. My = commentary is in square brackets.

Ruddick

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

MOD= ULES
-Each module will have a short designation that is unique in coreli= b (ie, uart, timer, pwm)
-The public API for each module should be in a = single header file named after the module (ie, uart.h) [is this too restric= tive?]

FILES
-File names should be lower-cased with words separated by unde= rscores.
-All files in a module should have the module name at the begin= ning of the filename (ie, uart.c, uart_calculations.h).
-All files shoul= d have a standard header [which will be defined, probably with the BSD, con= tributors, etc]

COMMENTS
-Comments should conform to the Doxygen style [I think there's one alre= ady for avr-libc]
-All functions should have a description of the argume= nts they take and the values they return

FUNCTIONS
-Function names should be lower-cased with words separated by underscores.<= br>-All public functions in a module should have the module name at the beg= inning of the filename (ie, uart_init(), spi_send()).
-Private functions= should be declared as static.
[Do we want to prepend private functions with an underscore (ie, _my_privat= e_function())?]

VARIABLES
-Variable names should be lower-cased w= ith words separated by underscores.
-Private variables should be declare= d as static.
-No global variables [this was always hammered into me. Is it actually a go= od policy?]
[Do we want to prepend private variables with an underscore (ie, _my_privat= e_var)?]

CONSTANTS
-Constant names should be all upper-cased with= words separated by underscores (ie, CONSTANT_DEFINITION)
-Constant names should have the module name at the beginning (ie, UART_BAUD= ) [Do we actually want this?]
[Do we want to specify when to use #define= 's and when to use enums? How about const?]

DATA STRUCTURES
-Data typedefs should be in camel case, with the first letter capitalized (= ie, CamelCase) [This is pretty subjective, but I feel it distinguishes betw= een a data type and an instance]
-Data typedefs should end in _t (ie, Lo= ngTimer_t)
-Any member variables should follow the rules specified above, under VARIAB= LES.


--0016361e83da005db4047433bc35-- From MAILER-DAEMON Wed Sep 23 01:19:43 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqKGU-00013D-So for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 01:19:43 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqKGS-000129-Vo for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 01:19:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqKGO-0000z0-Ba for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 01:19:40 -0400 Received: from [199.232.76.173] (port=56907 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqKGO-0000ys-6Q for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 01:19:36 -0400 Received: from sid6170.sslaccess.com ([202.125.37.67]:46488) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqKGN-0008VC-7n for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 01:19:35 -0400 Received: (qmail 28023 invoked from network); 23 Sep 2009 15:19:16 +1000 Received: from 202.63.38.189.static.rev.aanet.com.au (HELO DEVELOPMENT) (202.63.38.189) by sid6170.sslaccess.com with SMTP; 23 Sep 2009 15:19:10 +1000 From: "Ron Kreymborg" To: References: <000001ca3b4e$36838fc0$a38aaf40$@com.au> <93ef05bc0909220559t2fa8be06q9d83dc6d32b1009c@mail.gmail.com> In-Reply-To: <93ef05bc0909220559t2fa8be06q9d83dc6d32b1009c@mail.gmail.com> Subject: RE: [Avr-libc-corelib] The SPI implementation Date: Wed, 23 Sep 2009 15:18:37 +1000 Message-ID: <005001ca3c0d$626f4060$274dc120$@com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aco7hKHQ1u0BHREwR1e9gHS8SbOWbAAh8biA Content-Language: en-au X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 05:19:41 -0000 > I would rather have spi_init(mode,CLOCK speed, SPI_PHASE phase, > SPI_CLOCK_POL > polarity); > Than having two seperate init block that do most of the same thing, Well the master call would call the slave call in the library after setting the delay flag, so no duplication. > Missed SPI_CLK2 = 1, may not be available to all device though. But of > course it can't be used if you just pass the value to the register. No spi clock Fosc/2 as many spi slaves are only guaranteed to work at Fosc/4. Ron From MAILER-DAEMON Wed Sep 23 02:22:33 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqLFJ-0006p0-Hw for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 02:22:33 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqLFF-0006ni-TD for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:22:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqLFB-0006mN-8p for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:22:29 -0400 Received: from [199.232.76.173] (port=33948 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqLFA-0006m4-Na for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:22:24 -0400 Received: from smtp-roam1.stanford.edu ([171.67.219.88]:57190 helo=smtp-roam.stanford.edu) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqLFA-0004Ps-44 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:22:24 -0400 Received: from smtp-roam.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5739337D57 for ; Tue, 22 Sep 2009 23:22:22 -0700 (PDT) Received: from mail-yw0-f199.google.com (mail-yw0-f199.google.com [209.85.211.199]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ruddick) by smtp-roam.stanford.edu (Postfix) with ESMTPSA id 7ACA337D4E for ; Tue, 22 Sep 2009 23:22:21 -0700 (PDT) Received: by ywh37 with SMTP id 37so555868ywh.4 for ; Tue, 22 Sep 2009 23:22:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.141.6 with SMTP id t6mr1119329agn.49.1253686940563; Tue, 22 Sep 2009 23:22:20 -0700 (PDT) In-Reply-To: <604fcf830909221723n19fa6cb6ic652efbeaa7a5a29@mail.gmail.com> References: <604fcf830909221723n19fa6cb6ic652efbeaa7a5a29@mail.gmail.com> From: Ruddick Lawrence Date: Tue, 22 Sep 2009 23:21:59 -0700 Message-ID: <604fcf830909222321p1549476ckbaed093e26a718d1@mail.gmail.com> To: avr-libc-corelib@nongnu.org Content-Type: multipart/alternative; boundary=0016e6470eecc089f0047438bc98 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: [Avr-libc-corelib] Re: proposed corelib style guide X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 06:22:30 -0000 --0016e6470eecc089f0047438bc98 Content-Type: text/plain; charset=ISO-8859-1 Another category I just thought of that we should probably add: INITIALIZATION -If a module has any initialization code, it should go in a function with the module name prepended onto _init (ie, uart_init()) -Init functions should not enable global interrupts [pro: developer has more control, and interrupts will only happen after everything is set up; con: subsytems don't "go" as soon as they are set up] -All registers that the initialization function modifies should follow the read/modify/write paradigm to avoid overwriting other parts of the register [Do we want some way to tell if two init functions will conflict (ie, trying to use the same timer with both PWM and output compare)? I guess this goes back to determining the uses of each pin for each AVR model] On Tue, Sep 22, 2009 at 5:23 PM, Ruddick Lawrence wrote: > Hi all, > > Based on the recent discussion, and some things that I find sensical, I > have put together this proposed style guide. Please respond to the list with > comments and additions. Certain stylistic decisions are just a matter of > taste, so try to be aware of this when responding. Some decisions are to try > to keep the code consistent with avr-libc code (speaking of which, is there > already a style guide created for that?). > > Some of the following style doesn't make sense yet, or may change once we > have a more detailed definition of the structure, but I always find it's > easier to edit than to create, so this gives a starting point. My commentary > is in square brackets. > > Ruddick > > =============== > > MODULES > -Each module will have a short designation that is unique in corelib (ie, > uart, timer, pwm) > -The public API for each module should be in a single header file named > after the module (ie, uart.h) [is this too restrictive?] > > FILES > -File names should be lower-cased with words separated by underscores. > -All files in a module should have the module name at the beginning of the > filename (ie, uart.c, uart_calculations.h). > -All files should have a standard header [which will be defined, probably > with the BSD, contributors, etc] > > COMMENTS > -Comments should conform to the Doxygen style [I think there's one already > for avr-libc] > -All functions should have a description of the arguments they take and the > values they return > > FUNCTIONS > -Function names should be lower-cased with words separated by underscores. > -All public functions in a module should have the module name at the > beginning of the filename (ie, uart_init(), spi_send()). > -Private functions should be declared as static. > [Do we want to prepend private functions with an underscore (ie, > _my_private_function())?] > > VARIABLES > -Variable names should be lower-cased with words separated by underscores. > -Private variables should be declared as static. > -No global variables [this was always hammered into me. Is it actually a > good policy?] > [Do we want to prepend private variables with an underscore (ie, > _my_private_var)?] > > CONSTANTS > -Constant names should be all upper-cased with words separated by > underscores (ie, CONSTANT_DEFINITION) > -Constant names should have the module name at the beginning (ie, > UART_BAUD) [Do we actually want this?] > [Do we want to specify when to use #define's and when to use enums? How > about const?] > > DATA STRUCTURES > -Data typedefs should be in camel case, with the first letter capitalized > (ie, CamelCase) [This is pretty subjective, but I feel it distinguishes > between a data type and an instance] > -Data typedefs should end in _t (ie, LongTimer_t) > -Any member variables should follow the rules specified above, under > VARIABLES. > > > --0016e6470eecc089f0047438bc98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Another category I just thought of that we= should probably add:

INITIALIZATION
-If a module has any i= nitialization code, it should go in a function with the module name prepend= ed onto _init (ie, uart_init())
-Init functions should not enable global interrupts [pro: developer has mor= e control, and interrupts will only happen after everything is set up; con:= subsytems don't "go" as soon as they are set up]
-All reg= isters that the initialization function modifies should follow the read/mod= ify/write paradigm to avoid overwriting other parts of the register
[Do we want some way to tell if two init functions will conflict (ie, tryin= g to use the same timer with both PWM and output compare)? I guess this goe= s back to determining the uses of each pin for each AVR model]

On Tue, Sep 22, 2009 at 5:23 PM, Ruddick Lawrence <ruddick@stanford.edu> wr= ote:
Hi all,

Based on the recent discussion, and some things that I find = sensical, I have put together this proposed style guide. Please respond to = the list with comments and additions. Certain stylistic decisions are just = a matter of taste, so try to be aware of this when responding. Some decisio= ns are to try to keep the code consistent with avr-libc code (speaking of w= hich, is there already a style guide created for that?).

Some of the following style doesn't make sense yet, or may change o= nce we have a more detailed definition of the structure, but I always find = it's easier to edit than to create, so this gives a starting point. My = commentary is in square brackets.

Ruddick

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

MOD= ULES
-Each module will have a short designation that is unique in coreli= b (ie, uart, timer, pwm)
-The public API for each module should be in a = single header file named after the module (ie, uart.h) [is this too restric= tive?]

FILES
-File names should be lower-cased with words separated by unde= rscores.
-All files in a module should have the module name at the begin= ning of the filename (ie, uart.c, uart_calculations.h).
-All files shoul= d have a standard header [which will be defined, probably with the BSD, con= tributors, etc]

COMMENTS
-Comments should conform to the Doxygen style [I think there's one alre= ady for avr-libc]
-All functions should have a description of the argume= nts they take and the values they return

FUNCTIONS
-Function names should be lower-cased with words separated by underscores.<= br>-All public functions in a module should have the module name at the beg= inning of the filename (ie, uart_init(), spi_send()).
-Private functions= should be declared as static.
[Do we want to prepend private functions with an underscore (ie, _my_privat= e_function())?]

VARIABLES
-Variable names should be lower-cased w= ith words separated by underscores.
-Private variables should be declare= d as static.
-No global variables [this was always hammered into me. Is it actually a go= od policy?]
[Do we want to prepend private variables with an underscore (ie, _my_privat= e_var)?]

CONSTANTS
-Constant names should be all upper-cased with= words separated by underscores (ie, CONSTANT_DEFINITION)
-Constant names should have the module name at the beginning (ie, UART_BAUD= ) [Do we actually want this?]
[Do we want to specify when to use #define= 's and when to use enums? How about const?]

DATA STRUCTURES
-Data typedefs should be in camel case, with the first letter capitalized (= ie, CamelCase) [This is pretty subjective, but I feel it distinguishes betw= een a data type and an instance]
-Data typedefs should end in _t (ie, Lo= ngTimer_t)
-Any member variables should follow the rules specified above, under VARIAB= LES.



--0016e6470eecc089f0047438bc98-- From MAILER-DAEMON Wed Sep 23 02:24:33 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqLHF-0007qE-QN for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 02:24:33 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqLHE-0007pQ-DK for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:24:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqLH9-0007mk-BM for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:24:31 -0400 Received: from [199.232.76.173] (port=57334 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqLH9-0007mh-3w for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:24:27 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.125]:57908) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqLH8-0004gM-TX for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:24:27 -0400 Received: from [127.0.0.1] (really [66.68.23.44]) by hrndva-omta01.mail.rr.com with ESMTP id <20090923062426095.DVDR29486@hrndva-omta01.mail.rr.com> for ; Wed, 23 Sep 2009 06:24:26 +0000 Message-ID: <4AB9BF16.7070706@oakmicros.com> Date: Wed, 23 Sep 2009 01:24:22 -0500 From: Mike Perks User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: avr-libc-corelib@nongnu.org Subject: Re: [Avr-libc-corelib] proposed corelib style guide Content-Type: multipart/alternative; boundary="------------060503090905020003040104" X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (1203?) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 06:24:32 -0000 This is a multi-part message in MIME format. --------------060503090905020003040104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ruddick, This is a good start. I agree with most of what you have said except the following: 1. We need to define what to do with functions defined via macros. Macros in the .h file are public by definition and macros in the .c file are private. Macros in c files should probably never be used and substituted with static functions, possibly inlined 2. There are several rules for typedefs in avr-libc. Probably the most consistent with what we already have is a lower case words with underscore and a simple suffix of _t e.g. clock_div_t The only other question is when to use #defines, enums and const values. The first two are rvalues. A const value is a non-modifiable lvalue and the compiler may reserve storage for it e.g. int const N = 100; int const *p = &N; // ok ** However most people are probably not going to write this type of code. Defines do not have scope restrictions whereas enums and consts do. I think we should use the simplest definitions in header files (#defines) and possibly some enums for a grouping of values. Inside an implementation then people should use enums and consts. Again enums for a logical grouping such as a state indicator and consts for individual constants such as a buffer size. Mike Perks Oak Micros (oakmicros.com) --------------060503090905020003040104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ruddick,

<posting to correct list this time>

This is a good start. I agree with most of what you have said except the following:

1. We need to define what to do with functions defined via macros. Macros in the .h file are public by definition and macros in the .c file are private. Macros in c files should probably never be used and substituted with static functions, possibly inlined
2. There are several rules for typedefs in avr-libc. Probably the most consistent with what we already have is a lower case words with underscore and a simple suffix of _t e.g. clock_div_t

The only other question is when to use #defines, enums and const values. The first two are rvalues. A const value is a non-modifiable lvalue and the compiler may reserve storage for it e.g.
    int const N = 100;
    int const *p = &N;    // ok

However most people are probably not going to write this type of code. Defines do not have scope restrictions whereas enums and consts do.

I think we should use the simplest definitions in header files (#defines) and possibly some enums for a grouping of values. Inside an implementation then people should use enums and consts. Again enums for a logical grouping such as a state indicator and consts for individual constants such as a buffer size.

Mike Perks
Oak Micros (oakmicros.com)

--------------060503090905020003040104-- From MAILER-DAEMON Wed Sep 23 02:25:51 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqLIV-000873-6H for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 02:25:51 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqLIS-00086P-Rm for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:25:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqLIM-00086B-N1 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:25:46 -0400 Received: from [199.232.76.173] (port=57338 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqLIM-000868-I1 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:25:42 -0400 Received: from sid6170.sslaccess.com ([202.125.37.67]:40405) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqLIL-0004nr-Le for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:25:42 -0400 Received: (qmail 11726 invoked from network); 23 Sep 2009 16:25:35 +1000 Received: from 202.63.38.189.static.rev.aanet.com.au (HELO DEVELOPMENT) (202.63.38.189) by sid6170.sslaccess.com with SMTP; 23 Sep 2009 16:25:35 +1000 From: "Ron Kreymborg" To: Date: Wed, 23 Sep 2009 16:25:06 +1000 Message-ID: <005101ca3c16$a9f31e30$fdd95a90$@com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aco8Fpc6uJ3r6+LaRReiaPSunWEmgQ== Content-Language: en-au X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: [Avr-libc-corelib] proposed corelib style guide X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 06:25:50 -0000 A few points of difference: FUNCTIONS I have mentioned elsewhere that corelib can use both camels and underscores with little effort. There are enough of us who use the former and abhor the latter that I for one am prepared to include both so I can eventually use the library without grinding my teeth at every function. VARIABLES Let's not prepend or append private functions with anything. Making them static hides them away from other modules. We can't say at this time that we will never have a global variable, and I agree including one will need a strong argument. However at this stage the ones I can think of can be covered by call-backs, eg void GetClockFrequency(long crystal); Thinking of call-back, is there some gcc modifier that allows for definition of a "weak" function? This would allow call-backs to be instanced in the library as null functions and save the user from creating an instance in their code just to satisfy the linker when they have no need for it. Hmmm. Or does that invite problems? CONSTANTS I am ambivalent about always pre-pending the module name to constants. Perhaps for defines within the code (and thus private) needs not, but it may be a requirement for public module constants as similar names will probably come up as the library develops. DATA STRUCTURES Oh dear. It's a pity we didn't all go to the same School for Programmers. I name a type definition in upper case and instances in camel (where did this "camel" come from?). However I agree exposed typedefs should conform to a style. Please let's not add stuff like _t to names - what's the point? Ron From MAILER-DAEMON Wed Sep 23 02:34:31 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqLQt-0003sr-9Q for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 02:34:31 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqLQs-0003rz-5d for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:34:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqLQm-0003oo-MU for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:34:28 -0400 Received: from [199.232.76.173] (port=42867 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqLQm-0003ol-Df for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:34:24 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.125]:59417) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqLQm-0006SZ-7Z for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:34:24 -0400 Received: from [127.0.0.1] (really [66.68.23.44]) by hrndva-omta01.mail.rr.com with ESMTP id <20090923063423595.DXKK29486@hrndva-omta01.mail.rr.com> for ; Wed, 23 Sep 2009 06:34:23 +0000 Message-ID: <4AB9C16B.8080406@oakmicros.com> Date: Wed, 23 Sep 2009 01:34:19 -0500 From: Mike Perks User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: avr-libc-corelib@nongnu.org Subject: Re: [Avr-libc-corelib] proposed corelib style guide References: <005101ca3c16$a9f31e30$fdd95a90$@com.au> In-Reply-To: <005101ca3c16$a9f31e30$fdd95a90$@com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (1203?) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 06:34:30 -0000 Ron > Oh dear. It's a pity we didn't all go to the same School for Programmers. I > name a type definition in upper case and instances in camel (where did this > "camel" come from?). However I agree exposed typedefs should conform to a > style. Please let's not add stuff like _t to names - what's the point? > We all come from different backgrounds and different coding standards. I believe we established for this project that we would be consistent with avr-libc even though some of us don't particularly like it's coding conventions (me included). In the name of making progress I understand this and am willing to live with it. The _t is a standard naming convention that other people use (including avr-libc). Mike Perks Oak Micros (oakmicros.com) From MAILER-DAEMON Wed Sep 23 02:51:51 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqLhe-0001Tf-VE for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 02:51:50 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqLhd-0001TD-ED for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:51:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqLhY-0001S8-Td for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:51:48 -0400 Received: from [199.232.76.173] (port=57266 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqLhY-0001S5-Ng for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:51:44 -0400 Received: from mx20.gnu.org ([199.232.41.8]:61242) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqLhY-0000yo-6D for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:51:44 -0400 Received: from mail1.freeserver.sk ([217.67.30.194]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqLhS-0005WN-DS for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 02:51:38 -0400 Received: from [91.127.72.181] (helo=TEST) by mail1.freeserver.sk with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MqLhM-000Ixk-W6; Wed, 23 Sep 2009 08:51:33 +0200 Message-ID: X-Mailer: Ultrafunk Popcorn 1.77 (19-July-2007) X-Priority: 3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 23 Sep 2009 08:51:25 +0200 From: Jan Waclawek To: Ruddick Lawrence , avr-libc-corelib@nongnu.org Subject: Re: [Avr-libc-corelib] proposed corelib style guide In-Reply-To: <604fcf830909221723n19fa6cb6ic652efbeaa7a5a29@mail.gmail.com> X-detected-operating-system: by mx20.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 06:51:49 -0000 I would add (from the user's viewpoint): MODULES - Each module will have a usage guideline and a comprehensible example of use I would anticipate that users will copy the library files to their projects, potentially modifying them, rather than use a pre-built library or such. So the usage guideline should include a method how to add all that's necessary into a makefile, preferrably "compatible" with mfile's "standard" output (or shall we attempt to expand mfile's capabilities accordingly?) JW From MAILER-DAEMON Wed Sep 23 03:52:16 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqMe7-0003kd-Vk for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 03:52:16 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqMe5-0003jD-JL for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:52:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqMe0-0003gA-7G for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:52:13 -0400 Received: from [199.232.76.173] (port=53417 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqMe0-0003g5-2N for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:52:08 -0400 Received: from mx20.gnu.org ([199.232.41.8]:1094) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqMdz-0008IL-AD for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:52:07 -0400 Received: from sid6170.sslaccess.com ([202.125.37.67]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqMdx-00010Q-NK for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:52:06 -0400 Received: (qmail 28006 invoked from network); 23 Sep 2009 17:51:24 +1000 Received: from 202.63.38.189.static.rev.aanet.com.au (HELO DEVELOPMENT) (202.63.38.189) by sid6170.sslaccess.com with SMTP; 23 Sep 2009 17:51:24 +1000 From: "Ron Kreymborg" To: References: <005101ca3c16$a9f31e30$fdd95a90$@com.au> In-Reply-To: <005101ca3c16$a9f31e30$fdd95a90$@com.au> Subject: RE: [Avr-libc-corelib] proposed corelib style guide Date: Wed, 23 Sep 2009 17:50:54 +1000 Message-ID: <000901ca3c22$a6b90b60$f42b2220$@com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aco8Fpc6uJ3r6+LaRReiaPSunWEmgQAC1Pzg Content-Language: en-au X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 07:52:14 -0000 > void GetClockFrequency(long crystal); Of course this should be: long GetClockFrequency(void): > Thinking of call-back, is there some gcc modifier that allows for > definition > of a "weak" function? This would allow call-backs to be instanced in > the > library as null functions and save the user from creating an instance > in > their code just to satisfy the linker when they have no need for it. > Hmmm. > Or does that invite problems? Answering myself, I just built a quick test library and gcc's __attribute__ ((weak)) works fine. My question could be answered by the weak version returning something or doing something impossible, which the library could use to define an error. This probably needs more thought... Ron From MAILER-DAEMON Wed Sep 23 04:00:55 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqMmV-0007Av-EE for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 04:00:55 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqMmT-0007Ag-R8 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:00:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqMmP-00077M-Dd for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:00:53 -0400 Received: from [199.232.76.173] (port=56688 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqMmP-00077J-1C for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:00:49 -0400 Received: from mx20.gnu.org ([199.232.41.8]:2242) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqMmN-0000zG-D9 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:00:47 -0400 Received: from smtp-roam2.stanford.edu ([171.67.219.89] helo=smtp-roam.stanford.edu) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqMmM-0001Ze-0B for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:00:46 -0400 Received: from smtp-roam.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A400D779E3 for ; Wed, 23 Sep 2009 01:00:42 -0700 (PDT) Received: from mail-yx0-f173.google.com (mail-yx0-f173.google.com [209.85.210.173]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ruddick) by smtp-roam.stanford.edu (Postfix) with ESMTPSA id 0DF10779BF for ; Wed, 23 Sep 2009 01:00:41 -0700 (PDT) Received: by yxe3 with SMTP id 3so611098yxe.4 for ; Wed, 23 Sep 2009 01:00:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.141.6 with SMTP id t6mr1169912agn.49.1253692841083; Wed, 23 Sep 2009 01:00:41 -0700 (PDT) In-Reply-To: <4AB9CEC2.7090202@westcontrol.com> References: <4AB9CEC2.7090202@westcontrol.com> From: Ruddick Lawrence Date: Wed, 23 Sep 2009 01:00:21 -0700 Message-ID: <604fcf830909230100u43062a1djab47f2288a0c7de5@mail.gmail.com> Subject: Re: [Avr-libc-corelib] proposed corelib style guide To: David Brown Content-Type: multipart/alternative; boundary=0016e6470eec73426604743a1c17 X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: avr-libc-corelib@nongnu.org X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 08:00:54 -0000 --0016e6470eec73426604743a1c17 Content-Type: text/plain; charset=ISO-8859-1 We may want to divide the style guide into two sections: code and comments (then we could also do a brief outline of using doxygen). I think having very detailed guidelines is good, but we have to be careful how we present them. All "stable" code should follow the guidelines to the T, but we don't want to scare off potential developers/contributors by making the learning curve to develop too high. A good module that only follows half of the guidelines is a better start than no module at all. On Wed, Sep 23, 2009 at 12:31 AM, David Brown wrote: > Jan Waclawek wrote: > >> I would add (from the user's viewpoint): >> >> MODULES - Each module will have a usage guideline and a >> comprehensible example of use >> >> I would anticipate that users will copy the library files to their >> projects, potentially modifying them, rather than use a pre-built >> library or such. So the usage guideline should include a method how >> to add all that's necessary into a makefile, preferrably "compatible" >> with mfile's "standard" output (or shall we attempt to expand mfile's >> capabilities accordingly?) >> >> > Given that people will copy the files into their projects, it's also > important to make it clear how different modules interact, and what files > are part of each module. It might make sense to have modules within their > own directory - thus making it as easy as possible to see exactly what is > needed. The directories could also contain test or example code (test code > discussions should probably be a new topic). > > Sharing between modules should be done when it is beneficial, but only if > it really is beneficial. For example, just because the SPI and Uart modules > both use ring buffers, does not mean there should be a separate ringbuffer > module that is required for each of them. On the other hand, if someone > writes a great memory pool manager, then a module for implementing web > servers should take advantage of it. > > Since we expect users to copy files into their projects, it is important to > remember that there are no private, internal implementation files. There > will always need to be a higher standard of commenting, reader-friendliness > and style consistency for "interface" files (i.e., uart.h) than for the > implementation files (it is not a big deal if a static variable is named > camelCaps rather than camel_caps). But every file will need a consistent > comment block at the start with fields for module summary, copyright and > licensing, version and revision information, etc. There should also be a > comment field specifically for "customisation history". It is very easy for > users to forget to add such information at the top of a file they modify, > causing confusion later if someone else wants to update the module. By > explicitly adding such a field, we give them an extra reminder. > > mvh., > > David > --0016e6470eec73426604743a1c17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We may want to divide the style guide into two sections: code and comments = (then we could also do a brief outline of using doxygen).

I think ha= ving very detailed guidelines is good, but we have to be careful how we pre= sent them. All "stable" code should follow the guidelines to the = T, but we don't want to scare off potential developers/contributors by = making the learning curve to develop too high. A good module that only foll= ows half of the guidelines is a better start than no module at all.

On Wed, Sep 23, 2009 at 12:31 AM, David Brow= n <david@west= control.com> wrote:
Jan Waclawek wrote:
I would add (from the user's viewpoint):

MODULES - Each module will have a usage guideline and a
comprehensible example of use

I would anticipate that users will copy the library files to their
projects, potentially modifying them, rather than use a pre-built
library or such. So the usage guideline should include a method how
to add all that's necessary into a makefile, preferrably "compatib= le"
with mfile's "standard" output (or shall we attempt to expand= mfile's
capabilities accordingly?)


Given that people will copy the files into their projects, it's also im= portant to make it clear how different modules interact, and what files are= part of each module. =A0It might make sense to have modules within their o= wn directory - thus making it as easy as possible to see exactly what is ne= eded. =A0The directories could also contain test or example code (test code= discussions should probably be a new topic).

Sharing between modules should be done when it is beneficial, but only if i= t really is beneficial. =A0For example, just because the SPI and Uart modul= es both use ring buffers, does not mean there should be a separate ringbuff= er module that is required for each of them. =A0On the other hand, if someo= ne writes a great memory pool manager, then a module for implementing web s= ervers should take advantage of it.

Since we expect users to copy files into their projects, it is important to= remember that there are no private, internal implementation files. There w= ill always need to be a higher standard of commenting, reader-friendliness = and style consistency for "interface" files (i.e., uart.h) than f= or the implementation files (it is not a big deal if a static variable is n= amed camelCaps rather than camel_caps). =A0But every file will need a consi= stent comment block at the start with fields for module summary, copyright = and licensing, version and revision information, etc. =A0There should also = be a comment field specifically for "customisation history". =A0I= t is very easy for users to forget to add such information at the top of a = file they modify, causing confusion later if someone else wants to update t= he module. =A0By explicitly adding such a field, we give them an extra remi= nder.

mvh.,

David

--0016e6470eec73426604743a1c17-- From MAILER-DAEMON Wed Sep 23 04:09:43 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqMv1-0001AD-FV for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 04:09:43 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqMv0-000182-1M for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:09:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqMuv-000119-3g for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:09:41 -0400 Received: from [199.232.76.173] (port=59879 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqMuu-00010r-V8 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:09:36 -0400 Received: from mx20.gnu.org ([199.232.41.8]:2847) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqMuu-0002EX-F5 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:09:36 -0400 Received: from sid6170.sslaccess.com ([202.125.37.67]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqMut-0002Aj-Dk for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:09:36 -0400 Received: (qmail 31755 invoked from network); 23 Sep 2009 18:09:32 +1000 Received: from 202.63.38.189.static.rev.aanet.com.au (HELO DEVELOPMENT) (202.63.38.189) by sid6170.sslaccess.com with SMTP; 23 Sep 2009 18:09:31 +1000 From: "Ron Kreymborg" To: References: <604fcf830909221723n19fa6cb6ic652efbeaa7a5a29@mail.gmail.com> In-Reply-To: Subject: RE: [Avr-libc-corelib] proposed corelib style guide Date: Wed, 23 Sep 2009 18:09:02 +1000 Message-ID: <000e01ca3c25$2eea1630$8cbe4290$@com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aco8GlZocC7tlfaaQeyF3m3cMhSumQACTQkA Content-Language: en-au X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 08:09:42 -0000 > I would add (from the user's viewpoint): > > MODULES > - Each module will have a usage guideline and a comprehensible example > of use > > I would anticipate that users will copy the library files to their > projects, potentially modifying them, rather than use a pre-built > library or such. > So the usage guideline should include a method how to add all that's > necessary into a makefile, preferrably "compatible" with mfile's > "standard" output (or shall we attempt to expand mfile's capabilities > accordingly?) > > JW As I understand it, the library will be a pre-compiled lib file, with the MCU name in the makefile linking to the matching version for that processor. Maintaining a source version would be nigh on impossible. Imagine: "I increased the buffer limit and changed the speed setting and now my app resets about every 5 minutes. Help!". I suggested earlier that the current source be available (not necessarily with an avr-avr release but perhaps on a web site somewhere) after the library is also released in its current final version. This would be "modify at your own risk". Any other suggestions? Certainly there will be at least one example for each module. Ron From MAILER-DAEMON Wed Sep 23 04:19:46 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqN4k-0004sx-Bt for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 04:19:46 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqN4i-0004qS-H5 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:19:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqN4e-0004p0-TX for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:19:44 -0400 Received: from [199.232.76.173] (port=36058 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqN4e-0004ox-R4 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:19:40 -0400 Received: from smtp-roam2.stanford.edu ([171.67.219.89]:47565 helo=smtp-roam.stanford.edu) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqN4e-0003vp-63 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 04:19:40 -0400 Received: from smtp-roam.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6DE9577A40 for ; Wed, 23 Sep 2009 01:19:38 -0700 (PDT) Received: from mail-yx0-f173.google.com (mail-yx0-f173.google.com [209.85.210.173]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ruddick) by smtp-roam.stanford.edu (Postfix) with ESMTPSA id E772577A3D for ; Wed, 23 Sep 2009 01:19:37 -0700 (PDT) Received: by yxe3 with SMTP id 3so620884yxe.4 for ; Wed, 23 Sep 2009 01:19:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.122.11 with SMTP id z11mr1168776agm.111.1253693977090; Wed, 23 Sep 2009 01:19:37 -0700 (PDT) In-Reply-To: <000e01ca3c25$2eea1630$8cbe4290$@com.au> References: <604fcf830909221723n19fa6cb6ic652efbeaa7a5a29@mail.gmail.com> <000e01ca3c25$2eea1630$8cbe4290$@com.au> From: Ruddick Lawrence Date: Wed, 23 Sep 2009 01:19:17 -0700 Message-ID: <604fcf830909230119p78617013hf4e07963a9f3a67f@mail.gmail.com> Subject: Re: [Avr-libc-corelib] proposed corelib style guide To: Ron Kreymborg Content-Type: multipart/alternative; boundary=0016e646a326295b5c04743a6065 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: avr-libc-corelib@nongnu.org X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 08:19:44 -0000 --0016e646a326295b5c04743a6065 Content-Type: text/plain; charset=ISO-8859-1 I agree that we should not officially "support" a source version, but I do not think we should explicitly discourage or make it overly hard for people to get the source code (I'm pretty sure you can allow anonymous check outs with CVS, and Doxygen can generate pretty code webpages for each file). I bet most of us started out as hackers, and it really helps to find source code that does ALMOST what you want, and be able to figure out where you can modify it for your specific purposes. I see our responsibility as commenting the code (even private) well, and making sure people can find the source. Beyond that it's definitely "at your own risk." On Wed, Sep 23, 2009 at 1:09 AM, Ron Kreymborg wrote: > > > I would add (from the user's viewpoint): > > > > MODULES > > - Each module will have a usage guideline and a comprehensible example > > of use > > > > I would anticipate that users will copy the library files to their > > projects, potentially modifying them, rather than use a pre-built > > library or such. > > So the usage guideline should include a method how to add all that's > > necessary into a makefile, preferrably "compatible" with mfile's > > "standard" output (or shall we attempt to expand mfile's capabilities > > accordingly?) > > > > JW > > As I understand it, the library will be a pre-compiled lib file, with the > MCU name in the makefile linking to the matching version for that > processor. > Maintaining a source version would be nigh on impossible. Imagine: "I > increased the buffer limit and changed the speed setting and now my app > resets about every 5 minutes. Help!". > > I suggested earlier that the current source be available (not necessarily > with an avr-avr release but perhaps on a web site somewhere) after the > library is also released in its current final version. This would be > "modify > at your own risk". Any other suggestions? > > Certainly there will be at least one example for each module. > > Ron > > > > > --0016e646a326295b5c04743a6065 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree that we should not officially "support" a source version,= but I do not think we should explicitly discourage or make it overly hard = for people to get the source code (I'm pretty sure you can allow anonym= ous check outs with CVS, and Doxygen can generate pretty code webpages for = each file). I bet most of us started out as hackers, and it really helps to= find source code that does ALMOST what you want, and be able to figure out= where you can modify it for your specific purposes.

I see our responsibility as commenting the code (even private) well, an= d making sure people can find the source. Beyond that it's definitely &= quot;at your own risk."

On Wed, Sep = 23, 2009 at 1:09 AM, Ron Kreymborg <ron@jennaron.com.au> wrote:
<= div class=3D"h5">
> I would add (from the user's viewpoint):
>
> MODULES
> - Each module will have a usage guideline and a comprehensible example=
> of use
>
> I would anticipate that users will copy the library files to their
> projects, potentially modifying them, rather than use a pre-built
> library or such.
> So the usage guideline should include a method how to add all that'= ;s
> necessary into a makefile, preferrably "compatible" with mfi= le's
> "standard" output (or shall we attempt to expand mfile's= capabilities
> accordingly?)
>
> JW

As I understand it, the library will be a pre-compiled lib file= , with the
MCU name in the makefile linking to the matching version for that processor= .
Maintaining a source version would be nigh on impossible. Imagine: "I<= br> increased the buffer limit and changed the speed setting and now my app
resets about every 5 minutes. Help!".

I suggested earlier that the current source be available (not necessarily with an avr-avr release but perhaps on a web site somewhere) after the
library is also released in its current final version. This would be "= modify
at your own risk". Any other suggestions?

Certainly there will be at least one example for each module.

Ron





--0016e646a326295b5c04743a6065-- From MAILER-DAEMON Wed Sep 23 06:21:04 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqOy8-0001zM-AS for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 06:21:04 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqOy5-0001y6-V4 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 06:21:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqOy1-0001vO-KC for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 06:21:01 -0400 Received: from [199.232.76.173] (port=33560 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqOy1-0001vD-Az for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 06:20:57 -0400 Received: from mail1.freeserver.sk ([217.67.30.194]:61452) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqOy0-0000j7-Us for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 06:20:57 -0400 Received: from [91.127.72.181] (helo=TEST) by mail1.freeserver.sk with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MqOy1-0001YD-Dt; Wed, 23 Sep 2009 12:20:57 +0200 Message-ID: X-Mailer: Ultrafunk Popcorn 1.77 (19-July-2007) X-Priority: 3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 23 Sep 2009 12:20:49 +0200 From: Jan Waclawek To: "Ron Kreymborg" , Subject: RE: [Avr-libc-corelib] proposed corelib style guide In-Reply-To: <000e01ca3c25$2eea1630$8cbe4290$@com.au> X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 10:21:02 -0000 >> I would anticipate that users will copy the library files to their >> projects, potentially modifying them, rather than use a pre-built >> library or such. >> So the usage guideline should include a method how to add all that's >> necessary into a makefile, preferrably "compatible" with mfile's >> "standard" output (or shall we attempt to expand mfile's capabilities >> accordingly?) >> > >As I understand it, the library will be a pre-compiled lib file, with the >MCU name in the makefile linking to the matching version for that processor. Making things bulletproof usually makes them way too rigid and heavyweight. And then they are far from being perfect. Although this would need to be confirmed by a poll or similar, I assume that most users of the Procyon library make modifications to it at some point anyway. >Maintaining a source version would be nigh on impossible. Imagine: "I >increased the buffer limit and changed the speed setting and now my app >resets about every 5 minutes. Help!". Contrary: this might give good pointers to further development of the library. JW From MAILER-DAEMON Wed Sep 23 08:44:04 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqRCV-0005c0-Bf for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 08:44:03 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqRCQ-0005bq-BE for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 08:43:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqRCL-0005bd-0V for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 08:43:57 -0400 Received: from [199.232.76.173] (port=42700 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqRCK-0005ba-Mh for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 08:43:52 -0400 Received: from mx20.gnu.org ([199.232.41.8]:16668) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqRCK-0003qC-89 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 08:43:52 -0400 Received: from mail-ew0-f206.google.com ([209.85.219.206]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqRCI-0005R3-N7 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 08:43:50 -0400 Received: by ewy2 with SMTP id 2so662825ewy.34 for ; Wed, 23 Sep 2009 05:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=06Vc0r2znIi/QiT3wueMd1d5OUu/2koeniaddAs/QWk=; b=AM3MI62UuBhARnztNXnSR1TUHaeuuprNS7oVptir24CL1bl8DBiGU8zaexjIQBXCnj 25WKQUR8Kg6zZ3DH2fVi8deLwBrUwotqZK7RMfweOkZcGa1curGUeDMpT3wkirafgJN5 /TfX3CzfZZtJXEhiJtbG1O9cTizLm+U4zsZFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=v2gE5DA4s6Xb6iEInU1ASSytvt6Tom9bWJyrubJ9jG4Gw5ue8c44ohX6H5gAd4PqWb zXw3CbrkcXpfLOgsThjS3irNwm7dx2BRwsMiT1ab29Gts8Lx/jxy1Sw6a8zFJHwyBZ+r bY2OiG7yEpunZxi7LqQnOaHbpIK7tEi56pcRE= MIME-Version: 1.0 Received: by 10.211.153.14 with SMTP id f14mr2533715ebo.36.1253709828639; Wed, 23 Sep 2009 05:43:48 -0700 (PDT) In-Reply-To: <005001ca3c0d$626f4060$274dc120$@com.au> References: <000001ca3b4e$36838fc0$a38aaf40$@com.au> <93ef05bc0909220559t2fa8be06q9d83dc6d32b1009c@mail.gmail.com> <005001ca3c0d$626f4060$274dc120$@com.au> Date: Wed, 23 Sep 2009 08:43:48 -0400 Message-ID: <93ef05bc0909230543p1faf2219i334971c70c5526f6@mail.gmail.com> Subject: Re: [Avr-libc-corelib] The SPI implementation From: =?ISO-8859-1?Q?Fr=E9d=E9ric_Nadeau?= To: avr-libc-corelib@nongnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 12:43:59 -0000 On Wed, Sep 23, 2009 at 1:18 AM, Ron Kreymborg wrote: > Well the master call would call the slave call in the library after setti= ng > the delay flag, so no duplication. > I might just not get what you ment then. > > No spi clock Fosc/2 as many spi slaves are only guaranteed to work at > Fosc/4. This I don't get: spi slave are only guaranteed to work at Fosc/4. As far as I understand it the slave work at a maximum SPI clock. I'm not sure what you meant by that, but that does not prevent the ATmega from working at Fosc/2. Here are two examples. 1 An ATmega plug to an SD/MMC card. those support up to 25MHz SPI clock. Way faster than even the 20Mhz/2 of some ATmega 2 An ATmega plug to a CANBus transceiver CP2515 who has it's own external clock and work at SPI 10Mhz. My opinion is that it falls on the developers burden to make sure that the SPI clock it uses is slower or as fast as what the device can work with. If not including the SPI_CLK2, at least I think it is appropriate to have a separate function like: spi_set_double_clock_rate(), or something alike. My opinion --=20 Fr=E9d=E9ric Nadeau ing. jr From MAILER-DAEMON Wed Sep 23 09:30:04 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqRv2-0003FZ-AZ for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 09:30:04 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqRuz-0003A7-TK for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 09:30:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqRuv-0002yS-1x for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 09:30:01 -0400 Received: from [199.232.76.173] (port=36378 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqRuu-0002yL-Sk for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 09:29:56 -0400 Received: from sid6170.sslaccess.com ([202.125.37.67]:48639) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqRut-0000LU-VN for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 09:29:56 -0400 Received: (qmail 13342 invoked from network); 23 Sep 2009 23:29:49 +1000 Received: from 202.63.38.189.static.rev.aanet.com.au (HELO DEVELOPMENT) (202.63.38.189) by sid6170.sslaccess.com with SMTP; 23 Sep 2009 23:29:49 +1000 From: "Ron Kreymborg" To: References: <604fcf830909221723n19fa6cb6ic652efbeaa7a5a29@mail.gmail.com> <000e01ca3c25$2eea1630$8cbe4290$@com.au> <4ABA1137.2000901@xs4all.nl> In-Reply-To: <4ABA1137.2000901@xs4all.nl> Subject: RE: [Avr-libc-corelib] proposed corelib style guide Date: Wed, 23 Sep 2009 23:29:16 +1000 Message-ID: <000601ca3c51$ecc1c5a0$c64550e0$@com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aco8R34iAUYetepzToKI5hBo07sf1QABFtcQ Content-Language: en-au X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 13:30:02 -0000 > > As I understand it, the library will be a pre-compiled lib file, with > the > > MCU name in the makefile linking to the matching version for that > processor. > > This approach is ok for built-in modules, but how about a HD44780 > driver? I have not ever made a PCB where the pins for the HD44780 were > exactly like any previous. > Using a HD44780 driver with runtime flexible pin definitions is a (code > size) nightmare. Or is a HD44780 not supposed to be in this library? > > Wouter Not sure about the PCB pin problem. For the library, I think a device like this should not be too hard. Most of the complex stuff is associated with providing various display functions - text strings, scrolling, flashing, etc, and this would be provided by the library. Actually handling the ports would be handled by a call-back function. From memory I think all you need is a send function and perhaps an "are you busy" function. Not positive here, but the send would probably look like: void LcdSend(uint8 value, bool commandFlag); The user would then stitch their various assigned pin numbers into a boilerplate sample function provided as part of the library, probably just by setting a few macros. The byte to output is , and whether it is a command or data is defined by . Where necessary, the user could edit another provided boilerplate function that splits the byte for 4-bit interfaces. And libc already provides an accurate delay function should this be needed. The library need know almost nothing about the hardware connections. Ron From MAILER-DAEMON Wed Sep 23 09:46:59 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqSBP-0003QM-NS for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 09:46:59 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqSBO-0003QF-Hm for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 09:46:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqSBJ-0003PZ-3w for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 09:46:57 -0400 Received: from [199.232.76.173] (port=47718 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqSBI-0003PV-UX for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 09:46:52 -0400 Received: from sid6170.sslaccess.com ([202.125.37.67]:39719) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqSBI-00042F-25 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 09:46:52 -0400 Received: (qmail 15753 invoked from network); 23 Sep 2009 23:46:48 +1000 Received: from 202.63.38.189.static.rev.aanet.com.au (HELO DEVELOPMENT) (202.63.38.189) by sid6170.sslaccess.com with SMTP; 23 Sep 2009 23:46:47 +1000 From: "Ron Kreymborg" To: References: <000001ca3b4e$36838fc0$a38aaf40$@com.au> <93ef05bc0909220559t2fa8be06q9d83dc6d32b1009c@mail.gmail.com> <005001ca3c0d$626f4060$274dc120$@com.au> <93ef05bc0909230543p1faf2219i334971c70c5526f6@mail.gmail.com> In-Reply-To: <93ef05bc0909230543p1faf2219i334971c70c5526f6@mail.gmail.com> Subject: RE: [Avr-libc-corelib] The SPI implementation Date: Wed, 23 Sep 2009 23:46:17 +1000 Message-ID: <000701ca3c54$4be63d20$e3b2b760$@com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aco8S7T6P97aYY5FRYSD1rVT3J21vAABxKjQ Content-Language: en-au X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 13:46:58 -0000 > > Well the master call would call the slave call in the library after > setting > > the delay flag, so no duplication. > > > I might just not get what you ment then. The calls are almost identical except the master has one more parameter. Within the library the master function would handle that extra = parameter, and then pass the rest onto the slave call. > > No spi clock Fosc/2 as many spi slaves are only guaranteed to work = at > > Fosc/4. >=20 > This I don't get: spi slave are only guaranteed to work at Fosc/4. As > far as I understand it the slave work at a maximum SPI clock. I'm not > sure what you meant by that, but that does not prevent the ATmega from > working at Fosc/2. Here are two examples. >=20 > 1 An ATmega plug to an SD/MMC card. those support up to 25MHz SPI > clock. Way faster than even the 20Mhz/2 of some ATmega >=20 > 2 An ATmega plug to a CANBus transceiver CP2515 who has it's own > external clock and work at SPI 10Mhz. >=20 > My opinion is that it falls on the developers burden to make sure that > the SPI clock it uses is slower or as fast as what the device can work > with. >=20 > If not including the SPI_CLK2, at least I think it is appropriate to > have a separate function like: > spi_set_double_clock_rate(), or something alike. >=20 > My opinion > -- > Fr=E9d=E9ric Nadeau ing. Jr Yes, you are correct about an AVR as master. I must admit I was thinking about AVR to AVR, and that is where the no Fosc/2 for a slave came from. = So assume Fosc/2 is part of the SPI library. Ron From MAILER-DAEMON Wed Sep 23 09:57:11 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqSLH-0000s9-9y for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 09:57:11 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqSLF-0000rs-D2 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 09:57:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqSLB-0000rO-2W for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 09:57:09 -0400 Received: from [199.232.76.173] (port=43974 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqSLA-0000rK-Sf for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 09:57:04 -0400 Received: from mx20.gnu.org ([199.232.41.8]:21394) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqSLA-0007Lx-Et for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 09:57:04 -0400 Received: from mail1.freeserver.sk ([217.67.30.194]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqSL7-0001fT-08 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 09:57:01 -0400 Received: from [91.127.72.181] (helo=TEST) by mail1.freeserver.sk with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MqSL9-0009td-Ci; Wed, 23 Sep 2009 15:57:03 +0200 Message-ID: X-Mailer: Ultrafunk Popcorn 1.77 (19-July-2007) X-Priority: 3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 23 Sep 2009 15:56:56 +0200 From: Jan Waclawek To: "Ron Kreymborg" , Subject: RE: [Avr-libc-corelib] The SPI implementation In-Reply-To: <000701ca3c54$4be63d20$e3b2b760$@com.au> X-detected-operating-system: by mx20.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 13:57:10 -0000 >Yes, you are correct about an AVR as master. I must admit I was thinking >about AVR to AVR, and that is where the no Fosc/2 for a slave came from. So >assume Fosc/2 is part of the SPI library. Just a note: even in AVR to AVR clocked at the same Fosc, it would be hazardous to set the master to Fosc/4. JW From MAILER-DAEMON Wed Sep 23 10:11:45 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqSZN-0006VB-FF for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 10:11:45 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqMGb-0003HF-2r for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:27:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqMGZ-0003Fh-Ag for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:27:56 -0400 Received: from [199.232.76.173] (port=41271 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqMGY-0003FM-Sk for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:27:54 -0400 Received: from mx20.gnu.org ([199.232.41.8]:63705) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqMGX-00053x-Lw for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:27:54 -0400 Received: from 70-88-163-233-nm.albuq.hfc.comcastbusiness.net ([70.88.163.233] helo=tiger.med-info.com) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqMGP-0007vW-Vn for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:27:46 -0400 Received: from [192.168.1.143] (flounder-3.local [192.168.1.143]) by tiger.med-info.com (8.14.3/8.14.3/Debian-6) with ESMTP id n8N72JiR019217; Wed, 23 Sep 2009 01:02:19 -0600 Subject: Re: [Avr-libc-corelib] proposed corelib style guide Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Kevin Rosenberg In-Reply-To: <005101ca3c16$a9f31e30$fdd95a90$@com.au> Date: Wed, 23 Sep 2009 01:02:19 -0600 Content-Transfer-Encoding: 7bit Message-Id: <734C7015-871A-4FCD-99BD-10C473780133@rosenberg.net> References: <005101ca3c16$a9f31e30$fdd95a90$@com.au> To: "Ron Kreymborg" X-Mailer: Apple Mail (2.1076) X-detected-operating-system: by mx20.gnu.org: Genre and OS details not recognized. X-Greylist: delayed 1511 seconds by postgrey-1.27 at nadesico; Wed, 23 Sep 2009 03:27:37 EDT X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-Mailman-Approved-At: Wed, 23 Sep 2009 10:11:43 -0400 Cc: avr-libc-corelib@nongnu.org X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 07:27:57 -0000 On Sep 23, 2009, at 12:25 AM, Ron Kreymborg wrote: > name a type definition in upper case and instances in camel (where > did this > "camel" come from?). However I agree exposed typedefs should conform > to a Perhaps your question is rhetorical, but I'll go ahead and answer: CamelCase (also called medial capitals[1]) refers to the "humps" of the taller uppercase letters between the shorter lower case letters. Kevin [1] http://en.wikipedia.org/wiki/CamelCase From MAILER-DAEMON Wed Sep 23 10:11:46 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqSZN-0006VZ-TD for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 10:11:45 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqQuv-0000GO-Bs for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 08:25:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqQur-0000CO-3R for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 08:25:52 -0400 Received: from [199.232.76.173] (port=54291 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqQkb-0003lb-2U for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 08:15:13 -0400 Received: from smtp-vbr10.xs4all.nl ([194.109.24.30]:3437) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqQka-0004kN-FP for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 08:15:12 -0400 Received: from [192.168.108.25] (ip4daa055d.direct-adsl.nl [77.170.5.93]) (authenticated bits=0) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id n8NCEwd8090025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Sep 2009 14:15:04 +0200 (CEST) (envelope-from avrmail@xs4all.nl) Message-ID: <4ABA1137.2000901@xs4all.nl> Date: Wed, 23 Sep 2009 14:14:47 +0200 From: Wouter van Gulik User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ron Kreymborg Subject: Re: [Avr-libc-corelib] proposed corelib style guide References: <604fcf830909221723n19fa6cb6ic652efbeaa7a5a29@mail.gmail.com> <000e01ca3c25$2eea1630$8cbe4290$@com.au> In-Reply-To: <000e01ca3c25$2eea1630$8cbe4290$@com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-Mailman-Approved-At: Wed, 23 Sep 2009 10:11:43 -0400 Cc: avr-libc-corelib@nongnu.org X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 12:25:53 -0000 Ron Kreymborg schreef: >> I would add (from the user's viewpoint): >> >> MODULES >> - Each module will have a usage guideline and a comprehensible example >> of use >> >> I would anticipate that users will copy the library files to their >> projects, potentially modifying them, rather than use a pre-built >> library or such. >> So the usage guideline should include a method how to add all that's >> necessary into a makefile, preferrably "compatible" with mfile's >> "standard" output (or shall we attempt to expand mfile's capabilities >> accordingly?) >> >> JW > > As I understand it, the library will be a pre-compiled lib file, with the > MCU name in the makefile linking to the matching version for that processor. > Maintaining a source version would be nigh on impossible. Imagine: "I > increased the buffer limit and changed the speed setting and now my app > resets about every 5 minutes. Help!". > > I suggested earlier that the current source be available (not necessarily > with an avr-avr release but perhaps on a web site somewhere) after the > library is also released in its current final version. This would be "modify > at your own risk". Any other suggestions? > This approach is ok for built-in modules, but how about a HD44780 driver? I have not ever made a PCB where the pins for the HD44780 were exactly like any previous. Using a HD44780 driver with runtime flexible pin definitions is a (code size) nightmare. Or is a HD44780 not supposed to be in this library? Wouter From MAILER-DAEMON Wed Sep 23 10:11:46 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqSZN-0006VR-Lo for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 10:11:45 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqMLT-0004Le-Mc for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:32:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqMLO-0004Kt-S9 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:32:59 -0400 Received: from [199.232.76.173] (port=34637 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqMLO-0004Kq-MT for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:32:54 -0400 Received: from mx20.gnu.org ([199.232.41.8]:63972) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqMLO-0005ZD-5m for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:32:54 -0400 Received: from smtp02.hesbynett.no ([81.29.32.168]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqMLM-0008GR-8b for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 03:32:52 -0400 Received: from localhost.localdomain (81-29-46-32.ipc21.adsl.hesbynett.no [81.29.46.32]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.hesbynett.no (Postfix) with ESMTPS id 947AD1F243; Wed, 23 Sep 2009 09:32:44 +0200 (CEST) Received: from [192.168.0.179] (helo=[192.168.0.179]) by localhost.localdomain with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1MqMLE-00014F-6J; Wed, 23 Sep 2009 09:32:44 +0200 Message-ID: <4AB9CEC2.7090202@westcontrol.com> Date: Wed, 23 Sep 2009 09:31:14 +0200 From: David Brown User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jan Waclawek Subject: Re: [Avr-libc-corelib] proposed corelib style guide References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: 947AD1F243.12CF3 X-HesbynettAS-MailScanner: Found to be clean X-HesbynettAS-MailScanner-From: david@westcontrol.com X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-Mailman-Approved-At: Wed, 23 Sep 2009 10:11:43 -0400 Cc: avr-libc-corelib@nongnu.org X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 07:32:59 -0000 Jan Waclawek wrote: > I would add (from the user's viewpoint): > > MODULES - Each module will have a usage guideline and a > comprehensible example of use > > I would anticipate that users will copy the library files to their > projects, potentially modifying them, rather than use a pre-built > library or such. So the usage guideline should include a method how > to add all that's necessary into a makefile, preferrably "compatible" > with mfile's "standard" output (or shall we attempt to expand mfile's > capabilities accordingly?) > Given that people will copy the files into their projects, it's also important to make it clear how different modules interact, and what files are part of each module. It might make sense to have modules within their own directory - thus making it as easy as possible to see exactly what is needed. The directories could also contain test or example code (test code discussions should probably be a new topic). Sharing between modules should be done when it is beneficial, but only if it really is beneficial. For example, just because the SPI and Uart modules both use ring buffers, does not mean there should be a separate ringbuffer module that is required for each of them. On the other hand, if someone writes a great memory pool manager, then a module for implementing web servers should take advantage of it. Since we expect users to copy files into their projects, it is important to remember that there are no private, internal implementation files. There will always need to be a higher standard of commenting, reader-friendliness and style consistency for "interface" files (i.e., uart.h) than for the implementation files (it is not a big deal if a static variable is named camelCaps rather than camel_caps). But every file will need a consistent comment block at the start with fields for module summary, copyright and licensing, version and revision information, etc. There should also be a comment field specifically for "customisation history". It is very easy for users to forget to add such information at the top of a file they modify, causing confusion later if someone else wants to update the module. By explicitly adding such a field, we give them an extra reminder. mvh., David From MAILER-DAEMON Wed Sep 23 10:43:10 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqT3l-0003QC-Uu for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 10:43:09 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqT3k-0003PW-Ih for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 10:43:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqT3g-0003MR-5i for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 10:43:08 -0400 Received: from [199.232.76.173] (port=53085 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqT3f-0003MO-Ui for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 10:43:03 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:36622) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqT3f-0005KJ-G6 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 10:43:03 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e39.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8NEbTli013625 for ; Wed, 23 Sep 2009 08:37:29 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8NEgfkq009536 for ; Wed, 23 Sep 2009 08:42:42 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8NEgfnw017545 for ; Wed, 23 Sep 2009 08:42:41 -0600 Received: from [127.0.0.1] (MPERKS2.austin.ibm.com [9.41.103.141]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8NEgcw1017306 for ; Wed, 23 Sep 2009 08:42:40 -0600 Message-ID: <4ABA33D4.1050406@oakmicros.com> Date: Wed, 23 Sep 2009 09:42:28 -0500 From: Mike Perks User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: avr-libc-corelib@nongnu.org Subject: Re: [Avr-libc-corelib] Re: proposed corelib style guide References: <604fcf830909221723n19fa6cb6ic652efbeaa7a5a29@mail.gmail.com> <604fcf830909222321p1549476ckbaed093e26a718d1@mail.gmail.com> In-Reply-To: <604fcf830909222321p1549476ckbaed093e26a718d1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 14:43:08 -0000 Ruddick Lawrence wrote: > [Do we want some way to tell if two init functions will conflict (ie, > trying to use the same timer with both PWM and output compare)? I > guess this goes back to determining the uses of each pin for each AVR > model] I think we should handle this case, at least in part. The simplest approach is by #defining "in-use" values at compile time so that any conflicts in the use of the headers results in a #error compilation error. Trying to do this at run-time is doable but much harder. This comes back to the issue of error checking and how much we should add. For example opening an SPI port twice in a row or opening a new SPI port before closing the previous one may not do any harm and the code should be written to take these use cases into account. Perhaps we need yet another #define which conditionally includes more thorough error checking paths for code development and debug. For production the user may decide to conserve code space and remove these extra paths e.g. develop on a mega328p but ship on a mega168p. Mike Perks Oak Micros (oakmicros.com) From MAILER-DAEMON Wed Sep 23 11:45:43 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqU2J-0007UT-HT for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 11:45:43 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqU2H-0007Tc-Dc for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 11:45:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqU2C-0007Ph-Mz for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 11:45:41 -0400 Received: from [199.232.76.173] (port=60917 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqU2C-0007PZ-HA for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 11:45:36 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:58141) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqU2C-0002zh-5f for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 11:45:36 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8NFoEeK024141 for ; Wed, 23 Sep 2009 11:50:14 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8NFjNnA1089612 for ; Wed, 23 Sep 2009 11:45:24 -0400 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8NFjGT7000732 for ; Wed, 23 Sep 2009 09:45:16 -0600 Received: from [127.0.0.1] (MPERKS2.austin.ibm.com [9.41.103.141]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8NFjCci032686 for ; Wed, 23 Sep 2009 09:45:15 -0600 Message-ID: <4ABA427B.8040008@oakmicros.com> Date: Wed, 23 Sep 2009 10:44:59 -0500 From: Mike Perks User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: avr-libc-corelib@nongnu.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: [Avr-libc-corelib] Interrupt Handlers X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 15:45:41 -0000 One of the issues that will need to handled (intentional pun) by the library is ISRs. There are several use cases to consider: 1. Library module wants to use an ISR 2. User wants to use an ISR 3. User wants to use an ISR but it is used by a library module 4. Two library APIs (presumably from different modules) both want to use the same ISR Having a first come first served policy will not work. We probably need to provide a way to have hooks such as a callback. The problem is that this could be too heavyweight for what is supposed to be a fast response. Do we provide default ISRs as part of a library core and then individual library modules hook in using a callback. The advantage of this technique is for debugging. Standards for debug support is probably a separate thread. Mike Perks Oak Micros (oakmicros.com) From MAILER-DAEMON Wed Sep 23 14:04:02 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqWC9-0003YA-Uk for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 14:04:01 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqWC8-0003Wv-LW for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 14:04:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqWC3-0003SN-O7 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 14:04:00 -0400 Received: from [199.232.76.173] (port=33637 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqWC3-0003SJ-KY for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 14:03:55 -0400 Received: from mail1.freeserver.sk ([217.67.30.194]:51740) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqWC3-0007C4-24 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 14:03:55 -0400 Received: from [195.91.86.171] (helo=eeepc-wek) by mail1.freeserver.sk with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MqWBy-000HOw-V4; Wed, 23 Sep 2009 20:03:51 +0200 Date: Wed, 23 Sep 2009 20:07:12 +0200 From: Jan Waclawek To: Mike Perks Subject: Re: [Avr-libc-corelib] Interrupt Handlers Message-Id: <20090923200712.9c63ab65.konfera@efton.sk> In-Reply-To: <4ABA427B.8040008@oakmicros.com> References: <4ABA427B.8040008@oakmicros.com> X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: avr-libc-corelib@nongnu.org X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 18:04:01 -0000 On Wed, 23 Sep 2009 10:44:59 -0500 Mike Perks wrote: > One of the issues that will need to handled (intentional pun) by the > library is ISRs. There are several use cases to consider: > > 1. Library module wants to use an ISR > 2. User wants to use an ISR > 3. User wants to use an ISR but it is used by a library module > 4. Two library APIs (presumably from different modules) both want to use > the same ISR Can you please provide examples? > Having a first come first served policy will not work. Why not? > We probably need > to provide a way to have hooks such as a callback. The problem is that > this could be too heavyweight for what is supposed to be a fast response. > I see no problem with having alternatives: lightweight, heavyweight, let the user choose what he wants. I repeat myself: I anticipate the user will copy files to his project and possibly modify. I can't even imagine how could a pre-build library be less than cumbersome. JW From MAILER-DAEMON Wed Sep 23 16:43:05 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqYg5-0000QO-DE for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 16:43:05 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqYg4-0000Q1-48 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 16:43:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqYfz-0000Ou-ET for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 16:43:03 -0400 Received: from [199.232.76.173] (port=36585 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqYfz-0000Or-8k for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 16:42:59 -0400 Received: from smtp-roam1.stanford.edu ([171.67.219.88]:59556 helo=smtp-roam.stanford.edu) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqYfy-0008IX-LQ for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 16:42:59 -0400 Received: from smtp-roam.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EDE6737D3E for ; Wed, 23 Sep 2009 13:42:55 -0700 (PDT) Received: from mail-yx0-f173.google.com (mail-yx0-f173.google.com [209.85.210.173]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ruddick) by smtp-roam.stanford.edu (Postfix) with ESMTPSA id F1C4437D29 for ; Wed, 23 Sep 2009 13:42:54 -0700 (PDT) Received: by yxe3 with SMTP id 3so1248799yxe.4 for ; Wed, 23 Sep 2009 13:42:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.22.2 with SMTP id 2mr1547932agv.104.1253738573095; Wed, 23 Sep 2009 13:42:53 -0700 (PDT) In-Reply-To: <20090923200712.9c63ab65.konfera@efton.sk> References: <4ABA427B.8040008@oakmicros.com> <20090923200712.9c63ab65.konfera@efton.sk> From: Ruddick Lawrence Date: Wed, 23 Sep 2009 13:42:33 -0700 Message-ID: <604fcf830909231342v6fa6e52dpe28b8102f57fd7d7@mail.gmail.com> Subject: Re: [Avr-libc-corelib] Interrupt Handlers To: Jan Waclawek Content-Type: multipart/alternative; boundary=00163616403d4a648a047444c22f X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: avr-libc-corelib@nongnu.org X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 20:43:04 -0000 --00163616403d4a648a047444c22f Content-Type: text/plain; charset=ISO-8859-1 A possible solution would be for each module that needs to put code in an ISR to define a macro with that code. The user would then have the responsibility of defining the ISR and calling the macro in it. This would give users full control of the order, and the ability to add their own code, with the drawback that it is one more thing to remember. The existence of an ISR macro in a module would have to be VERY well documented, including which ISR it should be put in (perhaps a standard heading in module documentation so it was also clear when there weren't any ISR macros in a module). However, if this method is used throughout the library, users will get used to looking for it as part of learning how to use a module. Ruddick On Wed, Sep 23, 2009 at 11:07 AM, Jan Waclawek wrote: > On Wed, 23 Sep 2009 10:44:59 -0500 > Mike Perks wrote: > > > One of the issues that will need to handled (intentional pun) by the > > library is ISRs. There are several use cases to consider: > > > > 1. Library module wants to use an ISR > > 2. User wants to use an ISR > > 3. User wants to use an ISR but it is used by a library module > > 4. Two library APIs (presumably from different modules) both want to use > > the same ISR > > Can you please provide examples? > > > Having a first come first served policy will not work. > > Why not? > > > We probably need > > to provide a way to have hooks such as a callback. The problem is that > > this could be too heavyweight for what is supposed to be a fast response. > > > > I see no problem with having alternatives: lightweight, heavyweight, let > the user choose what he wants. > > I repeat myself: I anticipate the user will copy files to his project and > possibly modify. I can't even imagine how could a pre-build library be less > than cumbersome. > > JW > > > --00163616403d4a648a047444c22f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A possible solution would be for each module that needs to put code in an I= SR to define a macro with that code. The user would then have the responsib= ility of defining the ISR and calling the macro in it. This would give user= s full control of the order, and the ability to add their own code, with th= e drawback that it is one more thing to remember. The existence of an ISR m= acro in a module would have to be VERY well documented, including which ISR= it should be put in (perhaps a standard heading in module documentation so= it was also clear when there weren't any ISR macros in a module). Howe= ver, if this method is used throughout the library, users will get used to = looking for it as part of learning how to use a module.

Ruddick


--00163616403d4a648a047444c22f-- From MAILER-DAEMON Wed Sep 23 18:54:43 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqajT-000786-HW for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 18:54:43 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqajR-00076i-S1 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 18:54:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqajN-00072m-45 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 18:54:41 -0400 Received: from [199.232.76.173] (port=45563 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqajM-00072X-WD for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 18:54:37 -0400 Received: from mail-ew0-f221.google.com ([209.85.219.221]:59611) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqajM-0004TG-F2 for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 18:54:36 -0400 Received: by ewy21 with SMTP id 21so1154381ewy.8 for ; Wed, 23 Sep 2009 15:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=JxKYCpAzvb7hdsBVatG/YHxj9QpyW7W88HzB3gfF8dQ=; b=PhfmJb6LMGhse2DmdCKPyvLSGdngxGH/81miZ19ut6npbYAhMwcS3pPVB3vdLUfwMF 66aTnJqLAkipOBZCe2Lu7T7FmI1MrvENe/jK1WgoCwDdFGyawTzIehbMdppr0tc1xO9F dEYHqp53qCyNpVOCzbLRfK1nGnBfO2AuPP/Ck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=f9/1sv6rusIEpZAP25msMSu+YXLeX2NScBjcdHEHg4ldUV+3ahr9ISmTxLJrrgffV0 9WgotLEdJm+ZVcdoORsyF2/m9SS1ZbRW+W8HHz8W/K3ZFGFCnzTK0KiOzsLnqJZ7La9C VAVMb+TPUuYyvUMMJmE47kU6y9lUpAkMU/uOs= MIME-Version: 1.0 Received: by 10.211.147.25 with SMTP id z25mr6582162ebn.84.1253746475111; Wed, 23 Sep 2009 15:54:35 -0700 (PDT) In-Reply-To: References: <000701ca3c54$4be63d20$e3b2b760$@com.au> Date: Wed, 23 Sep 2009 18:54:35 -0400 Message-ID: <93ef05bc0909231554i6bbef475r603699451cb7c5e5@mail.gmail.com> Subject: Re: [Avr-libc-corelib] The SPI implementation From: =?ISO-8859-1?Q?Fr=E9d=E9ric_Nadeau?= To: avr-libc-corelib@nongnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 22:54:42 -0000 On Wed, Sep 23, 2009 at 9:56 AM, Jan Waclawek wrote: > Just a note: even in AVR to AVR clocked at the same Fosc, it would be haz= ardous to set the master to Fosc/4. > > JW > We should keep that note for the documentation at least. --=20 Fr=E9d=E9ric Nadeau ing. jr From MAILER-DAEMON Wed Sep 23 23:13:43 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mqem7-00015M-Q6 for mharc-avr-libc-corelib@gnu.org; Wed, 23 Sep 2009 23:13:43 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqceY-0000OL-Lb for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 20:57:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqceT-0000IK-3U for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 20:57:45 -0400 Received: from [199.232.76.173] (port=42607 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqceS-0000HR-HK for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 20:57:40 -0400 Received: from blu0-omc1-s18.blu0.hotmail.com ([65.55.116.29]:45223) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqceR-0006pv-5N for avr-libc-corelib@nongnu.org; Wed, 23 Sep 2009 20:57:39 -0400 Received: from BLU145-DS3 ([65.55.116.9]) by blu0-omc1-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 17:57:37 -0700 X-Originating-IP: [99.59.118.244] X-Originating-Email: [j_w_myers@hotmail.com] Message-ID: From: "John Myers" To: "'Ron Kreymborg'" , References: <005101ca3c16$a9f31e30$fdd95a90$@com.au> <000901ca3c22$a6b90b60$f42b2220$@com.au> Subject: RE: [Avr-libc-corelib] proposed corelib style guide Date: Wed, 23 Sep 2009 17:57:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000901ca3c22$a6b90b60$f42b2220$@com.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Aco8r7SMLcmWHehVSmueLOSje0r5MgAAMsHA X-OriginalArrivalTime: 24 Sep 2009 00:57:37.0693 (UTC) FILETIME=[027AD4D0:01CA3CB2] X-detected-operating-system: by monty-python.gnu.org: Windows 2000 SP4, XP SP1+ X-Mailman-Approved-At: Wed, 23 Sep 2009 23:13:42 -0400 Cc: X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 00:57:47 -0000 The code below works even without ever defining the weak function, so defining the function can be reserved for the user when they need it. uint8_t i2c_get_address (void) __attribute__ ((weak)); if (i2c_get_address) i2c_get_address (); --John -----Original Message----- From: Ron Kreymborg [mailto:ron@jennaron.com.au] Sent: Wednesday, September 23, 2009 12:51 AM To: avr-libc-corelib@nongnu.org Subject: RE: [Avr-libc-corelib] proposed corelib style guide > void GetClockFrequency(long crystal); Of course this should be: long GetClockFrequency(void): > Thinking of call-back, is there some gcc modifier that allows for > definition > of a "weak" function? This would allow call-backs to be instanced in > the > library as null functions and save the user from creating an instance > in > their code just to satisfy the linker when they have no need for it. > Hmmm. > Or does that invite problems? Answering myself, I just built a quick test library and gcc's __attribute__ ((weak)) works fine. My question could be answered by the weak version returning something or doing something impossible, which the library could use to define an error. This probably needs more thought... Ron From MAILER-DAEMON Thu Sep 24 03:42:31 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqiyE-0005Mx-RY for mharc-avr-libc-corelib@gnu.org; Thu, 24 Sep 2009 03:42:30 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqiyD-0005Ms-Tw for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 03:42:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mqiy8-0005Mg-AE for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 03:42:28 -0400 Received: from [199.232.76.173] (port=44966 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mqiy8-0005Md-4T for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 03:42:24 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:43800) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mqiy7-0002NR-LX for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 03:42:23 -0400 Received: from [127.0.0.1] (really [66.68.23.44]) by hrndva-omta01.mail.rr.com with ESMTP id <20090924074221178.YCCK29486@hrndva-omta01.mail.rr.com> for ; Thu, 24 Sep 2009 07:42:21 +0000 Message-ID: <4ABB22D8.6020208@oakmicros.com> Date: Thu, 24 Sep 2009 02:42:16 -0500 From: Mike Perks User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: avr-libc-corelib@nongnu.org Subject: Re: [Avr-libc-corelib] Interrupt Handlers References: <4ABA427B.8040008@oakmicros.com> <20090923200712.9c63ab65.konfera@efton.sk> In-Reply-To: <20090923200712.9c63ab65.konfera@efton.sk> Content-Type: multipart/alternative; boundary="------------000100020906060202010204" X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (1203?) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 07:42:30 -0000 This is a multi-part message in MIME format. --------------000100020906060202010204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jan >> One of the issues that will need to handled (intentional pun) by the >> library is ISRs. There are several use cases to consider: >> >> 1. Library module wants to use an ISR >> 2. User wants to use an ISR >> 3. User wants to use an ISR but it is used by a library module >> 4. Two library APIs (presumably from different modules) both want to use >> the same ISR >> > > Can you please provide examples? > For the case of a user wanting to use an ISR, then this usually ameliorated by the API in some fashion. For example transmit and receive buffers are used for serial comms. One place everyone is interested in is RESET. On a reset interrupt how we do handle initialization of every one including the user code? Presumably the user has a init() routine (could be a callback) that than calls all of the other init routines. Another case is that the user sets up an RTC timeofday routine but also needs to know when each tick occurs so they can do their own processing at predefined intervals. It might be as simple as incrementing a counter. If you introduce an API such as WaitForInterrupt() or WaitForTick() then the user code is stalled unless you also introduce some kind of RTOS that allows other user code (separate task) to proceed while waiting for the interrupt. >> Having a first come first served policy will not work. >> > > Why not? > Because some piece of code will never get the interrupt they are expecting. Worse case the compiler has a link error with two ISR routines. >> We probably need >> to provide a way to have hooks such as a callback. The problem is that >> this could be too heavyweight for what is supposed to be a fast response. > I see no problem with having alternatives: lightweight, heavyweight, let the user choose what he wants. > The purpose of this append is to discuss how it might be done in code. Ruddick has an idea with his macro approach although I would prefer to see it with public inlined static functions. Another idea is with a weak reference callback, to at least give one part of the code a chance to hook in. > I repeat myself: I anticipate the user will copy files to his project and possibly modify. I can't even imagine how could a pre-build library be less than cumbersome. > The issue of whether we build libraries for each device or family of devices I think is still open. In either case we still have to test the code. However I do not see most people scrambling around trying to understand the library code so they can modify it to explicitly add some additional ISR code. I believe the whole point here is to have a standardized API with documentation that people can just use. Mike Perks Oak Micros (oakmicros.com). --------------000100020906060202010204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jan
One of the issues that will need to handled (intentional pun) by the 
library is ISRs. There are several use cases to consider:

1. Library module wants to use an ISR
2. User wants to use an ISR
3. User wants to use an ISR but it is used by a library module
4. Two library APIs (presumably from different modules) both want to use 
the same ISR
    

Can you please provide examples?
  
For the case of a user wanting to use an ISR, then this usually ameliorated by the API in some fashion. For example transmit and receive buffers are used for serial comms.

One place everyone is interested in is RESET. On a reset interrupt how we do handle initialization of every one including the user code? Presumably the user has a init() routine (could be a callback) that than calls all of the other init routines. Another case is that the user sets up an RTC timeofday routine but also needs to know when each tick occurs so they can do their own processing at predefined intervals. It might be as simple as incrementing a counter. If you introduce an API such as WaitForInterrupt() or WaitForTick() then the user code is stalled unless you also introduce some kind of RTOS that allows other user code (separate task) to proceed while waiting for the interrupt.
Having a first come first served policy will not work. 
    

Why not?
  
Because some piece of code will never get the interrupt they are expecting. Worse case the compiler has a link error with two ISR routines.
We probably need 
to provide a way to have hooks such as a callback. The problem is that 
this could be too heavyweight for what is supposed to be a fast response.
I see no problem with having alternatives: lightweight, heavyweight, let the user choose what he wants.
  
The purpose of this append is to discuss how it might be done in code. Ruddick has an idea with his macro approach although I would prefer to see it with public inlined static functions. Another idea is with a weak reference callback, to at least give one part of the code a chance to hook in.
I repeat myself: I anticipate the user will copy files to his project and possibly modify. I can't even imagine how could a pre-build library be less than cumbersome.
  
The issue of whether we build libraries for each device or family of devices I think is still open. In either case we still have to test the code. However I do not see most people scrambling around trying to understand the library code so they can modify it to explicitly add some additional ISR code. I believe the whole point here is to have a standardized API with documentation that people can just use.

Mike Perks
Oak Micros (oakmicros.com).
--------------000100020906060202010204-- From MAILER-DAEMON Thu Sep 24 05:05:56 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqkGy-0007PO-8Q for mharc-avr-libc-corelib@gnu.org; Thu, 24 Sep 2009 05:05:56 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqkGv-0007P3-7h for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 05:05:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqkGp-0007Oq-Sf for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 05:05:52 -0400 Received: from [199.232.76.173] (port=41042 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqkGp-0007On-Q6 for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 05:05:47 -0400 Received: from smtp01.hesbynett.no ([81.29.32.167]:43414) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqkGp-0002LM-5Z for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 05:05:47 -0400 Received: from localhost.localdomain (81-29-46-32.ipc21.adsl.hesbynett.no [81.29.46.32]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.hesbynett.no (Postfix) with ESMTPS id 025071F271; Thu, 24 Sep 2009 11:05:36 +0200 (CEST) Received: from [192.168.0.179] (helo=[192.168.0.179]) by localhost.localdomain with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1MqkGb-0005ey-Pc; Thu, 24 Sep 2009 11:05:33 +0200 Message-ID: <4ABB3614.2080504@westcontrol.com> Date: Thu, 24 Sep 2009 11:04:20 +0200 From: David Brown User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ron Kreymborg Subject: Re: [Avr-libc-corelib] proposed corelib style guide References: <604fcf830909221723n19fa6cb6ic652efbeaa7a5a29@mail.gmail.com> <000e01ca3c25$2eea1630$8cbe4290$@com.au> <4ABA1137.2000901@xs4all.nl> <000601ca3c51$ecc1c5a0$c64550e0$@com.au> In-Reply-To: <000601ca3c51$ecc1c5a0$c64550e0$@com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: 025071F271.979E4 X-HesbynettAS-MailScanner: Found to be clean X-HesbynettAS-MailScanner-From: david@westcontrol.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: avr-libc-corelib@nongnu.org X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 09:05:53 -0000 Ron Kreymborg wrote: >>> As I understand it, the library will be a pre-compiled lib file, with >> the >>> MCU name in the makefile linking to the matching version for that >> processor. >> >> This approach is ok for built-in modules, but how about a HD44780 >> driver? I have not ever made a PCB where the pins for the HD44780 were >> exactly like any previous. >> Using a HD44780 driver with runtime flexible pin definitions is a (code >> size) nightmare. Or is a HD44780 not supposed to be in this library? >> >> Wouter > > Not sure about the PCB pin problem. > > For the library, I think a device like this should not be too hard. Most of > the complex stuff is associated with providing various display functions - > text strings, scrolling, flashing, etc, and this would be provided by the > library. Actually handling the ports would be handled by a call-back > function. From memory I think all you need is a send function and perhaps an > "are you busy" function. > > Not positive here, but the send would probably look like: > > void LcdSend(uint8 value, bool commandFlag); > > The user would then stitch their various assigned pin numbers into a > boilerplate sample function provided as part of the library, probably just > by setting a few macros. The byte to output is , and whether it is a > command or data is defined by . Where necessary, the user could > edit another provided boilerplate function that splits the byte for 4-bit > interfaces. And libc already provides an accurate delay function should this > be needed. > > The library need know almost nothing about the hardware connections. > > Ron > I expect you are thinking of something like low-level functions to put send a byte to the screen and strobe the various control lines or address bus signals. One thing here is that it can be difficult to find a balance between hiding as much as possible in the library code, and generating fast code. If your low-level functions are too simplistic, then the function call overhead becomes dominant - something like "strobeChipEnable()" or "setRegisterSelectBit()" should be macros or static inline functions, not normal function calls. If we aim that for the modules to be usable as either pre-compiled code (for user convenience), or by copying the modules to the project, then users can choose themselves. They can then define a their "stropeChipEnable()" function as a normal function linked to the library, or as a static inline function compiled directly into the module if speed is important. From MAILER-DAEMON Thu Sep 24 05:09:12 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqkK8-0007qX-BV for mharc-avr-libc-corelib@gnu.org; Thu, 24 Sep 2009 05:09:12 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqkK6-0007pB-Lr for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 05:09:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqkK1-0007nF-8W for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 05:09:09 -0400 Received: from [199.232.76.173] (port=52760 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqkK0-0007nB-Vo for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 05:09:05 -0400 Received: from smtp02.hesbynett.no ([81.29.32.168]:40487) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqkK0-0003Ao-GP for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 05:09:04 -0400 Received: from localhost.localdomain (81-29-46-32.ipc21.adsl.hesbynett.no [81.29.46.32]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.hesbynett.no (Postfix) with ESMTPS id 555CE1F243; Thu, 24 Sep 2009 11:08:57 +0200 (CEST) Received: from [192.168.0.179] (helo=[192.168.0.179]) by localhost.localdomain with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1MqkJs-0005fl-VB; Thu, 24 Sep 2009 11:08:56 +0200 Message-ID: <4ABB36DF.7050800@westcontrol.com> Date: Thu, 24 Sep 2009 11:07:43 +0200 From: David Brown User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ruddick Lawrence Subject: Re: [Avr-libc-corelib] Interrupt Handlers References: <4ABA427B.8040008@oakmicros.com> <20090923200712.9c63ab65.konfera@efton.sk> <604fcf830909231342v6fa6e52dpe28b8102f57fd7d7@mail.gmail.com> In-Reply-To: <604fcf830909231342v6fa6e52dpe28b8102f57fd7d7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: 555CE1F243.CF87A X-HesbynettAS-MailScanner: Found to be clean X-HesbynettAS-MailScanner-From: david@westcontrol.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: avr-libc-corelib@nongnu.org X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 09:09:10 -0000 Ruddick Lawrence wrote: > A possible solution would be for each module that needs to put code in > an ISR to define a macro with that code. The user would then have the > responsibility of defining the ISR and calling the macro in it. This > would give users full control of the order, and the ability to add their > own code, with the drawback that it is one more thing to remember. The > existence of an ISR macro in a module would have to be VERY well > documented, including which ISR it should be put in (perhaps a standard > heading in module documentation so it was also clear when there weren't > any ISR macros in a module). However, if this method is used throughout > the library, users will get used to looking for it as part of learning > how to use a module. > > Ruddick > This sounds like a good plan, except for the "macro" bit - such code should be "static inline" functions. Generally speaking, "code" macros should be static inline functions these days - they are clearer to write and to understand, and provide better error checking. mvh., David > On Wed, Sep 23, 2009 at 11:07 AM, Jan Waclawek > wrote: > > On Wed, 23 Sep 2009 10:44:59 -0500 > Mike Perks > wrote: > > > One of the issues that will need to handled (intentional pun) by the > > library is ISRs. There are several use cases to consider: > > > > 1. Library module wants to use an ISR > > 2. User wants to use an ISR > > 3. User wants to use an ISR but it is used by a library module > > 4. Two library APIs (presumably from different modules) both want > to use > > the same ISR > > Can you please provide examples? > > > Having a first come first served policy will not work. > > Why not? > > > We probably need > > to provide a way to have hooks such as a callback. The problem is > that > > this could be too heavyweight for what is supposed to be a fast > response. > > > > I see no problem with having alternatives: lightweight, heavyweight, > let the user choose what he wants. > > I repeat myself: I anticipate the user will copy files to his > project and possibly modify. I can't even imagine how could a > pre-build library be less than cumbersome. > > JW > > > From MAILER-DAEMON Thu Sep 24 07:48:52 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mqmoe-0003ND-1d for mharc-avr-libc-corelib@gnu.org; Thu, 24 Sep 2009 07:48:52 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mqmoc-0003MI-UW for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 07:48:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqmoY-0003I3-5V for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 07:48:50 -0400 Received: from [199.232.76.173] (port=48179 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqmoX-0003Hj-Qi for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 07:48:45 -0400 Received: from sid6170.sslaccess.com ([202.125.37.67]:50598) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqmoW-0008AP-Vc for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 07:48:45 -0400 Received: (qmail 3158 invoked from network); 24 Sep 2009 21:48:35 +1000 Received: from 202.63.38.189.static.rev.aanet.com.au (HELO DEVELOPMENT) (202.63.38.189) by sid6170.sslaccess.com with SMTP; 24 Sep 2009 21:48:34 +1000 From: "Ron Kreymborg" To: References: <005101ca3c16$a9f31e30$fdd95a90$@com.au> <000901ca3c22$a6b90b60$f42b2220$@com.au> In-Reply-To: Subject: RE: [Avr-libc-corelib] proposed corelib style guide Date: Thu, 24 Sep 2009 21:48:04 +1000 Message-ID: <004801ca3d0c$f2f38d30$d8daa790$@com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Aco8r7SMLcmWHehVSmueLOSje0r5MgAAMsHAABbwjHA= Content-Language: en-au X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 11:48:51 -0000 > The code below works even without ever defining the weak function, so > defining the function can be reserved for the user when they need it. > > > uint8_t i2c_get_address (void) __attribute__ ((weak)); > > if (i2c_get_address) > i2c_get_address (); > > --John Looks a good solution to me, with the else providing an error or an alternate operation. Ron From MAILER-DAEMON Thu Sep 24 09:24:36 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MqoJI-0004Cl-Qr for mharc-avr-libc-corelib@gnu.org; Thu, 24 Sep 2009 09:24:36 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqoJG-0004Bw-HG for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 09:24:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqoJB-0004B1-75 for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 09:24:33 -0400 Received: from [199.232.76.173] (port=44570 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqoJB-0004Aw-3j for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 09:24:29 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:60272) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqoJA-0001Mu-Np for avr-libc-corelib@nongnu.org; Thu, 24 Sep 2009 09:24:28 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e39.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8ODItTP005130 for ; Thu, 24 Sep 2009 07:18:55 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8ODONvC183098 for ; Thu, 24 Sep 2009 07:24:23 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8ODONmH031996 for ; Thu, 24 Sep 2009 07:24:23 -0600 Received: from [127.0.0.1] (MPERKS2.austin.ibm.com [9.41.103.141]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8ODOLVu031885 for ; Thu, 24 Sep 2009 07:24:23 -0600 Message-ID: <4ABB72FB.1050202@oakmicros.com> Date: Thu, 24 Sep 2009 08:24:11 -0500 From: Mike Perks User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: avr-libc-corelib@nongnu.org Subject: Re: [Avr-libc-corelib] Interrupt Handlers References: <4ABA427B.8040008@oakmicros.com> <20090923200712.9c63ab65.konfera@efton.sk> <604fcf830909231342v6fa6e52dpe28b8102f57fd7d7@mail.gmail.com> <4ABB36DF.7050800@westcontrol.com> In-Reply-To: <4ABB36DF.7050800@westcontrol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: avr-libc-corelib.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 13:24:35 -0000 David Brown wrote: > This sounds like a good plan, except for the "macro" bit - such code > should be "static inline" functions. Generally speaking, "code" > macros should be static inline functions these days - they are clearer > to write and to understand, and provide better error checking. Agree 200%. This is why I believe quite a bit of the library will actually be in header files. Mike Perks Oak Micros (oakmicros.com) From MAILER-DAEMON Fri Sep 25 17:06:24 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MrHzj-0006JL-Qm for mharc-avr-libc-corelib@gnu.org; Fri, 25 Sep 2009 17:06:23 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MrHzi-0006HD-0y for avr-libc-corelib@nongnu.org; Fri, 25 Sep 2009 17:06:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MrHzc-0006BX-VZ for avr-libc-corelib@nongnu.org; Fri, 25 Sep 2009 17:06:21 -0400 Received: from [199.232.76.173] (port=46617 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MrHzc-0006BI-MA for avr-libc-corelib@nongnu.org; Fri, 25 Sep 2009 17:06:16 -0400 Received: from smtp-roam2.stanford.edu ([171.67.219.89]:53710 helo=smtp-roam.stanford.edu) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MrHzb-0000eq-WC for avr-libc-corelib@nongnu.org; Fri, 25 Sep 2009 17:06:16 -0400 Received: from smtp-roam.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0624C77AEA for ; Fri, 25 Sep 2009 14:06:13 -0700 (PDT) Received: from mail-yx0-f173.google.com (mail-yx0-f173.google.com [209.85.210.173]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ruddick) by smtp-roam.stanford.edu (Postfix) with ESMTPSA id 4FB8877AD0 for ; Fri, 25 Sep 2009 14:06:12 -0700 (PDT) Received: by yxe3 with SMTP id 3so929400yxe.4 for ; Fri, 25 Sep 2009 14:06:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.226.13 with SMTP id y13mr967972agg.107.1253912771145; Fri, 25 Sep 2009 14:06:11 -0700 (PDT) From: Ruddick Lawrence Date: Fri, 25 Sep 2009 14:05:51 -0700 Message-ID: <604fcf830909251405o4cbcbcefx7d93856bbada98e2@mail.gmail.com> To: avr-libc-corelib@nongnu.org Content-Type: multipart/alternative; boundary=0016e64352644db21b04746d5185 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: [Avr-libc-corelib] repository structure X-BeenThere: avr-libc-corelib@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions about the development of the AVR " core library" " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 21:06:22 -0000 --0016e64352644db21b04746d5185 Content-Type: text/plain; charset=ISO-8859-1 I hope you're all not too tired of my infrastructure emails, but it has to be done so we can get to the good stuff. This one is about how to organize the CVS repo. Here is my proposal, based on my own thoughts and some of the mailing list discussion. Each module will have its own directory. The organization below this level is TBD (probably however avr-libc does it). The module directories will be organized into groups (we'll need a better name for this) based on functionality (perhaps a communications group, a time group, a protocol group, etc). In order to distinguish between development and stable code, there will be a stable branch that modules will be merged into once their APIs are stable (some of this might have to be changed depending on the best way to use CVS). There was some worry about code forever remaining "unstable," but as long as the focus is on the API being stable, I don't think it will be a problem. We could even have a set amount of time for a "release candidate" to be in testing before it automatically moves into stable (unless serious problems were found). I dont' know if development code should just be in the trunk, or a separate branch, or even a separate branch for each new module (someone with more development experience should chime in here). There would also be another branch for contributed code, which would basically just be a code dump. So that's what I'm envisioning. Send out any comments to the list. Ruddick --0016e64352644db21b04746d5185 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I hope you're all not too tired of my infrastructure emails, but it has= to be done so we can get to the good stuff. This one is about how to organ= ize the CVS repo. Here is my proposal, based on my own thoughts and some of= the mailing list discussion.

Each module will have its own directory. The organization below this le= vel is TBD (probably however avr-libc does it). The module directories will= be organized into groups (we'll need a better name for this) based on = functionality (perhaps a communications group, a time group, a protocol gro= up, etc).

In order to distinguish between development and stable code, there will= be a stable branch that modules will be merged into once their APIs are st= able (some of this might have to be changed depending on the best way to us= e CVS). There was some worry about code forever remaining "unstable,&q= uot; but as long as the focus is on the API being stable, I don't think= it will be a problem. We could even have a set amount of time for a "= release candidate" to be in testing before it automatically moves into= stable (unless serious problems were found). I dont' know if developme= nt code should just be in the trunk, or a separate branch, or even a separa= te branch for each new module (someone with more development experience sho= uld chime in here). There would also be another branch for contributed code= , which would basically just be a code dump.

So that's what I'm envisioning. Send out any comments to the li= st.
Ruddick
--0016e64352644db21b04746d5185--