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 <vi...@rtems.org> wrote: > Hi, > > > On Wed, Jul 21, 2021 at 2:25 AM Pavel Pisa <ppisa4li...@pikron.com> 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 <ppisa4li...@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. > 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 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. > > > Thank you for the feedback on the APIs, I'll look into the NETCONN API > and start a discussion in a separate thread. > > Best regards, > Vijay > > Best wishes, > > > > Pavel Pisa > > e-mail: p...@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/ >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
