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