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

I have to create a small network composed by some nodes.  At the moment, the number of nodes is about 10, but I want to have a flexible architecture that 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 bus (like for RS485).
I don't need very high-speed, so it could be sufficient the 10Mbps.  100Mbps could be nice in the future.

What is the smallest and cheapest solution?  A microcontroller with embedded MAC and an external PHY, magnetics and connector, or a microcontroller with 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 single 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?

On Tue, 22 Jan 2013 00:14:04 -0800 (PST), pozzugno@gmail.com wrote:

>I have to create a small network composed by some nodes.  At the moment, the number of nodes is about 10, but I want to have a flexible architecture that 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, ...

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.

>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 bus 
>(like for RS485).

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.

>I don't need very high-speed, so it could be sufficient the 10Mbps.  
>100Mbps could be nice in the future.

And consume a lot more power.

>What is the smallest and cheapest solution?  A microcontroller with embedded MAC and an external PHY, magnetics and connector, or a microcontroller with 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 single 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?

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.

On Tue, 22 Jan 2013 00:14:04 -0800 (PST), pozzugno@gmail.com wrote:

>I have to create a small network composed by some nodes.  At the moment, the number of nodes is about 10, but I want to have a flexible architecture that 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 bus (like for RS485).
>I don't need very high-speed, so it could be sufficient the 10Mbps.  100Mbps could be nice in the future.
>
>What is the smallest and cheapest solution?  A microcontroller with embedded MAC and an external PHY, magnetics and connector, or a microcontroller with 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 single 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?


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.

On 22/01/13 09:52, upsidedown@downunder.com wrote:
> On Tue, 22 Jan 2013 00:14:04 -0800 (PST), pozzugno@gmail.com wrote:
> 
>> I have to create a small network composed by some nodes.  At the
>> moment, the number of nodes is about 10, but I want to have a
>> flexible architecture that 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, ...
> 
> 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.

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).

> 
>> 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 bus (like for RS485).
> 
> 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.
> 

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.

>> I don't need very high-speed, so it could be sufficient the 10Mbps.
>>  100Mbps could be nice in the future.
> 
> And consume a lot more power.
> 
>> What is the smallest and cheapest solution?  A microcontroller with
>> embedded MAC and an external PHY, magnetics and connector, or a
>> microcontroller with 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 single 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?
> 
> 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.
> 

On 22/01/13 09:14, pozzugno@gmail.com wrote:
> I have to create a small network composed by some nodes.  At the
> moment, the number of nodes is about 10, but I want to have a
> flexible architecture that 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 bus (like for RS485). I don't need very high-speed, so it
> could be sufficient the 10Mbps.  100Mbps could be nice in the
> future.
> 
> What is the smallest and cheapest solution?  A microcontroller with
> embedded MAC and an external PHY, magnetics and connector, or a
> microcontroller with 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 single 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?
> 

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.

On 22/01/2013 08:14, pozzugno@gmail.com wrote:
> I have to create a small network composed by some nodes.  At the
> moment, the number of nodes is about 10, but I want to have a
> flexible architecture that 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, ...

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.

> 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 bus (like for RS485). I don't need very high-speed, so it
> could be sufficient the 10Mbps.  100Mbps could be nice in the
> future.

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.


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

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 (http://www.FreeRTOS.org/udp) which might suite, again
depending on what else your system is doing and the hardware it is doing
it on.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 103000 downloads in 2012.

+ http://www.FreeRTOS.org/plus
Trace, safety certification, UDP/IP, TCP/IP, training, and more...

On Tue, 22 Jan 2013 10:36:43 +0000, FreeRTOS info <noemail@given.com>
wrote:

>> I think Ethernet is a very good bus technology that solves many
>> problems to the developer: framing, multi-master, addressing,
>> conflicts, ...
>
>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.

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.
 

On 22/01/13 11:55, upsidedown@downunder.com wrote:
> On Tue, 22 Jan 2013 10:36:43 +0000, FreeRTOS info <noemail@given.com>
> wrote:
> 
>>> I think Ethernet is a very good bus technology that solves many
>>> problems to the developer: framing, multi-master, addressing,
>>> conflicts, ...
>>
>> 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.
> 
> 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).

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.

> 
> 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.

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.

> 
> 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.
>  

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.

On Tue, 22 Jan 2013 12:58:39 +0100, David Brown
<david@westcontrol.removethisbit.com> wrote:

>On 22/01/13 11:55, upsidedown@downunder.com wrote:
>> On Tue, 22 Jan 2013 10:36:43 +0000, FreeRTOS info <noemail@given.com>
>> wrote:
>> 
>>>> I think Ethernet is a very good bus technology that solves many
>>>> problems to the developer: framing, multi-master, addressing,
>>>> conflicts, ...
>>>
>>> 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.
>> 
>> 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).
>
>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.
>
>> 
>> 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.

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

pozzugno@gmail.com wrote:
> I have to create a small network composed by some nodes.  At the
> moment, the number of nodes is about 10, but I want to have a
> flexible architecture that 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 bus (like for RS485). I don't need very high-speed, so it
> could be sufficient the 10Mbps.  100Mbps could be nice in the
> future.
>


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.

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

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
2.

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.

> 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 single 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?
>

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