Beaglebone Black GPIO Interrupt, and minor JTAG/gdb issue

[Angelo Fraietta]

Do you have a makefile that will enable me to build the app?
Thanks

On Mon, Jun 22, 2015 at 4:14 PM, Steve B <sbattazzo at gmail.com> wrote:

> 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/20150629/fc5923d2/attachment-0002.html>