Connecting an Ethernet PHY to Arduino Due

Hey Palliser, how are you getting on with interfacing your phy to the Due? I don't mean to chase you but I am keen to see the library/ethernet files as I would like to add support for a different PHY.

Hello TonyT3P3,

Following is a summary of my progress with the EMAC/PHY interface.

Firstly, I got good Ethernet communication between my new Russian PHY board (AS-DM9161) with the SAM3X-EK board. I performed this with the purpouse of verify the functionality of this PHY board because is slightly different from the one embedded in the SAM3X-EK.

Here a log excerpt of the EMAC/external EPHY communication between SAM3X-EK board and AS-DM9161 Ethernet PHY board:

-- MAC 0:4:25:1c:a0:2
-- IP  192.168.0.2
Link detected.
-- IP  255.255.255.255
-- IP  20.254.181.156
======= IP   60 bytes, HEADER ==========
 IP Version        = v.4
 Header Length     = 5
 Type of service   = 0x0
 Total IP Length   = 0x22
 ID                = 0x4B8E
 Header Checksum   = 0x2E92  Protocol          =
UDP

 IP Src Address    = 192:168:0:3
 IP Dest Address   = 255:255:255:255
----------------------------------------
-- IP  255.255.255.255
-- IP  20.254.181.156
======= IP   60 bytes, HEADER ==========
 IP Version        = v.4
 Header Length     = 5
 Type of service   = 0x0
 Total IP Length   = 0x2C
 ID                = 0x4B91
 Header Checksum   = 0xAF94  Protocol          =
ICMP

 IP Src Address    = 192:168:0:3
 IP Dest Address   = 255:255:255:255
----------------------------------------
...

So far so good.

Then, I started tests between the Taijiuino board and the AS-DM9161,but hitherto, I have not managed to get communication between them. The EMAC sample sketch compiles OK in the Arduino IDE but I believe
I am overlooking something, specially in the Pio/pin configuration (in the variant files).

Here a log excerpt of the Taijiuino DUE EMAC/external EPHY:

-- MAC 0:4:25:1c:a0:2
-- IP  192.168.0.2
Link detected.

I can see leds activity (FD/100/LINK) in the DM9161 but I am getting the same log even with the Taijiuino disconnected from the PHY.

Thus and unlike my CAN project, I have decided to publish and keep updates of the EMAC library files here (see my very first post in this thread). This files are the ones I am using now. The purpose of this is to obtain help from you guys.

Because the sketch compiles OK, I think that the only way to help testing the code, is to do it with the Taijiuino board and a DM9161 based board. Anyway, any comment/revision of the code is very welcome.

Other exercise I am going to do this week, is to run the same test SAM3X-EK/DM9161 but with the DP83848 to confirm that it works also, thus, using this second PHY as another option.

For your information, I am also trying to get direct support from Atmel. Thank you.

Whoever ventures to help me with the Ethernet MAC library, here what I have done regarding the EMAC pin configuration:

-I added in the variant.cpp the EMAC pin definition (lines 291 to 301) and the initialization of the EMAC Pio configuration (lines 431 to 485).
-I added in the variant.h the defines of the EMAC pins (lines 187 to 202).

Here a picture of my test of the DM9161 board. My test with the DP83848 still pending. I also still trying to get help from Atmel technical support team.
But don't worry, I will solve it.

Regards!

Hi Palliser,

I'm currently designing a SAM3X8E Arduino "work-alike" system and was planning to use a W5200 but this thread has convinced me to at least break out all the EMAC signals so I can add the PHY at a later date.

Thanks for you work in this (and other) areas, I also have both CAN interfaces on my backplane so will presumably be looking to your work there as well.


Rob

Hello Graynomad,

I am delighted to know about your Due-oriented system! Please, remember to include also the pin 69 (NRST) which adds the capability of the SAM to reset external components. Keep us posted about your progress and count on me if you need any assistance.

Palliser

remember to include also the pin 69 (NRST)

Already done.

I'm trying to provide full access to all peripherals like HSMCI, SSC, SMC, EMAC etc. Unfortunately the chip MUXs many signals and provides no optional pins so there will always be trade-offs of the "If you use X you can't use Y" type.

Do you know what frequencies I can expect on the EMAC signals? The full 100MHz or only 50 because there are two data lines. I plan to run these signals across a backplane to an Ethernet card and am a bit worried about the speeds.


Rob

Unfortunately the chip MUXs many signals and provides no optional pins

Yep. Multiplexing scheme (to reduce I/O) is our eternal karma with micro-controllers.

Do you know what frequencies I can expect on the EMAC signals?

The frequency depends on the interface supported by the external PHY. Most PHYs support both.

-25 MHz for MII
-50 MHz for RMII.

I am using RMII (higher speed and saves me 4 pins).

-Palliser

Is there any progress with DP83848 with sam3x-ek?
Later I would like to contribute LAN8720A PHY once I understand how you port it.
Thanks for your work.

Hello anon10500,

I haven't started my tests with DP83848 but I am almost certain that it will work in a similar way to the DM9161. I also checked some specs and schems of the LAN8720A PHY you mentioned and it should also work. What I do not understand is why the people from MikroElectronika didn't connect the reset pin?...though I'm mostly centered now trying to communicate the Due with the PHY. As you may have noticed, I am working together with Atmel tech support to achieve this. And I also published in the forum my library asking for help. Even though what separates me to begin to see result is too little, I cannot be precise about the 'when'. Just keep in touch.

Hello Palliser,

I am working together with Graynomad (Rob) in the design of a new modular Due 'work-a-like' system, in which we intend to use the EMAC together with a PHY such as the DM9161 chip from Davicom or maybe something better still.

Firstly, I wish to say that we appreciate your willingness and openness in wanting to have a working SAM3X EMAC/PHY Ethernet library for the Due family.

I would like clarification as to the current progress of your library to allow the SAM3X EMAC interface to connect to a PHY.

In your first post you write:

See the attachment with the latest EMAC library (compiles OK but not working)

You say it compiles ok but that it does not work, can you give us some details as to what you have been able to get working and what is not working please?

In your post #10 you wrote:

I just ported the Atmel Ethernet API to Arduino IDE. At least the 'EMAC_EMAC_EXAMPLE1' now called 'Arduino_Due_EMAC_Sample_1.ino' is compiling with no errors

When you say you ported the Amtel Ethernet API to Arduino IDE, can you elaborate a little for us, in terms of what functionality does this port provide in the Arduino IDE, for example, does it allow full configuration of and use of the EMAC interface?

In your post #13 your wrote:

Don't ask but even though DM9161 is obsolete, expensive and difficult to purchase it, it has been Atmel's workhorse for the SAM family all these years. No "TX underrun" messages under heavy loads with 100M link. I still believe is the best option for now.

I understand Davicom have a newer DM-9162 now, in your opinion, is this any better?
If not, what other PHY would you suggest for best design for a better system?

In your reply #22 you mention:

better but more expensive option is to use a Micrel PHY, pretty much because, according to Atmel, it has better hardware integration and documentation.
Indeed, it is in my list To-Do to purchase one of the series KSZ80.

Looking at the Micrel list for PHY chips, I found this one, a KSZ8081RNA, http://www.micrel.com/index.php/en/products/lan-solutions/phys/article/3-ksz8081rna.html. It looks to be a modern PHY that offers a few more niceties such as termination resistors on chip as well as being able to use a 25Mhz crystal which generates the 50Mhz clock for RMII.
When you say 'more expensive', I checked the cost of these chips and I found them to be one of the cheapest, at around US$1.00 each as compared to the TI DP83848 which sells at around US$3.00 to US$5.00. Why did you find this option 'more expensive' ?

In post #27 on February TonyT3P3 wrote:

I am working with a KSZ8051RNL which I had working on LPC1789 and want to port to the SAM3X8E.

I believe the KSZ8051 to which he refers is a model before KSZ8081, and with my limited research, both appear to be a very suitable PHY to use, especially since the DM-9161, as you say is 'obsolete', or at least quite a number of years old now.

In your reply #46 you wrote:

I have been trying to modify the EMAC library to make the DP83848 work with the Taijiuino but only communication errors.

Can you tell us if you have since been able to understand and rectify those errors or have you made further progress with this?

In reply #48 you wrote:

I got good Ethernet communication between my new Russian PHY board (AS-DM9161) with the SAM3X-EK board. I performed this with the purpose of verify the functionality of this PHY board because is slightly different from the one embedded in the SAM3X-EK.

Can you tell us in more detail what you mean exactly by 'good Ethernet communication'?
My understanding from looking at the schematic of the SAM3X-EK where the DM-9161 is located looks to be the same as the AM-DM-9161 module, is this not correct?

In reply #48 you wrote:

The EMAC sample sketch compiles OK in the Arduino IDE but I believe
I am overlooking something, specially in the Pio/pin configuration (in the variant files).

I wonder if you can elaborate on this?
Do you believe the problems are in the initial PHY configuration or are you getting past that point and the problem lies in the actual implementation of Ethernet communication?

Lastly, I noticed that in your first post, the last edit states 'Last Edit: 15 March 2013, 02:18:35 by Palliser'.
But I notice in your reply #49, dated March 19 it appears you have made further improvements to your library as follows;

I added in the variant.cpp the EMAC pin definition (lines 291 to 301) and the initialization of the EMAC Pio configuration (lines 431 to 485).
added in the variant.h the defines of the EMAC pins (lines 187 to 202).

Can I confirm with you that you are keeping the first post the location of the latest code?

Palliser, I realise this is a long list of questions, but we are very keen to use the SAM3X EMAC in our design.
I like what you say when I read 'But don't worry, I will solve it'. Please keep at it Palliser, it will be a major step forward to have it functional.

I would also like to say we would invite any others who might have 'tinkered' with this interface who may have something to add to please step up to the podium.


Paul

We are experimenting with 5 Due's (Arduino y TAIJIUINO varieties) at the moment. While I am enjoying the freedom of multiple UARTs and Allot of I/O... well, I'm growing frustrated getting LCD touch screens, SDfat and I2C working acceptably. (I bet we have 9 different LCD panels ranging from 2.4" to 7"). I haven't even begun with Ethernet...nor do I have the technical expertise and capabilities you all have. It's frustrating because I want to stop messing around with getting the prototyping platform (DUE) operational and just move on to designing and building my proof of concepts. Admittedly the stuff I am trying with DUE is magnitudes more difficult than what I've done with Uno and Mini. I need local user interface (lcd/sdfat), remote user interface (web/Ethernet), local I/O (done! finding hardware debounce was awesome) and remote I/O (I2C) operational.

That said..if you all (GreyNomad, Wallaby and Pallisar) identify a number of PHYs you want to try.... just direct me to where they can be purchased in quantity and at good prices...and I will donate them to the cause... I'll gather a mess of them together and then get them shipped to Oz and Venezuela. (I live in Mexico but I get up to Arizona, USA allot). I'll send you multiples so that you can burn a few of them up at will. Sorry, guys, that is the best I can do stepping up to the plate to help you guys with the effort.

Hello Wallaby and GreyNomad,

I just stopped 'Round Midnight in my cassette player. Sometimes the Monk helps to put some ideas in order! I am glad to know that you and Rob are taking seriously the challenge of building your own Due-oriented system. Godspeed.
Thank you very much also for your words regarding this initiative to exploit the full potential inside SAM3X8E. That is the minimum we can do in favor of Arduino in return for their amazing contribution.

Here my answers:

Post#1:
What is working: If you test the EMAC sample sketch with Arduino IDE 1.5.2 using the EMAC library, it compiles OK (No errors. No warnings).

What is not working: When you test it on real hardware (DM9161 phy/Taijiuino), it doesn't work. There is no way to get any communication between them. I have double-checked the wiring, pull-up/down resistors, and I even ran a simple code that blinked all the Ethernet pins in the SAM3X8E. Furthermore, I connected the DM9161 to the SAM3X-EK and I got communication between them. Thus, all the hardware is OK but the something in the software is wrong.

Post#10:
This EMAC library is the result of the same porting approach I did to the CAN library (which is workable and available here in the forum). Let me just recap that: I took the Atmel ASF EMAC library that actually permits, through a couple of samples, the perfect communication between the SAM3X8H and DM9161 embedded in the SAM3X-EK board. Thus, SAM3X8H and PHY DM9161 work OK. That’s why I decided to ‘port’ the library to the Arduino environment. To achieve this, I had to get rid of a lot (and I mean ‘a lot’) of unneeded references that ASF uses. Of course, CAN was easier because involved only two pins unlike Ethernet that uses ten pins. I can post later the details of how to port ASF libraries but I have a warning, it is not very Arduino-style, lot of pointers, structures, and low-level stuff, written for engineers, not for beginners.

Post#13:
I don't know if the new DM-9162 is better or not. I need to read about it. Because of SAM3X8E, all my design consideration are derived from Atmel's literature, I know from them that the DM9161 was the best option (you can read other phy suggestions of Atmel in their document 11153) but recently I knew that Atmel just turned to Micrel for the reasons I mentioned in my reply #22.

Post#22:
I was making reference to some phy boards based on KSZ80 series (KSZ8001,KSZ80
51MNL) I did read after Google it. I believe (may be I am wrong), most people in the forum does not build stuff from scratch, like you, but get/purchase parts ready to go. $1 for a KSZ8081RNA sounds like a good deal.

Post#27:
I don't know how old is KSZ8051RNL but Atmel recommended it in their doc 11153.
I can ask Atmel about Micrel and let you guys know.

Post#46:
I am prompted to test again DP83848 but with SAM3X-EK. In the past, I made some mistakes synchronizing the reset pin of the phy. PHY reset pin should be disable for few milliseconds before start handshake. The good of the EMAC library is that lets SAM3X8E to take control over this.

Reply#48:
First quote: The log excerpt that I did read in the serial monitor it means to me that I have good communication.
Second quote: The problem should be in the actual implementation of Ethernet communication.
(Working on it with Atmel technical support. Nothing clear yet).
Both statements make reference to the same library. With my last quote, I wanted to point the user to where (in the files/lines) the attention has to be focused.

I hope I have enlightened you a bit more with my answers. Please, feel free to ask more questions if needed. Regards!

-Wilfredo

Wilfredo,
Thank you for your prompt and detailed reply, it helps me to better understand where you are at with your progress.

I have some further questions, and I would first like to confirm a few things with you if I may.
You were able to get 'good communication' with a Davicom AM-DM-9161 module connected to the SAM3X-EK development board using the sample code provided by Amtel, correct?
With the above test, the Davicom module was wired in place of the existing on-board DM-9161 PHY, yes?
And so far, this has been the only success with use of a PHY in any way, other than the on-board PHY of the SAM3X-EK, correct?

Thus, there has been no success as yet with a PHY connected to a Taijiuino or a Due, is this correct?

I believe the SAM3X-EK, the development board you have is using the 'beRTOS', is that correct?
I know nothing of this OS, other than to assume it is a Real Time multi thread capable Operating System?
That being the case, any porting from an OS based system to a no OS based system such as used on Arduino is going to need some careful attention to detail for a successful porting.

ODwyerPW,
Thanks for your generous offer, I can understand your keenness also, though I'm not sure that having the PHY chips right at this moment will help us.
What would help would be if I had my hands on a Taijiuino and a PHY module.
I would then be in a better position to assist Palliser with the porting and testing, more hands or brains on deck would certainly help.
I might need to go out and buy those things, but am hesitant as I would have little use for them afterwards, and it will just be another board collecting dust. If anyone wants to donate one on a temporary basis, that would be great, I'll pay postage :slight_smile:

Wilfredo (Palliser) wrote:

There is no way to get any communication between them. I have double-checked the wiring, pull-up/down resistors, and I even ran a simple code that blinked all the Ethernet pins in the SAM3X8E

I take it you meant there was no indication of any communication between them, rather than 'there is no way to get..' :slight_smile:

When you did the test to toggle the EMAC IO lines on the chip, did that succeed?
If you were able to do that, then my first suggestion to you is that you would appear to have those IO lines set for GPIO use rather than having them set to what I believe should be, to use peripheral 'A', the EMAC function.
For that test, maybe you configured those pins for GPIO use?
Did you then configure those pins for peripheral use to continue with EMAC?

I think it will be important for you to make sure you are setting up the peripheral the correct way and to confirm that you can read and write various EMAC registers initially. Check section 42.6 of the main SAM3X pdf for Ethernet MAC 10/100 (EMAC) User Interface Register Mapping at table 42-6.

Make a test code that goes ahead and configures the EMAC and then have it read back those registers and display them in a way you can see the values, maybe even a Serial.print might be good.

Also, from you photo at reply #43 it appears to me you are attempting the test in MII mode rather than what I would assume to be an easier mode of RMII. In your software I see you have mii.h, do you also have a rmii.h to work with for RMII later?

Wilfredo, with a 25Mhz MII or 50Mhz RMII clock, all wires need to be very short, otherwise I expect you'll have a lot of problems getting it to work. See if it is possible for you to mount the PHY module directly on top of the Taijiuino with wires no longer than 50mm.

Later on I would suggest using RMII as it uses fewer of IO pins of the SAM3X and that the interface to the PHY should be simpler, in terms of both hardware and also PHY register configuration.

Can you check that none of the additional lines used for MII over RMII are not used by other functions of the DUE or Taijiuino as they will need to be free for EMAC?

But for now, make sure you configure the EMAC interface to match your PHY, whether that be MII or RMII.

At this point my suggestion would be to focus on using the Taijiuino and to know that you are accessing the internal EMAC interface correctly. Once this has been achieved and proven, we can connect up a PHY.

As stated in the Atmel 11153.pdf, 'How to connect an Ethernet PHY to SAM3X' documentation;

'Due to standardization, the connection between a MAC controller and a PHY is straightforward and simple. Even, any PHY can work with any MAC'

I would hope that to be the case, and with that I am pretty keen to develop with Micrel's KSZ8081RNA, though let's get what we have now going first, in terms of PHY chip.

Micrel's KSZ8081RNA is a purely RMII unit, so no extra lines for MII.
It uses a 25Mzh crystal to produce the required 50Mhz clock for both EMAC and PHY timing.
It supports standard IEEE 802.3 MII management interface.
My thoughts are that it would be quite a simple and preferable PHY to use, once we get EMAC proven.
Link to PHY info http://www.micrel.com/index.php/en/products/lan-solutions/phys/article/3-ksz8081rna.html


Paul

Paul,
Thank you again for your questions and notes. It's glad to know you can take time to help here.

Here my answers,

I have some further questions, and I would first like to confirm a few things with you if I may.
You were able to get 'good communication' with a Davicom AM-DM-9161 module connected to the SAM3X-EK development board using the sample code provided by Amtel, correct?

Yes. Correct.

With the above test, the Davicom module was wired in place of the existing on-board DM-9161 PHY, yes?

Yes. Correct.

And so far, this has been the only success with use of a PHY in any way, other than the on-board PHY of the SAM3X-EK, correct?

Yes. Correct.

Thus, there has been no success as yet with a PHY connected to a Taijiuino or a Due, is this correct?

Yes. Correct.

I believe the SAM3X-EK, the development board you have is using the 'beRTOS', is that correct?

No. For this EMAC example, I am using some CMSIS thirdparty sources and SAM compiler drivers.
There is a couple of other EMAC samples that use FreeRTOS, a thirdparty API, but again, not for this current application.

I know nothing of this OS, other than to assume it is a Real Time multi thread capable Operating System?

Yes. More specifically a mini Real-Time Kernel.

That being the case, any porting from an OS based system to a no OS based system such as used on Arduino is going to need some careful attention to detail for a successful porting.

It is not the current case.

ODwyerPW,
Thanks for your generous offer, I can understand your keenness also, though I'm not sure that having the PHY chips right at this moment will help us.
What would help would be if I had my hands on a Taijiuino and a PHY module.
I would then be in a better position to assist Palliser with the porting and testing, more hands or brains on deck would certainly help.
I might need to go out and buy those things, but am hesitant as I would have little use for them afterwards, and it will just be another board collecting dust. If anyone wants to donate one on a temporary basis, that would be great, I'll pay postage

Yes ODwyerPW. Thank you also for you interest and offering. So far, I am covered with my Taijiuino and PHY. If I need something, I will let you know.

There is no way to get any communication between them. I have double-checked the wiring, pull-up/down resistors, and I even ran a simple code that blinked all the Ethernet pins in the SAM3X8E
I take it you meant there was no indication of any communication between them, rather than 'there is no way to get..'

Right, no indication of any communication between them.

When you did the test to toggle the EMAC IO lines on the chip, did that succeed?

Yes. I made all the EMAC pins to blink accordingly.

If you were able to do that, then my first suggestion to you is that you would appear to have those IO lines set for GPIO use rather than having them set to what I believe should be, to use peripheral 'A', the EMAC function.
For that test, maybe you configured those pins for GPIO use?

Interesting. Yes. For that specific ‘blink’ test I did set the Emac I/O lines for GPIO use.

Did you then configure those pins for peripheral use to continue with EMAC?

Not sure now. I will verify that.

I think it will be important for you to make sure you are setting up the peripheral the correct way and to confirm that you can read and write various EMAC registers initially. Check section 42.6 of the main SAM3X pdf for Ethernet MAC 10/100 (EMAC) User Interface Register Mapping at table 42-6.

I will do that as soon as possible. Thanks.

Make a test code that goes ahead and configures the EMAC and then have it read back those registers and display them in a way you can see the values, maybe even a Serial.print might be good.

I will do that also as soon as possible. Thanks.

Also, from you photo at reply #43 it appears to me you are attempting the test in MII mode rather than what I would assume to be an easier mode of RMII. In your software I see you have mii.h, do you also have a rmii.h to work with for RMII later?

No. Remember that for MII you need: carrier sense (ECRS), collision detect (ECOL), receive clock (ERXCK) and transmit error (ETXER) pins. I have not use any of those phys pins in my tests. For a better understanding, please, see my schematics on reply #29 and read page 2 of doc11153. Regarding rmii.h, even though I am not using it, I wanted to keep it for further use.

Wilfredo, with a 25Mhz MII or 50Mhz RMII clock, all wires need to be very short, otherwise I expect you'll have a lot of problems getting it to work. See if it is possible for you to mount the PHY module directly on top of the Taijiuino with wires no longer than 50mm.
I will consider that in my next tests. Thanks.
Later on I would suggest using RMII as it uses fewer of IO pins of the SAM3X and that the interface to the PHY should be simpler, in terms of both hardware and also PHY register configuration.

Again, so far I have been using RMII, with less pins as you said.

Can you check that none of the additional lines used for MII over RMII are not used by other functions of the DUE or Taijiuino as they will need to be free for EMAC?

I checked them and all the Taijiuino EMAC lines are free for EMAC.

But for now, make sure you configure the EMAC interface to match your PHY, whether that be MII or RMII.

I will consider that in my next tests. Thanks.

At this point my suggestion would be to focus on using the Taijiuino and to know that you are accessing the internal EMAC interface correctly. Once this has been achieved and proven, we can connect up a PHY.

I will consider that also in my next tests. Thanks.

As stated in the Atmel 11153.pdf, 'How to connect an Ethernet PHY to SAM3X' documentation;
Quote
'Due to standardization, the connection between a MAC controller and a PHY is straightforward and simple. Even, any PHY can work with any MAC'
I would hope that to be the case, and with that I am pretty keen to develop with Micrel's KSZ8081RNA, though let's get what we have now going first, in terms of PHY chip.

Like you, I hope and believe that any RMII PHY transceiver should make it with SAM3X8E/EMAC.

Micrel's KSZ8081RNA is a purely RMII unit, so no extra lines for MII.
It uses a 25Mzh crystal to produce the required 50Mhz clock for both EMAC and PHY timing.
It supports standard IEEE 802.3 MII management interface.
My thoughts are that it would be quite a simple and preferable PHY to use, once we get EMAC proven.
Link to PHY info http://www.micrel.com/index.php/en/products/lan-solutions/phys/article/3-ksz8081rna.html

Yes. I believe Micrel should be my next phy choice.

Again, thank you Paul and Rob for your interest. I will keep you posted about my progress here.

Regards and Happy Easter!
Wilfredo

Paul,
Let's get a Taiji-uino and it's programmer over to you. I'm all for dividing the workload and splitting expenses.
email me at odwyerpw@sonoratechnical.com with shipping info.
Peter

At some point, when you're ready just send it over my way. A sort of rob Paul to pay back Peter.

Wilfredo,
Thank you for your detailed answers, I appreciate your time in explaining them.

I would like to spend some time looking over the software as you have it in the zip file at your first post, just getting my head around it. Can you update it as you make changes so I keep updated as well?

Could I also suggest we set up a off site file location for the library files, say for example Github, as I believe you already have one set up for the CAN bus library. That way we can share the code changes.

Peter, I have sent an email to you, which I guess you will have seen already before reading this.


Paul

Hello rockwallaby,

I have good news. I just got GOOD communication between Taijiuino's EMAC and the DM9161 PHY!

I just did two things:

  1. I re-built from very scratch the EMAC library and sample sketch but using the prior CAN library as a base.
    (For the current non-working EMAC library I used the new Arduino IDE 1.5.2).
  2. I connected the Ethernet error pin (I never connected it before for my prior tests considering it was not necessary).

I will be running some tests before publishing this working EMAC library/Arduino sample sketch in github.

I am so happy that after two months, finally I can see positive results.

Good news Wilfredo.

Two Taijiuinos have been sent to Oz, so that Paul & Rob can continue validation with other PHYs... as they develop their DUE work alike.

However, I do not know how to source the Ethernet PHYs that you folks are developing with. I still have three Taijiuinos in my possession and I'd like to give it a try too.

I have one PHY in my possession,
LCTech ENC28J60 Network Module
here is the info:
http://www.lctech-inc.com/Hardware/Detail.aspx?id=588fbc2e-ecc1-4013-ac35-69bc83bda1fb
On-board ENC28J60-I/SO chip.
On-board 25MHZ crystal.
On-board HR91105A network interface.
3.3V power supply pin.
Size: 56(mm) x34(mm).

Is anyone doing any work with this one?

Wilfredo, that is good news so far.

As you have read in the post above, Peter has kindly organised for two Taijiuino's for us to assist in the testing phase.
I have been in contact with the Russian supplier of the Davicom AS-DM9161 PHY module and am organising two of these modules to be sent to me as well.

As well, I am currently researching the preferred Micrel KSZ8081RNA PHY chip and organising the components to make up a test board of this PHY. I am thinking of mounting the Micrel PHY and its required components using a xQFP Protoboard from Dangerous Protoboards - DP.

Peter, the ENC28J60 module is much like the Wiznet 5100 Ethernet shield commonly used with Arduino 8 bitters.
The chip used on that board is a Ethernet and PHY in one, and communicates with the micro-controller via SPI and as such it has rather limited capability in compassion.

Using the EMAC on-board the SAM3X together with the PHY's we are looking at will provide far greater performance.
I would go so far as to say, Ethernet performance and capability like we have not seen on the standard Arduino platform as yet.

With the SAM3X EMAC located internally on the processor AHB Bus via a DMA controller, we should have the opportunity to support sustained fast Ethernet data transfers with quite low CPU overhead.

In contrast, the existing Arduino Ethernet shields need the processor to move each byte of data in and out of SPI which is connected to the Ethernet shield, thus preventing a lot of anything else happening at that time for the cpu.

Wilfredo, can you elaborate more with details of what tests you have been successful with so far please.
Are you ready to set up the git for it so we can start to look at a testing program and documentation.


Paul

Hello Paul,

As you have read in the post above, Peter has kindly organised for two Taijiuino's for us to assist in the testing phase.

One of my karmas to Peter was very little for his pro-activity. Thank you Paul!

I have been in contact with the Russian supplier of the Davicom AS-DM9161 PHY module and am organising two of these modules to be sent to me as well.

By the way, I was drawing today a schematic of my current Taijiuino/DM9161 system showing the wiring. It is working OK 'as is'. Here a picture:

You can download my pdf file with better definition in the link below.

As well, I am currently researching the preferred Micrel KSZ8081RNA PHY chip and organising the components to make up a test board of this PHY. I am thinking of mounting the Micrel PHY and its required components using a xQFP Protoboard from Dangerous Protoboards - DP.

I found an evaluation board literature based on the KSZ8081RNA that can help you. Here the link:

http://www.micrel.com/_PDF/Ethernet/hw_designkit/KSZ8081RNA_RND/

And other link to the KSZ8081RNA datasheet that I assumed you already got.

http://www.micrel.com/_PDF/Ethernet/datasheets/KSZ8081RNA-RND.pdf

Peter, the ENC28J60 module is much like the Wiznet 5100 Ethernet shield commonly used with Arduino 8 bitters.
The chip used on that board is a Ethernet and PHY in one, and communicates with the micro-controller via SPI and as such it has rather limited capability in compassion.

Using the EMAC on-board the SAM3X together with the PHY's we are looking at will provide far greater performance.
I would go so far as to say, Ethernet performance and capability like we have not seen on the standard Arduino platform as yet.

With the SAM3X EMAC located internally on the processor AHB Bus via a DMA controller, we should have the opportunity to support sustained fast Ethernet data transfers with quite low CPU overhead.

In contrast, the existing Arduino Ethernet shields need the processor to move each byte of data in and out of SPI which is connected to the Ethernet shield, thus preventing a lot of anything else happening at that time for the cpu.

I am happy you can see the meaning of this small 'cornerstone' as the beginning of a huge building.

Wilfredo, can you elaborate more with details of what tests you have been successful with so far please.

I am pretty much done with the tests. There is not much to test because the sketch is very simple as you may have noticed for the previous
non-working EMAC library. Basically, the sample demonstrates how to configure ans use the EMAC peripheral enabling the Taijiuino to respond to a ping
command send by the host computer.

Software:
Packet tests:

  • Send ICMP ECHO requests to get response from Due/PHY system after being PING'ed.
  • Send ARP requests to get reply with MAC address.
  • Error detection by simulating lost of communication.

Hardware:

  • Direct connection computer <-> Due/PHY system using cross-over cat cable.
  • Connection via network computer <-> switch <-> Due/PHY system

All the tests have run OK with few data reading inconsistencies related to the IP Dest Address. This may be caused because my wires are not short.
But again, in general, the library is doing the job.

Are you ready to set up the git for it so we can start to look at a testing program and documentation.

The EMAC library is very raw now. I didn't want to touch it waiting for communication. No that that has been solved,
I have planned to build at least the EMAC class before released it (I am trying to get support from Atmel to gain some time).
Bottom line, I should be publishing the Emac library by the end of this week.

Let's continue braking a leg!

-Wilfredo

EMAC_PHY1_wo_rst.PDF (121 KB)