<div dir="ltr"><div>Do you have a makefile that will enable me to build the app?<br></div><div>Thanks</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 22, 2015 at 4:14 PM, Steve B <span dir="ltr"><<a href="mailto:sbattazzo@gmail.com" target="_blank">sbattazzo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Sure, here is an updated version.<br></div>I erased commented out code lines that I wasn't using anymore.<br><br></div>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.<br><br></div>"Test task" is periodic, runs every two seconds and toggles GPIO1_13 on and off.<br><br></div>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.<br><br></div><div>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!<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888">Steve<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 21, 2015 at 10:53 PM, Angelo Fraietta <span dir="ltr"><<a href="mailto:newsgroups@smartcontroller.com.au" target="_blank">newsgroups@smartcontroller.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">When you have it going I would really like to see what you have done. </div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Jun 22, 2015 at 3:43 PM, Steve B <span dir="ltr"><<a href="mailto:sbattazzo@gmail.com" target="_blank">sbattazzo@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div><div>UPDATE:<br></div>Found my answer on the ISR causing reset.<br></div>The answer was: "Do not call puts() from the ISR!"<br></div><div>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.<br></div><br></div><div>Instead I did something with the user LEDs to convince myself that the ISR was being reached, and now I'm happy.<br><br></div><div>Still not sure what's up with JTAG loading.. seems like I have to reset the processor between exe reloads.<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div><br></div>Steve<br><br><br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 21, 2015 at 10:13 PM, Steve B <span dir="ltr"><<a href="mailto:sbattazzo@gmail.com" target="_blank">sbattazzo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hello all,<br><br></div>I'm playing around with getting an interrupt service routine going on Beaglebone Black.<br><br></div>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.<br><br></div><div>Here's what I have done:<br></div><div>1. Set GPIO1_13 as an output, physically jumped GPIO1_13 (P8, 11) to GPIO1_12 (P8, 12).<br></div><div>2. Set bit (1 << 12) to the GPIO_IRQENABLE_SET_1 and GPIO_IRQENABLE_SET_0 registers for GPIO1, per AM338x technical reference manual.<br></div><div>3. Set bit (1 << 12) to the GPIO_RISINGDETECT register for GPIO1. <br></div><div>4. Installed an ISR to GPIO number 98 or 99 which is the IRQ for GPIO1. <br><br></div><div>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.<br><br><div>I may be close but something is not quite right here.<br></div>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?<br>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.<br><br></div><div>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?<br><br></div><div><br></div><div><br></div><div>Thanks,<br><br></div><div>Steve<br></div><div><br></div><div><br><br></div></div>
</blockquote></div><br></div>
</div></div><br></div></div>_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>