Beaglebone Black GPIO Interrupt, and minor JTAG/gdb issue

[Steve B]

Yes, off the top of my head that's what I did.. just need to loop those two
pins together and it should work!

On Thu, Jul 2, 2015 at 11:58 PM, Angelo Fraietta <
newsgroups at smartcontroller.com.au> wrote:

> I have the program running now. Have not tried the interrupts yet but will
> give it a quick go next week. From the code it looks like you do a toggle
> on all 4 LEDS when an interrupt occurs. Is that correct?
>
> On Wed, Jul 1, 2015 at 7:10 AM, Angelo Fraietta <
> newsgroups at smartcontroller.com.au> wrote:
>
>> Thanks. I am still getting the error trying to make.
>>
>> On Wed, Jul 1, 2015 at 3:15 AM, Steve B <sbattazzo at gmail.com> wrote:
>>
>>> Hi Angelo,
>>>
>>> You should just need these three files in the same folder, and you need
>>> to have the RTEMS compiler in your path and the RTEMS_MAKEFILE_PATH defined.
>>>
>>> Steve
>>>
>>> On Mon, Jun 29, 2015 at 8:00 PM, Angelo Fraietta <
>>> newsgroups at smartcontroller.com.au> wrote:
>>>
>>>> That would be great. Thanks
>>>>
>>>> On Tue, Jun 30, 2015 at 11:50 AM, Steve B <sbattazzo at gmail.com> wrote:
>>>>
>>>>> Hi Angelo. I just used the makefile from an application in the
>>>>> examples-v2 repo that's available on github, and I also copied some header
>>>>> file from there into my application folder because I wanted my own folder
>>>>> tree instead of a new one in examples-v2.
>>>>> I am away from the office today but can send it tomorrow if you need
>>>>> it.
>>>>> On Jun 28, 2015 4:45 PM, "Angelo Fraietta" <
>>>>> newsgroups at smartcontroller.com.au> wrote:
>>>>>
>>>>>> 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/20150705/84f334f5/attachment-0002.html>