2
\$\begingroup\$

I am currently undertaking my first hardware design attempt of an embedded Ethernet project w/ PoE+. I have experience working with embedded systems with Ethernet (mostly ARM M3/M4 processors with RMII interface to an external Ethernet PHY transceiver), but this is my first time actually doing the hardware design for an Ethernet capable device. I will also be writing the firmware for this project.

The purpose of this project is to create a downstream I/O board that communicates over TCP/IP to a controller board. Multiple downstream boards will be connected to one controller and report analog input statuses as well as execute output control commands from the controller. This downstream board will also have a basic web server that will be accessed via a web browser so a user can set configuration options.

In regards to the PoE+ feature, I will be using a third party module. I bring up the PoE+ in case this has any impact on the answer to my question, but I don't think it does.


I will be using an ARM Cortex processor so there are two paths to take for embedded Ethernet...

(1) ARM Cortex M3/M4 processor with internal MAC and (R)MII interface to external PHY. And then obviously the RJ45 and magnetics. This design I am familiar with and I know will guarantee satisfy my needs.

Or the other, less expensive option that I am considering...

(2) ARM M0+ processor with external 3-in-1 Ethernet controller interfaced with SPI. And then obviously the RJ45 and magnetics. For the SPI Ethernet controller, I am looking at the Microchip KSZ8851SNL.


Can anyone give me a reason NOT to go with the less expensive M0 route with external Ethernet controller. Ultimately, the only cost savings is about $4 or $5 for the M0 vs M4 processor setup because both the external PHY and external MAC+PHY controller are basically the same price. This however will be a mass produced design so any savings makes a difference as volume goes up.

I am mainly concerned with potential bottlenecks in performance using the SPI interface, however I am also thinking that with such minimal traffic requirements, I should be OK with the SPI interface. The datasheet for the KSZ8851SNL says it can run at a MAX SPI clock speed of 40MHz. I am not sure if I would need to run at the max or if a slower clock speed would do. And then what would the minimum clock speed of the M0 MCU be to get good performance (no lag loading pages etc)? I am looking at M0 options that have a max clock speed of 50-75 MHz.

Firmware wise, is MII or SPI more difficult to implement, or are they the same difficulty?

What are some network applications or requirements that would make SPI Ethernet controllers not cut it and I would need to use the MII with a more advanced processor?

Or in any of your humble opinions, is it worth it just to go for the M4 MII solution and have a future proof design that could also be re-used for new, upcoming hardware projects?

And lastly, in regards to PoE+, am I correct in thinking that PoE+ will be unaffected by SPI vs MII? Also would it be possible to design the board in a way that PoE+ population is optional? Basically can I offer a Ethernet OR a Ethernet with PoE+ assembly option with the same board design? I think the PoE+ is a parallel circuit so PoE+ should be able to be optional without effecting Ethernet data transmission.

Sorry for the long read and I appreciate any insights!

\$\endgroup\$

bumped to the homepage by Community 12 hours ago

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

  • \$\begingroup\$ M0 vs M4, you be the judge. One advantage if you go for SPI to Ethernet I see is that you can swap any controller in the future still keeping Ethernet section intact. Honestly I feel you should go with M3 or M4 ..RMII MII or SPI you can decode or keep both \$\endgroup\$ – Umar Jul 10 '18 at 3:21
  • \$\begingroup\$ I'd say you didn't look hard enough for the MCU - an STM32F1 or ATSAME53 are not that expensive as compared to that KSZ8851. Also AFAIK PoE has some negotiation involved - I am not sure if the MAC and/or PHY need to support it. \$\endgroup\$ – Jan Dorniak Jul 10 '18 at 8:44
0
\$\begingroup\$

Having looked at both options, I ended up implementing an MII interface

Firmware wise, is MII or SPI more difficult to implement, or are they the same difficulty?

The MII is more difficult to wrap your head around, odds are you'll get a library and need to understand a lot of it. Ethernet is complicated with multiple layers such as the physical, data link and transport layers. These all have software components that need to be understood to send even one packet. However, you can write your own software and have the flexibility to change anything. If you wanted to run a simple web server an MII with a more complicated processor is probably the way to go. Or need something more than just sending packets to a server then use MII. In all likelyhood the data rate will be higher. Find a processor with examples to get you started and help you troubleshoot. To write MII drivers from scratch would be very difficult.

A spi interface is usually less configurable and more simple, but you only need to set registers. If it's simplicity you need and your just sending packets and need minimal configurabilty then use SPI. I think SPI would be less time to implement.

If you really do require bandwidth (get a comm budget) then go with the MII.

\$\endgroup\$
  • \$\begingroup\$ Thank you for the insights. I think I am going to go with the MII interface. It will be a re-usable design for future projects that require better network performance. There are plenty of libraries and online help for doing the firmware too. Gotta love the ARM processors! \$\endgroup\$ – zme Jul 11 '18 at 14:43
  • \$\begingroup\$ meta.stackexchange.com/questions/126180/… \$\endgroup\$ – laptop2d Jul 11 '18 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.