LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

[Pavel Pisa]

Hello Vijay,

thanks of the status.

On Wednesday 21 of July 2021 07:16:51 Vijay Kumar Banerjee wrote:
> Hi Pavel,
>
> On Tue, Jul 20, 2021 at 1:13 PM Pavel Pisa <ppisa4lists at pikron.com> wrote:
> > Is it devel branch of  Vijay Kumar Banerjee's
> > repo
> >
> >   https://git.rtems.org/vijay/rtems-lwip.git/
>
> Right now yes. Once this is mature, it will probably be pushed to the
> top directory.
>
> > If so, it would worth to put that on the top
> > of LwIP RTEMS info page to guide people interested
> > to live work and not lose time in another
> > abandonned attempts
> >
> >   https://devel.rtems.org/wiki/Packages/LWIP
>
> Thanks, I'll add a note there.
>
> > Addition of pointers to STM WIP to some
> > central place would worth too with
> > pointer to the instructions or instructions
> > included...
>
> I haven't tested it myself. Robin is working on this one and might be
> able to add the instructions. But this is supposed to be merged into
> the repo you mentioned above.

Great that there is the common merge place.


> > Generally I am curious what works and where
> > are problems. I do not expect to have time or
> > find students this summer but I try to offer
> > project as theses and next summer and there
> > chance (small) that I find some studnet
> > to participate.
>
> I am currently actively working on the lwip port to get it working
> with at least a few boards, along with a streamlined build system. I
> could only get the BBB running with a telnetd application that I added
> in the test/ directory in the rtems-lwip repository. I used the
> drivers from TI for BBB.

OK, I have some access to BBB so when my or some studnet
time allows we can test it on this target.
I am more personally interested to TMS570.
I think that I can find some time for testing on TMS570LS3137
if the instructions and code is declared to worth to test.
I hope that I have all tools for this setup.

=============================================================
Side note to TMS570 FEE CTU code (if there is interest,
I it would worth to move to separate thread)

By the way, the way my former colleagues who left faculty
stopped blocking (after many years) TMS570 Rapid Prototyping
Platform code
  http://rtime.felk.cvut.cz/rpp-tms570/
and changed master branch license to MIT (The work has been
exploited to gain money from their industrial partners and has
little value for them now). Code was and is licensed under our
faculty name and I can legally show it to third parties now
and  try to find arrangement to share my and my students effort
with community.

There is XCP https://en.wikipedia.org/wiki/XCP_(protocol)
loader implemented on FreeRTOS base which allows to update
firmware over ETHERNET so it can be used as boot block for
RTEMS. It can make RTEMS support testing and even continuous
integration much easier. When RTEMS is run from SDRAM it
would prevent Flash wear-out, important for TMS570,
because guaranteed erase cycles are limited.

Then there is support for lot of the TMS570 peripherals
in the state twisted with HalCoGen, not directly usable,
but valuable as reference. Lot of Matlab/Simulink glue
which can be reused with minimal changes and  N2HET and
DMA based "HW" implementation of time triggered CAN
transfers with clock scaling and synchronization.

So if there is interest, I can provide more information
and collect it in RTEMS Wiki or on 

  Open Technologies Research Education and Exchange Services
  https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

pages, which are intended primarily for cooperation with
our students.

As for original RTIME wiki and documentation (even documenting
RTEMS and GNU/Linux work shared from my company, done with studnets,
myself at home), I do not expect to contribute to it any more.
Even that substantial part is result of my 25 years of investent
to that group but its leaders took it with them to another
place with end expressed strong will/command to not contact
"their" people anymore. Most of them have left them anyway
so no problem to ask them for advises and help directly.
=============================================================
Back to LwIP

Extending loader and OpenOCD support for TMS570LC4357
is another target long term on my list.

Back to LwIP, I see some your effort to implement
select  sowwakeup(so); and sorwakeup() based
on some code copied from BSD stack

  https://git.rtems.org/vijay/rtems-lwip.git/tree/netinet?h=devel

I think that there would be problem to integrate
select cleanly when LwIP SOCK API is used.
If we limit select only on sockets, then the option
is to translate FD sets to LwIP struct *socket and
then use LwIP select implementation. But I do not like
this approach. I would prefer if the select mechanism
is part of RTEMS core, allows character devices (UART...)
support and stack provides only mechanism how to register
into this generic support.

I think that such arrangement would not be problem with LwIP
when NETCON API is used. But select support in RTEMS
core could be problem for BSD stack implementation
seamless plugin into core.... So I suggest some discussion
and ideas posted by others in this respect.

Best wishes,  

                Pavel Pisa
    e-mail:     pisa at cmp.felk.cvut.cz
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://dce.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/