[lwip-users] Help on porting LWIP
André
I'm needing some help.
I'm working on an evaluation board with an OMAP processor (Texas). So, my
activity is to pass some datas through a network connection between my board and
my PC.
As I was informed, I can port the lwip into different processors by changing the
access addresses on the code.
I'd like to know if someone could indicate me a literature that explains how do
I find/change this addresses.
In time: I'm not suposed to use a embedded OS, so the addresses changes would be
enought to use it on my board?
Sorry if it is a newbie question, but I'm starting on the area.
Regards
André
_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
Pettinato, Jim
Out of curiosity, which eval board are you working with? The BeagleBoard or Gumstix Overo perhaps? These are interesting platforms for many applications.
The OMAP line of processors is pretty advanced - I wouldn't relish writing code for an OMAP-based platform without starting with a known good board support package - and ideally with a full OS (such as the Angstrom Linux distribution used with the above boards).
Yes, you could probably port lwIP to the device, and yes, you could probably strip out any embedded OS and use lwIP's raw interface to provide the network connection - but it is going to be quite a bit of work. Especially since the network interfaces on the eval board(s) I mentioned above work out of the box.
I guess I'm curious as to why you would want to essentially 'downgrade' such a platform (which is essentially a Linux computer in a tiny form factor) to a polled application with a network interface? Is this for a class assignment or something? If you are targeting a specific application, you might be better off using the standard Linux stack.
There is a generic Unix port of lwIP maintained on the Savannah if you are using one of the above platforms - that might help get you started with lwIP.
Good luck with your project!
- Jim
André
I'm using the "Zoom OMAP-L138 EVM Development Kit" (if you want to take a look http://www.logicpd.com/products/development-kits/zoom-omap-l138-evm-development-kit).
There are two problems using my board with an OS.
1 - We need memory economy.
2 - We need rigorous time control.
So, if we use an embedded linux, we will lose lots of necessary memory and the embedded linux will mess up our time control.
Basically, we will put a sensor to acquire some datas and pass it to a PC.
In fact we will not 'downgrade' our platform, because this is only one tiny part of the project. We will do lots of digital signal processing with the DSP core side in OMAP. So, every byte is realy important.
That is why we are looking for porting directly to the board. But I realy don't know how I do this.
Ty
[]s
André
--- Em qui, 4/11/10, Pettinato, Jim <Jim.Pe...@fmcti.com> escreveu:
Kieran Mansley
> That is why we are looking for porting directly to the board. But I
> realy don't know how I do this.
Porting to a new board, tool chain, etc is not a good way to start with
lwIP: the learning curve is steep and the documentation is limited. I
would start here:
http://lwip.wikia.com/wiki/LwIP_Platform_Developers_Manual
but I would expect you will need a lot of help to get going.
Kieran
Pettinato, Jim
Thank you for satisfying my curiosity. We are actually starting a project here in which we are using the L-138. We have had a LogicPD ZOOM eval board here for a while to play with, but we are basing our design on the MityDSP SOM (http://www.mitydsp.com/products-services/cpu-engines/mitydsp-l138F/) - another, similar reference platform from a company called CriticalLink which will also make heavy use of the DSP, etc. I am not working directly on that project, however so I am only slightly familiar with the design. It seems for our purposes, with the DSP and other coprocessors on the OMAP, the ARM9 side of the device becomes less time-critical.
Without knowing the specifics of your app, of course I really can't comment on the need to strip the OS out, etc. Have you considered the real time extensions to Linux for the time-critical stuff? As for memory, it seems that you could strip out unnecessary stuff and end up with a pretty lean Linux to run on.
You know better than I. It just sounds like a lot of hard work to run on that platform with no OS. I think there are a few other RTOSes that have been ported to the OMAP that may be more deterministic than Linux if that is an option.
Again, good luck with your project!
Kieran Mansley
On 4 Nov 2010, at 17:55, Jeff Barber wrote:
> I went through this learning curve last year and did essentially the
> same thing (for a very different board environment). The basic steps
> are:
This is a very useful guide to what is needed for those new to the stack. Would you like to add it (or a similar version) to the wiki?
André
Thanks a lot for this steps.
By now, as I can see, I will have a lot of work to do.
If I got any sucees I will post in here, so anyone who needs something that looks like what I'm doing will be able to use it.
Ty everyone
[]s
André
--- Em qui, 4/11/10, Jeff Barber <jeff...@gmail.com> escreveu:
> De: Jeff Barber <jeff...@gmail.com>
> Assunto: Re: [lwip-users] Help on porting LWIP
> Para: "Mailing list for lwIP users" <lwip-...@nongnu.org>
> Data: Quinta-feira, 4 de Novembro de 2010, 15:55
> I went through this learning curve
> last year and did essentially the
> same thing (for a very different board environment).
> The basic steps
> are:
>
> 1. Create a cc.h for your port. This is
> straight-forward and involves
> choosing types for u8, u16, u32, etc. as well as setting
> endianness
>
> 2. Create a sys_arch.h for your port. For a no-OS
> (NOSYS=1)
> environment, this is trivial.
>
> 3. Create an lwipopts.h for your port. Some is
> straight-forward; some
> is tricky even though the file is not large. It requires
> you to make
> choices about several things that you probably don't know
> enough about
> to make competent choices (at least that was the case for
> me when I
> started); you may need to ask questions on the list about
> this.
>
> 4. Create a driver for your network adapter. This is very
> device-specific and probably a pretty large task,
> especially if you're
> starting from nothing. This needs to:
> A. Find and initialize the adapter and get it ready
> for operation
> (probably prime it with buffers to receive into).
> B. Pull received frames from your network adapter
> and place each
> into an LWIP pbuf, then pass those up the stack into LWIP
> C. Provide an entry point for LWIP that can take a
> frame contained
> within a pbuf and transmit it to your network adapter.
>
> 5. Call LWIP init function, add your driver above as a
> netif under LWIP.
>
> 6. Create your main loop that essentially polls your
> driver, and
> periodically calls the LWIP housekeeping function.
>
> I've attached a sanitized version of my LWIP port files in
> case it's
> helpful as a model. Note that my system has gobs of
> memory available
> and the LWIP performance is not critical so my lwipopts.h
> settings are
> likely completely unsuitable for you.
>
> Jeff
>
>
>
>
> On Thu, Nov 4, 2010 at 9:23 AM, Kieran Mansley <kie...@recoil.org>
> wrote:
> > On Thu, 2010-11-04 at 06:14 -0700, André wrote:
> >> That is why we are looking for porting directly to
> the board. But I
> >> realy don't know how I do this.
> >
> > Porting to a new board, tool chain, etc is not a good
> way to start with
> > lwIP: the learning curve is steep and the
> documentation is limited. I
> > would start here:
> >
> > http://lwip.wikia.com/wiki/LwIP_Platform_Developers_Manual
> >
> > but I would expect you will need a lot of help to get
> going.
> >
> > Kieran
>
> -----Anexo incorporado-----
André
I think I will have some problems in the beggining, if I get lots of troubles, I will try to port on a Windows machine and learn it before porting.
Ty for your answer.
[]s
André
--- Em qui, 4/11/10, Kieran Mansley <kie...@recoil.org> escreveu:
> De: Kieran Mansley <kie...@recoil.org>
> Assunto: RE: [lwip-users] Help on porting LWIP
> Para: "Mailing list for lwIP users" <lwip-...@nongnu.org>
Simon Goldschmidt
There are a few things I would change though, if it's OK for you (and when I find the time):
- lwIP 1.4.0 provides ready-to-use functions for timers, so there's no need to implement that yourself
- you used the type mch_ip_add, which is not defined anywhere - later, this type is implicitly casted struct ip_addr
Other than that, a great example!
Simon
Jeff Barber <jeff...@gmail.com> wrote:
> Done. New page on the wiki at http://lwip.wikia.com/wiki/Porting_For_Bare_Metal
>
>
> On Thu, Nov 4, 2010 at 3:50 PM, Kieran Mansley <kie...@recoil.org> wrote:
>>
>> On 4 Nov 2010, at 17:55, Jeff Barber wrote:
>>
>>> I went through this learning curve last year and did essentially the
>>> same thing (for a very different board environment). The basic steps
>>> are:
>>
>> This is a very useful guide to what is needed for those new to the stack. Would you like to add it (or a similar version) to the wiki?
>
André
I need to chose what features I will use on lwip... So, anyone could advise me what protocol is the most recommended to pass 32 bits datas to my PC... and if there is no problem if I disable the other ones... I'm using IPv4... and, by now, i'v used this settings...
"
#define NO_SYS 1
#define MEM_ALIGNMENT 4
#define MEM_SIZE 50000
#define ETHARP_SUPPORT_VLAN 1
#define LWIP_SOCKET 0
#define LWIP_NETCONN 0
"
Sorry about this newbie question again... but I don't know almost nothing about IP protocols...
Ty
--- Em sex, 5/11/10, Jeff Barber <jeff...@gmail.com> escreveu:
> De: Jeff Barber <jeff...@gmail.com>
> Assunto: Re: [lwip-users] Help on porting LWIP
> Para: "Mailing list for lwIP users" <lwip-...@nongnu.org>
Piotr Piwko
> Just another newbie question.
>
> I need to chose what features I will use on lwip... So, anyone could advise me what protocol is the most recommended to pass 32 bits datas to my PC... and if there is no problem if I disable the other ones... I'm using IPv4... and, by now, i'v used this settings...
It's really hard to help you with so less information about your
target system and its desired functionality. Please, provide more
details. What do you exactly try to achieve? What kind of features do
you need?
I believe that someone will give you some advices, but you must tell
more about your project.
Regards,
--
Piotr Piwko
http://www.embedded-engineering.pl/
André
My objective is to acquire datas from a sensor and process it... storage it in an array and, when the array gets full, send this array to my PC as faster as I can...
I.e. I get 2kB in my array (maximuns length). Done that, I start (or resume) my connection with my PC and send this array...
The PC gets this information and use it for something.
The problme is that I don't know what feature is the most recommended to do this work... If I open a socket and stay in communication or start a new communication each time I need to send this array...
My estimates is to send my array 100 times per second...
I'd like to know what is the most indicated protocol to make it... My area is the controllers, not protocols, so that is why I get so many doubts and don't know almost nothing about protocols...
Anyway, TY
regards
André
--- Em qua, 10/11/10, Piotr Piwko <piotr...@embedded-engineering.pl> escreveu:
> De: Piotr Piwko <piotr...@embedded-engineering.pl>
> Assunto: Re: [lwip-users] Help on porting LWIP
> Para: "Mailing list for lwIP users" <lwip-...@nongnu.org>
Piotr Piwko
> My estimates is to send my array 100 times per second...
> I'd like to know what is the most indicated protocol to make it...
You have a choice between TCP and UDP protocols. TCP provides
reliable, ordered delivery of a bytes stream whereas UDP provides a
reduced latency over reliability. You have to chose one of these, but
you can always perform some tests with the both of them.
At the beginning, as you exactly know, you have to create and edit the
lwipopts.h file according your requirements. As a base I encourage you
to use one of these which are included in 'contrib' packages (I think
'contrib/ports/unix/proj/minimal/' will be the best). Look also at
http://lwip.wikia.com/wiki/LwIP_Wiki.
The best solution for you is to make a lot of tries of building and
configuring your lwIP module. I know that it may seems complicated at
the beginning, but believe me if you get familiarize with its
philosophy it will be very logical.
Good luck!
Yoav Nissim
Hi Andre,
I just had a chance to go over this thread, and have some info you might
find useful.
We use lwIP on windows currently, so porting was not very difficult. As
was mentioned here earlier, I recommend going over the contrib code - it
will show you exactly what the porting layer requirements are, and
possibly give you some hints relevant to your platform as well.
As for the networking side - If I am correct in the following
assumptions, I would go with UDP:
1. loosing 1 KB of sensor data for every 1 GB of data transferred is not
a problem
2. you need to pass 200 KB to the PC per second (100 arrays * 2 KB per
array) [this is easily within the nominal data rate of a 10 Mbps link
not to mention a 100 Mbps link]
3. you need to keep overhead and memory consumption down to a minimum.
If you cannot afford to loose data, TCP is your best option.
Once you get lwIP up and running, you need to decide which lwIP
interface you are going to use to write your networking client
application (I believe there are 3 options - sockets, netconn, and raw).
Given the amounts of sockets code available on the net, it should be the
easiest option for you.
You might be able to save on image size and efficiency by using the
netconn or raw interfaces, but I have no direct experience with those so
cannot give you the pros and cons (beside the additional learning curve).
HTH,
Yoav.
--
Yoav Nissim
Software Engineer, Software Tools Division
Jungo Software Technologies
Email: yo...@jungo.com
Web: http://www.jungo.com
Phone: +972-74-7212138
Fax: +972-74-7212122
Mobile: +972-54-2271315
André
As I can see, TCP seems to be the best choise, because I can not affort losing datas, so this is the best way to take.
Actualy, I've already configured lwipopts.h and the code (in high level) is almost done....
My problem now is to configure the very low level...
In time of writting, my compiler seems not to support packed attribute yet. Is it vital to use it on that packed structures or it is just for compacting the code?
Ty all
regards
André
--- Em qua, 10/11/10, Piotr Piwko <piotr...@embedded-engineering.pl> escreveu:
> De: Piotr Piwko <piotr...@embedded-engineering.pl>
> Assunto: Re: [lwip-users] Help on porting LWIP
> Para: "Mailing list for lwIP users" <lwip-...@nongnu.org>
Kieran Mansley
> In time of writting, my compiler seems not to support packed attribute
> yet. Is it vital to use it on that packed structures or it is just for
> compacting the code?
It is vital that the structures that are marked packed do not have any
padding inserted between the fields. Some compilers do this to give
fields improved alignment. If your compiler does not support packed
structures (it may support them, just using a different syntax to gcc)
then you must also make sure that it does not insert padding into
structures (i.e. it effectively packs everything).
Kieran