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