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. -- Rick
SmartFusion2 SoC
Started by ●October 14, 2015
Reply by ●October 14, 20152015-10-14
rickman <gnuarm@gmail.com> writes:> combine a flash based FPGA with a CM3... 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.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: http://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/index.html http://www.chibios.org/dokuwiki/doku.php http://savannah.nongnu.org/projects/lwip 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: http://excamera.com/sphinx/fpga-j1.html
Reply by ●October 14, 20152015-10-14
On 10/14/2015 7:52 PM, Paul Rubin wrote:> rickman <gnuarm@gmail.com> writes: >> combine a flash based FPGA with a CM3... 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. > > 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: > > http://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/index.html > http://www.chibios.org/dokuwiki/doku.php > http://savannah.nongnu.org/projects/lwip > > 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: > > http://excamera.com/sphinx/fpga-j1.htmlWhat 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? -- Rick
Reply by ●October 14, 20152015-10-14
On 15.10.2015 г. 03:56, rickman wrote:> .... >> >> There is even some J1 Forth code here that does IP and UDP, though I >> don't see the code for TCP: >> >> http://excamera.com/sphinx/fpga-j1.html > > 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
Reply by ●October 15, 20152015-10-15
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.
Reply by ●October 15, 20152015-10-15
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/
Reply by ●October 15, 20152015-10-15
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.
Reply by ●October 15, 20152015-10-15
On 10/15/2015 12:42 AM, 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").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. -- Rick
Reply by ●October 15, 20152015-10-15
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? 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? -- Rick
Reply by ●October 15, 20152015-10-15
On 15.10.2015 г. 08:54, rickman wrote:> On 10/15/2015 12:42 AM, 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"). > > 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. >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
