public inbox for ecos-patches@sourceware.org
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <bug-1001787-104-avfrvjirRh@http.bugs.ecos.sourceware.org/> (raw)
In-Reply-To: <bug-1001787-104@http.bugs.ecos.sourceware.org/>

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 <mjones@linear.com> ---
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.

  parent reply	other threads:[~2013-03-20  7:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-02 18:25 [Bug 1001787] New: " bugzilla-daemon
2013-03-02 20:03 ` [Bug 1001787] " bugzilla-daemon
2013-03-17 14:00 ` bugzilla-daemon
2013-03-19 22:37 ` bugzilla-daemon
2013-03-20  7:28 ` bugzilla-daemon [this message]
2013-04-06 14:57 ` bugzilla-daemon
2013-04-06 15:01 ` bugzilla-daemon
2013-04-07 20:33 ` bugzilla-daemon
2013-06-12 21:34 ` bugzilla-daemon
2013-06-13 19:17 ` bugzilla-daemon
2017-02-15  7:35 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-1001787-104-avfrvjirRh@http.bugs.ecos.sourceware.org/ \
    --to=bugzilla-daemon@bugs.ecos.sourceware.org \
    --cc=ecos-patches@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).