RTEMS on Beaglebone Black

Joel Sherrill joel.sherrill at oarcorp.com
Tue Jul 28 16:01:21 UTC 2015



On 7/28/2015 8:39 AM, Mr. Andrei Chichak wrote:
> Hey Angelo,
>
> If you have about an hour, listen to the embedded.fm podcast #110 (www.embedded.fm <http://www.embedded.fm> or iTunes). They talk with Jason Kridner of Beagleboard.org <http://Beagleboard.org>, also from TI. He wants people to send him queries about the Beagle Boards, like your pinout questions.
>
> RTEMS even comes up in the conversation.
>

I saw a tweet on this last week. I need to listen to Jason also.
He is a nice guy and the embedded.fm podcast is a great resource.

Thanks to Andrei, a podcast with me is in the recent ones. :)

--joel

> Andrei
>
>
>
>
>> On 2015-July-28, at 01:19, Angelo Fraietta <newsgroups at smartcontroller.com.au <mailto:newsgroups at smartcontroller.com.au>> wrote:
>>
>> I can confirm that the interrupts do work, however, it is on both edges, not just the rising.
>> I wanted to see what sort of performance I could get out of the interrupts by inputting various frequency signals
>> I modified the code so 13 would toggle every 8 interrupts. It toggled after four full pulses, therefore it interrupted on both edges (see code at end)
>>
>> Also, I found that it took 1.3us to service the interrupt (I measured the time between the edge of interrupt pin and the toggle point of 13). The beagle is supposed to be 1 1GHz machine. Is there any way I can push faster than 1.3us with a setting in RTEMS (eg nanoseconds per tick) or is 1.3us my absolute best?
>>
>> Thanks
>>
>>
>> //ISR:
>> rtems_isr GPIO1_IRQHandler (rtems_vector_number vector)
>> {
>>   static int i = 0;
>>
>>   i++;
>>   //Toggle other three LEDs here:
>>   *(unsigned long *)(GPIO1_ADDR+GPIO_DATAOUT) ^= ((1<<22)| (1<<23) |(1<<24));
>>   //Clear interrupt:
>>   //Per AM335x technical reference manual, we can read IRQSTATUS,
>>   // and then write corresponding bits on IRQSTATUS to clear whichever one was serviced.
>>   // in this application it's hard coded to number 12 so I just write that bit.
>>   // For some reason writing IRQSTATUS value back to itself doesn't clear the interrupt.
>>   unsigned long irqstat = *(unsigned long*)(GPIO1_ADDR + GPIO_IRQSTATUS_1);
>>   *(unsigned long*)(GPIO1_ADDR + GPIO_IRQSTATUS_1) = (1<<12);
>>
>>   // we will toggle every
>>   //*(unsigned long*)(GPIO1_ADDR + GPIO_IRQSTATUS_1) = irqstat;
>>   if (!(i % 4))
>>     {
>>     *(unsigned long *)(GPIO1_ADDR+GPIO_DATAOUT) ^= (1<<13);
>>     }
>> }
>>
>>
>> On Tue, Jul 28, 2015 at 1:54 AM, Steve B <sbattazzo at gmail.com <mailto:sbattazzo at gmail.com>> wrote:
>>
>>     Hi Angelo,
>>
>>     Here's a handy diagram that shows which ones are which (found on Google Images):
>>     http://cholla.mmto.org/computers/beagle/hardware/pinout1-1024x585.png
>>
>>     GPIO1_12 is connector P8 pin 12. I think I used the adjacent pin (P8 pin 11, or GPIO1_13) and installed a jumper wire between the two.
>>     I think it says so in my comments too but I know that may not exactly jump out.
>>
>>     Steve
>>
>>
>>     On Sun, Jul 26, 2015 at 6:38 PM, Angelo Fraietta <newsgroups at smartcontroller.com.au <mailto:newsgroups at smartcontroller.com.au>> wrote:
>>
>>         Greetings Steve, I have modified your code so the standard task only toggles one LED and the interrupt on GPIO12 should toggle the other 3. However, IO cannot for the life of me find which pin is GPIO12 so I can test on the hardware. I have posted the code with the mods I made at the bottom of this email
>>
>>         http://beagleboard.org/support/bone101
>>
>>         What physical pin should I be toggling to make it work?
>>
>>         Thanks
>>
>>
>>
>> _______________________________________________
>> users mailing list
>> users at rtems.org <mailto:users at rtems.org>
>> http://lists.rtems.org/mailman/listinfo/users
>
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985


More information about the users mailing list