SmartFusion2 SoC

I don't think you can run Linux on a CM since it needs an MMU like on the Cortex-A's. There have been some stripped down versions but that's different. However there are various TCP stacks and RTOS's that should work on the CM3 just fine. You might look at:

And there are others. I've never used any of them though.

There is even some J1 Forth code here that does IP and UDP, though I don't see the code for TCP:

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?

Hi Rick, generally you cannot serve webpages using udp. It gives you just a "best effort" delivery, even on a local ethernet packets do get lost. TCP OTOH is pretty much like a wire between say two uarts in good proximity, you just know (well, assume) there is no lost communication. Then tcp also gives you the byte sequencing, you just "read" bytes from a tcp connection just like you would read them from an uart. In udp, you get a packet and have to deal with its header and payload yourself. Basically to have "normal" network functionality you need tcp, all the http, ftp etc. rely on it (one can replace it with some alternative but this is more theoretical than practical).

Small machines generally must be implementing some very limited tcp/ip versions (just my assumption), it takes large buffers to achieve speed to begin with.

Dimiter

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.

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 (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 think you are working from the large end downward, trying to reduce large systems to fit smaller footprints. An embedded target won't have windows and likely not really a file system.

I don't think that HTTP *requires* TCP does it? Isn't that why the ISO model done in layers? 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?

At the moment the smaller ones yes, but how far are we from treating all this like "small stuff"? Not very far I suppose. Then if you remove the window support and the filesystem support and just leave tcp/ip (which will take some work, it does use the filesystem but not a lot) things can easily fit into 200k, with some sweat may be even in 100k. One will still need a lot of RAM to run at decent speed of course.

Dimiter

I've done FreeRTOS and the older uip stack on a CM3. I had to do a few uip hacks to get it all working. I would like to port to the LWIP stack but have not had the time. I need to look at this SOC if we do a board update. The FPGA would probably let me get rid of some of the glue logic hanging around the uC.

It does not require it, of course http can run over some other link. Although it has primitives which are tcp oriented, like the connection related lines (suggesting the connection to be closed or to stay open) and perhaps more. But it cannot run over udp over a serial link, it can run over such a link directly, no udp between. HTTP has byte granularity, UDP does not have it - and there are more reasons why you just don't need it in the whole picture. Then you do not need http to view web content, it can be just on a local disk (or on an emulation of one which may not even be local...).

Dimiter

Some protocols have both UDP and TCP forms defined, though the ones that I know of were defined as UDP first, and TCP later.

NFS, for example, was for years UDP only, with clients doing their own time-out and retransmit request. NFS requests and replies tend to be smaller than 64K, with 4K and 8K (plus headers) popular RSIZE and WSIZE.

If the http replies were known to be smaller than 64K, I suppose one could define a UDP based http.

But if you are just transfering data, there is TFTP and also NFS which could be used. You would know that it was http data, but the protocol doesn't need to know.

-- glen

HTTP requires a /reliable/ transport layer - and that basically means TCP/IP. UDP is not reliable - there is no method of identifying lost, out-of-order or damaged packets at the transport layer. With TCP/IP, you are sure that you either get /exactly/ (with very high levels of CRC checking) the correct stream of data in the correct order - or the connection dies completely. So while you can use HTTP protocol format over UDP, you would have to either be sure that the link is completely reliable, or you would have to assume that your HTTP communication would sometimes fail.

And of course, there is little point in the exercise - if you are making just one side (client or server) of HTTP over UDP, you would have no one to talk to. And if you are making both sides and want to communicate over UDP, there is no point in using HTTP.

Note that you can use more than one layer of encapsulation. You can make the HTTP layer run over TCP/IP, but put the TCP/IP packets into UDP datagrams (along with your own error checking and connection tracking data), and then these UDP telegrams can go over a serial link. You might do that for tunneling, or for a VPN, or a transparent line compression, etc.

True. But it is often very handy to use standard HTTP for small JSON packets to handle dynamic data, even if the larger lumps of HTML, pictures, JavaScript, etc., are held locally to save bandwidth.

Yes, HTTP's requirement is a reliable transport layer, which is normally TCP but doesn't have to be; e.g. you could do it over a serial port or something like that. About UDP: hmm, UDP is a datagram protocol and doesn't have connections, so you'd have to add a connection layer over it, and again you're gradually reinventing TCP. You need connections to serve web pages because browsers will typically try to retrieve multiple resources at the same time.

TCP works by sending IP packet and resending if acknowledgements don't arrive in a reasonable time. So the simplest implementation sends one packet, waits for an ack, sends next packet, etc. This can be done with a few K of code and a few hundred bytes of ram, so I don't think you should worry about it being too big for your CM3. This is probably reasonable for a LAN or USB connection. It's painful over the internet because of the network delays waiting for the turnaround and ACK, so serious implementations have multiple packets in flight simultaneously, fragmented and OOO packet reassembly, etc. But those are optimizations and a minimal implementation doesn't need them.

This looks interesting:

It apparently includes a very small tcp/ip stack:

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

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.

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.

I have an old book "TCP/IP Lean" by Jeremy Bentham. It presents various cut-down implementations, some only a couple of KB IIRC. Not full-featured general-purpose stacks, but suitable for serving up a web page for example.

Yeah, I guess you aren't far off. I remember a decade or so ago some of the electronics magazines would talk about the not too distant future when embedded micros would all be running Linux. I guess we aren't too far off from that. The rPi is just a small handful of chips with the memory soldered on top of the CPU and a couple of chips for USB and Ethernet. But for the Microsemi SoC the limitation is memory unless it is added externally. It has 144 kB RAM and up to 512 kB Flash (256 kB on the Kickstart kit) so it's no slouch, but not enough for Linux.

They do have a cut down version available, uClinux kernel v2.6.33. "Ethernet device driver and networking (ping, NFS, Telnet, FTP, ntpd, etc.)" But this is in the manual for the Starter Kit which has 64 MB DDR.

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". When things go splat, they really go splat. You still end up needing timers and making guesses about state.

TCP is quite efficient; there just can be long timeouts when some things happen and there's not much configuration wise you can do about it. It may be as long a five minutes before you are notified that a channel has actually gone dark in certain cases.

SNMP was implemented on top of UDP because it was judged that SNMP would be most important when things were going splat. Those guys knew what they were doing.

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.

Har! But people don't necessarily pay any attention to that.

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