RTEMS+LWIP for LPC1768 BSP

Joel Sherrill joel.sherrill at oarcorp.com
Tue Aug 26 18:46:17 UTC 2014


First. Thanks for the work and taking the time and effort to
submit it.

Specifics below, but the general answer is to submit all RTEMS
changes as reviewable patches to devel at rtems.org. We can
then review them and get them merged. This will leave us
with just the LWIP changes.

Then we can review those and begin to work with that community
to get them merged.


On 8/26/2014 6:22 AM, Federico Casares wrote:
> Hi,
>
> In the past weeks we were working on porting the last LWIP version to
> RTEMS for
> the LPC1768 microcontroller. Our main goal was to accomplish this with the
> minimum number of changes for both projects. Fortunately, the result was
> positive.
>
> Now, we are capable of providing to the community with this new
> version of the
> RTEMS+LWIP port. In details:
>
> - RTEMS: last git revision = baa3c91ecb8a3b48ef387b938fcdb6
> e60b5bdc8a
> - LWIP: last git revision = 63038e03055183e3bc043711ada1de3bb907e989
> - LPC1768: based on MBED driver =
> https://github.com/mbedmicro/mbed/tree/master/libraries/net/eth/lwip-eth/arch/TARGET_NXP
>
>
> The list of changes follows:
>
> - RTEMS OS: No changes were needed here. Despite this we will be posting a
> possible improvement in the newlib maillist soon. It consist in adding
> the gcc
> function attribute "warn_unused_result" to the pthread_*_init
> functions. As a
> result, developers will be warned about checking the return value. NOTE: a
> common error here could be not checking the return value, assuming a
> successful
> result, and trying to, for example, lock a mutex which init function has
> returned ENOMEM. (We found this exact mistake in the current LWIP OS layer
> implementation for Unix)
>
FWIW the gcc C++ library adapters for threading do not check the results
from
those operations. This is an open sore spot for us.
> - RTEMS LPC1768_MBED BSP: We added a new section to the linker script,
> so we
> were able to put the LWIP and driver buffers in an exact memory
> location (useful
> when working with DMA devices).
>
This sounds like a discrete patch to submit to devel at rtems.org.
> - RTEMS LPC1768_MBED Ethernet Driver: Based on an existing driver from
> MBED, we
> ported it to RTEMS. NOTE: we will be creating our own driver in the
> near future.
>
What is the license of these drivers?
> - LWIP: As mentioned previously, we needed to put all LWIP buffers in
> DMA memory
> locations. Consequently, we added the "section" attribute to LWIP
> ram_heap and
> memp_memory buffers. Furthermore, as this is a common strategy in embedded
> devices with DMA, we made it generic and we will send these changes to
> the LWIP
> project. Additionally, we will provide some minor adds/changes to the
> lwip log
> system and statistics system.
>
OK. Those are obviously their's to review. :)
> - LWIP-contrib: Some of the changes/adds were: fixing some issues
> related with
> posix initialization checks and allow set threads stack size.
>
What all specific to RTEMS was added? Do you want RTEMS Community review
on this?

Is there a readme/howto to configure and use LWIP on RTEMS?

It sounds like the port is largely BSP independent. Is this the case?
> - LWIP-test-app: A simple TCP echo server with debugging functionality
> (rtems malloc statistics, rtems stack checker, lwip statistics, driver
> statistics and registers dump) available.
>
Very cool!

How large was the code/data/RAM use of the test application?
>
> As this new port is comprised of several patches and adds, it would be
> great
> to have some advice in how to proceed. We can provide you with the
> project as a
> whole or divided into independent patches. Also, we will need to know
> which
> parts of the port are of RTEMS interest to be submitted.
>
RTEMS needs to nibble and digest the RTEMS stuff. That sounds pretty easy.

Then we can help or at least track and provide help getting the LWIP port
reviewed and merged by them.
> Regards.
>
>
> -- 
> http://www.tallertechnologies.com <http://www.tallertechnologies.com>
> Casares, Federico
> Sr. Software Engineer
> Taller Technologies Argentina
>
> San Lorenzo 47, 3rd Floor, Office 5
> Córdoba, Argentina

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140826/9213ea07/attachment-0002.html>


More information about the devel mailing list