Recommend a microcontroller with Gigabit Ethernet support

[komet]

What MCU would you suggest that supports Gigabit Ethernet?

Note that I do not need any performance at all - a few packets per second is quite sufficient, but I absolutely require gigabit Ethernet, and raw access to the packets.

[Scrts]

Check TI Sitara series: http://www.ti.com/product/AM3358/compare

Or get a BeagleBone board.

[komet]

Check TI Sitara series: http://www.ti.com/product/AM3358/compare

Or get a BeagleBone board.

Thanks. This chip is already overkill for my application. Any other ideas?

[nctnico]

The easiest is probably to add an ethernet switch to the board:
https://www.microsemi.com/products/ethernet-solutions/ethernet-switches/vsc7511-4-port-layer-2-gigabit-ethernet-switch

[amyk]

What MCU would you suggest that supports Gigabit Ethernet?

Note that I do not need any performance at all - a few packets per second is quite sufficient, but I absolutely require gigabit Ethernet, and raw access to the packets.

Saying "do not need any performance" and "raw access to the packets" is quite contradictory, no? It may only be a few packets per second but each one is going to come in really, really fast.

[julian1]

I am wondering, do you need layer 2 switching, or just packet inspection? What about layer 3 routing? If the requirement is gigabit packet response speed (albeit not throughput), then a decent cpu may be needed just for the checksumming, assuming there's a full tcp/ip stack in there.

[komet]

The easiest is probably to add an ethernet switch to the board:
https://www.microsemi.com/products/ethernet-solutions/ethernet-switches/vsc7511-4-port-layer-2-gigabit-ethernet-switch

Thanks, yes, that is obviously the easiest solution and I can't quite fathom why I didn't hit on it myself. I actually already have a 100 Mb/s version of my product, so this is clearly the easiest way.

Looks like Microsemi want an NDA for their parts, but there are other suppliers.

[Howardlong]

This is an area lacking in low to mid range MCUs. Finding support for high speed USB isn't a problem (although getting them to stream approaching 480Mbps usually takes work), I'd have hoped that by now GigE on such device in the upper Cortex M4/M7 class would have become much more commonplace by now.

GigE, being the domain of application processors, means it pretty much becomes a prereq to be running fully fledged OS such as Linux, and having to deal with all the baggage that entails.

[alm]

This is an area lacking in low to mid range MCUs. Finding support for high speed USB isn't a problem (although getting them to stream approaching 480Mbps usually takes work), I'd have hoped that by now GigE on such device in the upper Cortex M4/M7 class would have become much more commonplace by now.

GigE, being the domain of application processors, means it pretty much becomes a prereq to be running fully fledged OS such as Linux, and having to deal with all the baggage that entails.

I doubt they would have the memory or processing power to effectively use > 100 MBit/s (apart from some niche usage of streaming the data directly to an output device). And since pretty much all equipment that supports GigE also supports fast Ethernet (I seem to recall rate auto-sensing is a required part of the 1000baseT spec), there is little reason to support GigE unless you need the bandwidth.

Few IoT devices would need GigE. Add to that that networking will often involve wireless Ethernet at some point, which in many cases will limit the throughput anyway. So I do not see a very good case for low/mid-end micros with gigE .

[mikeselectricstuff]

What MCU would you suggest that supports Gigabit Ethernet?

Note that I do not need any performance at all - a few packets per second is quite sufficient, but I absolutely require gigabit Ethernet, and raw access to the packets.

Saying "do not need any performance" and "raw access to the packets" is quite contradictory, no? It may only be a few packets per second but each one is going to come in really, really fast.

But as long as the hardware buffer is big enough to hold the packets of interest, and filtering is good enough to not overflow the buffer, that won't be an issue.

[Howardlong]

This is an area lacking in low to mid range MCUs. Finding support for high speed USB isn't a problem (although getting them to stream approaching 480Mbps usually takes work), I'd have hoped that by now GigE on such device in the upper Cortex M4/M7 class would have become much more commonplace by now.

GigE, being the domain of application processors, means it pretty much becomes a prereq to be running fully fledged OS such as Linux, and having to deal with all the baggage that entails.

I doubt they would have the memory or processing power to effectively use > 100 MBit/s (apart from some niche usage of streaming the data directly to an output device). And since pretty much all equipment that supports GigE also supports fast Ethernet (I seem to recall rate auto-sensing is a required part of the 1000baseT spec), there is little reason to support GigE unless you need the bandwidth.

Few IoT devices would need GigE. Add to that that networking will often involve wireless Ethernet at some point, which in many cases will limit the throughput anyway. So I do not see a very good case for low/mid-end micros with gigE .

Streaming is precisely the application!

(Edit: in one application of mine I use USB streaming at ~250Mbps, I would love to add GigE natively, but I don't have the appetite to go the Linux route, I've been burned with that before, it's makes it too big a project for a one man band, and I'm useless at delegating.)

[alm]

Video and audio will be compressed, and then you are back to being CPU-power limited. The rest is most likely too niche for TI et al to bother. If there was a customer wanting to design one into the next consumer gadget or car, they would release on in a heartbeat.

[Kjelt]

What MCU would you suggest that supports Gigabit Ethernet?
Note that I do not need any performance at all - a few packets per second is quite sufficient, but I absolutely require gigabit Ethernet, and raw access to the packets.

Your application might just sent a few packets per second but the device is on a shared network and any other device or application thinks it is a mature 1Gbps device. Unless you want your device to be "out of service" you better make sure you can process that speed for a prolonged period of time or you will have to drop packets. What is the application anyway that for those few packets 10Mbps is not enough ?

[Howardlong]

Video and audio will be compressed, and then you are back to being CPU-power limited. The rest is most likely too niche for TI et al to bother. If there was a customer wanting to design one into the next consumer gadget or car, they would release on in a heartbeat.

That's the problem, my application is too niche, being multi-channel streaming. For now it's high speed USB attached and can also be used over 100BaseT, but not to its full capacity. The first attempt was Linux based, and I found myself debugging and fixing kernel drivers, and found that unless you're in the right clique, you'll generally be ignored and unsuccessful at getting any fixes put into mainstream builds. That was about four years ago though, maybe things have changed, but I doubt it.

[Scrts]

Not sure of the application, but aren't the packets going to wait until your CPU will be ready to parse them, so that the delay is still comparable to 100Mbps link?

[NiHaoMike]

Pogoplug goes for $10 or less and is the cheapest embedded system I know of that has Gigabit.

[Howardlong]

Not sure of the application, but aren't the packets going to wait until your CPU will be ready to parse them, so that the delay is still comparable to 100Mbps link?

There is nothing inside the packets to parse, it is essentially ultra fast data acquisition. The IP stack already has no difficulty filling a 100BaseT channel (or 250Mbps in USB), even with older devices running at 1/3 the currently available cpu speed.

[alm]

Depending on the type of data, is a simple compression scheme (even run-length encoding) useful? If you have CPU cycles to spare, that could improve your throughput.

[Jeroen3]

What MCU would you suggest that supports Gigabit Ethernet?
Note that I do not need any performance at all - a few packets per second is quite sufficient, but I absolutely require gigabit Ethernet, and raw access to the packets.

Your application might just sent a few packets per second but the device is on a shared network and any other device or application thinks it is a mature 1Gbps device. Unless you want your device to be "out of service" you better make sure you can process that speed for a prolonged period of time or you will have to drop packets. What is the application anyway that for those few packets 10Mbps is not enough ?

Indeed, it makes no sense to require Gigabit if you will not be using it. Nor be able to process it.
Switches will just link your device up with 10 Mbit, and will work happily.
If you are currently experiencing a saturated link, it is not the fault of the device, it is the fault of the network. Add a firewall to filter unrelated traffic.

[nctnico]

What MCU would you suggest that supports Gigabit Ethernet?
Note that I do not need any performance at all - a few packets per second is quite sufficient, but I absolutely require gigabit Ethernet, and raw access to the packets.

Your application might just sent a few packets per second but the device is on a shared network and any other device or application thinks it is a mature 1Gbps device. Unless you want your device to be "out of service" you better make sure you can process that speed for a prolonged period of time or you will have to drop packets. What is the application anyway that for those few packets 10Mbps is not enough ?

Indeed, it makes no sense to require Gigabit if you will not be using it. Nor be able to process it.
Switches will just link your device up with 10 Mbit, and will work happily.

No they won't. In many companies they disable 10Mbit mode on their switches and require at least 100Mbit/s devices on their network. 1Gbit/s is the new standard nowadays. I guess this has to do with network congestion. A switch feeding 10Mbit/s devices may be prone to internal buffer overflows because the 10Mbit port can't sink data fast enough. It is better to drop packets at the device side than using resources inside the switch.

[Howardlong]

Depending on the type of data, is a simple compression scheme (even run-length encoding) useful? If you have CPU cycles to spare, that could improve your throughput.

That is exactly the scheme I use for WiFi, I double the effective throughput that way, but even a simple RLE compression is too expensive in CPU terms when you're talking about hundreds of Mbps of a wired connection.