David Brown wrote:> On 14/10/15 20:58, rickman wrote: >> I haven't seem a lot of mention of the Microsemi SmartFusion2 SoC >> devices. The combine a flash based FPGA with a CM3, memory and various >> I/O including Ethernet and CAN. The earlier SoC products from Actel >> were a bit pricey, but these parts are available from $16, qty 1. >> >> I haven't tried the tools yet, but I have ordered a Kickstart kit for >> $60 and am looking forward to using it. I'm wondering what I will be >> able to do with the Ethernet port unless the SoC has external memory >> attached to be able to boot something like Linux. I suppose there are >> TCP stacks available which fit a smaller footprint. >> > > There seems to be a good deal of mixup and misunderstanding on this > thread. Let me try to make a few points. > > First, you /can/ run Linux on a Cortex M3. It is rarely a good idea, > but it can be done on parts with enough memory. It means using MMU-less > Linux (which used to be known as �c-Linux), and that puts limitations on > the system (no swap, no normal fork, and some tasks are much less > efficient). There was a time when MMU-less Linux made sense in some > systems, as it saved the significant expense and complexity of using a > larger cpu with an MMU. But these days chips like Freescale's i.mx6 > make it much easier to make a full embedded Linux. > > Secondly, there are lots of OS's for the Cortex M - mostly RTOS's. > FreeRTOS is a good example. > > Thirdly, there is no need of an OS to run a network stack over Ethernet. > Some tasks may be easier with an RTOS, but the RTOS adds complexity > over a bare-bones system. It's a tradeoff, and there are no fixed > answers - it varies by application, and by developer preference and > experience. > > Fourthly, it is perfectly possible to run good, solid, feature-rich > TCP/IP network stacks on a Cortex M3. LWIP is the most popular network > stack (being solid quality, well-tested, and fully open with a friendly > license - but beware the limited documentation). High throughput on > TCP/IP and support for multiple simultaneous connections means buffer > space (with TCP/IP, you have to be able to re-try sending the packets of > up to 1.5K - the easiest method is if the network stack keeps these > copies). You want perhaps 64K ram to make life easy for yourself - but > can certainly do it in 32K ram. > > It is even possible to run TCP/IP over Ethernet with very much smaller > systems - it can be done on an 8-bit AVR with a few K of RAM if you > want. But that is very limited. > > > As for choosing between UDP and TCP/IP for a given application, UDP has > fewer overheads and can be a little faster. However, it requires more > effort on the application level to make sure everything works correctly > - if you need to be sure a packet has reached the other side, then your > application on the other side has to explicitly send an acknowledgement > and you need to receive it and check it. With TCP/IP, that is all > handled for you - the "send" call is not complete until an > acknowledgement has been received. >And then one day it just hangs...> It is also much easier to have TCP/IP working through firewalls, VPNs, > or other complex routing. For my own use, I pick TCP/IP every time. >-- Les Cargill
SmartFusion2 SoC
Started by ●October 14, 2015
Reply by ●October 15, 20152015-10-15
Reply by ●October 15, 20152015-10-15
On 10/15/2015 9:29 PM, Les Cargill wrote:> rickman wrote: >> On 10/15/2015 1:36 AM, Paul Rubin wrote: >>> rickman <gnuarm@gmail.com> writes: >>>> What all can you do using UDP instead of TCP? Can you serve up web >>>> pages? The primary reason for using TCP is the reliability from what >>>> I understand. But if this is a local, point to point connection that >>>> should not be an issue, no? >>> >>> HTTP (used for serving web pages) is a protocol that runs over TCP, so >>> no you can't serve web pages with UDP. UDP is typically used for low >>> latency or realtime protocols (say VOIP) where you if you drop a packet >>> here or there, you want to keep going rather than try to recover it. >>> Some people decide to add a reliability layer over UDP and end up doing >>> a bad reimplementation of TCP, so if you want TCP it's better to just >>> use it. There are some very lightweight TCP stacks out there, but as >>> Dimiter says, you lose performance if you don't have enough ram to >>> buffer several large-ish packets. >>> >>> I do expect UDP to be pretty reliable within a LAN segment unless >>> there's a ton of congestion. >> >> I don't think that HTTP *requires* TCP does it? > > I expect it's a very baked-in assumption. When you read how people use > HTTP, it's almost always deeply entangled. > > Might be worth looking at QUIC, but I have no idea of you lose browser > support or what. > > You could, I suppose, always bridge UDP and TCP on localhost > in the machine the browser is running on. > >> Isn't that why the ISO >> model done in layers? > > Har! But people don't necessarily pay any attention > to that. > >> Can't HTTP be sent over other transport and >> session layers? If the link is highly reliable, such as a USB >> interface, can't UDP serve as well as TCP? Or are there other issues >> involved? >> > > Chances are good that nobody's found it interesting.I hear this > a lot - "but TCP *guarantees delivery*" and I send 'em off > to read the Two Generals Problem. > > Once, Barry Margolin sent *me* off to read the Two Generals Problem > on comp.protocols.tcp-ip :)I'm not familiar with the two generals problem, but I know that no protocol can guarantee delivery of a packet. Not if the unit is disconnected or turned off. I think they mean delivery is guaranteed *or* you are aware of the failure. -- Rick
Reply by ●October 15, 20152015-10-15
On 16.10.2015 г. 04:19, Les Cargill wrote:> Dimiter_Popoff wrote: >> On 15.10.2015 г. 07:13, Roberto Waltman wrote: >>> Dimiter_Popoff wrote: >>> >>>> generally you cannot serve webpages using udp. It gives you just a >>>> "best effort" delivery, even on a local ethernet packets do get lost. >>> >>> Rick, Dimiter, check this: >>> >>> ENet - Reliable UDP networking library >>> >>> ENet's purpose is to provide a relatively thin, simple and robust >>> network communication layer on top of UDP (User Datagram Protocol). >>> >>> The primary feature it provides is optional reliable, in-order >>> delivery of packets. >>> >>> http://enet.bespin.org/ >>> >>> R.W. >>> >> >> Hi Roberto, >> >> I gave it a brief glance, looks interesting and is probably useful for >> certain tasks but it is far from a replacement for tcp. From what I saw >> in the overview I believe they ensure in order delivery by waiting for >> the ack before sending a new packet; meaning an RTT between each two >> packets, which may mean seconds. >> TCP is very well thought through,it can hardly be simplified any further >> and stay useful. For data streaming it is just "the" choice by a great >> margin. It will take a while until all the tiny MCUs are capable >> of it but they are closing in on that. For example my tcp/ip >> implementation for DPS can easily fit in half a megabyte of code, >> that including the entire OS basics (file system, window support, all >> the system calls etc., all that uncompromised and not really planned >> as "small footprint"). >> >> Dimiter >> >> >> ------------------------------------------------------ >> Dimiter Popoff, TGI http://www.tgi-sci.com >> ------------------------------------------------------ >> http://www.flickr.com/photos/didi_tgi/ >> > > Tactically, UDP is preferable for real-time-ish things. > This is especially true if the things are local to each other - > say, no the same basically layer 2 network without much routing > in place. > > You don't improve the channel entropy by using TCP; all > you do is buy "insurance".> ... It is not just that. TCP gives you byte level streaming/sequencing out of the box, with UDP you have to reinvent that - and you will be seriously challenged to match what tcp gives you. So UDP is good only when you either do not need that or when you have some compelling reason to reinvent it. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Reply by ●October 15, 20152015-10-15
On 10/15/2015 9:43 PM, Dimiter_Popoff wrote:> On 16.10.2015 г. 04:19, Les Cargill wrote: >> Dimiter_Popoff wrote: >>> On 15.10.2015 г. 07:13, Roberto Waltman wrote: >>>> Dimiter_Popoff wrote: >>>> >>>>> generally you cannot serve webpages using udp. It gives you just a >>>>> "best effort" delivery, even on a local ethernet packets do get lost. >>>> >>>> Rick, Dimiter, check this: >>>> >>>> ENet - Reliable UDP networking library >>>> >>>> ENet's purpose is to provide a relatively thin, simple and robust >>>> network communication layer on top of UDP (User Datagram Protocol). >>>> >>>> The primary feature it provides is optional reliable, in-order >>>> delivery of packets. >>>> >>>> http://enet.bespin.org/ >>>> >>>> R.W. >>>> >>> >>> Hi Roberto, >>> >>> I gave it a brief glance, looks interesting and is probably useful for >>> certain tasks but it is far from a replacement for tcp. From what I saw >>> in the overview I believe they ensure in order delivery by waiting for >>> the ack before sending a new packet; meaning an RTT between each two >>> packets, which may mean seconds. >>> TCP is very well thought through,it can hardly be simplified any further >>> and stay useful. For data streaming it is just "the" choice by a great >>> margin. It will take a while until all the tiny MCUs are capable >>> of it but they are closing in on that. For example my tcp/ip >>> implementation for DPS can easily fit in half a megabyte of code, >>> that including the entire OS basics (file system, window support, all >>> the system calls etc., all that uncompromised and not really planned >>> as "small footprint"). >>> >>> Dimiter >>> >>> >>> ------------------------------------------------------ >>> Dimiter Popoff, TGI http://www.tgi-sci.com >>> ------------------------------------------------------ >>> http://www.flickr.com/photos/didi_tgi/ >>> >> >> Tactically, UDP is preferable for real-time-ish things. >> This is especially true if the things are local to each other - >> say, no the same basically layer 2 network without much routing >> in place. >> >> You don't improve the channel entropy by using TCP; all >> you do is buy "insurance". > > ... > > It is not just that. TCP gives you byte level streaming/sequencing out > of the box, with UDP you have to reinvent that - and you will be > seriously challenged to match what tcp gives you. > So UDP is good only when you either do not need that or when you have > some compelling reason to reinvent it.I don't know what you guys are discussing, but the OP's app (mine) would be something that was highly reliable. -- Rick
Reply by ●October 15, 20152015-10-15
rickman <gnuarm@gmail.com> writes:> I don't know what you guys are discussing, but the OP's app (mine) > would be something that was highly reliable.There's another issue which is that while in principle you can send HTTP over any reliable channel, in practice browsers are TCP clients. You could get around that with a client side proxy that speaks UDP to your embedded device and TCP to the browser, but why bother? Your CM3 should be able to run a lightweight TCP stack so that's probably the path of least resistance. If that's too heavy, you might as well ditch the IP/UDP stuff too, and just talk to the host by USB or serial port, again maybe with a client app if you want to use a browser as a GUI.
Reply by ●October 15, 20152015-10-15
On 16.10.2015 г. 04:50, rickman wrote:> On 10/15/2015 9:43 PM, Dimiter_Popoff wrote: >> On 16.10.2015 г. 04:19, Les Cargill wrote: >>> Dimiter_Popoff wrote: >>>> On 15.10.2015 г. 07:13, Roberto Waltman wrote: >>>>> Dimiter_Popoff wrote: >>>>> >>>>>> generally you cannot serve webpages using udp. It gives you just a >>>>>> "best effort" delivery, even on a local ethernet packets do get lost. >>>>> >>>>> Rick, Dimiter, check this: >>>>> >>>>> ENet - Reliable UDP networking library >>>>> >>>>> ENet's purpose is to provide a relatively thin, simple and robust >>>>> network communication layer on top of UDP (User Datagram Protocol). >>>>> >>>>> The primary feature it provides is optional reliable, in-order >>>>> delivery of packets. >>>>> >>>>> http://enet.bespin.org/ >>>>> >>>>> R.W. >>>>> >>>> >>>> Hi Roberto, >>>> >>>> I gave it a brief glance, looks interesting and is probably useful for >>>> certain tasks but it is far from a replacement for tcp. From what I saw >>>> in the overview I believe they ensure in order delivery by waiting for >>>> the ack before sending a new packet; meaning an RTT between each two >>>> packets, which may mean seconds. >>>> TCP is very well thought through,it can hardly be simplified any >>>> further >>>> and stay useful. For data streaming it is just "the" choice by a great >>>> margin. It will take a while until all the tiny MCUs are capable >>>> of it but they are closing in on that. For example my tcp/ip >>>> implementation for DPS can easily fit in half a megabyte of code, >>>> that including the entire OS basics (file system, window support, all >>>> the system calls etc., all that uncompromised and not really planned >>>> as "small footprint"). >>>> >>>> Dimiter >>>> >>>> >>>> ------------------------------------------------------ >>>> Dimiter Popoff, TGI http://www.tgi-sci.com >>>> ------------------------------------------------------ >>>> http://www.flickr.com/photos/didi_tgi/ >>>> >>> >>> Tactically, UDP is preferable for real-time-ish things. >>> This is especially true if the things are local to each other - >>> say, no the same basically layer 2 network without much routing >>> in place. >>> >>> You don't improve the channel entropy by using TCP; all >>> you do is buy "insurance". >> > ... >> >> It is not just that. TCP gives you byte level streaming/sequencing out >> of the box, with UDP you have to reinvent that - and you will be >> seriously challenged to match what tcp gives you. >> So UDP is good only when you either do not need that or when you have >> some compelling reason to reinvent it. > > I don't know what you guys are discussing, but the OP's app (mine) would > be something that was highly reliable. >I am speaking not about reliability here, just about what is practical. Considering udp as a transport for http or ftp is just impractical, no sane reason why you would go this way. Obviously if you are chasing reliability you will have to go into all the details yourself and make your pick, the reliability of tcp depends on error detection/correction underneath it (tcp itself only has a checksum per segment, it is up to ip and below (mostly the ethernet CRC or the PPP CRC) to deliver the packets error free - losing some is OK, delivering a damaged one much less so). Dimiter
Reply by ●October 16, 20152015-10-16
Dimiter_Popoff wrote:> On 16.10.2015 г. 04:19, Les Cargill wrote: >> Dimiter_Popoff wrote: >>> On 15.10.2015 г. 07:13, Roberto Waltman wrote: >>>> Dimiter_Popoff wrote: >>>> >>>>> generally you cannot serve webpages using udp. It gives you just a >>>>> "best effort" delivery, even on a local ethernet packets do get lost. >>>> >>>> Rick, Dimiter, check this: >>>> >>>> ENet - Reliable UDP networking library >>>> >>>> ENet's purpose is to provide a relatively thin, simple and robust >>>> network communication layer on top of UDP (User Datagram Protocol). >>>> >>>> The primary feature it provides is optional reliable, in-order >>>> delivery of packets. >>>> >>>> http://enet.bespin.org/ >>>> >>>> R.W. >>>> >>> >>> Hi Roberto, >>> >>> I gave it a brief glance, looks interesting and is probably useful for >>> certain tasks but it is far from a replacement for tcp. From what I saw >>> in the overview I believe they ensure in order delivery by waiting for >>> the ack before sending a new packet; meaning an RTT between each two >>> packets, which may mean seconds. >>> TCP is very well thought through,it can hardly be simplified any further >>> and stay useful. For data streaming it is just "the" choice by a great >>> margin. It will take a while until all the tiny MCUs are capable >>> of it but they are closing in on that. For example my tcp/ip >>> implementation for DPS can easily fit in half a megabyte of code, >>> that including the entire OS basics (file system, window support, all >>> the system calls etc., all that uncompromised and not really planned >>> as "small footprint"). >>> >>> Dimiter >>> >>> >>> ------------------------------------------------------ >>> Dimiter Popoff, TGI http://www.tgi-sci.com >>> ------------------------------------------------------ >>> http://www.flickr.com/photos/didi_tgi/ >>> >> >> Tactically, UDP is preferable for real-time-ish things. >> This is especially true if the things are local to each other - >> say, no the same basically layer 2 network without much routing >> in place. >> >> You don't improve the channel entropy by using TCP; all >> you do is buy "insurance". > > ... > > It is not just that. TCP gives you byte level streaming/sequencing out > of the box, with UDP you have to reinvent that - and you will be > seriously challenged to match what tcp gives you.It's interesting because a lot of things we think of as inherently streaming - like VoIP, or internet radio - are very very much UDP. You also get multicast, which can be a big deal. TCP is fine for what it is. But you still have to have a "dead man" timeout because you won't get a socket closed error reliably when you want it.> So UDP is good only when you either do not need that or when you have > some compelling reason to reinvent it. >99.99% of what I have ever done involved essentially packetized data anyway. So that accounts for some of my bias. I don't always. but they could all run over UDP, TCP or a serial port. It'd just be changing some options and probably adjusting a few things in test. I'd only used UDP in production starting about 2012 or so.> Dimiter > > ------------------------------------------------------ > Dimiter Popoff, TGI http://www.tgi-sci.com > ------------------------------------------------------ > http://www.flickr.com/photos/didi_tgi/ > > > >-- Les Cargill
Reply by ●October 16, 20152015-10-16
rickman wrote:> On 10/15/2015 9:29 PM, Les Cargill wrote: >> rickman wrote: >>> On 10/15/2015 1:36 AM, Paul Rubin wrote: >>>> rickman <gnuarm@gmail.com> writes: >>>>> What all can you do using UDP instead of TCP? Can you serve up web >>>>> pages? The primary reason for using TCP is the reliability from what >>>>> I understand. But if this is a local, point to point connection that >>>>> should not be an issue, no? >>>> >>>> HTTP (used for serving web pages) is a protocol that runs over TCP, so >>>> no you can't serve web pages with UDP. UDP is typically used for low >>>> latency or realtime protocols (say VOIP) where you if you drop a packet >>>> here or there, you want to keep going rather than try to recover it. >>>> Some people decide to add a reliability layer over UDP and end up doing >>>> a bad reimplementation of TCP, so if you want TCP it's better to just >>>> use it. There are some very lightweight TCP stacks out there, but as >>>> Dimiter says, you lose performance if you don't have enough ram to >>>> buffer several large-ish packets. >>>> >>>> I do expect UDP to be pretty reliable within a LAN segment unless >>>> there's a ton of congestion. >>> >>> I don't think that HTTP *requires* TCP does it? >> >> I expect it's a very baked-in assumption. When you read how people use >> HTTP, it's almost always deeply entangled. >> >> Might be worth looking at QUIC, but I have no idea of you lose browser >> support or what. >> >> You could, I suppose, always bridge UDP and TCP on localhost >> in the machine the browser is running on. >> >>> Isn't that why the ISO >>> model done in layers? >> >> Har! But people don't necessarily pay any attention >> to that. >> >>> Can't HTTP be sent over other transport and >>> session layers? If the link is highly reliable, such as a USB >>> interface, can't UDP serve as well as TCP? Or are there other issues >>> involved? >>> >> >> Chances are good that nobody's found it interesting.I hear this >> a lot - "but TCP *guarantees delivery*" and I send 'em off >> to read the Two Generals Problem. >> >> Once, Barry Margolin sent *me* off to read the Two Generals Problem >> on comp.protocols.tcp-ip :) > > I'm not familiar with the two generals problem, but I know that no > protocol can guarantee delivery of a packet. Not if the unit is > disconnected or turned off. I think they mean delivery is guaranteed > *or* you are aware of the failure. >In one case, I measured five minutes before the failure was signaled by the stack. -- Les Cargill
Reply by ●October 16, 20152015-10-16
Les Cargill <lcargill99@comcast.com> writes:> In one case, I measured five minutes before the failure > was signaled by the stack.It can be longer than that. If you need to detect disconnections quicker than that, simplest is build a heartbeat into your protocol. Each end is required to send a message every few seconds and the other end times out if the message doesn't arrive within a slight delay of when it's expected.
Reply by ●October 16, 20152015-10-16
On 10/15/2015 10:30 PM, Dimiter_Popoff wrote:> On 16.10.2015 г. 04:50, rickman wrote: >> On 10/15/2015 9:43 PM, Dimiter_Popoff wrote: >>> On 16.10.2015 г. 04:19, Les Cargill wrote: >>>> Dimiter_Popoff wrote: >>>>> On 15.10.2015 г. 07:13, Roberto Waltman wrote: >>>>>> Dimiter_Popoff wrote: >>>>>> >>>>>>> generally you cannot serve webpages using udp. It gives you just a >>>>>>> "best effort" delivery, even on a local ethernet packets do get >>>>>>> lost. >>>>>> >>>>>> Rick, Dimiter, check this: >>>>>> >>>>>> ENet - Reliable UDP networking library >>>>>> >>>>>> ENet's purpose is to provide a relatively thin, simple and robust >>>>>> network communication layer on top of UDP (User Datagram Protocol). >>>>>> >>>>>> The primary feature it provides is optional reliable, in-order >>>>>> delivery of packets. >>>>>> >>>>>> http://enet.bespin.org/ >>>>>> >>>>>> R.W. >>>>>> >>>>> >>>>> Hi Roberto, >>>>> >>>>> I gave it a brief glance, looks interesting and is probably useful for >>>>> certain tasks but it is far from a replacement for tcp. From what I >>>>> saw >>>>> in the overview I believe they ensure in order delivery by waiting for >>>>> the ack before sending a new packet; meaning an RTT between each two >>>>> packets, which may mean seconds. >>>>> TCP is very well thought through,it can hardly be simplified any >>>>> further >>>>> and stay useful. For data streaming it is just "the" choice by a great >>>>> margin. It will take a while until all the tiny MCUs are capable >>>>> of it but they are closing in on that. For example my tcp/ip >>>>> implementation for DPS can easily fit in half a megabyte of code, >>>>> that including the entire OS basics (file system, window support, all >>>>> the system calls etc., all that uncompromised and not really planned >>>>> as "small footprint"). >>>>> >>>>> Dimiter >>>>> >>>>> >>>>> ------------------------------------------------------ >>>>> Dimiter Popoff, TGI http://www.tgi-sci.com >>>>> ------------------------------------------------------ >>>>> http://www.flickr.com/photos/didi_tgi/ >>>>> >>>> >>>> Tactically, UDP is preferable for real-time-ish things. >>>> This is especially true if the things are local to each other - >>>> say, no the same basically layer 2 network without much routing >>>> in place. >>>> >>>> You don't improve the channel entropy by using TCP; all >>>> you do is buy "insurance". >>> > ... >>> >>> It is not just that. TCP gives you byte level streaming/sequencing out >>> of the box, with UDP you have to reinvent that - and you will be >>> seriously challenged to match what tcp gives you. >>> So UDP is good only when you either do not need that or when you have >>> some compelling reason to reinvent it. >> >> I don't know what you guys are discussing, but the OP's app (mine) would >> be something that was highly reliable. >> > > I am speaking not about reliability here, just about what is practical. > Considering udp as a transport for http or ftp is just impractical, no > sane reason why you would go this way. > Obviously if you are chasing reliability you will have to go into all > the details yourself and make your pick, the reliability of tcp depends > on error detection/correction underneath it (tcp itself only has > a checksum per segment, it is up to ip and below (mostly the ethernet > CRC or the PPP CRC) to deliver the packets error free - losing some is > OK, delivering a damaged one much less so).Why are you so worried about "reliability" in this one instance while nothing else in your computer gives any consideration to errors other than possibly the data internal to a hard or flash drive which uses somewhat unreliable media. Other than possibly servers, even RAM no longer uses parity which only flags that there was an error, without fixing it. Why do I need anything special to look for errors from a USB device? -- Rick
