Ethernet Interface

» Show archived comment by baljemmett

# 01 Jul 2012

Not sure if I'm doing something wrong, but the TCPSocket_HelloWorld example acts strangely for me; it works, in that I can see both the DHCP and HTTP transactions in a packet sniffer, but the console output is garbled. Chucking in some extra printf()s between calls shows everything works fine up until the eth.init() call, after which only junk gets printed - almost as if the network stack is trampling on the baud rate settings or something along those lines.

I haven't tried the UDP version yet, but the weirdness happens early enough in execution that I suspect it'll do the same thing.

Anybody else seeing this?

» Show archived comment by baljemmett

Ben Jemmett

# 01 Jul 2012

... and indeed, after some more digging today it appears that adding Serial console(USBTX, USBRX); console.baud(9600); after the eth.init() call restores the expected output, as well as showing some debug messages from the library. Taking it back out and changing my terminal settings to 115200 baud works even better, as eth.init() itself prints some messages after it changes the baud rate.

Might be worth a mention somewhere, as the SerialPC page does list 9600 baud as the default (with a caution that you need to reconfigure both sides of the connection if you change it, of course!)

Now back to trying to work out why this library works when the mbed is connected through my switch, but the older one doesn't!

» Show archived comment by emilmont

Emilio Monti

# 02 Jul 2012

Ben Jemmett wrote:

works fine up until the eth.init() call, after which only junk gets printed - almost as if the network stack is trampling on the baud rate settings or something along those lines.

Yes, a small debug module was silently resetting the UART baud to 115200, from the default 9600. We modified that to respect the Principle Of Least Astonishment.

Cheers, Emilio

» Show archived comment by Madmanmav

Maverick War

# 08 Jul 2012

Compiled this demo takes 70% RAM whereas the old ethernetif HttpClientStream only takes 9% RAM I assume the bloat is from RTOS any way of getting rid of it ?

» Show archived comment by emilmont

Emilio Monti

# 09 Jul 2012

Maverick War wrote:

Compiled this demo takes 70% RAM

It does not "take" 70% RAM, it makes "available" 70% RAM for user thread stacks... :-)

Anyway, it is completely configurable, you just need to edit: mbed-rtos/RTX_Conf_CM.c

We are actually working on providing better memory usage and diagnostic...

Cheers, Emilio

» Show archived comment by Madmanmav

Maverick War

# 09 Jul 2012

Thanks Emilio. I tried reducing the thread count OS_TASKCNT 5 seemed to be as low as I could go with the example without the micro crashing out with mbed_die(); (i think). still 'reserves' a lot of RAM compared to the old ethernetif. I understand the ram is reserved for other threads in RTOS but not everyone needs or wants an RTOS and the overhead related (me I struggle without adding the complexity of mutexes,semaphores ect) Is there likely to be a non rtos version of the libs for those who don't need and Rtos? or will I simply have to use ethernetif ? I like the fact that the driver in the new Ethernet libs can be changed so I could use the lpc_phy_lan8720.c. Please excuse my noobness :)

» Show archived comment by dmagda

Denis Magda

# 10 Jul 2012

Emilio Monti wrote:

Maverick War wrote:

Compiled this demo takes 70% RAM

It does not "take" 70% RAM, it makes "available" 70% RAM for user thread stacks... :-)

Anyway, it is completely configurable, you just need to edit: mbed-rtos/RTX_Conf_CM.c

We are actually working on providing better memory usage and diagnostic...

Cheers, Emilio

Trying to configure the RTOS, setting the minimal values for stacks sizes (64KB) and threads counts but always get "section `.bss' will not fit in region `RAM'" error from a linker. I use the GCC ARM compiler.

» Show archived comment by loopsva

Kevin Braun

# 10 Jul 2012

Emilio, I just compiled this code for the first time. I get a lot of the following warnings similar to this:

"statement is unreachable" in file "EthernetInterface/LwIPNetworking/mbed-lwip/lwip/apiapi_lib.c", Line: 140, Col: 2 "loop is not reachable from preceding code" in file "EthernetInterface/LwIPNetworking/mbed-lwip/lwip/apisockets.c", Line: 415, Col: 2

About 40 warnings in all. There are no compile errors. However, the linker fails.

...kevin

» Show archived comment by donatien

Donatien Garnier

# 15 Jul 2012

Hi Kevin,

The EthernetInterface library has been updated and this should make the warnings disappear. Can you try updating the library and compile again?

Donatien

voy ager

# 17 Jul 2012

TCPSocket_HelloWorld.

I am having severe problems using this sample. The original code works perfect. But as soon as i try to call a small Keil server on my ip 192.168.0.104 the system breaks down. Any help possible ?

voy

/* sock.connect("mbed.org", 80); */

/* sock.connect("217.140.96.42", 80); even calling with ip works

char http_cmd[] = "GET /media/uploads/donatien/hello.txt HTTP/1.1\r\nHost: %s\r\n\r\n";

/

sock.connect("192.168.0.104", 80);

char http_cmd[] = "GET /ipwe.txt HTTP/1.1\r\nHost: %s\r\n\r\n";

sock.send(http_cmd, sizeof(http_cmd) - 1, 3000);

Roy van Dam

# 18 Jul 2012

During the implementation of the udp receive routine for the NetworkAPI library I noticed that up on reception of the very first UDP packet, no valid endpoint information is provided by the network stack. The size returned for the sockaddr_in structure is zero, every packet received after the first one however works fine though.

Has this behavior been encountered before?

Edit: Found the problem, had to manually override the structure size variable before calling the recvfrom function.

Emilio Monti

# 02 Aug 2012

You might be interested in a performance comparison with the legacy networking library: Networking Libraries Benchmark

Cheers, Emilio

Sheldon Cooper

# 03 Aug 2012

Would it be possible to include the following functionality in the ethernet library: - instead of blocking forever in init() when DHCP is not available, returning after a given timeout with an errorcode and make it possible to handle error in application? - be able to get IP address (DHCP assigned) in a machine readable format (eg. byte array) instead of returning it as a string - be able to return the HW address

I know the last two are possible with LWIP, but I'd like to use just a single API.

Emilio Monti

# 03 Aug 2012

Sheldon Cooper wrote:

instead of blocking forever in init() when DHCP is not available, returning after a given timeout with an errorcode and make it possible to handle error in application?

Yep, good improvement: implemented

» Show archived comment by csorbag

Sheldon Cooper

# 03 Aug 2012

What is the difference between TCPSocketConnection.send() and send_all()?

» Show archived comment by emilmont

Emilio Monti

# 04 Aug 2012

Hi Sheldon,

Sheldon Cooper wrote:

What is the difference between TCPSocketConnection.send() and send_all()?

I updated the "TCPSocketConnection" documentation, I hope it is clear now:

» Import this library into a program
Socket - TCPSocketConnection Class Reference

Public Member Functions
	TCPSocketConnection ()
	TCP socket connection.
int	connect (const char *host, const int port)
	Connects this TCP socket to the server.
bool	is_connected (void)
	Check if the socket is connected.
int	send (char *data, int length)
	Send data to the remote host.
int	send_all (char *data, int length)
	Send all the data to the remote host.
int	receive (char *data, int length)
	Receive data from the remote host.
int	receive_all (char *data, int length)
	Receive all the data from the remote host.
void	set_blocking (bool blocking, unsigned int timeout=1500)
	Set blocking or non-blocking mode of the socket and a timeout on blocking socket operations.
int	set_option (int level, int optname, const void *optval, socklen_t optlen)
	Set socket options.
int	get_option (int level, int optname, void optval, socklen_t optlen)
	Get socket options.
int	close (bool shutdown=true)
	Close the socket.
void	reset_address (void)
	Reset the address of this endpoint.
int	set_address (const char *host, const int port)
	Set the address of this endpoint.
char *	get_address (void)
	Get the IP address of this endpoint.
int	get_port (void)
	Get the port of this endpoint.
Friends
class	TCPSocketServer

Cheers, Emilio

» Show archived comment by csorbag

Sheldon Cooper

# 04 Aug 2012

It's pretty clear now. Thanks.

Uwe Haertel

# 16 Aug 2012

I want to establish a client server communication between the mbed LPC1768 and a PC. The mbed should work as server receiving commands from the PC and respond on these after doing some measurement or controlling stuff by sending results or status messages – all that in text lines. I took the echo server example and tried to modify it to do so. The echo server works fine (sending one line and getting the same line in response). But trying to send a row of measurement results from the mbed I realized, that this connection is very slow maybe 3 lines per second. Is that correct or am I doing something wrong. The Ethernet is connected via a Magjack.

First doing some init stuff:

TCPSocketServer server; TCPSocketConnection client; EthernetInterface::init(); EthernetInterface::connect(); server.bind(1234); server.listen(); server.set_blocking(true); client.set_blocking(false);

Then writing lines by: if (0 >= client.send(str, strlen(str)) exit;

While the first line appears promptly on the terminal the next ones drop in old telegraph style. I had expected much higher speed.

Bests Uwe

Emilio Monti

# 16 Aug 2012

Hi Uwe,

Uwe Haertel wrote:

Trying to send a row of measurement results from the mbed I realized, that this connection is very slow maybe 3 lines per second. Is that correct or am I doing something wrong.

Firstly, could you run the following benchmark and confirm me that you are getting around (5.852) Mbits/s of (RX+TX) throughput? BENCHMARK

If you are getting the above throughput, then there are only two possible causes:

Your "lines" are tens of kilobytes long.
What you are doing between receiving a command and producing a response is taking hundreds of milliseconds.

Cheers, Emilio

Kevin Braun

# 16 Aug 2012

Update on TFTP Server. Using a Windows XP PC and a 135KB file, I'm getting 33.3KB (266.4Kb) GET and 44.5KB (356Kb) PUT. Not bad... Interesting that writing to local Flash (PUT) is faster than reading from it (GET). Of course, I have no idea what the performance of FatFileSysterm is.

...kevin

» Show archived comment by extraherb

Uwe Haertel

# 17 Aug 2012

Good morning, I’m not able to import anything, neither with Firefox nor with IE, neither programs nor libraries. Any clue? Uwe

» Show archived comment by Stavlin

Joe Staton

# 17 Aug 2012

Possibly to do with this:

http://mbed.org/blog/entry/Scheduled-downtime-August-16th/

Uwe Haertel

# 17 Aug 2012

Emilio Monti wrote:

Hi Uwe,

Uwe Haertel wrote:

Trying to send a row of measurement results from the mbed I realized, that this connection is very slow maybe 3 lines per second. Is that correct or am I doing something wrong.

Firstly, could you run the following benchmark and confirm me that you are getting around (5.852) Mbits/s of (RX+TX) throughput? BENCHMARK

If you are getting the above throughput, then there are only two possible causes:

Your "lines" are tens of kilobytes long.
What you are doing between receiving a command and producing a response is taking hundreds of milliseconds.

Cheers, Emilio

The benchmark works fine with the TX+RX Throughput: (5.168)Mbits/s.

Neither are the line longer the a few byte nor does the measurement need more the 20ms. But might it be that the server can only quickly send a line in RESPOND to a client request line? When I try to answer one line from the client (a “command” like “list all parameters”) and the server tries to send a list (means more than one line) it becomes very slow. Is that the rule?

Thanks, Uwe

Teemu Tuominiemi

# 17 Aug 2012

Uwe Haertel wrote:

Emilio Monti wrote:

Hi Uwe,

Uwe Haertel wrote:

Trying to send a row of measurement results from the mbed I realized, that this connection is very slow maybe 3 lines per second. Is that correct or am I doing something wrong.

Firstly, could you run the following benchmark and confirm me that you are getting around (5.852) Mbits/s of (RX+TX) throughput? BENCHMARK

If you are getting the above throughput, then there are only two possible causes:

Your "lines" are tens of kilobytes long.
What you are doing between receiving a command and producing a response is taking hundreds of milliseconds.

Cheers, Emilio

The benchmark works fine with the TX+RX Throughput: (5.168)Mbits/s.

Neither are the line longer the a few byte nor does the measurement need more the 20ms. But might it be that the server can only quickly send a line in RESPOND to a client request line? When I try to answer one line from the client (a “command” like “list all parameters”) and the server tries to send a list (means more than one line) it becomes very slow. Is that the rule?

Thanks, Uwe

I think I had the same thing when I tested websockets with the new Ethernet library. Websocket's send()-function sends multiple small messages calling socket.send(). I changed the code so that all the short messages were pushed into one longer message. After that I sent all at once. This significantly improved the response time that was almost 1s before.

Unlike in Uwe's application in my application mbed is a client.

Teemu

Emilio Monti

# 17 Aug 2012

Hi Uwe, Teemu, could you publish your benchmarks to support your claims, like we did?

Here we have done different tests with different payloads and different TX/RX configurations: we have never seen a rate lower than 3000 calls to "send" per second.

My first impression is that you are overlooking something you are doing in between each "send". For example, a "printf", or an access to the "local file-system", or an access to other external peripherals, is going to take immediately the larger share of the time.

Cheers, Emilio

Teemu Tuominiemi

# 20 Aug 2012

Emilio Monti wrote:

Hi Uwe, Teemu, could you publish your benchmarks to support your claims, like we did?

Here we have done different tests with different payloads and different TX/RX configurations: we have never seen a rate lower than 3000 calls to "send" per second.

My first impression is that you are overlooking something you are doing in between each "send". For example, a "printf", or an access to the "local file-system", or an access to other external peripherals, is going to take immediately the larger share of the time.

Cheers, Emilio

Benchmark: TX+RX Throughput: (3.629)Mbits/s.

I ran a simple test with the Websocket_Ethernet_HelloWorld-program adding a timer to count how long it takes to send a message:

Timer t;
while (1) {  
   t.start();
   ws.send("WebSocket Hello World over Ethernet");
   t.stop();
   printf("it took %f s to send a message\n\r",t.read());
   t.reset();   
   wait(1.0);
}

The result was 0.25s. I also ran the same test with the websocket library that I modified. With the modified library I got 0.000085s. I don't know if you can get the same results?

BR, Teemu

Samuel Mokrani

# 20 Aug 2012

Hi Teemu,

Quote:

The result was 0.25s. I also ran the same test with the websocket library that I modified. With the modified library I got 0.000085s. I don't know if you can get the same results?

Yes I did the modifs (and pushed them (http://mbed.org/users/samux/code/WebSocketClient)) and have exactly the same results as you.

Sam

Uwe Haertel

# 20 Aug 2012

Hallo again,

Was with my son on GAMESCOM over weekend thus couldn’t proceed with this project.

As I already mentioned, the benchmark works fine with the expected result of about 5500 MBit/s, as long as I use the original program. But when I modify the code in a way that a sent line is not followed by a line received in an instant, the speed dramatically drops (to about 4 lines per second).

For instant: python script sends a line, mbed receives it and returns it twice. Of cause python script has changed to receive two lines. Then I barely get 0.01 MBit/s.

When I change the code that mbed only sends and python only receives, mbed sends 5 lines and then stops working at all.

Looks like I have to poll each singe line from the server.

Uwe

Ivo Noorhoff

# 22 Aug 2012

I have tried out the two network stacks an there are a couple of features I'd like to see in the new stack. Maybe the features are available but just not documented.

1) Setting the link speed and mode. When debugging, i connect the mbed via a 10 Mb/s hub and listen to the traffic via wireshark. For that to work I need to be able to force the mbed in 10 Mb/s mode speed and half duplex mode. I used to be able to do this via : Ethernet eth; eth.set_link(Ethernet::HalfDuplex10);

2) getting the obtained IP, Netmask, Gateway and DNS. The IP seems to have been hacked in, but I'd rather not recieve it as string but as ip_addr_t (much more compact and easier to compare) and convert it myself via inet_ntoa(*ip_addr).

3) sending WOL packets. The solutions were to use "eth.write(buf, sizeof(buf));" directly or to create an UPD socket and write to it ("sock.sendto(buf, sizeof(buf), &them);"). I am unsure which solution will still work.

I have hacked a solution for 2) touching only the EthernetInterface class but i'm a bit unsure about the solution.

A "nice to have" would be recieving the IP of the NTP server via DHCP. NTP is not part of lwIP so i'm hacking a stub so the DHCP code can store the NTP server IP and the NTP client code can pick it up.

Mario Dominguez

# 24 Sep 2012

I have an app using EthernetNetIf.h and HTTPClient.h and I want migrate to InternetInterface but I have some questions. -There are some guide to do this migration? - In the main loop of my app I call NET::Poll() in order to maintain working the asynchronous calls of the HTTP client, how I must to proceed about that with the new library? - How can I get the MAC address(getHwAddr(); in EthernetNetIf)?

Thanks, HMarioD

Matt Johnston

# 01 Oct 2012

Denis Magda wrote:

Trying to configure the RTOS, setting the minimal values for stacks sizes (64KB) and threads counts but always get "section `.bss' will not fit in region `RAM'" error from a linker. I use the GCC ARM compiler.

Did you figure this out? I'm seeing the same problem with gcc4mbed.

Luis Linares

# 04 Oct 2012

Hello. I have just tried to port my code to this new library. I have successfully compiled and run, in original and modified forms, the TCP Echo Server example. But when invoking the library in my actual project, the following compiler errors show up:

"a value of type "void *" cannot be used to initialize an entity of type "lpc_enetdata *"" in file "EthernetInterface/lwip-eth/arch//lpc17_emac.c", Line: 266, Col: 38
"a value of type "void *" cannot be assigned to an entity of type "eth_hdr *"" in file "EthernetInterface/lwip-eth/arch//lpc17_emac.c", Line: 454, Col: 11
"a value of type "void *" cannot be used to initialize an entity of type "lpc_enetdata *"" in file "EthernetInterface/lwip-eth/arch//lpc17_emac.c", Line: 764, Col: 38
"a value of type "void *" cannot be used to initialize an entity of type "lpc_enetdata *"" in file "EthernetInterface/lwip-eth/arch//lpc17_emac.c", Line: 785, Col: 38
"cannot open source input file "us_ticker_api.h": No such file or directory" in file "EthernetInterface/lwip-sys/arch//sys_arch.c", Line: 23, Col: 26
"expected an identifier" in file "mbed-rtos/rtx//rt_TypeDef.h", Line: 61, Col: 9
"expected an identifier" in file "mbed-rtos/rtx//rt_TypeDef.h", Line: 61, Col: 9

... and a lot other library-originated errors. None of the errors point to lines in my sources. I have instantiated the library by dragging the 'EthernetInterface' and 'mbed-rtos' libraries from my working TCPEchoServer program into my actual project. I had deleted the instantiations of the 'EthernetNetIf' and 'SimpleSocket' libraries, which were the ones I was using previously.

I have no issue with falling back to the old libraries, but I would really benefit from the reported performance improvement of the new official libraries. In case it helps (but I suspect it does not), here's a skeleton of my code (It has a lot of issue-unrelated code):

main.cpp

#include "mbed.h"

#include "main.h"

EthernetInterface eth;
//... other objects...
int main()
{   
    // Some critical, ethernet-unrelated code...
    
    // Ethernet and server setup
    eth.init();
    eth.connect();
    TCPSocketServer server;
    server.bind (SERVER_PORT);
    server.listen();
    TCPSocketConnection client;

    // More unrelated initialization code...

    while (true)
    {
        if (currently_unconnected)
        { 
            server.accept (client);  
            currently_unconnected = false;
        }
        else
        {
             if ( client.is_connected() )
             {
                  // Do stuff...
             }
             else
             {
                 currently_unconnected = true;
                 client.close();
             }
        }
    }

main.h

#ifndef _MAIN_H_
#define _MAIN_H_
    
#include "EthernetInterface.h"
// Other libraries...

// #defines and prototypes, etc.
#endif /* _MAIN_H_ */

Thank you!

Hello. I have just tried to port my code to this new library. I have successfully compiled and run, in original and modified forms, the TCP Echo Server example. But when invoking the library in my actual project, the following compiler errors show up: <<code>> "a value of type "void *" cannot be used to initialize an entity of type "lpc_enetdata *"" in file "EthernetInterface/lwip-eth/arch//lpc17_emac.c", Line: 266, Col: 38 "a value of type "void *" cannot be assigned to an entity of type "eth_hdr *"" in file "EthernetInterface/lwip-eth/arch//lpc17_emac.c", Line: 454, Col: 11 "a value of type "void *" cannot be used to initialize an entity of type "lpc_enetdata *"" in file "EthernetInterface/lwip-eth/arch//lpc17_emac.c", Line: 764, Col: 38 "a value of type "void *" cannot be used to initialize an entity of type "lpc_enetdata *"" in file "EthernetInterface/lwip-eth/arch//lpc17_emac.c", Line: 785, Col: 38 "cannot open source input file "us_ticker_api.h": No such file or directory" in file "EthernetInterface/lwip-sys/arch//sys_arch.c", Line: 23, Col: 26 "expected an identifier" in file "mbed-rtos/rtx//rt_TypeDef.h", Line: 61, Col: 9 "expected an identifier" in file "mbed-rtos/rtx//rt_TypeDef.h", Line: 61, Col: 9 <</code>> ... and a lot other library-originated errors. None of the errors point to lines in my sources. I have instantiated the library by dragging the 'EthernetInterface' and 'mbed-rtos' libraries from my working TCPEchoServer program into my actual project. I had deleted the instantiations of the 'EthernetNetIf' and 'SimpleSocket' libraries, which were the ones I was using previously. I have no issue with falling back to the old libraries, but I would really benefit from the [[https://mbed.org/users/emilmont/notebook/networking-libraries-benchmark/|reported performance improvement]] of the new official libraries. In case it helps (but I suspect it does not), here's a skeleton of my code (It has a lot of issue-unrelated code): <<code main.cpp>> #include "mbed.h" #include "main.h" EthernetInterface eth; //... other objects... int main() { // Some critical, ethernet-unrelated code... // Ethernet and server setup eth.init(); eth.connect(); TCPSocketServer server; server.bind (SERVER_PORT); server.listen(); TCPSocketConnection client; // More unrelated initialization code... while (true) { if (currently_unconnected) { server.accept (client); currently_unconnected = false; } else { if ( client.is_connected() ) { // Do stuff... } else { currently_unconnected = true; client.close(); } } } <</code>> <<code main.h>> #ifndef _MAIN_H_ #define _MAIN_H_ #include "EthernetInterface.h" // Other libraries... // #defines and prototypes, etc. #endif /* _MAIN_H_ */ <</code>> Thank you!

Wim Huiskamp

# 13 Oct 2012

The 'old' Ethernet interface has an option to provide a name to the DHCP host that mbed tries connecting to. That name was visible in my router and useful for debugging. That feature seems to be unsupported in the new official lib. Anyone know how to do this or are there plans to add this feature.

see http://mbed.org/users/donde/code/EthernetNetIf-/file/f26903b63415/EthernetNetIf.h

///Instantiates the Interface and register it against the stack, DHCP will be used
/**
* An optional hostname can be specified which will be passed to the DHCP server.
* Examples without and with hostname specified:
*
* @code
* EthernetNetIf eth();
* @endcode
* @code
* EthernetNetIf eth("mbedSE");
* @endcode
*/
EthernetNetIf(const char* hostname = NULL); //W/ DHCP

Luis Linares

# 23 Oct 2012

Luis Linares wrote:

Hello. I have just tried to port my code to this new library. I have successfully compiled and run, in original and modified forms, the TCP Echo Server example. But when invoking the library in my actual project, the following compiler errors show up:

"a value of type "void *" cannot be used to initialize an entity of type "lpc_enetdata *"" in file "EthernetInterface/lwip-eth/arch//lpc17_emac.c", Line: 266, Col: 38
"a value of type "void *" cannot be assigned to an entity of type "eth_hdr *"" in file "EthernetInterface/lwip-eth/arch//lpc17_emac.c", Line: 454, Col: 11
"a value of type "void *" cannot be used to initialize an entity of type "lpc_enetdata *"" in file "EthernetInterface/lwip-eth/arch//lpc17_emac.c", Line: 764, Col: 38
"a value of type "void *" cannot be used to initialize an entity of type "lpc_enetdata *"" in file "EthernetInterface/lwip-eth/arch//lpc17_emac.c", Line: 785, Col: 38
"cannot open source input file "us_ticker_api.h": No such file or directory" in file "EthernetInterface/lwip-sys/arch//sys_arch.c", Line: 23, Col: 26
"expected an identifier" in file "mbed-rtos/rtx//rt_TypeDef.h", Line: 61, Col: 9
"expected an identifier" in file "mbed-rtos/rtx//rt_TypeDef.h", Line: 61, Col: 9

... and a lot other library-originated errors. None of the errors point to lines in my sources. I have instantiated the library by dragging the 'EthernetInterface' and 'mbed-rtos' libraries from my working TCPEchoServer program into my actual project. I had deleted the instantiations of the 'EthernetNetIf' and 'SimpleSocket' libraries, which were the ones I was using previously.

.....

Well after all, I solved this by cloning the TCPEchoServer program and manually adding the files and functions, modifying them suitably. It seems, EthernetInterface and mbed-rtos MUST be imported first and foremost before actual code development starts.

FAST LHR

# 06 Nov 2012

I am having a huge problem with EthernetInterface Library. Upon compiling this code I get the following error.

struct "os_thread_def" has no field "stack_pointer" in EthernetInterface/lwip-sys/arch/sys_arch.c

Some forums suggested that I updated the EthernetInterface and rtos libraries but this didn't work for me.

Please help me with this.

Tayyab

technooliq .

# 09 Nov 2012

Has anyone successfully built this library using GCC ? I got a run-time issue (Blue Lights of Death). I am just trying to build the TCPSocketHelloWorld program. I had the same issue as Denis Magda and Matt Johnston regarding the "section `.bss' will not fit in region `RAM'", so I have just put a return statement in my main so everything get optimised out. I have added a led flicking at start of the main before the return statement, but can't get that working, I believe something is not being initialised correctly thus the Blue lights of death... Thanks for any help.

- Edit: I have found the issue, it actually has something to do with RTOS. Thanks to a post from Adam Green in the RTOS handbook , I have been able to successfully build the new library using gcc4mbed. I still need to run some tests though. Cheers. -

Static Public Member Functions
static int	init ()
	Initialize the interface with DHCP.
static int	init (const char ip, const char mask, const char *gateway)
	Initialize the interface with a static IP address.
static int	connect (unsigned int timeout_ms=15000)
	Connect Bring the interface up, start DHCP if needed.
static int	disconnect ()
	Disconnect Bring the interface down.
static char *	getMACAddress ()
	Get the MAC address of your Ethernet interface.
static char *	getIPAddress ()
	Get the IP address of your Ethernet interface.

mbed

Networking

Hardware¶

Software¶

» Import this library into a program EthernetInterface

» Import this library into a program
EthernetInterface - EthernetInterface Class Reference

Static Public Member Functions

Examples¶

» Import this program TCPSocket_HelloWorld

» Import this program
UDPSocket_HelloWorld - main.cpp

Feedback¶

2 related questions:

36 comments:

Ben Jemmett wrote:

Maverick War wrote:

Emilio Monti wrote:

Maverick War wrote:

Sheldon Cooper wrote:

Sheldon Cooper wrote:

» Import this library into a program
Socket - TCPSocketConnection Class Reference

Public Member Functions

Friends

Uwe Haertel wrote:

Emilio Monti wrote:

Uwe Haertel wrote:

Uwe Haertel wrote:

Emilio Monti wrote:

Uwe Haertel wrote:

Emilio Monti wrote:

Quote:

Denis Magda wrote:

main.cpp

main.h

Luis Linares wrote:

Recent changes