Recommendation for Ethernet chip needed

[nctnico]

That is not a problem. TCP/IP has inherent flow control and you'd be a fool to expect such a device to be able to cope with a lot of data. At some point the buffers are full and data will be dropped. You can say the same about having a 1Gbit device communicating with a 100Mbit ethernet device (through a switch).

[mrpackethead]

Its importnat to remember here that the choice of device is largely dictated by the application!
You dont' take a hand spade to a coal mine, and you don't dig your wifes flower garden with a 400T digger.

I use PIC32s + LAN870x's to receive around 640 multicast packets per second for lighting control data.  ( packet size is 620 bytes ).   It works just fine.     

[Scrts]

Meh. There are a lot of applications where performance does not matter one iota, including just about every "internet of things" device. If your product has a 100MHz ARM core with a 256 kiB of RAM, it's unlikely it's going to generate enough data to saturate a 10Mb/s Ethernet link anyway.

I know a project where STM32F205 does UDP/RTP video broadcasting to the IP network up to 90Mbps. The video is already MPEG-TS, but the processor does many other things too. E.g. MPEG-TS table parsing, PID filtering, table generation, etc.

On the other hand, you will always find 10/100 PHY anyway.

[westfw]

You know what's really sad?  You can probably add an OTS wireless router to your existing wireless design and wind up with a lower BOM than adding hardwired ethernet...

[richardman]

You know what's really sad?  You can probably add an OTS wireless router to your existing wireless design and wind up with a lower BOM than adding hardwired ethernet...

Not for the product I have in mind 

[bson]

That sounds a bit over the top because there are still lots of old e-mail programs in use. It could be true though when wanting to use a provider's e-mail server from outside their network. That typically requires a login + password so could also require encryption.

Just about any ESMTP server on the net these days is going to require at least STARTTLS.  And that's rapidly going away (which is a good thing) to requires TLS from the get-go.  I run my own mail server (and have since the pre-Internet uucpnet bang!address days), and even I don't allow myself to send mail without TLS... for good reason.  Any embedded device on the public Internet is definitely going to need TLS at least, and probably also HMAC for request signing.

[bson]

Kinnexa makes some nice integrated RMII PHYs, all complete with magnetics inside a somewhat oversize RJ45 jack complete with blinkenlights.  Pretty much wire it up using some HS traces and press the 'go' button.  Price: no idea, but they sure look handy.

[nctnico]

That sounds a bit over the top because there are still lots of old e-mail programs in use. It could be true though when wanting to use a provider's e-mail server from outside their network. That typically requires a login + password so could also require encryption.

Just about any ESMTP server on the net these days is going to require at least STARTTLS.  And that's rapidly going away (which is a good thing) to requires TLS from the get-go.  I run my own mail server (and have since the pre-Internet uucpnet bang!address days), and even I don't allow myself to send mail without TLS... for good reason.  Any embedded device on the public Internet is definitely going to need TLS at least, and probably also HMAC for request signing.

If you have ever tried to implement TLS on a microcontroller you would know TLS is a no-go on many microcontrollers so IoT devices need another way to secure themselves. TLS is too big and too clunky for use in a small device. I expect some kind of standard will emerge in the next few years but until then you are on your own to come with a good security scheme which fits your microcontroller.

[westfw]

TLS is a no-go on many microcontrollers so IoT devices need another way to secure themselves.

Exactly.  So probably "many microcontollers cannot send eMail", even if they otherwise support TCP/IP and SMTP.
Sure, you can use some sort of relay; but then why bother having TCP/IP/SMTP on the micro; send UDP datagrams to the relay and let it reformat.
(Presumably, this is one of the reasons that a lot of IoT things are ending up with subscription "cloud servers" that they have to do things through.)

[Kjelt]

TLS in a minimum configuration like CYASSL (WolfSSL) will cost you 20k to 30k ROM and at least 10-15k RAM(minimum config) without PKI, full package runs you over 80kB ROM and 30kB RAM.

[nctnico]

But ask yourself how effective a cut down version of TLS is. Chances are servers are configured to not accept certain (weak) encryption methods.

I'm also not convinced about being unable to send e-mail without TLS. So far I have never seen an internet provider which requires to use TLS to send e-mail from within their own network.

[Kjelt]

Agree, up to date servers should only accept the latest proven ciphers which almost all include PKI.

Personally I think an M4/M7 cortex with 256kB RAM and 1M ROM can easily handle these requirements.
Devices with 64kB RAM and lower are cumbersome to implement TLS and an IP stack, there is hardly any RAM left for the program itself   

[nctnico]

I have some hands-on experience with PolarSSL. One of the problems is that an ARM running at 72MHz will need a lot of time to process the ciphers. I have seen the device I worked on needed about 5 seconds to setup an SSL connection with a web browser.

[Kjelt]

True but that is only the PKI handshake part which is once per connection (authentication and session key). After that the parties switch to symmetrical cryptography with the session key and that is way faster, with HW acceleration we talk about 100's Mbits per second  without HW acc. a few Mbits / s

[richardman]

We are looking at >100MHz F429 with 512M RAM, so I think hardware would be "minimally sufficient".

[Kjelt]

512MB of RAM? External dram then?

[bson]

TLS is a no-go on many microcontrollers so IoT devices need another way to secure themselves.

Exactly.  So probably "many microcontollers cannot send eMail", even if they otherwise support TCP/IP and SMTP.
Sure, you can use some sort of relay; but then why bother having TCP/IP/SMTP on the micro; send UDP datagrams to the relay and let it reformat.
(Presumably, this is one of the reasons that a lot of IoT things are ending up with subscription "cloud servers" that they have to do things through.)

You don't want connected devices to send email anyway.  Email is simply not a good notification mechanism.  You'll want to stand up or use an existing rendez-vous infrastructure and do something like http post an hmac-signed json dict.  (Or implement jsonrpc, which is what I did for samba.tv's connected device middleware.)

[richardman]

512MB of RAM? External dram then?

Yes

[westfw]

Hmm.  thinking slightly outside-the box:  has anyone tried using a microcontroller USB Host port and one of the single-chip USB/Ethernet chips?  Lots less PCB complexity than a even an RMII interface to a phy.  On the minus side, more SW complexity and somewhat less performance (but possibly USEFUL SW complexity.  USB Host stack, mostly-similar chips that include USB HUB...)  (This is how raspberry Pi does ethernet.   This is how MANY laptops do WiFi...)

[djacobow]

512MB of RAM? External dram then?

Ah, with the external memory and a real eth i/f we're getting well into the realm of being a "real computer."  Not what I was imagining when you first posted at all.

Curious how this compares, cost-wise with going with one of the ARM SoC kitchen sink "application processors" with MMU, on-board DRAM, etc. There's something to be said for being able to boot linux and access its device drivers, openssl, console access over ssh, scripting languages, etc, no fuss.

[nctnico]

Hmm.  thinking slightly outside-the box:  has anyone tried using a microcontroller USB Host port and one of the single-chip USB/Ethernet chips?

Not with a microcontroller but I did that in one of my SoC designs in which the SoC didn't have ethernet (=MAC) build in.

[Kjelt]

There's something to be said for being able to boot linux and access its device drivers, openssl, console access over ssh, scripting languages, etc, no fuss.

To get it up and running there is little fuss, to keep it updated and running automa(g)(t)ically at the customer and guarantee 10 years of support there can be a lot of fuss.

[djacobow]

There's something to be said for being able to boot linux and access its device drivers, openssl, console access over ssh, scripting languages, etc, no fuss.

To get it up and running there is little fuss, to keep it updated and running automa(g)(t)ically at the customer and guarantee 10 years of support there can be a lot of fuss.

Were you planning on keeping your 100% hard-coded firmware updated as well? Linux can be a pain in the ass, I get it, but some of the things that are a pain are things that embedded folks just skip altogether. You make a connected device you have opened yourself to vulnerability, and it will need to be maintain, full stop. Now, you could make a good argument that less code means less bugs, with which I agree. But this person is heading in the direction of a full networking stack, modern and complete crypto, etc. Might be less code to do without Linux baggage, but I slight prefer my odds with the well-trodden drivers and OS.

I think most of the work with embedding linux is creating your own 'distro' with every single thing you do not need stripped out. That's a boatload of work.

I've worked in the IoT space and lived the pain. My general sense is that the solutions right now for developers suck. You basically can turn over the keys to a platform company (and pay in perpetuity and be limited to what they thought was a worth doing), roll your own platform, or throw a proper OS on there. I don't like any of those options. And those are the same options and essentially the same complexity if you want to flip a few bits occasionally over the cloud, or you want to complex interactions and streaming Gb of data. Rolling your own, by the way, I find particularly unpleasant for a startup because you end up investing big time and money in "generic" plumbing that has nothing to do with your company's mission.

I think the option I would like to see is an OS _for_ IoT. Cut down, minimal, and, if it implements simpler (but still secure) network protocols, I'm all for that. I'll be happy to do the server-side work to talk.

[bson]

Curious how this compares, cost-wise with going with one of the ARM SoC kitchen sink "application processors" with MMU, on-board DRAM, etc. There's something to be said for being able to boot linux and access its device drivers, openssl, console access over ssh, scripting languages, etc, no fuss.

To run Linux out of external DRAM it's paramount to have on-chip caches.  Far from all processors have this.  Without caching the CPU clock is completely irrelevant past 10MHz or so and the whole thing will run at the speed of the DRAM, which is slooooow.

[Kjelt]

Were you planning on keeping your 100% hard-coded firmware updated as well? Linux can be a pain in the ass, I get it, but some of the things that are a pain are things that embedded folks just skip altogether. You make a connected device you have opened yourself to vulnerability, and it will need to be maintain, full stop. Now, you could make a good argument that less code means less bugs, with which I agree. But this person is heading in the direction of a full networking stack, modern and complete crypto, etc. Might be less code to do without Linux baggage, but I slight prefer my odds with the well-trodden drivers and OS.

I agree Linux is the better choice, however I just wanted to make the point that IF it is connected to the internet, and has open ports, any decent pentester can figure out within 1/2 hour which OS is running exactly, which SSL suite and which open source modules etc. etc. Look up in the vulnerability database all the vulnerabilities in those modules and if not updated owns that device and can use it for what it wants. Now making your own version of an OS/SSL stack is also not an option since although it would take an attacker much more time it actually would come down to security by obscurity.
However if you have a very simple device with no users with higher privileges, no software that can be modified etc. etc. you can become more safe than with Linux.
So actually the only secure thing you can do with any embedded Linux networked device that is not going to be monitored and updated is keep it away from the bad bad internet, close all ports and use other secure channels to communicate with it (a decent server with good firewall that is maintained and updated).
IoT: the Internet of Threads