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 <[email protected]> wrote: > Hi Sylvain. > > Thanks a ton for the clarifications !! > > On Sat, Aug 22, 2015 at 10:42 PM, Sylvain Rochet <[email protected]> > 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 >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/lwip-users >> > > > > -- > Regards, > Ajay > -- Regards, Ajay
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
