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
