next topic »

[Reply #75 on:]

Hope it could make things easy

[Reply #76 on:]

Hasn't helped me any.

_____
Rob

[Reply #77 on:]

swseansw,

Do you provide a magnifying glass.
Or some details about what you are suggesting could hopefully make what easy?

_____
Paul

[Reply #78 on:]

Hope it could make things easy

An little bit barely an explanation.

[Reply #79 on:]

This module is designed with reference to the Atmel SAM3X-EK board,  and has a microSD card slot on it. The PHY chip is DM9161.

This module is in testing now.  Detail information will be delivered when the testing is finished.

The testing process is not going well.
I compiled the beRTOS SAM3X-EK examples to test this DUE Ethernet module with Taijiuino DUE.  Unfortunately, something was wrong, the module didn't preform as expected. Now i want to open the beRtos's DEBUG option to see what happened. But i don't find the correct way.

I want to find out whether the DM9161 is working, does anyone know which SAM3X8E's register should i check.
How can i open the tcpip function's debug option.

[Reply #80 on:]

Hello,

I want to clarify that the emac class files (emac.c, emac.h) ARE NOT contained in the current Arduino IDE version 1.5.2.
For those interested to get these files, please refer to the following link:

For the emac.h ----> https://github.com/cmaglie/Arduino/tree/ide-1.5.x/hardware/arduino/sam/system/libsam/include
For the emac.c ----> https://github.com/cmaglie/Arduino/tree/ide-1.5.x/hardware/arduino/sam/system/libsam/source

Regards,
Wilfredo 

[Reply #81 on:]

I agree that we will end up having a number of different Phy drivers to incorporate within an overall "Due Ethernet" library. The SAM3X-EK example that I modified has ARM(CMSIS), ATMEL(ASF) and LwIP code. It might be better to look at a LwIP or another stack without all the rest and see if its possible to add Due support, we would then benefit from further developments of the LwIP stack, rather than a Arduino specific library that once working may not be further developed.

Thoughts?

[Reply #82 on:]

I have been lurking, watching this thread from the start, now its time for me to try with due-ethernet!   I have been working on a custom diy board which has onboard micrel 8051 phy and magjack.    Finally got one built up and it passed the blink test.  Now on to try and follow the leader with the lwip example.

[Reply #83 on:]

Hello komby,

Wow, I am amazed with what you have pulled off. Nice work!

This is getting really good. So far, you are the fourth developer with a Due DIY board-oriented that includes the Ethernet phy interface (floating or embedded).

Here the list (with no order of preference but chronological for me):

1- as-kit.ru new AS-SAM3X board (also includes the CAN bus embedded interface)

2- elechouse.com new Taijiuino R2 version.

3- Graynomad's Black Diamond (also includes CAN bus and other communication interfaces).

4- komby (web site?)

I am happy that this initiative has already gained a great deal of software/hardware support.

Thank you,
Wilfredo

[Reply #84 on:]

Hello komby,

Wow, I am amazed with what you have pulled off. Nice work!

This is getting really good. So far, you are the fourth developer with a Due DIY board-oriented that includes the Ethernet phy interface (floating or embedded).

Here the list (with no order of preference but chronological for me):

1- as-kit.ru new AS-SAM3X board (also includes the CAN bus embedded interface)

2- elechouse.com new Taijiuino R2 version.

3- Graynomad's Black Diamond (also includes CAN bus and other communication interfaces).

4- komby (web site?)

I am happy that this initiative has already gained a great deal of software/hardware support.

Thank you,
Wilfredo

Thanks Wilfredo.  To be fair I'm still unsure if its pulled off yet!...I just soldered the first one together yesterday ... That said I am working on making sure it does work.    I do have a little bit of information about it on komby.com but I was planning on verifying the board is working before publishing the eagle files.   If any of the people on the thread who are working on the Ethernet Library and are interested in one of the prototype boards PM me.   I made a lot of sacrifices on the board to get the ethernet onboard as well as some nRF24L01 headers so it may be a bit specialized for common use...

[Reply #85 on:]

Please allow me to tell everybody who might be interested in Due-Ethernet. You could find a hardware kit for developing this libaray here:
On ebay click here
On official web click here
We hope this kits could help those software guys who are less patient and sick of handing wires.

[Reply #86 on:]

Took a look at it.  This hardware kit can't be used simultaneously with your CTE LCD shields. Bummer.  Split decision... lots of wires for the LCD or lots of wires for the Ethernet.  Oh well. The DUE platform will get there eventually.

[Reply #87 on:]

We know it is not perfect. While designing it, we didn't consider its compatibility with other modules in hardware. The best choice would be a Due shield which contains PHY chips. But we think we should do that later. As this library is not finished yet, a small and cheap PHY module would be better. That's how it comes. Sure later there will be a shield for Due to have all on it.

[Reply #88 on:]

Yes, you are correct, I didn't mean it as a criticism.  DUE is such a work in progress... I appreciate you providing this module which eliminates all of the wiring for folks trying to develop the Ethernet libraries.  

Somewhere down the road, we will all figure out how to make the UI, Comms, and I/O portions all play nice together on DUE. Which will give us feature parity with UNO, but higher performance and greater capabilities.

I've looking forward to seeing what the folks down under will have when they release Black Diamond.

[Reply #89 on:]

I've looking forward to seeing what the folks down under will have when they release Black Diamond.

Me to

The project is alive and well, there has been a lot of changes in the last 2-3 weeks, often due to input from interested parties. We froze the design about 3 days ago then had another bright idea, oh well better to try and get it as right as possible.

When implementing various comms, EMAC, SD, and external memory interfaces there are not many pins left for GPIO so don't expect a huge IO pin count. That said what we do have should be quite robust, not just raw pins connected to the big bad world.

I'll post more details on the Black Diamond thread soon.

______
Rob