Ethernet speed on a PIC

[Rusttree]

I've been looking around the internet for ideas on connecting to an ethernet connection using a PIC. A couple of project descriptions I've seen talk about programming the PIC directly to transmit over the ethernet cable. Assuming a speed of 10Mbs, could any PIC ever acheive a transmission speed that high? Even the fastest PICs available, 32Mhz, can only actually execute instructions at 8Mhz (32Mhz divided by 4 oscillations per instruction).

So are these projects actually using a blackbox device between the PIC and the ethernet cable (an ethernet controller of some type)? Or is it possible to transmit at a slower data rate over a standard ethernet connection?

-Dan

 

[blueroomelectronics]

The fastest PICs available are around 40MIPs.

 

[edeca]

All the projects I have seen use either a module or control chip. PIC chips will run faster with a crystal, but you are correct the the instruction rate is 4x slower and therefore even an 80Mhz crystal only gets you a 20Mhz instruction clock.

Check **broken link removed** and SparkFun Electronics - Ethernet Web PIC Development Board.

 

[smanches]

The dsPics run at a 2:1 osc/instruction frequencies. And since they are a 5 stage RISC pipeline, you get 40 MIPS from 80Mhz clock.

The 32 bit version is 80 MIPS.

The Ethernet interface chip takes care of the 10Mbps aggregate rate, so the PIC doesn't have to worry about it.

 

[Rusttree]

Ah, I was looking only at the 8-bit 16F family of MCUs. Looks like there are definitely PICs that can handle the speed.

So, theoretically, there's no reason you couldn't fully program a PIC with a TCP/IP stack and directly connect it to an ethernet hardline (with voltage-leveling components in between, of course). On, say, a 40 MIPS PIC, you'd have to take care that you don't use more than 4 instructions per databit during the transmission.

 

[DirtyLude]

Ah, I was looking only at the 8-bit 16F family of MCUs. Looks like there are definitely PICs that can handle the speed.

So, theoretically, there's no reason you couldn't fully program a PIC with a TCP/IP stack and directly connect it to an ethernet hardline (with voltage-leveling components in between, of course). On, say, a 40 MIPS PIC, you'd have to take care that you don't use more than 4 instructions per databit during the transmission.

You need a proper MAC/PHY layer. You can't just connect an ethernet cable directly to some GPIO pins, even with level converters. I know some ARM chips have inbuilt MAC/PHY's, I don't know about PIC's, because I don't use them.

 

[blueroomelectronics]

Some PICs also have Ethernet hardware.

 

[Rusttree]

Some PICs also have Ethernet hardware.

I know, but I'm trying to avoid that if I can (for now). I'm interested enough in TCP/IP and such to learn how it all works at a low level. If nothing else, it would be satisfying to send a ping request to my ISP and get a response back.

 

[edeca]

You won't want to implement the physical layer yourself. What Bill refers to is that you can either use an external transceiver or use a PIC that has it built in. In either case you will need a fast enough PIC with RAM that can be used as a buffer.

 

[Rusttree]

What about the physical layer would be difficult/impossible to do on a fast PIC with a lot of RAM? I understand what the physical layer does conceptionally, but I'm unclear on some of the low-level details. Particularly, why does any device on a local network care what the MAC address is of any other device? Why aren't the unique IP addresses enough for all the devices to talk to each other?

 

[blueroomelectronics]

Again just use a PIC designed for Ethernet. The 18F67J60 is an excellent start.

 

[Rusttree]

Again just use a PIC designed for Ethernet. The 18F67J60 is an excellent start.

Right, but as I wrote above, I'm trying to avoid buying a blackbox solution. I'm actually interested in learning the low-level communication protocols. Maybe it's not possible on a PIC alone, but I want to at least fully understand why it's not possible before I buy someone else's hardware.

I realize this is a uC forum and not a networking forum, so this is really the wrong place for my last question anyway. I do appreciate the responses, though.

 

[Nigel Goodwin]

Right, but as I wrote above, I'm trying to avoid buying a blackbox solution. I'm actually interested in learning the low-level communication protocols. Maybe it's not possible on a PIC alone, but I want to at least fully understand why it's not possible before I buy someone else's hardware.

I realize this is a uC forum and not a networking forum, so this is really the wrong place for my last question anyway. I do appreciate the responses, though.

Why not just google for it?, there are a number of PIC Ethernet projects on the net - basically using chips off old ethernet cards.

 

[Rusttree]

Why not just google for it?, there are a number of PIC Ethernet projects on the net - basically using chips off old ethernet cards.

That is what I originally did. And those are the kinds of projects I found: using salvage parts or store-bought, blackbox ethernet controllers. The intent of my original post was to see if a sufficiently fast PIC could handle the job by itself. There were a few projects I found that seemed to indicate they were using just a PIC, but they didn't provide any details. I'd imagine they were also using an intermediary, ready-made device to interface with the network.

 

[Nigel Goodwin]

Don't forget, while PIC's may be very fast, they generally don't have much in the way of RAM.

 

[smanches]

Even if you do not use a transciever, you will still have to build one. If your intent is about learning to build transceivers, then by all means go ahead. If your intent is to learn how to use a PIC to do network communication, then just buy a transceiver and don't waste time trying to reinvent the wheel.

Either way you want to do it there are external components needed: level shifters, differential voltage comparators, pulse transformers, etc. You can't do it with just a PIC alone.