Interested in contributing to Beaglebone BSP

Christian Mauderer oss at c-mauderer.de
Sun Apr 26 12:25:10 UTC 2020


Hello James,

On 26/04/2020 12:05, James Fitzsimons wrote:
> Hi Christian,
> 
> Thanks for your reply.
> 
> On Wed, 22 Apr 2020 at 23:29, Christian Mauderer
> <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>> wrote:
> 
>     Hello James,
> 
>     On 20/04/2020 13:13, James Fitzsimons wrote:
>     > I am interested in adding support for the eQEP (Enhanced Quadrature
>     > Encoder Pulse Module) which I am using to decode the quadrature
>     encoders
>     > on my motors.
> 
>     That one isn't implemented yet and I don't know of any current work on
>     it. So feel free to go ahead.
> 
> 
> Thanks for the encouragement - I will start with the eQEP drivers. 
> 
>
>     > I will eventually also need support for the ADC, PRU (I see some work
>     > has already been done on that by a GSoC project),
> 
>     There has been some work on PRU. I'm not entirely sure about ADC.
> 
>     > and ideally the TI
>     > WiLink 8 WL1835MOD wireless chipset - although I realise that might be
>     > extremely difficult.
> 
>     That depends: What kind of interface is used for that? And is the chip
>     already supported in FreeBSD?
> 
> 
> I have done a bit of research and can't find any FreeBSD support for it.
> There are obviously linux drivers but I realise these are not suitable
> for porting to RTEMS

I had a look at the Linux drivers. They are GPL only. So you are right:
They wouldn't be accepted in RTEMS. In theory you could use a private
repo for a port of the drivers but expect a lot of maintenance effort if
you want to keep them up to date.

You should think about asking on a FreeBSD mailing list whether someone
is working on a driver. Maybe someone is working on it and there already
exists a partial or complete driver in some private or separate repository.

>  
> 
>     If it is an USB interface and it is supported in FreeBSD adding it
>     shouldn't be much work. If it is an SDIO it will get a bit more
>     difficult but still possible in a decent time frame. If FreeBSD doesn't
>     know anything about it you will have a really hard time. WLAN drivers
>     are _very_ complex and the need a lot of detail knowledge about the
>     chipset and the regulations.
> 
> 
> I'm pretty sure it uses an SDIO interface, but as you say without the
> FreeBSD support it may be a bit of a long shot.
>  

Yes, seems to be SDIO. We had a GSoC project regarding SDIO two or three
years ago. The student managed to do most of the work for a SDIO support
in libbsd. But we could only partially merge it because at that point
the libbsd was too far behind FreeBSD. One extra difficulty has been
that SDIO was a compile time option in FreeBSD back then. You might want
to take a look at the project and whether you can re-use some parts of
it if you want to add the SDIO stuff.

> 
>     > Are drivers for these features something that would be welcome in the
>     > BBB BSP, and if so any tips for getting started?
> 
>     Of course. Peripheral drivers are nearly always welcome.
> 
>     For the PRU you might should contact the GSoC student working on the
>     topic. For WLAN: Please check the interface and FreeBSD support. I don't
>     know exactly what the eQEP does. But if there is a FreeBSD driver for it
>     you might want to check that one too and maybe port it via libbsd
>     (except the eQEP is a really simple module and it's a lot simpler to
>     write the driver yourself in the BSP)
> 
> 
> I'll make a start on the eQEP module (quadrature decoder for reading
> encoders) and if that goes well I'll reach out to Nils Hölscher about
> the PRU work.

Sounds good. Feel free to ask questions on the mailing list anytime you
think necessary. And although I don't think that you have too much
overlap please keep an eye on this years GSoC projects and whether there
is any influence on your code or vice versa.

Best regards

Christian Mauderer

>  
> Thanks and regards, 
> James Fitzsimons
> 
> 
> 
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 


More information about the users mailing list