next topic »

[Reply #15 on:]

So after some more testing I was pretty sure the spi voltage had something to do with it. Even just dumping the registers (slower than I can click on a key) and the data would become inconsistent. And so the SPI input voltage problem has been solved. Using a SN74LS08 series AND gate running at 5v. two inputs are tied to the MISO of the ENC and tied to a pull down resistor. The output end up being ~4.5v, which is higher enough than the 2/3Vcc ratio the I/Os require (making 3.3v on the edge). Register readings now seem 100% consistant. I have also replace the 2.7k resistor on RBIAS by a 2.3k as noted in the Rev B5 errata. I definitely can read icmp, udp and tcp packets. More to come

Code:

Time    Eth Address    IP Address
---------------------------------------
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
Received ARP Request
ARP Packet:
Operation   : REQUEST
SrcHwAddr   : 0:16:CB:8B:1:EC
SrcProtoAddr: 192.168.0.12
DstHwAddr   : 0:0:0:0:0:0
DstProtoAddr: 192.168.0.126
Sending ARP Reply
ARP Packet:
Operation   : REPLY
SrcHwAddr   : CC:0:FF:FF:EE:EE
SrcProtoAddr: 192.168.0.126
DstHwAddr   : 0:16:CB:8B:1:EC
DstProtoAddr: 192.168.0.12

NET Rx: IP packet
Time    Eth Address    IP Address
---------------------------------------
d   ::[ch65533]:[ch65533]::[ch65533]  [ch65533].[ch65533]..
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
entering netstackIPProcess
NET Rx: UDP/IP packet
-1012UDP packet, len: 50
C1

  NET Rx: IP packet
Time    Eth Address    IP Address
---------------------------------------
d   ::[ch65533]:[ch65533]::[ch65533]  [ch65533].[ch65533]..
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
entering netstackIPProcess
NET Rx: TCP/IP packet
Rvd tcp Packet: len=68
NET Rx: IP packet
Time    Eth Address    IP Address
---------------------------------------
d   ::[ch65533]:[ch65533]::[ch65533]  [ch65533].[ch65533]..
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
entering netstackIPProcess
NET Rx: TCP/IP packet
Rvd tcp Packet: len=68

(the packets were sent using ping, nc and nc -u)

[Reply #16 on:]

Awesome.  Keep us posted.

[Reply #17 on:]

More fooling around the registers (and I might have removed my way off specs ferrite bead meanwhile) and... this happened http://pastie.textmate.org/private/qrg8ojxbtjsjqyh1bmc8fa. And then it happened again! The transmitted packets, I never received anything though. Snooping with wireshark reveals that both packets failed CRC which might be why nc/ping didn't pick them up. But the Arduino did and it definitely sent!

[Reply #18 on:]

The latest code can be obtained here. Have fun

[Reply #19 on:]

I'm in the process of seeing what I can do with µIP, it seems to have better checksum handling at least. And I wouldn't mind switching as µIP has a much better stack and properly support tcp.

EDIT: Doesn't seem like such a good idea. uIP is a little too feature complete for a mega168. And I won't even talk about OpenTCP. Looks like I'm going to stick with AVRLib.

[Reply #20 on:]

The code is now under version control using SVN. You can checkout a copy at svn+http://svn.mlalonde.net/Ethduino or browse the repository on the Trac site. Packets are still not getting received by applications, but they are getting sent (i can tcpdump them). As far as I can see, the checksum is definitely to blame. If anyone has an idea about this I'd really like to ear. As for running on the Mega168, so far so good... there's a good 6~8k free without all the debugging stuff which laves enough room for some business logic. (there's still definitely more things that could be done to reduce code size even further)

[Reply #21 on:]

I sorry if this post is rather dry when it should be rather high, but I don't have anything to show (I don't have LCD at hand to do the ethernet LCD or something). But here it is...

I have the honour to present you the very first ping replies!

Code:

PING 192.168.0.126 (192.168.0.126) from 192.168.0.12: 56 data bytes
64 bytes from 192.168.0.126: icmp_seq=0 ttl=64 time=1.341 ms
[...]
64 bytes from 192.168.0.126: icmp_seq=4 ttl=64 time=1.245 ms

--- 192.168.0.126 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.235/1.283/1.341/0.039 ms

I've written functions to allow using the ENC's internal checksum functions. And it worked! This is an issue however because as noted in the errata #15, use of the DMA for checksuming can cause drop packets. I guess for some this would be fine; it has the added advantage of having a zero footprint in the stack! Either ways this is a huge step as it confirms that the hardware is up and running and that most of the software runs fine!

There are no words to explain my joy! ;D ;D ;D

[Reply #22 on:]

now that's sounding nice.
this is the beginning of a new chapter in arduino's history  

congratulations, i hope it will not take too long for a little http functionality.

best, kuk_

[Reply #23 on:]

Congratulations!  I hope you plan to share your hard work and success with the rest of us by posting a schematic and some code.  

I don't recall what your final application is?  You're probably quite close to a working serial proxy app right now; a TCP connection (to allow HTTP) may be a bit more work...

-j

[Reply #24 on:]

Kuk: at this stage there is no plan for TCP support. The mega168 is small and TCP processing is heavy. I'm not saying it won't come but there are other priorities. Just like kg4wsv was saying were closer from an EthProxy than anything... I will post details (schematic, doc, etc) very soon. Meanwhile, the code is available above.

[Reply #25 on:]

And finally, in pictures ^-^


(Click for full flickr experience)

There's a lot more info, access to code and bug listing on the trac site.
There's still a lot of documentation work to be done, but it'll come!

[Reply #26 on:]

Hi,
after reading along, I'd like to try the Ethuino, too.
Do you think I could start with this module here :
http://www.olimex.com/dev/enc28j60-h.html

Eberhard

[Reply #27 on:]

Great !
I just saw there were someone playing with an Ethduino... Seems that I know this guy !
I can't wait to try this at home.

http://www.makezine.com/blog/archive/2007/09/ethduino.html

[Reply #28 on:]

It does look like you do

How does a shield sounds like? I'm trying to see if it'd be worth setting up a kit... let me know what you guys think!

[Reply #29 on:]

A shield sounds good, but IMO it would need to be "stackable" or otherwise expandable.  An ethernet Arduino is cool and all, but what will you do with it?  I'd interface sensors or buttons or an LCD or something, and that something needs a place to be attached.

It would be nice to be able to get a little kit that had the "magnetics" in it.

This does  sound a lot like the device from Olimex that was mentioned previously (although their price of US$34 sounds a bit steep to me).

just my $0.02.

-j