RTEMS+LWIP for LPC1768 BSP

Federico Casares federico.casares at tallertechnologies.com
Thu Aug 28 17:27:16 UTC 2014


Hi,

On Tue, Aug 26, 2014 at 3:46 PM, Joel Sherrill <joel.sherrill at oarcorp.com>
wrote:

>  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.
>
> Already sent.

>  - 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?
>
> GPLv2. Is this ok?

>  - 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?
>
> See below.

>  - 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?
>
> $ arm-rtems4.11-size -A -d o-optimize/lwip.exe

o-optimize/lwip.exe  :
section              size        addr
.start                840           0
.text              138000         840
.init                  12      138840
.fini                  12      138852
.rodata             14704      138864
.ARM.exidx              8      153568
.eh_frame               4      153576
.init_array             4      153580
.fini_array             4      153584
.jcr                    4      153588
.vector              1256   268435456
.data                1568   268436712
.bss                 8500   537378816
.work               29944   268438280
.eth                16312   537395200
.comment              109           0
.debug_aranges      15608           0
.debug_info       2525968           0
.debug_abbrev      290957           0
.debug_line        897089           0
.debug_frame        34048           0
.debug_str         384335           0
.debug_loc         271111           0
.debug_ranges       19536           0
.debug_macro       516169           0
.ARM.attributes        41           0
Total             5166143

(gdb) p Configuration
$1 = {work_space_size = 13640, stack_space_size = 3808, maximum_extensions
= 0, maximum_keys = 1, maximum_key_value_pairs = 0, microseconds_per_tick =
1000, nanoseconds_per_tick = 1000000, ticks_per_timeslice = 20,
  idle_task = 0x16195 <_CPU_Thread_Idle_body>, idle_task_stack_size = 200,
interrupt_stack_size = 0, stack_allocate_init_hook = 0x0
<bsp_start_vector_table_begin>
, stack_allocate_hook = 0x15f61 <_Workspace_Allocate>,
  stack_free_hook = 0x15f89 <_Workspace_Free>, do_zero_of_workspace =
false, unified_work_area = false, stack_allocator_avoids_work_space =
false, number_of_initial_extensions = 3, User_extension_table = 0x247e4
<Configuration_Initial_Extensions>}


>
> 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.
>


This project can be divided into 4 main parts:

1) RTEMS
2) LWIP
3) LWIP driver
4) User application
 Even though this project was developed for the LPC1768, almost all can be
used for
other devices, with the obvious exception of the driver.

As I told you, we tried to do this with minimum changes, and you will see
that. The only
pieces of code that are completely new (for RTEMS and LWIP) are the driver
and the
demo application.

So, for each part:

1) I will submit the change related to the linker script today, and we will
be working in
the "GCC attributes" to send it to newlib.
2) Should RTEMS have a version of LWIP in their building system? (maybe as
an external
library) so anyone can use it for their projects?
3) The driver is LWIP dependent and, as LWIP sources does not contains any
kind of
driver, should we add this driver to the LPC1768 dsp implementation of
RTEMS?.
4) Should we add this application example to the list of RTEMS
testsuites/samples?

Regards.



>
>  Regards.
>
>
> --
>  [image: 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 & Developmentjoel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>
>


-- 
[image: 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140828/36f50ecc/attachment-0002.html>


More information about the devel mailing list