Hello Gedare and others, as I have already informed some offlist, Premysl Houdek is working on TMS570 Ethernet driver and because we have other OS LwIP port of it we decided to test LwIP on RTEMS before possible attempt to port driver to RTEMS integrated TCP/IP stack.
I have found some work on RTEMS LwIP port already done git://github.com/ragunath3252/lwip-app.git and git://github.com/ragunath3252/lwip-nodrv Is there some newer code? Both of these ports looks to me as not directly mapping LwIP services to RTEMS. The ports seems to build own system constructs again based on mutex system service only. I did not liked that too much and Premysl Houdek has prepared new port which is based on direct mapping to RTEMS services. His whole driver repository is still much work in progress and includes branches of our other TMS570 drivers and code from other non RTEMS projects for industrial partners is included so until code is clean and fully rebased on RTEMS headers etc. files and other stuff cannot be made public. But I want to share and discuss the OS adaptation part which is in shape now. The code is included in our LwIP repo primary prepared to build LwIP under OMK make infrastructure for our system less environment. We use same build infrastructure for RTEMS so when code is included in RTEMS OMK template then next configuration options are enough to build it CONFIG_LWIP_LIB=y CONFIG_LWIP_OS_PORT=rtems CONFIG_LWIP_NO_SYS=0 There are no actual drivers (selectable by CONFIG_LWIP_DEVICE_DRIVERS option) ported to RTEMS yet in our repo. Repo is available git://git.code.sf.net/p/ulan/lwip-omk Actual files specific for RTEMS (cc.h, perf.h, sys_arch.c, sys_arch.h) can be found in http://sourceforge.net/p/ulan/lwip-omk/ci/master/tree/ports/os/rtems/arch/ These files should be directly usable in other build system based RTEMS projects. lwipopts.h for configuration are controlled by CONFIG_* defines, so other variant has to be used for other builds http://sourceforge.net/p/ulan/lwip-omk/ci/master/tree/ports/os/lwipopts.h The port has been tested to work/communicate with DHCP server and obtain address and configure network. We have some TMS570 HW specific problems with spurious interrupts (VIM resets it pending IRQ TMS570_VIM.IRQINDEX index for EMAC interrupts when Flash instruction fetch bypassing (bit VE in SCTLR) is enabled. But that problem is fully unrelated to RTEMS port generic part. I think that this port with direct mapping of services to RTEMS is a cleaner approach and has generally smaller overhead. There are things to consider still. We use counting semaphore as per LwIP sys port specification. But I expect that it is used in most (all?) cases to notify other party about new work and if the other side is capable to do more consecutive work without need to call sys function then simple binary only semaphore would eliminate abundant loops. The approach with self build object based on mutex and semaphores has little less overhead in case of message queues. LwIP stores only pointer size into them and RTEMS provides queues which can be allocated for larger message size and store size of data put into message in addition to the content. So for some really memory constrained environment own specialized queue object would take less memory and there is some code execution overhead to store and check size as well. But in general, I think code is clean and right way to go. When we finish and clean other parts, we prepare complete example for our RTEMS application template. As for LwIP and RTEMS integration in general, does exists some idea/implementation how to make LwIP sockets the fist class RTEMS citizens/objects - i.e. to get file descriptor compatible with RTEMS read, write etc. calls same as for native RTEMS stack? I would like to see select() supporting socket objects together with notification from character drivers as well one day to port applications waiting for more event sources in one thread possible. But I think that select() is not compatible with drivers even in RTEMS integrated stack. It it? Best wishes, Pavel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
