From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20061 invoked by alias); 20 Mar 2013 07:28:02 -0000 Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org Received: (qmail 20041 invoked by uid 89); 20 Mar 2013 07:27:53 -0000 X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 20 Mar 2013 07:27:49 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 5067C4680007 for ; Wed, 20 Mar 2013 07:27:47 +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 ScyAYgcRvCxY; Wed, 20 Mar 2013 07:27:42 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001787] GPIO Interrupt Support for Kinetis Date: Wed, 20 Mar 2013 07:28:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: mjones@linear.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: ilijak@siva.com.mk X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-03/txt/msg00028.txt.bz2 Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001787 --- Comment #4 from Mike Jones --- Ilija, I ordered the parameters to correspond to the order in the registers on the assumption that people will read the register manual to understand what they do and think of them in that order. But I don't have any strong attachment to the order, so I have changed to: #define CYGHWR_HAL_KINETIS_PIN_CFG(__port, __bit, __mux, __irqc, __cnf) \ ((CYGHWR_HAL_KINETIS_PORT##__port << 20) | ((__bit) << 27) \ | CYGHWR_HAL_KINETIS_PORT_PCR_IRQC(__irqc) \ | CYGHWR_HAL_KINETIS_PORT_PCR_MUX(__mux) | (__cnf)) #define CYGHWR_HAL_KINETIS_PIN(__port, __bit, __mux, __cnf) \ CYGHWR_HAL_KINETIS_PIN_CFG(__port, __bit, __mux, 0, __cnf) __externC void hal_kinetis_gpio_setup_port(cyg_uint32 port, cyg_uint32 pin, cyg_uint8 mux, cyg_uint8 irqc, cyg_uint8 config) { CYG_ASSERT((port >= 0 && port <= 4), "GPIO ACK PORT must be 0-4"); CYG_ASSERT((port >= 0 && port <= 31), "GPIO ACK PIN must be 0-31"); switch(port) { case 0: hal_set_pin_function(CYGHWR_HAL_KINETIS_PIN_CFG(A, pin, mux, irqc, config)); break; case 1: hal_set_pin_function(CYGHWR_HAL_KINETIS_PIN_CFG(B, pin, mux, irqc, config)); break; case 2: hal_set_pin_function(CYGHWR_HAL_KINETIS_PIN_CFG(C, pin, mux, irqc, config)); break; case 3: hal_set_pin_function(CYGHWR_HAL_KINETIS_PIN_CFG(D, pin, mux, irqc, config)); break; case 4: hal_set_pin_function(CYGHWR_HAL_KINETIS_PIN_CFG(E, pin, mux, irqc, config)); break; default: break; } } The reason I did not recode the interrupt acknowledge was I could see no way to avoid a conditional without a macro. Some logic has to decide on the register to use and that has to either be conditional logic in code, or hard coding the application via multiple API calls for each case, or a macro. I would prefer not to use macros in application code for a bunch of reasons that are not pure technical. I always write application code using these preferences with 1 being the highest preference: 1) Platform independent C/C++ 2) Platform dependent C/C++ 3) Macro This tends to result in the smallest use of flash and in the case of gpio would cause no performance issues, because I have no code that would ever read/write gpio in loops, as I would always use SPI, I2C, UART, Ethernet and standard IO peripherals for communication. If I needed very fast parallel performance, I would try to find a way to memory map it. Also, gpio interrupts are very rare events without a strong latency sensitivity. I don't expect this to be true for every application, but the macros are always available for those that need more performance. But in my case, memory is the biggest constraint, not gpio. gpio performance is way done on the list of my problems. As for being conservative about new API, I'm with Faust, "be careful what you ask for in youth, you may receive it in middle age." -- You are receiving this mail because: You are on the CC list for the bug.