From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24795 invoked by alias); 26 Jan 2012 18:32:45 -0000 Received: (qmail 24786 invoked by uid 22791); 26 Jan 2012 18:32:44 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Jan 2012 18:32:31 +0000 Received: by mail.ecoscentric.com (Postfix, from userid 48) id 906832F78007; Thu, 26 Jan 2012 18:32:29 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: unassigned@bugs.ecos.sourceware.org Subject: [Bug 1001442] LPC17XX bit band macro proposal X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: HAL X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: bernard.fouche@kuantic.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Thu, 26 Jan 2012 18:32:00 -0000 Message-Id: <20120126183225.CB6DA2F78005@mail.ecoscentric.com> Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-bugs-owner@sourceware.org X-SW-Source: 2012/txt/msg00151.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001442 --- Comment #5 from Bernard Fouch=C3=A9 2012-0= 1-26 18:32:19 GMT --- I did more reading on the topic (chapter 5, page 88 of "The Definitive Guid= e to the ARM Cortex-M3" by Joseph Yiu, google, datasheets etc.). Since gcc doesn't know about bit-band the only real advantage of bitband in= our case seems to replace atomic read-modify-write of a single bit, an operation that requires today to lock/unlock interrupts and/or DSR execution. This wo= uld be completely different with another compiler knowing about the bitband stu= ff, but in that case we would not need to care about bitband ;) SRAM is a problem: on some MCU, all SRAM can be accessed with bitband ops (STM32 but I looked only at 1 datasheet of this family: STM32F105xx/STM32F107xx). On other MCU, only parts of SRAM is eligible (LPC17XX/Kinetis). This is also the case for any MCU with external RAM. So bitband accesses for RAM can't be easily defined at the arch level, they could be defined only at platform level, probably by defining a RAM section with a specific name and then placing explicitly some variables in this section. But since accessing the concerned RAM also mean using specific mac= ros, because gcc knows nothing about bitband so it won't optimize accesses to the declared region, it's more likely this interest mainly the application, or drivers specific to a platform so RAM bitband ops can be provided by other means than the common HAL or arch HAL. GPIO: they can be mapped to peripheral memory or SRAM. However what to do w= ith a GPIO pin, once the pin is set as a GPIO pin, is quite simple: have the pin set to 0 or 1. I didn't look in the datasheets of several modern 32bits MCU, but if ever, for a MCU, setting a pin state requires a read-modify-write on= a register handling more than one pin, then bitband can also solve a problem = I've seen on smaller MCU: one pin is handled by a thread, another pin on the same port is used by another thread or an interrupt: any access to the involved = pin port must be atomic. LPC17XX, beside bitband, provides registers that allow clearing/setting a particular pin without troubling the other pins on the s= ame port, so in that case bitband isn't interesting. But if one knows of a MCU = that have no such registers, then bitband is an excellent solution because we are back to the problem of setting a single bit's value atomically. All in all, the only situation common to any M3/M4 MCU is when accessing a peripheral register, for operations clearing/setting a single bit, and especially if updating this bit must be done atomically. GPIO handling could be done also, but if there is no real need for it... New proposal (I'm ready to be flamed), higher level macros describe what th= ey must do, not how they do it: - common HAL offers: (I propose the common hal to allow code re-use for drivers while having dri= vers unaware of the bitband feature) - HAL_PERIPHERAL_BIT_SET(address,bit_number,bit_value): set a bit's value = in a peripheral register. Without bit-band it does a read-modify-write sequence = with HAL_READ/WRITE_UINT32(). However since this macro does not provide any real gain even with bitband ops, it could be avoided. - HAL_PERIPHERAL_BIT_SET_ATOMIC(ptr_to_lock_function, ptr_to_unlock_function, address, bit_number, bit_value) Without bitband, it does the job of HAL_PERIPHERAL_BIT_SET() but bordered with calls to the lock/unlock function (Function arguments could be removed= and have the macro to always use ISR lock/unlock, or the macro name could state= if it is atomic regarding ISR, DSR or thread, choose whatever fits eCos the mo= st). - cortex-M HAL (cdl) has interface 'HAL_PERIPHERAL_BITBAND'. - cortex-M HAL (include) defines bitband macros for peripheral area, so mac= ro names won't change between different platforms. The peripheral macro could = be what I initially proposed. - LPC17XX/STM32 and other concerned MCU implement this interface. Platforms having chips without bitband (M0, M1, M4 without bb option) do not. - LPC17XX platform also includes SRAM & GPIO macros, to avoid users re-inventing the wheel (and using different names) if they need the macros. Kinetis/STM32/Anything users/maintainers choose to do the same or not. - When 'HAL_PERIPHERAL_BITBAND' is implemented, HAL_PERIPHERAL_BIT_SET{_ATO= MIC} resolve(s) to bitband op(s) in the peripheral area only. - GPIO / SRAM bitband accesses are let to user code and/or platform specific drivers. Bernard --=20 Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=3Demail ------- You are receiving this mail because: ------- You are the assignee for the bug. >>From ecos-bugs-return-8723-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Jan 26 18:32:48 2012 Return-Path: Delivered-To: listarch-ecos-bugs@sources.redhat.com Received: (qmail 24860 invoked by alias); 26 Jan 2012 18:32:47 -0000 Received: (qmail 24832 invoked by uid 22791); 26 Jan 2012 18:32:46 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Jan 2012 18:32:31 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 8021F2F78001 for ; Thu, 26 Jan 2012 18:32:29 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5xWA7ffHpCF; Thu, 26 Jan 2012 18:32:29 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1001442] LPC17XX bit band macro proposal X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: HAL X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: bernard.fouche@kuantic.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Thu, 26 Jan 2012 18:32:00 -0000 Message-Id: <20120126183226.135672F78006@mail.ecoscentric.com> Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-bugs-owner@sourceware.org Delivered-To: mailing list ecos-bugs@sourceware.org X-SW-Source: 2012/txt/msg00152.txt.bz2 Content-length: 4940 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001442 --- Comment #5 from Bernard Fouch=C3=A9 2012-0= 1-26 18:32:19 GMT --- I did more reading on the topic (chapter 5, page 88 of "The Definitive Guid= e to the ARM Cortex-M3" by Joseph Yiu, google, datasheets etc.). Since gcc doesn't know about bit-band the only real advantage of bitband in= our case seems to replace atomic read-modify-write of a single bit, an operation that requires today to lock/unlock interrupts and/or DSR execution. This wo= uld be completely different with another compiler knowing about the bitband stu= ff, but in that case we would not need to care about bitband ;) SRAM is a problem: on some MCU, all SRAM can be accessed with bitband ops (STM32 but I looked only at 1 datasheet of this family: STM32F105xx/STM32F107xx). On other MCU, only parts of SRAM is eligible (LPC17XX/Kinetis). This is also the case for any MCU with external RAM. So bitband accesses for RAM can't be easily defined at the arch level, they could be defined only at platform level, probably by defining a RAM section with a specific name and then placing explicitly some variables in this section. But since accessing the concerned RAM also mean using specific mac= ros, because gcc knows nothing about bitband so it won't optimize accesses to the declared region, it's more likely this interest mainly the application, or drivers specific to a platform so RAM bitband ops can be provided by other means than the common HAL or arch HAL. GPIO: they can be mapped to peripheral memory or SRAM. However what to do w= ith a GPIO pin, once the pin is set as a GPIO pin, is quite simple: have the pin set to 0 or 1. I didn't look in the datasheets of several modern 32bits MCU, but if ever, for a MCU, setting a pin state requires a read-modify-write on= a register handling more than one pin, then bitband can also solve a problem = I've seen on smaller MCU: one pin is handled by a thread, another pin on the same port is used by another thread or an interrupt: any access to the involved = pin port must be atomic. LPC17XX, beside bitband, provides registers that allow clearing/setting a particular pin without troubling the other pins on the s= ame port, so in that case bitband isn't interesting. But if one knows of a MCU = that have no such registers, then bitband is an excellent solution because we are back to the problem of setting a single bit's value atomically. All in all, the only situation common to any M3/M4 MCU is when accessing a peripheral register, for operations clearing/setting a single bit, and especially if updating this bit must be done atomically. GPIO handling could be done also, but if there is no real need for it... New proposal (I'm ready to be flamed), higher level macros describe what th= ey must do, not how they do it: - common HAL offers: (I propose the common hal to allow code re-use for drivers while having dri= vers unaware of the bitband feature) - HAL_PERIPHERAL_BIT_SET(address,bit_number,bit_value): set a bit's value = in a peripheral register. Without bit-band it does a read-modify-write sequence = with HAL_READ/WRITE_UINT32(). However since this macro does not provide any real gain even with bitband ops, it could be avoided. - HAL_PERIPHERAL_BIT_SET_ATOMIC(ptr_to_lock_function, ptr_to_unlock_function, address, bit_number, bit_value) Without bitband, it does the job of HAL_PERIPHERAL_BIT_SET() but bordered with calls to the lock/unlock function (Function arguments could be removed= and have the macro to always use ISR lock/unlock, or the macro name could state= if it is atomic regarding ISR, DSR or thread, choose whatever fits eCos the mo= st). - cortex-M HAL (cdl) has interface 'HAL_PERIPHERAL_BITBAND'. - cortex-M HAL (include) defines bitband macros for peripheral area, so mac= ro names won't change between different platforms. The peripheral macro could = be what I initially proposed. - LPC17XX/STM32 and other concerned MCU implement this interface. Platforms having chips without bitband (M0, M1, M4 without bb option) do not. - LPC17XX platform also includes SRAM & GPIO macros, to avoid users re-inventing the wheel (and using different names) if they need the macros. Kinetis/STM32/Anything users/maintainers choose to do the same or not. - When 'HAL_PERIPHERAL_BITBAND' is implemented, HAL_PERIPHERAL_BIT_SET{_ATO= MIC} resolve(s) to bitband op(s) in the peripheral area only. - GPIO / SRAM bitband accesses are let to user code and/or platform specific drivers. Bernard --=20 Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=3Demail ------- You are receiving this mail because: ------- You are on the CC list for the bug. >>From ecos-bugs-return-8724-listarch-ecos-bugs=sources.redhat.com@sourceware.org Fri Jan 27 17:39:10 2012 Return-Path: Delivered-To: listarch-ecos-bugs@sources.redhat.com Received: (qmail 21781 invoked by alias); 27 Jan 2012 17:39:08 -0000 Received: (qmail 21673 invoked by uid 22791); 27 Jan 2012 17:39:07 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Jan 2012 17:38:54 +0000 Received: by mail.ecoscentric.com (Postfix, from userid 48) id C2B332F78001; Fri, 27 Jan 2012 17:38:53 +0000 (GMT) X-Original-To: unassigned@bugs.ecos.sourceware.org Delivered-To: unassigned@bugs.ecos.sourceware.org From: bugzilla-daemon@bugs.ecos.sourceware.org To: unassigned@bugs.ecos.sourceware.org Subject: [Bug 1001466] New: /dev/null serial driver X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: bernard.fouche@kuantic.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Fri, 27 Jan 2012 17:39:00 -0000 Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-bugs-owner@sourceware.org Delivered-To: mailing list ecos-bugs@sourceware.org X-SW-Source: 2012/txt/msg00153.txt.bz2 Content-length: 1191 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001466 Summary: /dev/null serial driver Product: eCos Version: CVS Platform: All OS/Version: All Status: UNCONFIRMED Severity: enhancement Priority: low Component: Patches and contributions AssignedTo: unassigned@bugs.ecos.sourceware.org ReportedBy: bernard.fouche@kuantic.com CC: ecos-patches@ecos.sourceware.org Class: Advice Request Try to mimick /dev/null. (inspired by loop serial driver.) $ tar tf devnull.tar null/ null/current/ null/current/cdl/ null/current/cdl/ser_null.cdl null/current/src/ null/current/src/null_serial.c null/current/ChangeLog null/current/doc/ null/current/doc/null_serial.sgml $ Comments welcome, maybe the semantics aren't close enough to Un*x but it should do the job for most cases. The doc may need to be rewritten? Bernard -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.