Beaglebone Black GPIO Interrupt, and minor JTAG/gdb issue

[Steve B]

Sure, here is an updated version.
I erased commented out code lines that I wasn't using anymore.

The "init" task sets up GPIO (user LEDs as outputs) and interrupt stuff
(GPIO1_12 as a rising edge trigger), and then ducks out of the way.

"Test task" is periodic, runs every two seconds and toggles GPIO1_13 on and
off.

With GPIO1_13 shorted to GPIO1_12), the ISR fires off, and toggles all four
LEDs. Since we're waiting for the periodic task to toggle twice, the LEDs
will toggle once every four seconds.

This isn't really the "right" way to do this.. so if there weren't already
plans to integrate this functionality into the GPIO API that's in the
pipeline, I'd like to help get it in there!

Steve

On Sun, Jun 21, 2015 at 10:53 PM, Angelo Fraietta <
newsgroups at smartcontroller.com.au> wrote:

> When you have it going I would really like to see what you have done.
>
> On Mon, Jun 22, 2015 at 3:43 PM, Steve B <sbattazzo at gmail.com> wrote:
>
>> UPDATE:
>> Found my answer on the ISR causing reset.
>> The answer was: "Do not call puts() from the ISR!"
>> I don't really know why this is the case, but I was a little hesitant
>> about using the puts() in the first place, but did it anyway out of
>> laziness. If I really wanted to print info I guess I could make another
>> task and trip it with a semaphore or similar from the ISR.
>>
>> Instead I did something with the user LEDs to convince myself that the
>> ISR was being reached, and now I'm happy.
>>
>> Still not sure what's up with JTAG loading.. seems like I have to reset
>> the processor between exe reloads.
>>
>> Steve
>>
>>
>>
>> On Sun, Jun 21, 2015 at 10:13 PM, Steve B <sbattazzo at gmail.com> wrote:
>>
>>> Hello all,
>>>
>>> I'm playing around with getting an interrupt service routine going on
>>> Beaglebone Black.
>>>
>>> I am aware that Ketul with GSoC is working on the GPIO code but for now
>>> I have just decided to manually peek and poke the registers from my
>>> application code, as I didn't see anything IRQ related yet in the patch on
>>> the github site for that effort.
>>>
>>> Here's what I have done:
>>> 1. Set GPIO1_13 as an output, physically jumped GPIO1_13 (P8, 11) to
>>> GPIO1_12 (P8, 12).
>>> 2. Set bit (1 << 12) to the GPIO_IRQENABLE_SET_1 and
>>> GPIO_IRQENABLE_SET_0 registers for GPIO1, per AM338x technical reference
>>> manual.
>>> 3. Set bit (1 << 12) to the GPIO_RISINGDETECT register for GPIO1.
>>> 4. Installed an ISR to GPIO number 98 or 99 which is the IRQ for GPIO1.
>>>
>>> I hacked this into the "ticker" demo from examples-v2 and added a line
>>> of code to toggle GPIO1_13 in the periodic task to stimulate the interrupt.
>>>
>>> I may be close but something is not quite right here.
>>> Whenever the interrupt happens, the CPU resets and runs the uboot that
>>> is stored on its eMMC instead of going to my ISR. Any thoughts on why that
>>> might be?
>>> Attaching my code here also. Sorry it's kind of an ugly hack for now, I
>>> just punched a few lines of code into the ticker example.
>>>
>>> And an unrelated note, anytime I do a "load" and run my application
>>> through GDB, if I try to halt and load again, the CPU always starts from
>>> uboot on the eMMC and I have to halt and load one extra time. This is with
>>> flyswatter2 and OpenOCD. Anyone experienced this?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Steve
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20150621/f6f59cfc/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: init.c
Type: text/x-csrc
Size: 4375 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20150621/f6f59cfc/attachment-0002.bin>