[Bug 1001787] GPIO Interrupt Support for Kinetis

[bugzilla-daemon at bugs dot ecos dot sourceware dot 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.