Embedded Ethernet

Il 22/09/2017 17:52, pozz ha scritto:

something based on wiznet chips ?

I think there is some ready solution from them

Yes - LWIP is very popular, and works well.

We have used Kinetis K64F, with LWIP. But a lot will depend on the other features you need, speed, development resources, etc. Don't skimp on the ram size for the microcontroller you get - it's a lot easier to use big buffers than to try to fine-tune them to exactly what you think you need.

How are you connecting to this "cloud" server? Simple TCP or UDP or is it some type of web services? What are your encryption requirements? What type of processing power do you need for this protocol to be defined? What ethernet speed do you need / want? What is your power budget?

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.

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.

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 mean the bits on the wire? RS485 is RS485 because it's an actual standard.

Can you use a USB to Ethernet converter? It won't be very fast but it'll be Ethernet.

Plenty.

MC001515 MC001514 JXD2-0010NL LMJ2138814S0L1T1C and many more...

TM4C129X family from TI Wiznet W7500

il.com a scris:

I mean W7500P whith the "P" standing for "PHY".

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.

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

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

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.

One issue is that (iirc) TCP's 'guarantee' uses only a 16-bit checksum, which might not be long enough for high speed data on less than stellar connections.

Cheers

Phil Hobbs

The justification for two separate protocols depends on the usage.

For UDP (or raw Ethernet framing):

• Need hard real time performance: if a frame is lost or arrives too late, just ignore it (e.g. audio/video samples). Retransmissions not wanted. A frame sequence number should be enough.

• A local LAN segment is enough.

For TCP/IP:

• Reliable data transfer is required,

• Unpredictable delays allowed (retransmissions).

Only if every message needs to be reliably transferred.

Depends if you need reliable transfer or not.

Fully agree on that.

If you use really small devices ("IoT"), you might use UDP on the LAN and if there is a bigger machine, such as a PC, you could use it as a gateway to proper TCP/IP network. With IoT, you really need to think, how and where to implement the data security issues

If you haven't thought about data security, you should really do it now.

Then there should not be a problem using 10 Mbit devices.

So 10 or 10/100 PHY should be OK.

It is a non-issue really. The 16 bit checksum is just within tcp, but the IP layer is either embedded within Ethernet frames which have a robust enough CRC or within a PPP frame which typically has 32 bit CRC. Not sure one can encounter a situation where this would be an issue - but then it is a wide world, who knows. Certainly no issue over Ethernet though.

Dimiter

====================================================== Dimiter Popoff, TGI

UDP is also far less likey that TCP to make it safely through firewalls and routers.

If you're going to have to re-invent TCP, then just use TCP and avoid all of the headaches you'll have with UDP and firewalls/routers.

TCP wont necessarly fix a firewall issue. All depends on the firewall configuration for inbound traffic. The firewall could be configured to allow UDP traffic to a specific dest addr/dest port For outbound many firewalls will allow a inbould UDP packet directed to the same src addr/src port that generated the outgoing packet.

But I agree if you need close to guaranteeded data delivery a TCP app is easier to build. FreeRTOS/lwip is a reasonable choice.

I have built such things with the TI/Stellaris LM3S6965 with both Ethernet MAC and PHY (10/100 Mbit/s) built-in. The chip is a Cortex-M3, but according to TI, it is obsolete now, and they offer the TMC4C129 instead. It has a development kit at about 25 USD, the EK-TM4C129EXL.

Of course it all depends on the firewall setup. And yes, you can get UDP to work through firewalls. But it is very difficult to get a firewall setup that is secure and reliable, and safely lets through the traffic you want and blocks traffic you don't want. And it is even more difficult when you have VPNs, tunnels, or other routes involved. Such routing is /really/ useful when you are testing and debugging network systems - when you are sitting back in your office, connecting securely to the customer network on the other side of the world, you will be glad everything is running over TCP/IP.

Good to know, thanks.

Cheers

Phil Hobbs

At least in the past, there have been cases where frames/packets have been damaged *inside* routers or switches. There's a lot to be said for an end-to-end checksum, even if it isn't super strong.

In any event, if you want a much stronger check (although not one providing recoverability), you can just insist on an SSL/TLS connection.

An area where the 16-bit TCP/IP checksum clearly show itself to be inadequate was with some high-error-rate links without their own protection. Dial-up SLIP was a good example. PPP's checksum (when used on dial-up) was also too weak (but far better than the non-existent one on SLIP), but most of the time it got combined with error correcting modems underneath, and since it was a different checksum than TCP/IP used, the net result was better than either alone.

It has been about 15 years since I last implemented tcp/ip and ppp but I think ppp - with 32 bit CRC as I used to have it most of the time IIRC - was fairly robust. The phone line I had back then was pathetic, 4 phones switched into a twisted pair by a box out in the rain, whatever the modem I got 14400 bps max. Then again I can't swear I never had a damaged packet but having one at 32 bit CRC which then makes it through the tcp segment checksum seems really unlikely. I do find the tcp checksum as it is quite adequate. I have never done SLIP so I can't comment on that, but if it relied solely on the modem error correction well, this may have been insufficient.

Dimiter

====================================================== Dimiter Popoff, TGI

I just last week had to put a dead man timer in a client to detect whether the server had gone offline using TCP.

You'll end up rippling the protocol up to the app layer no matter what :) You'll get a more performant system with UDP.