Main Site Documentation

Using STM32F4xxx built in Ethernet


I have noticed that the Mountaineer Ethernet Mainboard uses the larger 100 pin STM32F407 with built in ethernet. All of the newer GHI boards use the smaller 64 pin STM32F405. When creating the FEZ Cerbuino Net the STM32F405 was used with the ENC28xxx Ethernet chip instead of the STM32F407.

Why not use the build in Ethernet of the STM32Fxxx family instead of the ENC28? Are there any performance reasons? Does SDK Package 2013 R2 support the internal ethernet?
This post about the “Blue Genie” is what got me thinking about it.

Justin is using the new SMT32F427 that has more memory and the built in Ethernet.

I am sure there is a reason out there, I just couldn’t find it searching the forum. (I might have even asked this before but I have searched for over 2 hours for the answer.)



I believe a similar question was asked a week or so ago about another board. As I recall, the simple answer is there already exists the software to support the ENC28 and to use the built-in ethernet would require additional work. So, its easier for GHI to just use the ENC28 and not have to support multiple networking stacks.


Built in is more work but not much faster. Cerb family is made to be economical and simple with plenty of options, KISS.

Need power, get G400.


ianlees and gus,
Thanks for the info. It makes sense. Not really after power or performance per say, I was just wondering what the thought process was behind the design.


The Mountaineer firmware uses the built-in Ethernet hardware of the STM32 microcontroller. [em]CSA Engineering[/em], one of the companies of the Mountaineer Group, had written a highly efficient driver for that purpose. This driver has been published as part of our [em]NETMF for STM32 [/em]port on Codeplex:

Depending on your application code, this may or may not result in a noticeable speed up.


Cuno can correct me if I’m wrong here, but I believe the main disadvantage of using the built-in ethernet was code size and memory use. The new 42x parts should solve that problem, but adding just a PHY and using the built-in MAC is probably no less expensive than using the ENC28, and it consumes more pins, and it’s more complex to route on a board, and…


@ godefroi - You need the same lwIP stack in both cases, you need buffers for the Ethernet frames in both cases, and you need low-level drivers for the specific hardware in both cases. So code size and required RAM space should not be very different as far as I can tell.

It is difficult for me to say how the larger microcontroller size compares with the space needed for the additional ENC28.