ts-7000
[Top] [All Lists]

Re: [ts-7000] Re: Question about an interrupt handler and debounce

To:
Subject: Re: [ts-7000] Re: Question about an interrupt handler and debounce
From: Per Öberg <>
Date: Wed, 02 Jul 2008 07:51:28 +0200
Thanks for the tip, it helped a little but i still have no idea what's
going on in my OS. =)

I'm starting a new thread for this.

Per Öberg

David Hawkins wrote:
> Hi Per Öberg,
>
>> I'm currently developing a small os for my TS7250 as a course project
>> and i thought that it would be nice to do something like this.
>
> I ported the uCOS-II OS to the ARM LPC2000 series of micros.
>
> http://www.ovro.caltech.edu/~dwh/ucos/project_AR1803.pdf
> http://www.ovro.caltech.edu/~dwh/ucos/gcc_and_ucosii.zip
>
> The initial section of that document is independent of the OS
> used, and covers the setup of the ARM interrupt controller
> for FIQ and IRQ interrupts, and interrupt nesting.
> I'm not sure if the EP9302 controller is the same, but
> perhaps the above document could be of use to you.
>
> Cheers,
> Dave
>
>
>> I have come to the conclusion that using interrupts for this only messes
>> things up.
>>
>> Reason 1)
>> I am using the 8pin matrix keypad from TS and i have used 4 pins as
>> output and 4 as input. The four outputs are supposed to sink the four
>> inputs which works nicely without any pullups. I thought it would be
>> nice to set all outputs to zero and wait for a change on some of the
>> pins to go low (or high again) before scanning the keybord. This
>> approach only allows me to react on change from one key of each row at a
>> time so pushing more than one key at a time does not work with this
>> setup. Polling each 5 ms would allow me to react on a least 2 keys and
>> at most 4 keys at once depending on which keys are pressed.
>>
>> Reason 2)
>> I'm getting spurious interrupts when i disable and re enable the
>> interrupts for the GPIO (and yes, i have read the documentation for the
>> EP9302 and i'm using the procedure suggested there). I was trying to
>> program the VIC on my TS board to let the GPIO be a fast interrupt that
>> had precedence over the usual interrupt source but right now everything
>> is a mess. I guess you wont be running in to this one though since
>> you're not developing an entire OS.
>>
>> Regards
>> Per Öberg
>>
>>
>> David Farrell wrote:
>>> I'm not sure I would do this the same way. Why Interrupts? how soon do
>>> you need to respond to the key?  Pthreads run fine on TS-XXXX, create
>>> a separate thread to output row and read columns.
>>> If you need interrupts, stepping to the next row should disable the
>>> drive of the current (pressed) key so should reduce the time you need
>>> to wait for debounce, you may not even need to disable the interrupt.
>>>  Be sure to have pullups on the columns so un-driven return to
>>> inactive, only active row would be driven low. DO as little as
>>> possible in the isr.
>>>
>>> --- In  "bdon003" <> wrote:
>>>> I am using the ts-7300 for my senior design project, and I am
>>>> preparing to write a Linux driver for it.  Everything on the board is
>>>> pretty much how I got it, same kernel and everything.  I need to hook
>>>> up a 3x4 Matrix Keypad to the board and have it send an interrupt when
>>>> a key has been pressed.  I am going to connect the three column data
>>>> lines from the keypad to interrupt-enabled I/O pins on one of the
>>>> headers, and then the row data lines will be connected to the same
>>>> header but without interrupts enabled.  Will I need to worry about
>>>> debounce control inside the handler?  What I obviously don't want is
>>>> more than one interrupt to be sent for only one key press.  I am still
>>>> doing some more reading on drivers but my plan is:
>>>> 1. Disable interrupts associated with the keypad
>>>> 2. Read from the header what key was pressed and store it in the next
>>>> cell of an array
>>>> 3. Signal that a tasklet needs to be run to do the overall
>>>> processing/checking of the entered code so far
>>>> 4. Increment the counter keeping track of the next available cell in
>>>> the array
>>>> 5. Re-enable the disabled interrupts
>>>>
>>>> Will this solve my problem?   It seems that if the time it takes for
>>>> the key to settle is longer than the time it takes to do those five
>>>> steps, then I would need to do some adjusting.  What is a better way
>>>> to do this?  Thanks for any help
>>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
--
Per Öberg, Ph.D. Student
Address: Division of Vehicular Systems
Department of Electrical Engineering
Linköpings universitet
581 83 Linköping, SWEDEN
Phone: +46 (0)13-28 23 69
e-mail: 
PGP: http://www.fs.isy.liu.se/~oberg/0x61984A9D.asc

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ts-7000/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/ts-7000/join
    (Yahoo! ID required)

<*> To change settings via email:
    
    

<*> To unsubscribe from this group, send an email to:
    

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Attachment: oberg.vcf
Description: Vcard

<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU