Greetings all! A question from those of us that are Ethernet challenged.

I have four devices (all mbed microtrollers) that are all connected to an Ethernet switch. I would like to enable simple communication between all four devices, using some kind of Ethernet protocol.

I would like to have their four addresses configured as follows:

192.168.10.1

192.168.10.2

192.168.10.3

192.168.10.4

All subnet masks: 255.255.255.0

I am pretty sure that I need to use the "Ethernet" class, but I am not sure what other classes will be needed as well.

Question: If, for example, I would like mbed controller "192.168.10.2" to send a simple message to controller "192.168.10.4", how would I accomplish this?

Thanks for any help you can provide! -RT

A good place to start is the Networking Cookbook.

Okay,

I have read the Networking Cookbook, and although I am still a bit confused, here's what I *believe* I should do based on my first post:

1) use the ethernet.send to send an ethernet packet from 192.168.10.2 to all nodes

2) inside of this ethernet packet, embed the intended address for the message receiver (192.168.10.4).  For the other two nodes that receive the packet (192.168.10.1 and 192.168.10.3), have them simply disregard the packet

--> Am I right so far?

ALSO, for the ethernet.receive command, is there a way to have this generate an interrupt (as in, generate interrupt when a packet is received), or must it be a polled operation (check every so often to see if a new packet has arrived)?

I believe that the TCP/IP stack already does all that. All you have to do is send packets to the appropriate address. The TCP/IP protocol does all the framing of the ethernet packets and all that good stuff. You just have to open a socket between any two devices and send/receive packets between them using the NetServices library.

Something to consider: TCP/IP is not synonymous with Ethernet. Frequently it is easier to use raw Ethernet without TCP/IP; especially if the devices (addressed via their MACs) are known; there is no TCP/IP routing (everything OSI level 2, i.e. same switch); and no extrinsic need for TCP/IP functionality.

Raw Ethernet packets contain the source and target MAC addresses and can direct messages to specific recipients or broadcast messages to all devices on a switch. Ethernet seems to meet your needs without TCP/IP.

Thank you all for your responses!

--> Concerning raw ethernet, is there an API in the cookbook section that shows/performs how to make the packet, with the MAC address?  All I see in the "ethernet" section is the constructor (with IP, subnet, gateway, and DNS addresses), the setup function, and the getIP function.  I don't see anything regarding how to "send" a message to a specific ip or MAC address.

Ok. If you use raw ethernet, IP addresses don't exist. The ethernet section is a little misleading because it talks about IP addresses and such. To communicate via ethernet using MAC addresses see the Ethernet in the handbook. I have never tried to use the ethernet interface since I only have one mbed. But it seems pretty straight forward if you intend to set up a simple link.

I have 3 Mbeds and have had them all communicating using LLDP (which is an ethernet layer only protocol). I used LLDP as it allows you to broadcast and discover other Mbeds on the network and their MAC addresses. I didn't use any IP protocols at all and that of course leaves you with a lot of limitations, mainly, you have to code everything yourself. This is because the "standard" Mbed library (the IP stacks based around LWIP) doesn't allow you to "hook in" to handle a specific ethernet packet type at the lowest level (the eth device driver). I didn't look to see if there are any callbacks further up the stack so it maybe possible to implement LLDP further up. I just didn't need IP at all, just local ethernet network connectivity.

Hi Andy,

Is there any chance of you posting your LLDP code at some point (even if only as a library)?

I'm interested in something similar but don't yet know if I need to use IP or just plain Ethernet...so I might be able to use your solution & see whether the IP is required or not. (We already use IP for other features but want to be able to detect other mbeds on the network, though this can potentially be run at different times)

TIA

Jez

Aha!  I see that there are a few points of confusion here (I know that this is probably basic information for the experienced ethernet user, but for us beginners, it can be very difficult to understand exactly what is going on).

--> Both the handbook and cookbook sections have an "Ethernet" class, and they are different (as stated, the cookbook section has an ethernet function that sets the IP address - which doesn't make any sense!).

--> The Ethernet handbook section does have an example program of a packet "sniffer".  Unfortunately, this program does not make use of the ethernet.write and ethernet.send functions to actually SEND packets (this would be nice to see, so that we can understand how packets are sent, not just how they are received).

--> Regarding the ethernet.receive function, is there a way to tie this to an interrupt, so that it will automatically process a received ethernet packet, instead of having to keep polling to see if a packet has arrived?

SO, as an example for a SEND command, if I have one mbed with a mac address if aa.aa.aa.aa.aa.aa (herein referred to as "a") and another with a mac address of bb.bb.bb.bb.bb.bb (herein referred to as "b"), and I want to send, from a to b, a single byte of 0xff, then I would write (in pseudo code):

maca[6] = [0xaa,0xaa,0xaa,0xaa,0xaa,0xaa];

macb[6] = [0xbb,0xbb,0xbb,0xbb,0xbb,0xbb];

data = 0xff;

packet[13] = [macb, maca, data];

ethernet.write(packet,13); //13 bytes --> 6 for source and destination mac addresses, 1 byte of actual data

ethernet.send;

Is this the correct way of doing things?

Hi Richard,

As you go, it would be great if you could capture a how to and examples on a page in the cookbook as a bit of an Ethernet tutorial. It looks like you are discovering and working out lots of things, and i'm sure it could be useful to others following in your footsteps.

Hope you get it all working!

Simon

Jez, Richard, I can understand where you are coming from. I'm in a similar position, just a bit "further down the road" than yourselves. This evening I will sit down and write a notebook page on where I am now and what I've done to date (a notebook page as it's going to be lengthy and not appropiate to a forum post). Once I've done this then maybe we can "get together" (virtually online that is) and colaborate to produce library/documentation that opens up this "ethernet in the micro enviroment" subject to other beginners?

I curious as to the status on this "micro environment." I just found and began looking through Andy's LLDP test library to gain insight for use in my network. So far everything has been very straight forward with the provided libraries (NetIF, HTTPClient, HTTPServer). My biggest hurdle now is retrieving a file from a Client using a Server and auto discovery of the mbeds, once I can grasp those I will be free and clear.

The LLDP "test" program I did was something I knocked out quickly. It's unfinshed, it only broadcasts LLDP packets, it does not consume them (which makes it only half useful). The reason I stopped when I did is because I wanted to integrate into the network stack. That's when I ran into the issue the the currently implementation will drop packets for which the etherType field of the packet doesn't match it's tight criteria. There's no implementation to allow another library to hook itself into the eth_drv.c module.

So I made my own driver (which allows libraries to plug themselves in and handle etherTypes) and stack. In fact my stack is implemented as a plug-in itself. And my eth driver also handles the full MTU and the SRAM bank, something I think is only now becoming availble with the latest Mbed beta libraries.

Ah, so I'm thinking I'll avoid using the LLDP until I have learned more. I suppose if I make sure my HTTPServer has a static address the other mbeds could just contact it and "say hello" by leaving a file in its local directory. Ethernet send and receive can be used, but the receive will always have to be waiting, if I read about it correctly. Is there a better way that I can look up?

No. If you are using the library stack it's eth_drv.c module defines the ethernet and it's sending/receiving. You should spend some time learning how the stack works.

Hi guys, does anyone know if I could synchronise time with the NTP server by connecting the ethernet cable to the computer instead of connecting it to the modem?

Im currently using the EthernetNetIf library to connect to the NTP server

Reuben is asking about getting NTP protocol time from a PC rather than from the Internet. This was discussed in another thread. Short answer: No. Unless the PC is connected to the Internet to reach an NTP server, AND the PC's operating system gets an add-in NTP server. Getting NTP service from a user PC is most unusual.

Yes you're right. What if my computer is connected to the internet, how do I get mbed to be connected to the NTP server through my computer?