public inbox for ecos-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug 1001787] New: GPIO Interrupt Support for Kinetis
@ 2013-03-02 18:25 bugzilla-daemon
  2013-03-02 20:03 ` [Bug 1001787] " bugzilla-daemon
  2013-03-17 14:00 ` bugzilla-daemon
  0 siblings, 2 replies; 3+ messages in thread
From: bugzilla-daemon @ 2013-03-02 18:25 UTC (permalink / raw)
  To: unassigned

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001787

            Bug ID: 1001787
           Summary: GPIO Interrupt Support for Kinetis
           Product: eCos
           Version: CVS
            Target: All
  Architecture/Host Cortex-M
                OS:
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Patches and contributions
          Assignee: unassigned@bugs.ecos.sourceware.org
          Reporter: mjones@linear.com
                CC: ecos-patches@ecos.sourceware.org

Created attachment 2113
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2113&action=edit
Support Kinetis GPIO interrupts and add set/get API

This patch adds to the Kinetis GPIO macros and API. It allows code to accept an
interrupt on a port by applying a configuration call, getting the interrupt,
and clearing the interrupt. I also added API for set/get of pins. The interrupt
is well tested on one port and pin. The set/get underlying macro was tested on
a pin before writing the API. The API is coded in a simple manner such that by
inspection if the original macros work, the API will work.

I don't have a mechanism to test interrupts on multiple pins/ports. So strictly
speaking, I can only say it is very robust using the example below. The code is
simple enough I feel save putting this code in CVS. However, if anyone has
hardware that would allow more testing, please do so if you have time.

If anyone is unhappy with the API, I am happy to make changes, retest, and send
a new patch.

An example:

#define ALERT_PORT 0
#define ALERT_PIN 19

cyg_uint32 alert_isr( cyg_vector_t vector,
                              cyg_addrword_t data
)
{
    cyg_interrupt_mask(CYGNUM_HAL_INTERRUPT_PORTA);
    hal_kinetis_gpio_interrupt_acknowledge(ALERT_PORT, ALERT_PIN);

    // Do a little critical work.

    return CYG_ISR_HANDLED | CYG_ISR_CALL_DSR;
}

void alert_dsr( cyg_vector_t vector,
                        cyg_ucount32 count,
                        cyg_addrword_t data
                      )
{
    cyg_flag_setbits(&alert_flag, 0x01);
    cyg_interrupt_unmask(CYGNUM_HAL_INTERRUPT_PORTA);
}



    cyg_interrupt_create(
            CYGNUM_HAL_INTERRUPT_PORTA, // Vector
            0xA0,                         // Priority
            (cyg_addrword_t)0,             // Data
            alert_isr,                     // ISR
            alert_dsr,                     // DSR
            &alert_handle,                 // Handle
            &alert_interrupt);            // INTR

    cyg_interrupt_attach(alert_handle);

    hal_kinetis_gpio_setup_port(ALERT_PORT, ALERT_PIN, 0xA, 0x1, 0x00);
    hal_kinetis_gpio_interrupt_acknowledge(ALERT_PORT, ALERT_PIN);
    cyg_interrupt_unmask(CYGNUM_HAL_INTERRUPT_PORTA);

-- 
You are receiving this mail because:
You are the assignee for the bug.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug 1001787] GPIO Interrupt Support for Kinetis
  2013-03-02 18:25 [Bug 1001787] New: GPIO Interrupt Support for Kinetis bugzilla-daemon
@ 2013-03-02 20:03 ` bugzilla-daemon
  2013-03-17 14:00 ` bugzilla-daemon
  1 sibling, 0 replies; 3+ messages in thread
From: bugzilla-daemon @ 2013-03-02 20:03 UTC (permalink / raw)
  To: unassigned

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001787

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2113|0                           |1
           is patch|                            |
   Attachment #2113|application/octet-stream    |text/plain
          mime type|                            |

-- 
You are receiving this mail because:
You are the assignee for the bug.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug 1001787] GPIO Interrupt Support for Kinetis
  2013-03-02 18:25 [Bug 1001787] New: GPIO Interrupt Support for Kinetis bugzilla-daemon
  2013-03-02 20:03 ` [Bug 1001787] " bugzilla-daemon
@ 2013-03-17 14:00 ` bugzilla-daemon
  1 sibling, 0 replies; 3+ messages in thread
From: bugzilla-daemon @ 2013-03-17 14:00 UTC (permalink / raw)
  To: unassigned

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001787

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk
           Assignee|unassigned@bugs.ecos.source |ilijak@siva.com.mk
                   |ware.org                    |

--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> ---
Hi Mike

Thank you for your contribution. Now I have a little time to see your macros
and functions, but my ability for testing is limited.

Interrupt support:

To begin with, I should have added __irqc parameter to CYGHWR_HAL_KINETIS_PIN()
from the beginning.
CYGHWR_HAL_KINETIS_SETUP_PIN() corrects my mistake but I would avoid the
assignment operation in this macro in order to allow it's usage in arrays. It
is usually necesary to set several pins at once. Than we can define an array
and call macro HAL_SET_PINS() (See Ethernet, Flexbus and DDRAM drivers for use
cases). Therefore I propose following modification of your macro (then my
original macro will be a special case with __irqc = 0):

// Pin configuration descriptor PinCD
// PinCD is a 32 bit unsigned integer which contains configuration information
// for one pin. This macro produces PinCD based on following parameters:
//     __port - Port name, [A, F]
//     __bit  - Port bit [0, 31]
//     __mux  - Multiplexer index [0, 7]
//     __irqc - Interrupt configuration [0, F]
//     __cnf  - Configuration options

#define CYGHWR_HAL_KINETIS_PINCD(__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))

// PinCD with disabled interrupts. (For backward compatibility)
#define CYGHWR_HAL_KINETIS_PIN(__port, __bit, __mux, __cnf) \
        CYGHWR_HAL_KINETIS_PIN_CNF(__port, __bit, __mux, 0, __cnf)

The interrupt acknowledge function should be designed with efficiency in mind
so I would avoid switch even though it requires direct coding instead of using
macros.

Bit manipulation functions: Having such macros already, bit manipulation
functions seem redundant to me. Is there a use case where we must use function
(rather than macro)?

This is all for now.

Ilija

-- 
You are receiving this mail because:
You are the assignee for the bug.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-03-17 14:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-02 18:25 [Bug 1001787] New: GPIO Interrupt Support for Kinetis bugzilla-daemon
2013-03-02 20:03 ` [Bug 1001787] " bugzilla-daemon
2013-03-17 14:00 ` bugzilla-daemon

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).