Re: [lwip-users] TCP/IP/PPP for bare-metal

[Ajay Garg]

Hi All.

I began navigating the code.

First of all, let me present the scenarios where we intend to run our code ::

a)

Our client-application, deployed on a vanilla Linux-Desktop, using WIFI to communicate with a "normal" server running on a public IP-Address.

b)

Our client-application, flashed on a micro-controller, which interfaces with a GPRS-module to communicate with the same "normal" server running on a public IP-Address.

Following are the options ::

OPTION 1 :
========

Segregate the application-code in a way, so that all code "including and below" Layer-4 (TCP) is end-device specific.

That means that for vanilla Linux-Desktop, we use the vanilla Berkley-Socket SOCK_STREAM APIs.

For embedded, we utilize the extended-AT-command-set exposed by the GPRS-module (which has been built over the embedded TCP/IP stack of the GPRS-module).

Above approach works for both the end-devices, but suffers from the fact that the extended-AT-command-set is not a standard, so deploying our application on some other GPRS-module will require integration with some other extended-AT-command-set.

OPTION 2 :
=========

Use lwIP for TCP-headers (Layer-4) in the application, and segregate the application in such a way so that all code "including and below" Layer-3 (IP) is end-device specific.

That means that for vanilla Linux-Desktop, we use vanilla SOCK_RAW APIs, with the default option of letting the API add the IP-header.

For embedded, we let the GPRS-module AP+BP handle the Layer3/Layer2/Layer1 functionality.

Above seems feasible "logically", please confirm.

OPTION 3 :
=========

Use lwIP for TCP-headers (Layer-4) and IP-headers (Layer-3) in the application, and segregate the application in such a way so that all code "including and below" Layer-2 is end-device specific.

Now, here is my biggest query ::

Is it even logically-possible to separate the "Layer3 (IP) handling" (in the application) from "Layer2 handling" (in the end-device)?  According to the limited knowledge that I have, the IP-layer needs accesses to the interfaces (as even evident from code in ip.c in lwIP). That would mean that BOTH the Layer3-handling and Layer2- handling must be present in the same code context?

Kindly help resolve these architectural doubts ... I will be grateful no end ...

Thanks and Regards,

Ajay

On Sun, Aug 23, 2015 at 7:38 AM, Ajay Garg <address@hidden> wrote:

Hi Sylvain.

Thanks a ton for the clarifications !!

On Sat, Aug 22, 2015 at 10:42 PM, Sylvain Rochet <address@hidden> wrote:

Hi Ajay,

On Sat, Aug 22, 2015 at 10:20:27PM +0530, Ajay Garg wrote:
>
> I am sorry, I am not sure what is meant by an OS here.

OS = FreeRTOS, ChibiOS, … understand something which provide multiple
loops using lightweight threads.


> I presume if there were an OS, then the environment would "not" be
> bare-metal (since we would be depending on the functionalities being
> provided by the OS) ?

In embedded context, bare metal = everything runs in the main loop, no
threads, no context switch, no task priorities.

For lwIP,

NO_SYS = 1 = bare metal, lwIP event handler is integrated within the main loop.

NO_SYS = 0 = threaded, lwIP event handler runs within its own thread.

Well, that's it ...

In the application that we have designed and coded so far, everything has been kept single-threaded only (so as now to have any dependency on any third-party embedded-device-vendors).

So, it turns out, that we "do" need to use NO_SYS = 1

But I get your point, it should be feasible to integrate the functionality with NO_SYS = 1 (though it might require some code-rearrangement in lwIP).

Anyhow, if there are some examples of this particular scenario (NO_SYS = 1, everything within the main loop), kindly let know. It would save some time ticks for us :)

Thanks again.

Thanks and Regards,

Ajay

 

On a Linux/win32 host, everything obviously runs inside a heavy process,
but the bare metal vs threaded still apply.


Sylvain

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

--

Regards,
Ajay

--

Regards,
Ajay