Re: Embedded Ethernet

From	David Brown <david.brown@hesbynett.no>
Newsgroups	comp.arch.embedded
Subject	Re: Embedded Ethernet
Date	2017-09-23 12:02 +0200
Organization	A noiseless patient Spider
Message-ID	<oq5bf9$94c$1@dont-email.me> (permalink)
References	<oq3bj1$btg$1@dont-email.me> <WNWdnXHLauJvy1jEnZ2dnUU7-UednZ2d@earthlink.com> <oq417s$h39$1@dont-email.me>

Show all headers | View raw

On 23/09/17 00:01, pozz wrote:
> Il 22/09/2017 20:31, Joe Chisolm ha scritto:
>  > On Fri, 22 Sep 2017 17:52:01 +0200, pozz wrote:
>  >
>  >> There are many MCUs with embedded Ethernet (MAC). It seems most of the
>  >> open-source examples are lwip-based.
>  >>
>  >> I have to design a board with one RS485 port and one Ethernet port. It
>  >> could be seen as a serial-to-Ethernet converter, where the protocol on
>  >> RS485 is proprietary. On Ethernet side I will contact a server (cloud)
>  >> with a protocol that must be defined.
>  >>
>  >> At the moment, I don't need to implement a server, only a simple 
> client.
>  >>
>  >> Do you suggest some hw/fw platforms that you think are better than 
> others?
>  >
>  > How are you connecting to this "cloud" server?  Simple TCP or UDP or 
> is it
>  > some type of web services?
> I can choose. I know UDP is much smaller than TCP, but I should add some 
> TCP-features on top of UDP: mainly ack and retransmissions. So I can 
> argue TCP is overall better than UDP.

You certainly /can/ argue that!  TCP/IP has many advantages over UDP. 
The key ones are that it saves you worrying about reinventing the wheel 
here.  With UDP, you never know if your data got transferred - so you 
need application layers to handle that.  With TCP/IP, you know that 
either the data is transferred correctly, or you end up with a timeout 
and broken connection.  It keeps it a lot simpler.

Also, TCP/IP is /far/ easier and more reliable when you have routing, 
firewalls, VPNs, ssh tunnels, and all the other types of connections 
that make IP networking so flexible and fun.

So use UDP if you need an absolute minimal system with minimal traffic 
and latencies, but within a simple local LAN only.  Otherwise, go for 
TCP/IP.

> 
>  > What are your encryption requirements?
> Another question? ;-)
> 
> 
>  > What type of processing power do you need for this protocol to be 
> defined?
> "processing power for the protocol"? It should be very simple, maybe 
> MQTT. I would avoid HTTP.
> 
> 
>  > What ethernet speed do you need / want?
> I think this depends only to the PHY used... right?
> 

No, you need a MAC that handles the speed, as well as the PHY.  The MAC 
is usually in the microcontroller.  For most flash-based 
microcontrollers, MAC speeds will be 100 Mbit - Gbit MACs are more 
common on bigger and faster embedded processors.  If you are thinking 
bare metal or FreeRTOS, you are probably thinking 100 Mbit - if you want 
Gbit, you are probably thinking Linux.

Obviously you will also need a faster processor for Gbit to make sense. 
(There is no problem using 100 Mbit devices on an otherwise Gbit network.)

> 
>  > What is your power budget?
> No problem.
> 
> 
> I usually use Atmel/Microchip SAM Cortex-M MCUs. I saw SAM E70 and 
> similar devices. They have an internal MAC controller with RMII 
> interface for external PHY. There are some examples with lwip.
> 

That will probably be fine.  I haven't use Atmel's ARM devices, but I 
believe they are a perfectly reasonable choice.

> Is there an RJ45 connector with integrated magnetics and PHY in order to 
> reduce PCB space? I don't think there MCUs with integrated MAC+PHY.

You want the MAC inside the MCU.  But you want an external PHY unless 
you are desperate for board space.  There are a few MCU's with internal 
PHY's, but these cost more than separate chips and have poorer 
performance (power, speed, etc.).  Basically, the type of die stackup 
you want for an MCU and a MAC is geared towards fast, low-power digital 
switching.  But the PHY is quite high power and analogue, and is best 
done with a different die stackup and feature size.  Thus if you put 
both on the same die, you have serious compromises.

External PHY's can be very small, if you can handle the package types.

RJ45 with magnetics and LEDs are easily available.  They cost a little 
more than separate parts, but not much more.

Thread

Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-09-22 17:52 +0200
  Re: Embedded Ethernet mmm <m.colandrea@libero.it> - 2017-09-22 18:00 +0200
  Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-09-22 20:27 +0200
    Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-11-17 10:25 +0100
      Re: Embedded Ethernet Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-11-17 10:39 +0000
        Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-11-17 12:25 +0100
      Re: Embedded Ethernet "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2017-11-17 11:36 +0100
        Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-11-17 12:54 +0100
      Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-11-17 15:23 +0100
      Re: Embedded Ethernet Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2017-11-18 11:29 +0200
  Re: Embedded Ethernet Joe Chisolm <jchisolm6@earthlink.net> - 2017-09-22 13:31 -0500
    Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-09-23 00:01 +0200
      Re: Embedded Ethernet raimond.dragomir@gmail.com - 2017-09-22 22:38 -0700
        Re: Embedded Ethernet raimond.dragomir@gmail.com - 2017-09-22 22:41 -0700
      Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-09-23 12:02 +0200
        Re: Embedded Ethernet Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-23 06:32 -0400
          Re: Embedded Ethernet Dimiter_Popoff <dp@tgi-sci.com> - 2017-09-23 15:31 +0300
            Re: Embedded Ethernet Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-25 13:07 -0400
              Re: Embedded Ethernet Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:31 -0500
                Re: Embedded Ethernet Dimiter_Popoff <dp@tgi-sci.com> - 2017-09-27 01:50 +0300
          Re: Embedded Ethernet Les Cargill <lcargill99@comcast.com> - 2017-09-28 20:07 -0500
        Re: Embedded Ethernet upsidedown@downunder.com - 2017-09-23 14:48 +0300
        Re: Embedded Ethernet Les Cargill <lcargill99@comcast.com> - 2017-09-28 20:06 -0500
          Re: Embedded Ethernet Joe Chisolm <jchisolm6@earthlink.net> - 2017-09-29 09:41 -0500
          Re: Embedded Ethernet upsidedown@downunder.com - 2017-09-30 18:49 +0300
        Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-10-12 11:26 +0200
          Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-10-12 12:46 +0200
          Re: Embedded Ethernet Joe Chisolm <jchisolm6@earthlink.net> - 2017-10-12 10:49 -0500
      Re: Embedded Ethernet Grant Edwards <invalid@invalid.invalid> - 2017-09-23 20:40 +0000
        Re: Embedded Ethernet Joe Chisolm <jchisolm6@earthlink.net> - 2017-09-23 19:24 -0500
          Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-09-24 13:28 +0200
  Re: Embedded Ethernet Les Cargill <lcargill99@comcast.com> - 2017-09-22 21:12 -0500
  Re: Embedded Ethernet Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-09-24 11:01 +0300
  Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-10-16 14:10 +0200
    Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-10-16 15:10 +0200
      Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-10-16 17:54 +0200
        Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-10-16 23:45 +0200
          lwip/httpd: how to return dynamic data [was Re: Embedded Ethernet] pozz <pozzugno@gmail.com> - 2017-11-13 12:11 +0100
            Re: lwip/httpd: how to return dynamic data [was Re: Embedded Ethernet] David Brown <david.brown@hesbynett.no> - 2017-11-13 14:14 +0100

csiph-web