Smalles Ethernet (no TCP/IP) implementation, even 10Mbps

I have to create a small network composed by some nodes. At the moment, th e number of nodes is about 10, but I want to have a flexible architecture t hat could increase in the future.

I think Ethernet is a very good bus technology that solves many problems to the developer: framing, multi-master, addressing, conflicts, ...

I don't need the full TCP/IP stack that needs high resources. I just want to send raw Ethernet packets to the bus and receive raw packets from the bu s (like for RS485). I don't need very high-speed, so it could be sufficient the 10Mbps. 100Mbp s could be nice in the future.

What is the smallest and cheapest solution? A microcontroller with embedde d MAC and an external PHY, magnetics and connector, or a microcontroller wi th an external Ethernet controller (with MAC+PHY integrated), magnetics and connector?

Another problem could be the cabling of the network. Usually Ethernet is a star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each sin gle node, so I can make a "line" topology:

+---+ +---+ +---+ | |---| |---| | +---+ +---+ +---+

How can I implement this small two-ports hub/switch in every single node of the network?

Reply to
pozzugno
Loading thread data ...

number of nodes is about 10, but I want to have a flexible architecture that could increase in the future.

developer: framing, multi-master, addressing, conflicts, ...

What is the distance between stations and the total line length ? What are your actual data throughput requirements ?

Have you checked if this could be implemented with CAN (Controller Area Network) ? This would also solve the same problems as you listed.

from the bus

Consider using UDP instead of using raw Ethernet frames and it is easier to use normal diagnostic tools much easier. It actually adds only a few bytes into the frame header and requires the simple ARP protocol to be implemented.

And consume a lot more power.

MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics and connector?

star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each single node, so I can make a "line" topology:

network?

Have you considered RG-58 coaxial cable on 10Base2 :-)

You would need only one transceiver in each node and a T-coaxial connector at each node. I have no idea, if 10base2 transceivers are still available and what they cost.

I would still suggest first checking, if CAN would be sufficient.

Reply to
upsidedown

number of nodes is about 10, but I want to have a flexible architecture that could increase in the future.

developer: framing, multi-master, addressing, conflicts, ...

send raw Ethernet packets to the bus and receive raw packets from the bus (like for RS485).

could be nice in the future.

MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics and connector?

star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each single node, so I can make a "line" topology:

network?

There are a number of single-chip 3-port switches out there. For example the LAN9313. You can attach the Ethernet port on your microcontroller to the MII port on the LAN9313, and two 10/100-base-T ports on the other side. It'll look just like any other switch/bridge to the rest of the network.

Reply to
Robert Wessel

I strongly second that opinion - CAN is a lot easier and cheaper to work with than Ethernet. Of course, it is not nearly as good at transmitting large amounts of data - but it is often better than Ethernet for small frames (with low and predictable latencies).

UDP means IP, and that means ARP and a stack. You can get away with fixed ARP tables if you need to, but you still have a bit of overhead in time and code. Sending and receiving raw Ethernet frames is easy with most microcontroller MACs.

Far and away the most useful Ethernet diagnostic tools is Wireshark - and it has no problem with raw Ethernet frames. However, if you are stuck using Windows as a development tool rather than Linux, it is not easy to generate raw Ethernet frames because of limitations in the OS. You need to use something like WinPCap rather than normal Windows API calls. On Linux you do as you want.

If you go for UDP, however, you can then more easily integrate with other systems over the network - and the implementation is usually just a question of downloading LWIP and configuring it for your uses.

Reply to
David Brown

As noted by myself and others, first check if CAN will do the job as it is a lot easier.

If you need to use Ethernet, then as suggested by Robert Wessel you can easily put a small switch chip on the board. However, be aware that making a chain like this will give you large latencies in communication between the two ends of the chain as switches are often implemented as store-and-forward. Even if they have fast packet switching, they need to store and interpret the Ethernet header before passing on the packet

- you will get an absolute minimum of about 20 usec for each step in the chain. With 10 nodes, that's 0.2 msec - longer latency than a CAN bus.

If you don't want to go for a full star topology, you should at least consider more than two ports per card. You could use a switch chip with four PHYs plus a MAC interface, and then get a much flatter topology - even though most ports on most cards will be unused.

Reply to
David Brown

Ethernet has plentiful low cost cabling and router options, but you have not mentioned the price point for your nodes. Adding Etherent will raise the price of the nodes (maybe that doesn't matter if this is a one off with only 10).

You also have not mentioned anything about what is being communicated or how (data size, throughput, addressing, address configuration, etc.). It might be that you have considered all this and concluded that Ethernet is your best solution, but other people reading the post will wonder if it is overkill for what you want. Lots of people have mentioned CAN already, but multi-drop RS485/422 could also be a very simple and low cost solution if it meets your requirements.

Sending and receiving raw Ethernet is simple enough, as others have mentioned, if you wanted to go up a level in abstraction then UDP might be better.

Without knowing the requirements I couldn't say what the best solution was. If you go the Ethernet route then I have recently released a small UDP stack

formatting link
which might suite, again depending on what else your system is doing and the hardware it is doing it on.

Regards, Richard.

  • formatting link
    Designed for microcontrollers. More than 103000 downloads in 2012.

  • formatting link
    Trace, safety certification, UDP/IP, TCP/IP, training, and more...

Reply to
FreeRTOS info

CAN is essentially RS-485, in fact, in the early development stages, standard RS-485 chips were used (data to Driver Enable pin, Data pin tied to dominant state).

If multi-master is a critical requirement, I would suggest CAN or Ethernet, however, if standard two wire RS-485 is required, then some higher level protocol, like token passing is needed.

For instance Profibus-DP protocol allows multiple masters on the same (essentially) RS-485 bus, but each master have to pass a token to the next master, after the active master has scanned all slaves.

Reply to
upsidedown

No, CAN is not essentially RS-485. You can - as you say - use RS-485 drivers configured in a non-standard way to handle the physical layer of CAN. But CAN provides a protocol layer on top of that which is very different from the UART layer used with RS-485.

CAN gives you that and more.

There are times when RS-485 is best, and times when CAN is best - they are not the "essentially" same.

Note also that multi-master and multi-drop are two different concepts. Multi-master implies multi-drop, but not vice-versa.

No sane person would consider using Profibus-DP as an alternative to CAN, RS-485 or Ethernet unless communicating on Profibus is a requirement of the application.

Reply to
David Brown

I am sorry, I forget to include "electrically" in my statement about RS-485.

Reply to
upsidedown

For lack of a better term, "layer 2 socket" support is varied among O/S offerings. It would be daunting (but not impossible ) to do against bare metal. Managing all the MAC addresses might be a headache.

Seems like UDP might be a solution. And it almost sounds like you "want" UDP multicast, to emulate a bus.

There are dual-PHY offerings ( two "ports", one embedded MAC core ). A MAC core can have more than one MAC address, usually.

The problem is that it's a PHY, not a switch node. If nodes 1,2 and 3 are relatively in series with each other, how does a packet generated by

1 get forwarded to 3? Node 2 has to take a positive action to forward it. I don't think the PHY on node 2 just does that; you'd have to unmarshal the packet and retransmit on node
  1. You can have an Ethernet bridge per node. That's some overhead, though. An external switch is not just a patching box; it participates in the negotiation of layer 2 links and may make forwarding decisions.

Even if you go layer 3, the network configuration will be somewhat of a headache.

You'd need a learning bridge per node, best I can tell. You may be able to nail up a bridge configuration per node, but that will get painful fast.

--
Les Cargill
Reply to
Les Cargill

Fair enough - there are a lot of electrical similarities.

However, there are electrical differences too. With RS-485, the drivers can pull the lines high or low with quite a large current - this lets you run either very fast (such as 12 Mbps) or very far (up to several km). With CAN, you only drive dominant - recessive is by termination resistors, and is thus much slower on long high-capacitance lines. In addition, the CAN bus requires the whole bus to be stable at each state within half a bit time (whereas with a long or fast RS-485 bus, you can have several bits in flight at once). This means that your CAN bus is much shorter or slower than an RS-485 bus could be.

Reply to
David Brown
[...]

since it is a transmission line, the dominant -> recessive transition is also fast on long lines.

The cable capacitance is less a problem than the lumped capacitance of transceivers etc.

Oliver

--
Oliver Betz, Munich 
despammed.com is broken, use Reply-To:
Reply to
Oliver Betz

That's true - but the dominant to recessive transition by terminating resistor is still slower than a driven transition. It is the limiting factor in the speed vs. length trade-off.

mvh.,

David

Reply to
David Brown
[...]

Do you have numbers?

I made tests only with approx. 30m twisted pair cable and it's more than one year ago, but IIRC there was no big difference in rise/fall time.

Of course, you shouldn't measure with a standard 10:1scope probe beause it adds too much capacitance to the node.

Oliver

--
Oliver Betz, Munich 
despammed.com is broken, use Reply-To:
Reply to
Oliver Betz

the number of nodes is about 10, but I want to have a flexible architecture that could increase in the future.

to the developer: framing, multi-master, addressing, conflicts, ...

t to send raw Ethernet packets to the bus and receive raw packets from the bus (like for RS485).

bps could be nice in the future.

ded MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics a nd connector?

a star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each s ingle node, so I can make a "line" topology:

of the network?

Have a look at some of the 'industrial' ethernet parts that Micrel sells. KSZ8842-16MQL has a two port switch plus MAC with an 8/16 bit interface. I haven't used it, but looks like it's similar to your requirements.

Reply to
amdyer

number of nodes is about 10, but I want to have a flexible architecture that could increase in the future.

the developer: framing, multi-master, addressing, conflicts, ...

send raw Ethernet packets to the bus and receive raw packets from the bus (like for RS485).

could be nice in the future.

MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics and connector?

star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each single node, so I can make a "line" topology:

the network?

Hi!

Please tell us (the group) what you choose and why.

(Search:

formatting link
)

Take a look at:

"Powerpoint": Introduction to sensor hardware - Network and Systems Lab:

formatting link

"Powerpoint": Smart Sensor Design and Networking Standards - Esensors, Inc.:

formatting link
Quote: "... Numerous (>100) incompatible sensor networks are currently in use ? each speaking a different language ...

  • The IEEE 1451 Smart Transducer Protocol standard is the best universal solution
Reply to
Glenn

number of nodes is about 10, but I want to have a flexible architecture that could increase in the future.

the developer: framing, multi-master, addressing, conflicts, ...

send raw Ethernet packets to the bus and receive raw packets from the bus (like for RS485).

could be nice in the future.

MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics and connector?

star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each single node, so I can make a "line" topology:

the network?

Hi! (full version)

Please tell us (the group) what you choose and why.

(Search:

formatting link
)

Take a look at:

"Powerpoint": Introduction to sensor hardware - Network and Systems Lab:

formatting link

"Powerpoint": Smart Sensor Design and Networking Standards - Esensors, Inc.:

formatting link
Quote: "... Numerous (>100) incompatible sensor networks are currently in use ? each speaking a different language ...

  • The IEEE 1451 Smart Transducer Protocol standard is the best universal solution
Reply to
Glenn

number of nodes is about 10, but I want to have a flexible architecture that could increase in the future.

the developer: framing, multi-master, addressing, conflicts, ...

send raw Ethernet packets to the bus and receive raw packets from the bus (like for RS485).

could be nice in the future.

MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics and connector?

star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each single node, so I can make a "line" topology:

the network?

Hi! (full version)

Please tell us (the group) what you choose and why.

(Search:

formatting link
)

Take a look at:

"Powerpoint": Introduction to sensor hardware - Network and Systems Lab:

formatting link

"Powerpoint": Smart Sensor Design and Networking Standards - Esensors, Inc.:

formatting link
Quote: "... Numerous (>100) incompatible sensor networks are currently in use ? each speaking a different language ...

  • The IEEE 1451 Smart Transducer Protocol standard is the best universal solution
Reply to
Glenn

number of nodes is about 10, but I want to have a flexible architecture that could increase in the future.

the developer: framing, multi-master, addressing, conflicts, ...

send raw Ethernet packets to the bus and receive raw packets from the bus (like for RS485).

could be nice in the future.

MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics and connector?

star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each single node, so I can make a "line" topology:

the network?

Hi! (full version 4)

Please tell us (the group) what you choose and why.

(Search:

formatting link
)

Take a look at:

"Powerpoint": Introduction to sensor hardware - Network and Systems Lab:

formatting link

"Powerpoint": Smart Sensor Design and Networking Standards - Esensors, Inc.:

formatting link
Quote: "... Numerous (>100) incompatible sensor networks are currently in use ? each speaking a different language ...

  • The IEEE 1451 Smart Transducer Protocol standard is the best universal solution
  • Supported by NIST, IEEE and many Federal agencies ... IEEE 1451 Advantages
  • Comprehensive enough to cover nearly all sensors and actuators in use today (not 20/80% approach)
  • Many operating modes (buffered, no-buffer, grouped sensors, timestamps, timed data, streaming ...)
  • Extensive units, linearization and calibration options
  • Multiple timing and data block size constraints handled.
  • Compatible with most wired and wireless sensor buses and networks (point-to-point, mesh, TIM-to-TIM, mixed networks).
  • Efficient binary protocol (especially suitable for wireless)
  • Standard is 400+ pages for basic part, over 1500 page total ...
  • A compliance test procedure is also desirable to prove that the design is correct ..."

BACnet:

formatting link
Quote: "... BACnet is a communications protocol for building automation and control networks. It is an ASHRAE, ANSI, and ISO standard protocol. ... The BACnet protocol defines a number of data link / physical layers, including ARCNET, Ethernet, BACnet/IP, Point-To-Point over RS-232, Master-Slave/Token-Passing over RS-485, and LonTalk. ..."
formatting link

stitcs.com: White Paper: BACnet vs. Lon?The War is Over:

formatting link
Citat: "...How BACnet won the war. The outcome of most wars is determined by a few key battles. In the war of open protocols for building controls, BACnet?s decisive victory is defined by three: Industry-wide acceptance, greater benefits than LonWorks and a change in manufacturers? ideology about their building protocols offerings..."

Open-Source BACnet Protocol stack for Linux:

formatting link

Open-Source BACnet Protocol stack for embedded systems:

formatting link

Open-Source BACnet Protocol stack in Java:

formatting link

BACpypes, Open-Source BACnet Protocol stack in Python:

formatting link

BACsharp, Open-Source BACnet Protocol stack in C#:

formatting link

Might be useful for wired also:

12/04/07, Choosing the best system software architecture for your wireless smart sensor design: Part 1:
formatting link
12/10/07, Choosing the best system software architecture for your wireless smart sensor design: Part 2:
formatting link
12/17/07, Choosing a system software architecture for your wireless smart sensor design: Part 3:
formatting link

Energy-aware wireless-wired communications in sensor networks:

formatting link
Quote: "... In our sensor network architecture sensor units are organized in clusters where communication rely on a fieldbus, with each cluster connected to rest of the network through wireless links. A reliable and efficient data transmission model has been proposed for the intra-cluster communication, which takes into account energy constraints keeping the involved units in a power saving state as long as possible. ..."

Network and Control Protocol for a Wired Self-Organising Sensor:

formatting link

-

formatting link

-

formatting link

-

formatting link

formatting link

A layer 2 routing protcol:

formatting link
formatting link
formatting link
Quote: "... The batman-adv Ethernet type (0x4305) was accepted as "official" Ethernet type inside the Linux kernel to help avoiding future collisions with other protocols. ..."

formatting link
formatting link

formatting link

br,

Glenn

Reply to
Glenn

number of nodes is about 10, but I want to have a flexible architecture that could increase in the future.

the developer: framing, multi-master, addressing, conflicts, ...

I could imagine a maximum total line length of 100m. Anyway I have the possibility to use normal Ethernet switches to increase the network physical size with a small increase in cost.

It is actually low: 57600bps could be enough. But I have some ideas to implement in the feature.

Indeed I already thought about CAN. But the main focus of CAN bus is predictability and low latency that I don't need. Maybe the cost of a CAN network could be very low, but I don't know what could be the cost of a simple Ethernet network. Is it still high? Texas produces many microcontroller of Stellaris family with Ethernet MAX and PHY integrated. It is only to add magnetics and connector to implement a fully 10-100Mbps Ethernet node.

from the bus

UDP means IP...

MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics and connector?

star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each single node, so I can make a "line" topology:

the network?

Reply to
pozz

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.