Hello Ahamed,
Am 26.03.21 um 15:31 schrieb Ahamed Husni:
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
<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.
Best regards
Christian
USB OTG would allow more extended capabilities for the beagle board.
To work on the USB OTG devices, what would be the best way?
What I understood from what Christian says is,
1. Finding out how USB OTG works with libbsd and finding a
way to configure it for the beagle.
2. Work on CDC Ethernet
3. CDC Ethernet - Example application & Documentation
4. Work on Serial over USB
5. Serial over USB - Example application & Documentation
Am I right?
Most likely we would have to put some further open points at the end of
that because like I said: Depending on how well it works you might need
anything between a day and three weeks to get CDC Ethernet running. From
my first guess, it's maybe a week.
Note that I would expect that you will need a debugger and the RTEMS
event recording for this kind of project.
CDC Serial should be only a small step as soon as CDC Ethernet is running.
Mass storage depends on the current implementation for that in FreeBSD.
It might could be an interesting part.
Would implementing Ethernet and Serial solve the problem of using TTL
converters
when working on RTEMS in Beagle for the developers?
Depends on the application. For those who want to write an application,
a CDC Serial device would be a nice alternative. For those who want to
develop drivers or RTEMS itself: Very unlikely that CDC Serial is enough
for that.
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?
After completing the above milestones, if we have more time I can start
to work on
the Mass storage support.
I would suggest to put _more_ into the proposal and make it clear that
the later points depend on whether there is enough time or not.
@Gedare: The time and effort for that project is really hard to estimate
in my point of view. Do you have an idea how we could handle that?
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.
Also I don't think that this project should be continued without a
full DEBUGGING Setup.
Best,
Nils
+1, without a proper debugging setup I found it hard to precisely
pin point the problem when I initially took up this task.
What is the full DEBUGGING setup needed to work on the PRU?
I expect a JTAG-Debugger. I had good experience with the Segger J-Link
EDU for GSoC projects with BBB. Alternatively there are OpenOCD based
ones out there too that are said do work well. Note that you have to
solder a debug connector to the Beagle for that.
Best regards
Christian
Regards,
Husni.
On Tue, Mar 23, 2021 at 10:25 PM Utkarsh Rai <utkarsh.ra...@gmail.com
<mailto:utkarsh.ra...@gmail.com>> wrote:
On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher <nilho...@gmail.com
<mailto: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
<mailto: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
<mailto: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
<https://devel.rtems.org/ticket/2891>>]. *
>>> *
>>> *Adding PRU Support* [#3730
<https://devel.rtems.org/ticket/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
<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/2019-December/056478.html>
>
https://lists.rtems.org/pipermail/devel/2020-January/056958.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
<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
<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 <mailto:devel@rtems.org>
>>> http://lists.rtems.org/mailman/listinfo/devel
<http://lists.rtems.org/mailman/listinfo/devel>
>>>
>>
>> --
>> --------------------------------------------
>> embedded brains GmbH
>> Herr Christian MAUDERER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: christian.maude...@embedded-brains.de
<mailto: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/
<https://embedded-brains.de/datenschutzerklaerung/>
>> _______________________________________________
>> devel mailing list
>> devel@rtems.org <mailto:devel@rtems.org>
>> http://lists.rtems.org/mailman/listinfo/devel
<http://lists.rtems.org/mailman/listinfo/devel>
--
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
<mailto: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/
<https://embedded-brains.de/datenschutzerklaerung/>
--
--------------------------------------------
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
