Help Sample Code for ENC28J60 , I Can Use Arduino But Domino Not Use
ENC28J60 is not supported and the free ebook explains why this shouldnāt be supported.
To be fair to the OP, the e-book doesnāt really cover it.
A better answer is that the ENC28J60 has no in-built TCP/IP stack. It is a layer 2 device at the media access controller level.
The W5100 chip used in the ethernet shield does have the OSI stack from the transport layer (layer 4) all the way down to PHY.
This means if you need more than raw ethernet connectivity you need to implement the IP layer (layer 3) and the transport layer (Layer 4). Possible, but a challenge. There may not be enough space the the CLR may not be fast enough to process the data.
If all you need is layer 2 connectivity (and you can do a lot with that on a LAN) then you can use the ENC28J60, but you will need to spend a lot of time looking at the datasheet for it.
If none of that makes sense then use the ethernet shield, or do some serious research on networking at the hardware level. I suspect none of would make any sense because one look at the datasheet for the ENC28J60 should have told you that. Stick with the shield.
One question I do have for the GHI folks. The LPC2388 has a MAC on it, although no PHY. Any reason this wasnāt used?
Not enough memory to implent the features?
In comparision to EMX there were no external memory.Only the internal chip memory is used.
Iād be surprised if it was a memory issue.
Microchip have a full TCP/IP stack that fits onto a PIC18F series with plenty of room to spare. Itās about 45k. If you turn on all the bells and whistles it goes up to 100+k, but that includes SSL etc.
UIpdated:
Found this
http://www.ghielectronics.com/forum/index.php/topic,3174.0.html
[quote]Using the internal MAC, you need $3 PHY chipā¦
Using Wiznet would also cost you $3ā¦
So for cost, it is the sameā¦so why did we select Wiznet over PHY? Because, when using a PHY, you will lose too much resources for TCP/IP but if you use Wiznet then you lover very little resourceful.
On larger devices like EMX and ChipworkX, we have millions of bytes of RAM so it is better to have a full blown TCP/IP stack but on USBizi with few kilobytes of RAM, internal TCP/IP is not a good option.
With that said, we have plans on supporting Wiznet internally to the USBizi and so you would be opening/closing sockets just the large devices like EMX and ChipworkX. This is on teh to do list but it will be a while before we get to it. For now, you can use our beta managed driver for wiznet. See this for example (FEZ Domino uses USBizi) Basic Networking for FEZ Domino ā Field Effect, LLC
This is explained in details in our free ebook.[/quote]
To get .NET Micro Framework CLR (the core Virtual Machine) working, you need 300KB+ on your system. www.netmf.com for more details.
Comparing with PIC micros is pretty not fair. As if you are comparing a bicycle to a sophisticated car. Both does the same thing but they are completely different and each one is used efferently.
Of course you can compare PIC18 to LPC2488.
This is a personal opinion.
No one said you canāt. I said it is bad idea and pointed out how the book explains whyā¦basically, wiznet and enc28j60 cost about the same things and wiznet has everything built right in so why use enc28j60?
It would actually be fun to see uIP stack ported to C#. Again, this is good for fun but would be bad to put system resources into something where using wiznet is much better option.
Users are forgetting that there are hundreds of libraries built into USBizi (FEZ core), USB host, FAT file system, USB devices drivers, SD driver, PWM, CANā¦just way more than I can list here. So, adding TCP/IP on top of all that is a possible option but we decided to leave more resources free for end applications.
Not only that, PHY costs as much as the ENC28J60!!! so we are back to the original question of why not just use WIZnet?
Actually, I have an answer, you would not use wiznet if you are providing a TCP/IP stack that is more features than what WIZnet offers. For example, GHI larger devices like EMX have SSL, HTML, DNC, DHCPā¦and many more with 128 sockets simultaneously.
Not correct argument. Our libraries (pointed above) are about 350KB not including TCP/IP stackā¦try to fit that on a PIC.
Either way, comparing PIC ot USBizi is like comparing apples to oranges. Compare ARM to PIC yes, but comparing to USBizi is completely invalid! USBizi (FEZ) is a complete hardware/software packageā¦think of it as you are buying a 32-bit processor + 100 libraries for a very low price and you also get an unlimited free support on top of that free of charge 
Gus,
As regards this particular TCP/IP stack question I would assume you are using the MSSTACK api and layering the socket functions onto the W5100 to reduce the size of the footprint. I would hope then that the functionality is all exposed through System.Net.Sockets and not a custom GHI namespace.
If not then the one promise of using C# is suddenly dead. That the code is not longer portable between devices.
With a custom namespace that is not open source I canāt switch to another device with Adeneo Embedded firmware or the new freescale devices (if we ever see them here again).
We end up with a 2 way case of vendor lock, both the chipset and the .NET vendor. This would be very bad.
The rest of the points you make about tradeoffs are all valid, and really get to the core of the whole .NET Micro framework debate. WIth the CLR you get a Smorgasbord of functionality that is always there regardless of whether the particular application is using it or not.
If a particular application is not using the USB Host, or XML, the TCP/IP stack it is still there taking up space that might be required for the application.
As for comparisions not being valid, I very much beg to differ. In the hobbyist market that may well be the case. $5 or $15 doesnāt mean a whole lot.
In the commercial market pennies on a unit can make or break a hardware downselect. You will be subject to trade studies that will down select vendors. Itās one of the things I do for a living. I select suppliers and technologies.
You are going to need something better that āItās not fairā. Why not? What is my ROI for going .NET and spending more in the hrdware as opposed to native ARM, PIC, AVR, Motorola, Freescal, Rabbit or any of the others? Iāll ask for customer references and your own internal trade studies.
The bottom line is that for any non-trivial application I am likely to need to utilize a bigger or faster device to compensate for th CLR overhead. This costs money.
This begs a serious question. What is the intended market for GHI? If you only plan to serve the hobby community that is fine. Sparkfun started in a college dorm room and is now a 90 person company and a fantastic force for good on the community. That is nothing to be ashamed of.
If you want to serve the industrial community questions on ROI tradeoffs will be there all the time. You need to show me that my spending more on hardware is worthwhile, and you need metrics to back it up.
The API/namespace will be the same standard one with WIZnetā¦that is the plan at lease
Jeremy, if you canāt tell the TinyCLR side of things if a more relaxed site aimed at hobbyist. If you are concerned with commercial production than the GHI site forum might be your best avenue.
On a personal note: you attract more flies with honey than vinegar. Try sweetening your sour tone and see if you donāt find more ideas and helpful hints buzzing about.
Thanks Jeff 
By the way the GHI phone number is right on the website. Anyone can call to discuss their commercial application. Like I said before, if NETMF is not a good fit fir your application then we will just tell you that.
There is no need to stress out this forum
Hi Jeremy
That is a fantastic offer from Gus. If you have a real commercial requirement, pick up the phone and talk to him. I am sure that he can tell you if the NETMF will help you or not.
The TinyCLR ecosystem if mainly for enthusiasts. Dont spoil the experience for the small and growing community here. There are many people out there would would like to get started with embedded and blink a LED or light up the holiday tree. The Domino can help them get started easily and also provide superior debug capability (dont start talking on the Arduino, UBW, etc. now)
If you want portability, please consider a design pattern (the factory pattern maybe) that helps you to swap out vendor classes for a specific pheripheral. This way you should be able to port your code across boards with minimum effort.
All the NETMF is not just the libraries, there are a variery of processors and boards and the implementors are bound to have board specific extensions
HTH
-Rajesh
Gus
I will call in the next day or so. Iāve been otherwise engaged.
Agreed.