View previous topic :: View next topic |
Author |
Message |
arunb
Joined: 08 Sep 2003 Posts: 492 Location: India
|
Is it possible to interface an ENC28J60 to 16F877A mcu ?? |
Posted: Thu Dec 14, 2006 10:30 am |
|
|
Hi,
Compiler:PCM
MCU:16F877A
Is it possible to use an ENC28J60 with a 16F877A or 16F648A mcu ?? or do I need an mcu with a larger RAM ??
Also can I implement a webserver using the ENC28J60 ??
thanks
arunb |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
Re: Is it possible to interface an ENC28J60 to 16F877A mcu ? |
Posted: Thu Dec 14, 2006 5:25 pm |
|
|
arunb wrote: | Hi,
Compiler:PCM
MCU:16F877A
Is it possible to use an ENC28J60 with a 16F877A or 16F648A mcu ?? or do I need an mcu with a larger RAM ?? |
Yes you could but you would be making things very very difficult for yourself. I believe a far more productive path is to upgrade to PCH and use a pin compatible PIC like the PIC18F4620 with a LOT more RAM and Program memory.
Quote: | Also can I implement a webserver using the ENC28J60 ?? |
Yes but the current version of the Microchip stack is relatively large and beyond the resources of the 16F for implementing a WEB server for both RAM and Program Memory requirements but their is noting to stop you implementing you own stripped down stack. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
![](templates/subSilver/images/spacer.gif) |
arunb
Joined: 08 Sep 2003 Posts: 492 Location: India
|
RE |
Posted: Thu Dec 14, 2006 8:15 pm |
|
|
Hi,
Thank you for the reply.
Actually I just want to interface my applications with a LAN network, just for this application do you think a 16F877A will do the job ??
I have been reading some datasheets of ENC based interface products (example: LJCV electronics; nic28) and there it is mentioned that any mcu could be used, no restriction on RAM or program memory was stated...
thanks
arunb |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Thu Dec 14, 2006 8:34 pm |
|
|
arunb wrote: | Actually I just want to interface my applications with a LAN network, just for this application do you think a 16F877A will do the job ?? |
The 877A can definitely be used for network applications but naturally you are restricted by the resources of the hardware platform. In your first post of this thread you mentioned using a web page. This implies you need HTTP running on top of TCP. There are stateful protocols which requires RAM in the PIC to be used to maintain state. You also need sufficient resources to interface with the Ethernet controller.
If your requirement was not so ambitious, for example if you were to use UDP to send information between PICs or between a PC and a PIC, then a far simpler implementation of the stack could be realised. The original PICDEM.NET from Microchip shipped with a PIC16F877 processor. It talked to a Realtek controller as opposed to an ENC controller but the driver complexity and code size if of the same order for the ENC processor.
Quote: | I have been reading some datasheets of ENC based interface products (example: LJCV electronics; nic28) and there it is mentioned that any mcu could be used, no restriction on RAM or program memory was stated... |
You missed the "subtle" obvious. All applications they discuss assume you are using the Microchip stack ver 3.x. This stack is ONLY available for the C18 and C30 compilers - which naturally requires a PIC18F class processor, a dsPIC or PIC24F processor.
So yes, you can use any PIC supported by the C18 and C30 compilers - all of these PICs have significantly more RAM and better architected RAM access architecture than the 16F family. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!
Last edited by asmallri on Thu Dec 14, 2006 9:16 pm; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
arunb
Joined: 08 Sep 2003 Posts: 492 Location: India
|
RE: |
Posted: Thu Dec 14, 2006 8:50 pm |
|
|
Hi,
Do I need to implement a stack for even an ethernet interface ?
I won't be needing the web server...
thanks
arunb |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
Re: RE: |
Posted: Thu Dec 14, 2006 9:39 pm |
|
|
arunb wrote: | Do I need to implement a stack for even an ethernet interface ?
I won't be needing the web server... |
Well the term "stack" is a bit loose. If you wanted to implement a network transport protocol, such as UDP, it runs on top of IP which in turn runs on top of the Ethernet MAC layer. This is a protocol stack but your software does not need to be architected as such.
I sell the source code for some UDP client / server demonstration applications that use the ENC controller available in CCS and C18 implementations. These applications implement a minimalistic stack - they do not use the Microchip stack or drivers. I have a stripped down server only version - this version could be more readily ported to the 16F family because it requires far less RAM (for example, no ARP cache required).
I also have Ethernet bootloader drivers for 18F series PICs with RealTek or ENC controllers and for the PIC18F97J60 family of PICs with embedded controllers. These are UDP server only implementations using UPD as the transport and are coded in assembler. I have a PIC16F877 implementation of the bootloader (the original platform used for development) but did not commercialize it.
I have been developing Ethernet based PIC projects for several years. My first such product predated the original PICDEM.NET and based on the PIC16F877 and coded in assembler with my own stack and drivers and, as such, I have first hand knowledge in developing Ethernet applications with 16F processors. If you are after a challenge and some fun then this is a reasonable platform. However, if this is a commercial product, then you have to factor in the significantly increased development and debugging time associated with trying to fit and maintain your network application code into a PIC with very limited RAM and a RAM access architecture that is very inefficient.
Naturally the 16F family will only achieve half the effective network throughput of the 18F family with the ENC controller. This is because the 16F runs at 20MHz and the 18F at 40MHz which gives an SPI bus spped for interfacing to the ENC of 5MHz and 10MHz respectively. At 5MHz, you then have the problem that ENCs REV 4 and below will not work reliably at the SPI clock speed. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
![](templates/subSilver/images/spacer.gif) |
Douglas Kennedy
Joined: 07 Sep 2003 Posts: 755 Location: Florida
|
|
Posted: Fri Dec 15, 2006 7:59 am |
|
|
No you don't need a stack to run ethernet. All ethernet packets have a preamble that the hardware provides a header with the destination and sender MAC address ( botth six bytes each) and a two byte type field ( a.k.a SAP or service access point) followed by your payload data that you provide. There is a minimum size in bytes and a maximum size for your payload data (46-1500) at the end there is a 4 byte CRC
The internet protocols (IP) are merely added features and protocols wrapped inside the basic ethernet layer identified with a 0x800 type value. You could even use the type field as the length field for your payload but it's better to pick your own type code and use the first few bytes of your payload to indicate it's length |
|
![](templates/subSilver/images/spacer.gif) |
arunb
Joined: 08 Sep 2003 Posts: 492 Location: India
|
RE: |
Posted: Fri Dec 15, 2006 9:58 am |
|
|
Hi,
I would like to use the ENC connected to a PIC (this PIC contains all the implementations for ethernet access).
These two devices will become a module that can be used to interface with my controller modules or cards. The interfacing between the module and the controller is done serially.
When the controller needs to send data, it sends the data to the ethernet module serially, the ethernet module PIC uses the appropriate protocols to send data over the LAN network.
The same process is used to receive data.
In this context do you think the 16F877A has the necessary resources ??
thanks
arunb
The |
|
![](templates/subSilver/images/spacer.gif) |
Douglas Kennedy
Joined: 07 Sep 2003 Posts: 755 Location: Florida
|
|
Posted: Fri Dec 15, 2006 12:38 pm |
|
|
Both the CCS stack and the Microchip stack implementations involve simplifications on the full protocols. Ex TCPIP calls for packets to be resent that aren't received correctly and received out of sequence packets are to be resquenced. With a PIC then implementing this would require additional RAM both to store outgoing packets until a confirmation is received and to store incoming packets until a true sequence is there( this is RAM in addition to the ring buffer the ENC provides) So the simplified Microchip and CCS code assumes true receipt and true sequencing. With the resources you have available you need to pick what will fit. You must have the MAC layer so first start there. What you need to add depends on what you know about your LAN setup. The IP protocols provide ways to discover an unknown MAC address. Resolve web names to IP addresses handle overspeeding of the receiving device by window control provide additional information of the status of the connection provide for sockets etc. At some point you have to pick and choose since not all the code will fit into the 16F877A. If you can't build up the code layer by layer yourself them you are much better served by using an 18Fxxx with the maximum of program space and the most RAM ( Ex 18F8720) and use the CCS stack. |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
Re: RE: |
Posted: Fri Dec 15, 2006 6:39 pm |
|
|
arunb wrote: | In this context do you think the 16F877A has the necessary resources ?? |
I used an 877 with a Realtek controller to interface between a data capture engine via a high speed serial interface and a remote DSO application running on the PC. Data was tranfered to and from the PC using UDP (not TCP). This mechanism was used to drive the serial interface at 625kbps.
Future versions of the product migrated to the 18F252/452 family which, percause of the higher CPU formance and superior achitecture were able to achieve 2.5Mbps and were capacle of streaming (supporting this rate continuously). These platforms still use the realtek controller however the ENC will give you an equivalent level of performance.
In this appliocation the PC handles and error detection and correction by sending sequence numbers int the UDP payload and monitoring sequence numbers. This method puts the intelligence at the PC end and is therefore easy to implement the PIC side with limited resources. The Ethernet bootloader also use this mechanism. If youy download the bootloader package from my site you will find an overview of the protocol section to show how to do this.
So to answer your question - can this be done on an 877? Yes
Would I do this for a commercial product? No - you would have to be daft to use such a brain dead processor and waste a lot of development time coding around the architectual limitations of a platform that is not much cheaper than its 18F counter part. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
![](templates/subSilver/images/spacer.gif) |
|