Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
Hi all, On Thu, Jul 22, 2021 at 4:12 PM Pavel Pisa wrote: > > Hello Joel, > > On Thursday 22 of July 2021 22:19:21 Joel Sherrill wrote: > > On Thu, Jul 22, 2021 at 12:25 PM Robin Müller > > > The current version of the rtems-lwip support after I added STM32H7 can > > > still be found here: > > > https://github.com/rmspacefish/rtems-lwip/tree/mueller/master and > > > includes the TMS570 code as well. > > > > > > There is also a LPC port here: > > > https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/drive > > >r/lpc_emac But that one still appears to use Makefiles, and needs to be > > > updated to waf if it is integrated. > > > > Very nice. Updating to waf should be a lot easier than writing the driver. > > :) > > > > Vijay.. it's your call but if adding drivers with status of "compile > > only" is OK with you, that at least lays the groundwork for someone > > else to test later. I'm just thinking that compiles and untested makes > > it easy for someone to push it across the goal line. > > That is surprise, I forgot that port of our sysless LPC driver to RTEMS > exists. The code in sysless mode is used by Alvat company http://alvat.cz/ > (founded by our alumni Pavel Nemecek ) to provide Pick to Light system > gateway and embedded web on LPC. Our robotic control systems LX_RoCoN > use it in daily operation in selfbuild interferometer of Czech Academy > of Sciences aspherical lens production etc. So the core of the driver > should be functional. I have newer used it on RTEMS but I have > there LX_RoCoN running on table before me exactly now. Not > with RTEMS, but I have tested RTEMS on it, so I can give it > a try if I learn again WAF stuff. > This is amazing! I can help with the waf integration. I'm working on making the waf system in rtems-lwip better, so that it doesn't take much effort to integrate a new set of drivers like this. > I am adding Roman Bartosnsky to CC, he is main author > of LPC driver and LwIP OMK port done under my company > funding and then on some Alvat budget. He woks on more > ESA projects at his company https://www.daiteq.com/ , > an actual one is NOEL-V related. He worked with me for years > on our RTEMS based medical infusion systems, so he knew > RTEMS and CPU architectures well. > Great! It would be great to get it tested on a hardware after it's ported on rtems-lwip. > So there are people who have strong insight into the code. > So if it has been located again it would worth to collect > in on one place. We have some enhancements of the LPC > driver in our OMK repo, so we can merge updates. > I expect that they do not collide with changes for > RTEMS build. > I'm following the OMK repository for TMS570. After the waf support is added with the STM32 and LPC, It should be possible to merge the driver updates from omk. Best regards, Vijay > Best wishes, > > Pavel Pisa > > == > PiKRON s.r.o. Phone/Fax: +420 284684676 > Kankovskeho 1235Phone: +420 234697622 > 182 00 Praha 8 WWW: http://www.pikron.com/ > Czech Republic e-mail: pik...@pikron.com > == ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
Hello Joel, On Thursday 22 of July 2021 22:19:21 Joel Sherrill wrote: > On Thu, Jul 22, 2021 at 12:25 PM Robin Müller > > The current version of the rtems-lwip support after I added STM32H7 can > > still be found here: > > https://github.com/rmspacefish/rtems-lwip/tree/mueller/master and > > includes the TMS570 code as well. > > > > There is also a LPC port here: > > https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/drive > >r/lpc_emac But that one still appears to use Makefiles, and needs to be > > updated to waf if it is integrated. > > Very nice. Updating to waf should be a lot easier than writing the driver. > :) > > Vijay.. it's your call but if adding drivers with status of "compile > only" is OK with you, that at least lays the groundwork for someone > else to test later. I'm just thinking that compiles and untested makes > it easy for someone to push it across the goal line. That is surprise, I forgot that port of our sysless LPC driver to RTEMS exists. The code in sysless mode is used by Alvat company http://alvat.cz/ (founded by our alumni Pavel Nemecek ) to provide Pick to Light system gateway and embedded web on LPC. Our robotic control systems LX_RoCoN use it in daily operation in selfbuild interferometer of Czech Academy of Sciences aspherical lens production etc. So the core of the driver should be functional. I have newer used it on RTEMS but I have there LX_RoCoN running on table before me exactly now. Not with RTEMS, but I have tested RTEMS on it, so I can give it a try if I learn again WAF stuff. I am adding Roman Bartosnsky to CC, he is main author of LPC driver and LwIP OMK port done under my company funding and then on some Alvat budget. He woks on more ESA projects at his company https://www.daiteq.com/ , an actual one is NOEL-V related. He worked with me for years on our RTEMS based medical infusion systems, so he knew RTEMS and CPU architectures well. So there are people who have strong insight into the code. So if it has been located again it would worth to collect in on one place. We have some enhancements of the LPC driver in our OMK repo, so we can merge updates. I expect that they do not collide with changes for RTEMS build. Best wishes, Pavel Pisa == PiKRON s.r.o. Phone/Fax: +420 284684676 Kankovskeho 1235Phone: +420 234697622 182 00 Praha 8 WWW: http://www.pikron.com/ Czech Republic e-mail: pik...@pikron.com == ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
On Thu, Jul 22, 2021 at 12:25 PM Robin Müller wrote: > > Hello, > > I am still waiting on STM32 reply because of the licensing issue. Might still > take weeks/months.. The Ultimate Liberty license is a bit of a misnomer. Quite a few restrictions on liberty there. > > Another solution would be to write some scripts to copy the code from the > Cube sources.. > But I would prefer to avoid them, because I also had to merge some of the > files provided by STM so that I could use/test all three APIs. > > I was able to test and use all major APIs on a STM32H7 board with RTEMS, > including the Socket API.. Although I disliked about the Socket API that it's > easy to forget the cache invalidation on the TX/RX buffers (forgot which one > it was) if they are not protected via MPU but that's also a STM32H7 specific > issue. I remember this long discussion. Is this something that might show up again on other drivers? I'm just wondering if this is really a one-off or something we need a pattern for. > The current version of the rtems-lwip support after I added STM32H7 can still > be found here: https://github.com/rmspacefish/rtems-lwip/tree/mueller/master > and includes the TMS570 code as well. > > There is also a LPC port here: > https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/driver/lpc_emac > But that one still appears to use Makefiles, and needs to be updated to waf > if it is integrated. Very nice. Updating to waf should be a lot easier than writing the driver. :) Vijay.. it's your call but if adding drivers with status of "compile only" is OK with you, that at least lays the groundwork for someone else to test later. I'm just thinking that compiles and untested makes it easy for someone to push it across the goal line. --joel > Kind Regards > Robin > > > > On Thu, 22 Jul 2021 at 00:10, Vijay Kumar Banerjee wrote: >> >> Hi, >> >> >> On Wed, Jul 21, 2021 at 2:25 AM Pavel Pisa wrote: >> > >> > Hello Vijay, >> > >> > thanks of the status. >> > >> >> I added a note in the devel page: https://devel.rtems.org/wiki/Packages/LWIP >> >> >> >> > 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 >> > > 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. >> Thanks. Any feedback would be really appreciated. >> >> > 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. >> > >> This has not been tested yet, I'm working on the build system to >> streamline the process further. It would be great to get this port >> tested. Please ping me if you have any build issues when testing (if >> you happen to test before the build system update :) ). >> >> >> > = >> > 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 >> >
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
Hello, I am still waiting on STM32 reply because of the licensing issue. Might still take weeks/months.. Another solution would be to write some scripts to copy the code from the Cube sources.. But I would prefer to avoid them, because I also had to merge some of the files provided by STM so that I could use/test all three APIs. I was able to test and use all major APIs on a STM32H7 board with RTEMS, including the Socket API.. Although I disliked about the Socket API that it's easy to forget the cache invalidation on the TX/RX buffers (forgot which one it was) if they are not protected via MPU but that's also a STM32H7 specific issue. The current version of the rtems-lwip support after I added STM32H7 can still be found here: https://github.com/rmspacefish/rtems-lwip/tree/mueller/master and includes the TMS570 code as well. There is also a LPC port here: https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/driver/lpc_emac But that one still appears to use Makefiles, and needs to be updated to waf if it is integrated. Kind Regards Robin On Thu, 22 Jul 2021 at 00:10, Vijay Kumar Banerjee wrote: > Hi, > > > On Wed, Jul 21, 2021 at 2:25 AM Pavel Pisa wrote: > > > > Hello Vijay, > > > > thanks of the status. > > > > I added a note in the devel page: > https://devel.rtems.org/wiki/Packages/LWIP > > > > > 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 > 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. > Thanks. Any feedback would be really appreciated. > > > 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. > > > This has not been tested yet, I'm working on the build system to > streamline the process further. It would be great to get this port > tested. Please ping me if you have any build issues when testing (if > you happen to test before the build system update :) ). > > > > = > > 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, > >
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
Hi, On Wed, Jul 21, 2021 at 2:25 AM Pavel Pisa wrote: > > Hello Vijay, > > thanks of the status. > I added a note in the devel page: https://devel.rtems.org/wiki/Packages/LWIP > 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 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. Thanks. Any feedback would be really appreciated. > 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. > This has not been tested yet, I'm working on the build system to streamline the process further. It would be great to get this port tested. Please ping me if you have any build issues when testing (if you happen to test before the build system update :) ). > = > 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. > I'm interested in TMS570LC4357 and would like to you join efforts on this one. > Back to LwIP, I see some your effort to
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
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 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
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
Hi Pavel, On Tue, Jul 20, 2021 at 1:13 PM Pavel Pisa wrote: > > Hello everybody, > > I have no technical stuff to share for now, > but I am happy that work on LwIP alternative > stack for RTEMS continues on. > > I have question which repo is considered as > mainline (integration point) for this work. > 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. > In the longer term horizon, it would worth > to get rid of twisted translation layer I have > introduced initially > > > https://git.rtems.org/vijay/rtems-lwip.git/tree/lwip/src/api/rtems_lwip_sysdefs.c?h=devel > > The best option would be if mainline LwIP provides > configurable option to use external types, enums, > structures (struct sockaddr) prototypes from libc > (i.e. NewLib) which would remove this translation. > I still think that move to LWIP_NETCONN only > and disable of LWIP_SOCKET could be the way > forward, but would require to implement own > layer to switch right NetCon base according > to socket AF domain, and type. So it would not be > easy task and solution based on actual FD to LwIP FD > translation could be used until then. > > 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. > This summer is my main interrest with studnets > work focused on pysimCoder to boost usability. > > https://github.com/robertobucher/pysimCoder > > It is usable with preemptive GNU/Linux > on more targets, NuttX and adding support > for RTEMS would be easy as well. > Some demo with NuttX > > https://youtu.be/6HlGk3ecPNQ > > Same targets are supported by our support > for Matlab/Simulink, RTEMS is on my list > for this projet for many years as well, > so if somebody have interrest, I would help > by advice or some prototype (which I have > for RTEMS in some hacked state in the past) > > https://github.com/aa4cc/ert_linux/ > > Best wishes, > > Pavel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
Hello everybody, I have no technical stuff to share for now, but I am happy that work on LwIP alternative stack for RTEMS continues on. I have question which repo is considered as mainline (integration point) for this work. Is it devel branch of Vijay Kumar Banerjee's repo https://git.rtems.org/vijay/rtems-lwip.git/ 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 Addition of pointers to STM WIP to some central place would worth too with pointer to the instructions or instructions included... In the longer term horizon, it would worth to get rid of twisted translation layer I have introduced initially https://git.rtems.org/vijay/rtems-lwip.git/tree/lwip/src/api/rtems_lwip_sysdefs.c?h=devel The best option would be if mainline LwIP provides configurable option to use external types, enums, structures (struct sockaddr) prototypes from libc (i.e. NewLib) which would remove this translation. I still think that move to LWIP_NETCONN only and disable of LWIP_SOCKET could be the way forward, but would require to implement own layer to switch right NetCon base according to socket AF domain, and type. So it would not be easy task and solution based on actual FD to LwIP FD translation could be used until then. 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. This summer is my main interrest with studnets work focused on pysimCoder to boost usability. https://github.com/robertobucher/pysimCoder It is usable with preemptive GNU/Linux on more targets, NuttX and adding support for RTEMS would be easy as well. Some demo with NuttX https://youtu.be/6HlGk3ecPNQ Same targets are supported by our support for Matlab/Simulink, RTEMS is on my list for this projet for many years as well, so if somebody have interrest, I would help by advice or some prototype (which I have for RTEMS in some hacked state in the past) https://github.com/aa4cc/ert_linux/ Best wishes, Pavel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
