<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher <<a href="mailto:nilhoel1@gmail.com" target="_blank">nilhoel1@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>Regarding the PRU.</div><div>I was able to load code to the PRU.</div><div>However I wasn't able to map IRQ interrupts to the PRU, thus unable to communicate with it in a meaningful way</div></div></blockquote><div><br></div><div><div><br></div><div>Just a small addition, AFAIK the issue with this was the fact that mmap() would always fail.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>.</div><div>Also I don't think that this project should be continued without a full DEBUGGING Setup.</div></div></blockquote><div><br></div><div>+1, without a proper debugging setup I found it hard to precisely pin point the problem when I initially took up this task.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Best,</div><div>Nils</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 23 Mar 2021 at 17:00, Christian MAUDERER <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Gedare,<br>
<br>
Am 23.03.21 um 16:48 schrieb Gedare Bloom:<br>
> CC: Nils, Utkarsh<br>
> <br>
> On Tue, Mar 23, 2021 at 9:17 AM Christian MAUDERER<br>
> <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>> wrote:<br>
>><br>
>> Hello Ahamed,<br>
>><br>
>> Am 23.03.21 um 11:24 schrieb Ahamed Husni:<br>
>>> Hi everyone,<br>
>>><br>
>>> I'm really interested to work on the *Beagle BSP Projects* [#2891<br>
>>> <<a href="https://devel.rtems.org/ticket/2891" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/2891</a>>]. *<br>
>>> *<br>
>>> *Adding PRU Support* [#3730 <<a href="https://devel.rtems.org/ticket/3730" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/3730</a>>]<br>
>>> project seems really interesting to me.<br>
>>> This project is partially done during GSoC 2019<br>
>>> <<a href="https://devel.rtems.org/wiki/GSoC/2019" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/GSoC/2019</a>>by Nils Hölscher .<br>
>>> Is this a good project for the GSoC?<br>
>>><br>
>>> Up to now I have,<br>
>>><br>
>>> 1. Completed the GSoC prerequisite task<br>
>>> 2. Got the required hardware and tested it. (Beagleboard Black, USB to<br>
>>> TTL Converter)<br>
>>> 3. Installed RTEMS on the Beagleboard and tested. (Screenshot attached<br>
>>> below)<br>
>>><br>
>>><br>
>>> I need guidance to define the scope of the project.<br>
>>> I'm currently thinking of ,<br>
>>><br>
>>> 1. First finish the remaining work from GSoC 2019 on the PRU.<br>
>>> (What is the status of current implementation of the PRU?)<br>
>><br>
>> I'm really not sure what the state of the PRU is. I didn't follow that<br>
>> project closely. Maybe one of the mentors of that project can say<br>
>> anything regarding that.<br>
>><br>
> Some more background:<br>
> <a href="https://lists.rtems.org/pipermail/devel/2019-December/056478.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2019-December/056478.html</a><br>
> <a href="https://lists.rtems.org/pipermail/devel/2020-January/056958.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-January/056958.html</a><br>
> <br>
> Maybe Utkarsh or Nils have more to say.<br>
> <br>
>>> 2. Implement additional peripheral support.<br>
>>> What would be most useful?<br>
>>> (USB OTG, CAN, ...).<br>
>><br>
>> I think CAN is a bit hard without some CAN analyzer hardware as a peer.<br>
>><br>
>> USB OTG would be a nice area. But that will be less writing a driver for<br>
>> Beagle but more finding out how that works with libbsd and finding a<br>
>> good way to configure it. I once put a few hours into it didn't take too<br>
>> much time till a PC detected an USB device (see<br>
>> <a href="https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce</a>).<br>
>> Basically it's about importing the "usb_template" stuff and finding a<br>
>> way to configure it in libbsd.<br>
>><br>
>> I think that topic would have to be a bit of an open one: You might work<br>
>> only a day on it and have a working CDC Ethernet afterwards or you can<br>
>> need weeks for that. So you should add an open list of possible advanced<br>
>> targets. An OTG device can be:<br>
>><br>
>> - Ethernet<br>
>> - Serial port<br>
>> - Mass storage<br>
>> - Keyboard / Mouse<br>
>> - Modem<br>
>> - Audio<br>
>> - ...<br>
>><br>
>> The simplest one will most likely be Ethernet followed by serial port. I<br>
>> would add some of the others (like mass storage) as an extended targets.<br>
>><br>
> Yes, this seems like an area that can be chipped away at, with a<br>
> strong plan of activities. My concern would be whether it is about<br>
> writing code or not?<br>
> <br>
<br>
It won't produce a lot of code. But it will produce relevant one:<br>
<br>
1. Interface for configuration (if necessary)<br>
<br>
2. Example application<br>
<br>
3. Documentation<br>
<br>
For Ethernet and serial port that's most likely it. For Mass storage <br>
there might be some more code. Without a too detailed look: I would <br>
expect that the mass storage either implements some access to a raw <br>
block device - in which case it would be necessary to add the access to <br>
block devices. Or it implements something like the PTP stuff used on <br>
smartphones in which case there will be most likely some code that <br>
accesses the file system using POSIX functions instead of FreeBSD kernel <br>
functions.<br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
>> Best regards<br>
>><br>
>> Christian<br>
>><br>
>>><br>
>>> The builtin USB is NOT functional other than for power under RTEMS.<br>
>>> (USB OTG would have to be implemented in RTEMS to get rid of USB to<br>
>>> TTL Converter.)<br>
>>> - Ben Gras<br>
>>> <<a href="http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html" rel="noreferrer" target="_blank">http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html</a>><br>
>>> (Blog post)<br>
>>><br>
>>><br>
>>> Thanks,<br>
>>> Husni Faiz.<br>
>>><br>
>>><br>
>>> BBB_Serial_Out.png<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> devel mailing list<br>
>>> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>>><br>
>><br>
>> --<br>
>> --------------------------------------------<br>
>> embedded brains GmbH<br>
>> Herr Christian MAUDERER<br>
>> Dornierstr. 4<br>
>> 82178 Puchheim<br>
>> Germany<br>
>> email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>> phone: +49-89-18 94 741 - 18<br>
>> fax: +49-89-18 94 741 - 08<br>
>><br>
>> Registergericht: Amtsgericht München<br>
>> Registernummer: HRB 157899<br>
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
>> Unsere Datenschutzerklärung finden Sie hier:<br>
>> <a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
>> _______________________________________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian MAUDERER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 18<br>
fax: +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
</blockquote></div>
</blockquote></div></div>
</div>