[En-Nut-Discussion] EMAC and PHY separation?

[Ulrich Prinz]

Hi!

I started with the EMAC of the STM32F by today. And the first and 
easiest thing to understand is the PHY. Then I stumbled upon the fact 
that this PHY code is bundled to every EMAC driver. As I plan to add 
more EMACs ( thinking about a open-source/open-hardware PoE EMAC addon 
board for Ethernuts and others) I felt that the PHY is something that 
you can select more or less free independent of the EMAC.

So it should go into a separate driver file. I agree that the basic set 
of registers and bits is identical to most of them and therefore it is 
probably not needed to write a separate file for each of them. But it 
could be outsourced to dev/phy.c and include/phy.h.

So I think I start with that first and collect the phys from all 
architectures...

Then we see the next step, as the STM32F EMAC is very powerfull.

Best regards
Ulrich

Am 21.10.2010 17:35, schrieb Thiago A. Corrêa:
> Hi Ulrich,
>
> On Thu, Oct 21, 2010 at 1:24 PM,<uprinz2 at netscape.net>  wrote:
>>
>> This is not true for chips that incorporate both of them like modern Micrel or others.
>> But even there the driver for the PHY and the EMAC portion can be handled in different driver source files.
>>
>>
>> This makes the things mor configureable via nutconf and does not require the designer of a hardware to use the one PHY supported by the devel-kit but gives him freedom of choice.
>>
>
>     Yes I agree. A while back I proposed a library of phys. It could be
> a driver (stack) just as well. Also, we can make all platforms have
> access to some code or config that is PHY related.
>     Even thought they are more or less standard, there are some models
> that can provide an interrupt or other additional data (like detect
> cable disconnect).
>
> Att.
>     Thiago A. Correa
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion