Embedded Ethernet

If it's Ethernet, the MAC CRC is 32 bits and quite respectable.

--
Les Cargill 



> Cheers 
 Click to see the full signature
Reply to
Les Cargill
Loading thread data ...

+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 to
Joe Chisolm

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 to
upsidedown

Il 23/09/2017 12:02, David Brown ha scritto: >> [...]

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 to
pozz

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

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 to
David Brown

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.

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 to
Joe Chisolm

Il 22/09/2017 17:52, pozz ha scritto:

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 to
pozz

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.

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.

Reply to
David Brown

Thanks for sharing your experience.

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 to
pozz

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.

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.

Reply to
David Brown

Il 16/10/2017 23:45, David Brown ha scritto: [...]

I'm trying to do exactly this: jQuery, polling, JSON data requests. However I'm a little confused how to manage dynamic content with lwip and its httpd server.

I think dynamic content can be generated in a simple way by setting LWIP_HTTPD_CUSTOM_FILES and defining the function fs_open_custom() that snprintf() to a static string and set file content to that string.

int fs_open_custom(struct fs_file *file, const char *name) { if (!strcmp(name, "/data.json")) { static char json_data[1024]; unsigned int idx = 0;

idx += snprintf(&json_data[idx], sizeof(json_data) - idx, "{");

idx += snprintf(&json_data[idx], sizeof(json_data) - idx, ...);

idx += snprintf(&json_data[idx], sizeof(json_data) - idx, "}");

return 1; } return 0; }

The only problem is I can't access to query string params in fs_open_custom(). For example, I could have "/data.json?array=1" or "/data.json?array=23" or similar things.

Another problem is with CGI. After setting LWIP_HTTPD_CGI_SSI, I can define the CGI callback:

void httpd_cgi_handler(const char* uri, int iNumParams, char **pcParam, char **pcValue) { if (!strcmp(uri, "/led.cgi")) { if ((iNumParams >= 1) && !strcmp(pcParam[0], "status")) { if (!strcmp(pcValue[0], "on") led_on(); if (!strcmp(pcValue[0], "off") led_off(); } }

Here there's another problem. How to return dynamic data to a CGI request, for example a result code, maybe in JSON format? httpd_cgi_handler() doesn't return any data.

I could leave "/led.cgi" outside the static files and manage it as a custom file. However fs_open_custom() is called *before* httpd_cgi_handler(), so it's impossible to return a status code that depends on the CGI processing result.

Any help?

Reply to
pozz

Sorry - I wrote my own (simple and limited) httpd implementation.

Reply to
David Brown

Other questions on Embedded Ethernet based on lwip stack solution.

Actually I'm using a demo board with LPC1769 (with integrated MAC) and LAN8720 (Ethernet PHY). I arranged a simple HTTP server and it works (I started from example in LPCOpen libraries).

Now the problem is how to increase the security of communication over Internet. This isn't a simple task. In my application, it means adding HTTP authorization, strong encryption and so on. Unfortunately lwip HTTP server doesn't support authentication (even the basic method) and encryption, so it must be added.

I think authentication and encryption is not a problem only with HTTP applications, but for all communication protocols over public networks (so MQTT, SMTP, SNMP and so on).

I understood *the solution* is TLS/SSL (I think HTTPS means HTTP over TLS). And TLS/SSL means strong encryption that needs some crypto hw engine (that LPC1769 doesn't have).

I know I can build the system from low-level blocks (lwip, ssl, http...), but it isn't simple for me.

So the final question is: is there some Silicon vendors that show secure communication examples on their demo boards with a ready-to-use example? Or some examples from other sources that shows how to achieve what I want?

Do you solve those problems in some way?

Reply to
pozz

Op Fri, 17 Nov 2017 10:25:25 +0100 schreef pozz :

Nowadays yes. HTTP over SSL is deprecated.

All it *needs* is extra memory. It *benefits from* hw-crypto.

Well-written APIs and good documentation usually helps. But embedded software is rarely simple.

Why silicon vendors?

--
(Remove the obvious prefix to reply privately.) 
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Reply to
Boudewijn Dijkstra

ARM owns/manages/encourages (or whatever, it's open source) mbedTLS, so there are presumably examples for running it on a Cortex M.

I don't know whether that would be the right form factor for you, if you're expecting to buy a module that 'does HTTPS', rather than placing a microcontroller, MAC, PHY, etc yourself.

There might be an example for a microcontroller with integrated MAC, which would simplify the hardware.

Theo

Reply to
Theo Markettos

I found a ready-to-use example[1] from ST. I don't think I have found other similar examples from MCU vendors. However I'll have to search better.

I will use MCU with integrated MAC. Only the PHY (and RJ45) will be external. However the problem here isn't hw, but only sw (the hw issue is only related to a crypto engine useful in encryption used by TLS).

[1]
formatting link
Reply to
pozz

Il 17/11/2017 11:36, Boudewijn Dijkstra ha scritto: >> [...]

So the problem without an hw crypto engine is only RAM space?

Another good thing that helps is a ready-to-use example from MCU vendor that works on a demo board.

MCU (Silicon) vendors usually sells demo boards to show all the feaures of its products. And usually give many ready-to-use examples that works without any change on the demo boards.

Reply to
pozz

I recommend you read a bit about how these work (start with wikipedia). SSL is the older standard - TLS 1.0 was effectively SSL 3.0. But the names are often used interchangeably.

TLS provides encryption, but only a limited form of authentication. You /can/ use TLS certificates for identification, but usually they are only used for the client to check that the server has a signed certificate that is valid for its DNS name. If you want usernames, passwords, etc., you need to do that in other ways - and TLS just means you can transfer them securely.

TLS is big and complicated. It takes a good deal of code, and a good deal of processor resources. (It does not /need/ crypto hardware, but some TLS implementations can take advantage of it.) The implementations that I know of are either very big and flexible and under licenses such as the GPL, or efficient for small systems but have paid commercial licenses. I don't know if that is an issue for you.

We have simply not used TLS/SSL. For some systems, the networking is within a closed local network - encryption and authentication is not an issue. Any remote access will be via gateways with VPN's and the like.

For other systems, we do it independently of the connection. For example, one system downloads firmware updates from a server using normal http. The package itself is encrypted and digitally signed, so the receiving system can check that it is valid. That way there is no need to support the vast monstrosity of TLS and all its options and certificates - we can have one simple encryption and authentication routine in the embedded system. I don't remember off-hand what it is - probably AES.

Reply to
David Brown

We're using TLS with client side (and server side) certificates to do authentication (i.e. knowing who the other party is and create a secure channel). Keys can be kept on a separate TPM chip.

Authorization (who is allowed to do what) is more complex issue, basically our server is allowed to do almost anything, except update firmware. Firmware is signed with separate key.

We're running Linux on AM3352, though. I found references of mbedTLS being able to use client side certificates, but setting up the whole system may not be that easy. On Linux stunnel is a nice way to tunnel traffic if you don't want to do TLS connections from your application.

Separate crypto engine is not necessarily needed, it just gives you more security (key storage) or performance (crypto functionality).

--
mikko
Reply to
Mikko OH2HVJ

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.