Hi, My research into my embedded webserver project is going in circles. I need to find some way to connect the PIC to an ethernet controller before I attempt to write a working TCP/IP stack.
I have a 32bit 5volt PCI ethernet card. Is it possible to connect the PIC chip to just a few of the ethernet card's pins and get it to work?
1) Can it be done?
2) What is the minimum number of pins needed to receive data from the PCI ethernet card?
3) Can anyone suggest a better way to connect to ethernet? Note : I'm sticking with the PIC.
You're probably better off getting an ethernet controller meant to be used with microcontrollers than trying to use one that was meant for a general purpose CPU. I mean you're tryng to connect an 8-bit PIC to a 32-bit bus card. I have no idea what is involved with PCI protocols in just trying to talk to the chip, but I'm guessing that you are surely looking at having to load several 8-bit latches just to talk to the card.
I'm sure there are Ethernet controllers that are meant for use with 8 or 16-bit CPUs. I think some even use I2C or SPI to talk to the microcontroller. Of course, if your goal really is to write your own TCP/IP stack, then some of those chips might be more than you need as some, like i2Chips' 3100, already have a TCP/IP stack built-in.
Probably not. PCI is a really fast, complex interconnection system. It'll simply be too complicated for you poor little PIC to handle.
Don't even try.
Sure. Here's a complete package you all your problems:
formatting link
Describes exactly what you want to do and for the same reasons. You have the right idea (attach a PC NIC to the PIC). But the wrong bus. If you downgrade to ISA, then it becomes doable.
So now your problem is locating a suitable ISA card.
Can't help you with pci stuff but there are stacks of resources about connecting microcontrollers to the net.
Try the following:
formatting link
formatting link
formatting link
formatting link
formatting link
formatting link
--
Wing Wong.
Webpage: http://wing.ucc.asn.au
FAQs about me:
Are you and undergrad?
Yes
Are you looking for work and do you want to work for us?
Yes, but only if it pays.
Are you insane?
No, not at the moment.
More than you've got. Most PCI network cards act as bus masters, i.e. they control the PCI bus to transfer the data into PC memory at high speed. It is difficult to imagine how this could work with a PICmicro.
Many designs use a Realtek RTL8019AS ISA-bus chip, as this was adopted by Microchip for their PICDEM.net PICMicro Ethernet board, see
formatting link
Appendix A of this manual has the circuit diagram, which works with a PIC16F877 or PIC18f452; the latter is recommended as the larger RAM makes TCP/IP development easier.
Various PICmicro prototyping boards are available that use the same circuitry, but if you really want to build your own then look in a computer surplus shop for an old ISA networking card using the RTL8019 or 8019AS; you can even solder wires directly to the gold-plated ISA bus connector pads.
I think that writing your own TCP/IP stack is a laudable idea, but don't underestimate the work involved; my book "TCP/IP Lean" (now in
2nd edition) was written specifically to help in projects such as yours, and comes with source code that is directly compatible with PICDEM.net type of boards.
I'm surprised no one has even mentioned that PCI is a reflection wave technology, depending on unterminated lines and very special driving requirements. 1-2ns clock skew (33MHz is 2ns, 66MHz is 1ns), etc.
the only reason i was looking at pci was because i had a pci ethernet card i yanked out from my old computer. I had seen PICs connected to ISA ethernet cards and figured connecting a PCI shouldn't be all that difficult. I even found & downloaded the pci specification from a website.
sadly connectiing an 8 bit device to a 32 bit device is not to be.
btw i have that guy's book TCP/IP Lean which i only just started reading. Its got sooooo much info. Iits a wonder how he managed to figure all that out in a human's lifetime.
Why bother with PCI? Your PIC is not going to saturate even the ISA bus.
And unnecessary.
My guess for port pins: For ISA, 16 data, 10 addresses and 5 controls. For PCI, 32 data/addresses and 5 controls. plus other hard wired addresses.
Depends on the chip, it could implement polled mode. Of course, you have to ignore all the plug and play junks.
If you must do it, an FPGA with 2K static ram buffer. We have a 100T partial core in VHDL. We can build you a PIC w/ a 200,000 gates FPGA for approx $50 each. We are doing it for an AVR. You have to port it to the PIC.
you're right, its undoable. there's no way 4 latches (8 bit x 4 = 32) could bang out their data all in one instruction cycle. It would be BANG BANG BANG BANG... instead of just one (big) BANG. basically it would be a gang bang.
what is needed is an 8 bit mcu with a built in ethernet controller, a tcp/ip stack chip inside, 64kb of internal memory and selling for a dollar a piece.
Some people made an embedded webserver with an AVR and an old ISA based NEC2000 card they picked up for a couple of dollars in an article in Circuit Cellar several years ago. If they could do it with an AVR, it shouldn't be too great shakes to convert to a PIC. I think the original circuit used an '8515 device.
I think that your best bet is to try using one of Digi's ConnectME modules
formatting link
I have used these devices before and they work very well. The basi premise is that the ConnectME is a serial-to-ethernet converter and micr web server built into a device the size of an RJ-45 connector (like sugar cube). They also have a WiFi version where the RJ-45 connector i replaced with an antenna. If you are already accustomed to doing seria communication with the PIC, then this will be seamless. There are couple of ways to interface to the PIC via ethernet with the ConnectME:
Install Digi's virtual COM port drivers on any computer and you ca access the device as if it were a typical COM port. If you have tw devices, you can also set them up for "tunneling", where they will onl communucate with each other, as if they were using the Ethernet network a a really long serial cable.
The ConnectME contains also a simple web server and space to stor custom web pages and Java Applets. So, knowing the IP address of th device (which is user settable, as are many settings, from a administrator page built into the device), you can access it with any we browser. You could then have it serve up a page with an embedded apple which talks to your PIC via the serial port on the ConnectME. To the en user, it appears that you are communicating with the PIC directly throug the web browser.
Actually, the Digi ConnectME development kit includes some sample code an a test applet to do exactly this. My advice is, don't re-invent the whee and write a TCP/IP stack ... they have already done that for you!
Hope it helps!
This message was sent using the comp.arch.embedded web interface o
I don't want to spoil your fun writing a TCP/IP interface, however take a look at the Microchip ENC28J60 device. They have written a (free) C-source TCP/IP stack + server for PIC18, interfacing to this device. It is an SPI-controlled 10base T interface IC. For the hobbyists out there - you can get it in DIP!
All you have to do is choose the correct PIC and compile the code. Works out of the box. You will need to purchase/obtain the MPLAB-C18 compiler however the demo should be fine for this purpose.
I don't have access to the original message. So I'm answering it here.
Hello.
Is the objecting an embedded webserver? Or to work on a TCP/IP stack?
The reason I'm asking this question is that this project has already been done.
Not PCI. There's a lot of complexity there. However you're on the right track. Simply drop down a generation in bus interface to ISA. Then you have the plan.
Not PCI. Not without a PCI bridge. It'll be more trouble than it's worth.
We're not talking PCI.
Yes. Use an ISA card.
No problem. It's a PIC solution. A winning Circuit cellar embedded systems project by Ed Cheung. You can find an overview of the project here:
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.