Phil Hobbs wrote:> On 09/23/2017 06:02 AM, 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. 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. >If it's Ethernet, the MAC CRC is 32 bits and quite respectable. -- Les Cargill> Cheers > > Phil Hobbs > >
Embedded Ethernet
Started by ●September 22, 2017
Reply by ●September 28, 20172017-09-28
Reply by ●September 29, 20172017-09-29
On Thu, 28 Sep 2017 20:06:15 -0500, Les Cargill wrote:> 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>+1 UDP is very applicable in many situations and many times much better than TCP. Unless you understand the pitfalls of TCP, it can bite you in the ass. You have to understand when you need blocking vs non-blocking. Delay tolerance and the list goes on. With UDP you have to understand, and plan for, the lost packet. Though this is not as prevelant as it was many years ago. Understand your network environment, LAN only vs satellite WAN. Consider the case where the TCP implementation has minimal buffering or the app is pushing. The app writes 3 buffers to the TCP socket. The receive window is large enough for all 3 writes so you have 3 segments in flight. Segment 1 gets the ACK and then the remote system catches fire and dies a horiable death. The client has to wait some long time for a normal TCP timeout and then the question is "what of the 3 buffers did the remote get" If a simple UDP send/ack the client knows. As previously mentioned you also have the case of the client does not care if a packet is lost. No one size fits all apps. TCP has it's place and so does UDP. -- Chisolm Republic of Texas
Reply by ●September 30, 20172017-09-30
On Thu, 28 Sep 2017 20:06:15 -0500, Les Cargill <lcargill99@comcast.com> wrote:>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>I thought it was a standard practice to loop a test message from the client application layer to the server application layer and back to client application. Of course, the server needs to modify the message in a predictable way, such as adding a constant (typically 1) or negating the value (2's complement) before sending it back to the client. Assuming the client increments the loopback value between transmission, lost messages are easily detected as well as the two-way propagation delay. This also makes it possible to generate alarms on both client as well as server end for lost messages and typically switch to a redundant channel etc. It is important that the server/slave changes the loopback value. I once had a serial line system, in which the message was sent back as such. The loopback messages indicated that the connection was OK, but no application data did not get through. The problem was that the request and reply loopback had the same format and a short between Tx and Rx wires physically echoed the message, instead of going through the server application level.
Reply by ●October 12, 20172017-10-12
Il 23/09/2017 12:02, David Brown ha scritto: >> [...]>> 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 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.What about the PCB requirements with MAC and PHY separated? I understood there are two standards: MII and RMII. RMII requires fewer lines. Is it possible to design a simple two-layers PCB with MAC embedded in the MCU and an external PHY? Do you know of examples of gerber/layout?
Reply by ●October 12, 20172017-10-12
On 12/10/17 11:26, pozz wrote:> Il 23/09/2017 12:02, David Brown ha scritto: > >> [...] >>> 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 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. > > What about the PCB requirements with MAC and PHY separated? I understood > there are two standards: MII and RMII. RMII requires fewer lines.Yes. For 100 Mb Ethernet, MII has 4 Rx and 4 Tx lines running at 25 MHz. RMII has 2 Rx and 2 Tx lines at 50 MHz. RMII also reduces the number of extra lines (collision detect, data valid, etc.).> > Is it possible to design a simple two-layers PCB with MAC embedded in > the MCU and an external PHY? Do you know of examples of gerber/layout?I don't do much pcb design myself these days. But it is rare that we do two layer pcbs. Four layers (with one ground plane and 3 routing) makes it /far/ easier to meet EMC requirements with fewer filter components, as well as getting good quality on the analogue parts. You can use smaller components, a denser layout, and a smaller board overall. Considering both design and production, and the cost of EMC testing and certification, we find four layer boards are usually cheaper than two layer ones, and faster and easier to design, as well as being a better product in the end. We typically only use two layer boards for the very highest volume boards, or the very simplest boards. I would not expect an MCU with built-in MAC on a two layer board to be significantly cheaper or easier than an external MAC and a four layer board, and you will be much more restricted on your choice of MCU. It is up to you to figure out the economics here, of course - it depends on quantities, costs, production facilities, development times and costs (don't forget to consider differences in software development times when using the hardware designer's choice of MCU rather than the software designer's choice!).
Reply by ●October 12, 20172017-10-12
On Thu, 12 Oct 2017 11:26:11 +0200, pozz wrote:> Il 23/09/2017 12:02, David Brown ha scritto: > >> [...] >>> 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 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. > > What about the PCB requirements with MAC and PHY separated? I understood > there are two standards: MII and RMII. RMII requires fewer lines. >The SMSC (now Microchip) LAN8720 and LAN8740 PHYs are simple to use. The 8720 talks RMII only. An external PHY will not add significally to your board cost. The issue is do you have the space given your board size constraints. The 8720/8740 have built in LDOs so you only have to feed them 3.3V. You need to check the PHY power requirements. You are gonna need a 25Mhz or 50Mhz clock to feed the PHY or possibly a XTAL depending on the PHY.> Is it possible to design a simple two-layers PCB with MAC embedded in > the MCU and an external PHY? Do you know of examples of gerber/layout?You might be able to get by with a 2 layer but you will probably run out of routing space. You can be a little sloppy with the MII lines. With these newer PHYS you can route the cable side RX/TX pairs around a board and still get error free results. I have a board that brings the RX/TX pairs from a back plane connector, to a front side MUX. There is also a front side RJ45. Depending on the config the uC flips the mux to either the backplane port or front RJ45. Look at the data sheets and design refs for the various PHYs. There is a lot of information out there. Also software support for your uC. Picking a PHY that has a code base for your given uC and OS will save you a lot of time. -- Chisolm Republic of Texas
Reply by ●October 16, 20172017-10-16
Il 22/09/2017 17:52, pozz ha scritto:> 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?Another question related to embedded Ethernet. If I implement a simple Web Server to remotely control the device from a standard Web Browser, I need some non volatile memory space to store web pages (html, css, images...). It's difficult to estimate the amount of data I will need for "web server filesystem", however I think it's highly probable the internal Flash memory of MCU will not be sufficient. So I need an external Flash memory. Of course I can use a parallel or serial Flash memory: parallel is faster, but it needs more space on PCB and more signals to route. Serial Flash are cheaper and simpler to integrate in the board, however they are slower... will it be sufficient? I saw some LPC MCUs have a SPIFI peripheral that lets you use a serial SPI Flash and see it in the normal address space. I think it is a nice feature. Do you have other suggestions how to increase storage size for web pages?
Reply by ●October 16, 20172017-10-16
On 16/10/17 14:10, pozz wrote:> Il 22/09/2017 17:52, pozz ha scritto: >> 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? > > Another question related to embedded Ethernet. > > If I implement a simple Web Server to remotely control the device from a > standard Web Browser, I need some non volatile memory space to store web > pages (html, css, images...). > > It's difficult to estimate the amount of data I will need for "web > server filesystem", however I think it's highly probable the internal > Flash memory of MCU will not be sufficient. >That depends entirely on the MCU in question, and the complexity of the web page. I have no problem with webpages in the MCU I am using (512 KB flash). Note also that static data, such as images, javascript libraries, html files, can easily be taken from an independent webserver as long as the client has internet access - maybe you need nothing more than a "loader" index.html and dynamic json "files" on your internal webserver.> So I need an external Flash memory. Of course I can use a parallel or > serial Flash memory: parallel is faster, but it needs more space on PCB > and more signals to route. Serial Flash are cheaper and simpler to > integrate in the board, however they are slower... will it be sufficient?Parallel flash is not necessarily faster - serial flash can run quickly if you have a fast SPI. If your MCU supports quad SPI, it is probably faster than you can get with an external parallel flash. Plus, the serial types are smaller, cheaper, and more flexible (it's easier to add more storage without changing the board design). Note also that even if your static data is sent slowly, it only needs to be sent once - the client will cache it. Keep your dynamic data nicely separated, and you'll be fine.> > I saw some LPC MCUs have a SPIFI peripheral that lets you use a serial > SPI Flash and see it in the normal address space. I think it is a nice > feature. > > Do you have other suggestions how to increase storage size for web pages?
Reply by ●October 16, 20172017-10-16
Il 16/10/2017 15:10, David Brown ha scritto:> On 16/10/17 14:10, pozz wrote: >> Il 22/09/2017 17:52, pozz ha scritto: >>> 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? >> >> Another question related to embedded Ethernet. >> >> If I implement a simple Web Server to remotely control the device from a >> standard Web Browser, I need some non volatile memory space to store web >> pages (html, css, images...). >> >> It's difficult to estimate the amount of data I will need for "web >> server filesystem", however I think it's highly probable the internal >> Flash memory of MCU will not be sufficient. >> > > That depends entirely on the MCU in question, and the complexity of the > web page. I have no problem with webpages in the MCU I am using (512 KB > flash).Thanks for sharing your experience.> Note also that static data, such as images, javascript libraries, html > files, can easily be taken from an independent webserver as long as the > client has internet access - maybe you need nothing more than a "loader" > index.html and dynamic json "files" on your internal webserver.Good suggestion. I have other two doubts. RTOS (Free-RTOS) or not? I usually don't use RTOS and I never found it is necessary in my applications. However TCP/IP, HTTP server and a filesystem management could be tricky without an OS. I studied the contrib example httpserver_raw in lwip project (an HTTP server without an OS). It uses a script (makefsdata) to create a virtual filesystem as a C source code. Is it ok for simple web pages? The other question. What about dynamic content? The example seems show only static content.
Reply by ●October 16, 20172017-10-16
On 16/10/17 17:54, pozz wrote:> Il 16/10/2017 15:10, David Brown ha scritto: >> On 16/10/17 14:10, pozz wrote: >>> Il 22/09/2017 17:52, pozz ha scritto: >>>> 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? >>> >>> Another question related to embedded Ethernet. >>> >>> If I implement a simple Web Server to remotely control the device from a >>> standard Web Browser, I need some non volatile memory space to store web >>> pages (html, css, images...). >>> >>> It's difficult to estimate the amount of data I will need for "web >>> server filesystem", however I think it's highly probable the internal >>> Flash memory of MCU will not be sufficient. >>> >> >> That depends entirely on the MCU in question, and the complexity of the >> web page.� I have no problem with webpages in the MCU I am using (512 KB >> flash). > > Thanks for sharing your experience. > > >> Note also that static data, such as images, javascript libraries, html >> files, can easily be taken from an independent webserver as long as the >> client has internet access - maybe you need nothing more than a "loader" >> index.html and dynamic json "files" on your internal webserver. > > Good suggestion. > > > I have other two doubts. > > RTOS (Free-RTOS) or not? I usually don't use RTOS and I never found it > is necessary in my applications. However TCP/IP, HTTP server and a > filesystem management could be tricky without an OS. > > I studied the contrib example httpserver_raw in lwip project (an HTTP > server without an OS). It uses a script (makefsdata) to create a virtual > filesystem as a C source code. Is it ok for simple web pages? >An RTOS is not necessary for a web server. Use one if you think it makes things easier for you, or not if you don't. FreeRTOS is probably the most popular RTOS around, and is a good choice. You can use LWIP with or without FreeRTOS. In my most recent project with a webserver, I used LWIP but no RTOS. I used a similar principle to makefsdata, but with my own scripts for putting the static content files into C const arrays of data. I am quite happy making such scripts (in Python), so that suited me - but I am sure the LWIP demo and makefsdata will work fine too.> > The other question. What about dynamic content? The example seems show > only static content. >I handled that with JSON files. So my static index.html file has (static) javascript, using jQuery, that regularly polls the board webserver for a file "data.json". This is generated dynamically (basically just a big snprintf statement with the required data added), and the javascript running on the client then puts the data in the right places in the html.
