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