On Sat, 23 Sep 2017 12:02:17 +0200, David Brown <david.brown@hesbynett.no> wrote:>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 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).>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.Only if every message needs to be reliably transferred.>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.Depends if you need reliable transfer or not.>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.Fully agree on that.>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.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>> > What are your encryption requirements? >> Another question? ;-)If you haven't thought about data security, you should really do it now.>> >> >> > 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.)Then there should not be a problem using 10 Mbit devices.>> > What is your power budget? >> No problem.So 10 or 10/100 PHY should be OK.
Embedded Ethernet
Started by ●September 22, 2017
Reply by ●September 23, 20172017-09-23
Reply by ●September 23, 20172017-09-23
On 23.9.2017 г. 13:32, Phil Hobbs wrote:> On 09/23/2017 06:02 AM, David Brown wrote: > ...... >> >> 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. > > 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.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 http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Reply by ●September 23, 20172017-09-23
On 2017-09-22, pozz <pozzugno@gmail.com> wrote:> I can choose. I know UDP is much smaller than TCP,UDP is also far less likey that TCP to make it safely through firewalls and routers.> but I should add some TCP-features on top of UDP: mainly ack and > retransmissions.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. -- Grant Edwards grant.b.edwards Yow! Am I having fun yet? at gmail.com
Reply by ●September 23, 20172017-09-23
On Sat, 23 Sep 2017 20:40:04 +0000, Grant Edwards wrote:> On 2017-09-22, pozz <pozzugno@gmail.com> wrote: > >> I can choose. I know UDP is much smaller than TCP, > > UDP is also far less likey that TCP to make it safely through > firewalls and routers. > >> but I should add some TCP-features on top of UDP: mainly ack and >> retransmissions. > > 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. -- Chisolm Republic of Texas
Reply by ●September 24, 20172017-09-24
On 22.9.17 18:52, 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?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. -- -TV
Reply by ●September 24, 20172017-09-24
On 24/09/17 02:24, Joe Chisolm wrote:> On Sat, 23 Sep 2017 20:40:04 +0000, Grant Edwards wrote: > >> On 2017-09-22, pozz <pozzugno@gmail.com> wrote: >> >>> I can choose. I know UDP is much smaller than TCP, >> >> UDP is also far less likey that TCP to make it safely through >> firewalls and routers. >> >>> but I should add some TCP-features on top of UDP: mainly ack and >>> retransmissions. >> >> 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.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.> > But I agree if you need close to guaranteeded data delivery a TCP > app is easier to build. FreeRTOS/lwip is a reasonable choice. > >
Reply by ●September 25, 20172017-09-25
On 09/23/2017 08:31 AM, Dimiter_Popoff wrote:> On 23.9.2017 г. 13:32, Phil Hobbs wrote: >> On 09/23/2017 06:02 AM, David Brown wrote: >> ...... >>> >>> 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. >> >> 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. > > 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.Good to know, thanks. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
Reply by ●September 25, 20172017-09-25
On Mon, 25 Sep 2017 13:07:43 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>On 09/23/2017 08:31 AM, Dimiter_Popoff wrote: >> On 23.9.2017 ?. 13:32, Phil Hobbs wrote: >>> On 09/23/2017 06:02 AM, David Brown wrote: >>> ...... >>>> >>>> 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. >>> >>> 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. >> >> 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. > >Good to know, thanks.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.
Reply by ●September 26, 20172017-09-26
On 25.9.2017 г. 23:31, Robert Wessel wrote:> On Mon, 25 Sep 2017 13:07:43 -0400, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote: > >> On 09/23/2017 08:31 AM, Dimiter_Popoff wrote: >>> On 23.9.2017 ?. 13:32, Phil Hobbs wrote: >>>> On 09/23/2017 06:02 AM, David Brown wrote: >>>> ...... >>>>> >>>>> 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. >>>> >>>> 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. >>> >>> 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. >> >> Good to know, thanks. > > > 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 http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Reply by ●September 28, 20172017-09-28
David Brown wrote:> 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.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. <snip> -- Les Cargill
