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.
[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) http://www.fieldeffect.info/w/FEZNetwork
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
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.
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
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
I will call in the next day or so. I’ve been otherwise engaged.