10/100 Ethernet Chips

I am seeking recommendations for 10/100 Ethernet controller chips for the embedded environment. The microcontroller I will be using is the PIC18F8720, an 8-bit chip.

Thanks.

Reply to
Josh Fitzgerald
Loading thread data ...

Here's a couple of good links ...

formatting link

formatting link

EDTP has some good stuff for PIC/Ethernet development. Although I don't use PIC, I have the NICki board (CS8900) running with Atmel AVR and Motorola microcontrollers (in 8-bit polling mode).

Regards,

-Pete.

--
+
| http://home.comcast.net/~pete.gray/
 Click to see the full signature
Reply to
Pete Gray

You suppose that PIC will be able to handle data at anything close to wirespeed at 100 megabit/sec?

Reply to
Jim Stewart

No, but it sure cuts down on the time on wire for the packets. Could be important if there were a lot of units in the net and a lot of small packets to move about. As long as you don't need sustained through put an 8 bitter can still benefit from the above.

Jim

Reply to
James Beck

No way, An 8-bit microprocessor will not use the whole 100Mbps network bandwidth, but its not suppose to anyway. Most network device use about 10% of the total network bandwidth allowing other devices to also use the network.

T>

Reply to
garcia916

Use the Wiznet W3100A. It handles the TCP/IP stack itself for up to

4 connections. You only have to handle packets addressed to you.

Regards Anton Erasmus

Reply to
Anton Erasmus

Do you have a link to a US distributor and an approximate volume price? I dug around and could only find the .kr website.

Reply to
Jim Stewart

Of course a cheap switch will accomplish the same thing, and is likely part of the infrastructure anyway (except in the smallest environments).

Reply to
Robert Wessel

In my experience the decision to go with a 10/100 interfaces is based purely on marketing. Even if the device only needs to do a couple packets per second, the marketing people will refuse to sign off on a 10baseT-only device.

There was a reason for this way back when: the very first dumb, dual-speed Ethernet hubs that came out required all ports to run at the same speed. If you plugged in a single 10M-only device, all ports were forced to 10M. I don't think that's been a valid concern for a long time, but you still can't sell marketing types on a 10M only interface.

--
Grant Edwards                   grante             Yow!  Could I have a drug
                                  at               overdose?
 Click to see the full signature
Reply to
Grant Edwards

the biggest problem for reaching such a rate is the CRC computing of the TCP-package, which needs a lot of computing time. I doubt, any available microcontroller can reach more than 2 Mbit/sec. If need very high data rate you'd programm a dsp to implement TCP Michaek

--
Remove the sport from my address to obtain email
www.enertex.de - Innovative Systemlösungen der Energie- und Elektrotechnik
Reply to
Michael Schuster

The TCP checksum is just a sum - no CRC involved. It's computation can be made while transporting data into the output buffer thereby saving loading every byte to send once more before it's transmitted. I agree though that achiving full datarate with a microcontroller is hard.

Markus

Reply to
Markus Zingg

If you need a very high data rate, you offload IP and TCP header handling into hardware: $$.

Even with a 32-bit ARM CPU running at 44MHz, the IP checksum was the main bottleneck in TCP throughput using the BSD network stacks. The C implimentation of the checksum in the BSD stacks is very good, but moving it from C to carefully crafted assembly language improved throughput considerably. But, it's still the bottleneck. It's a 16-bit checksum, so implimenting it w/o 16-bit ALU operations is going to suck.

--
Grant Edwards                   grante             Yow!  Yow! Am I having
                                  at               fun yet?
 Click to see the full signature
Reply to
Grant Edwards

rate

Actually, it's a 16 bit checksum with end-around carries. There is a definite advantage in 32 bit ALU when calculating the checksum: the end-around carries can be added in after the checksum is otherwise accumulated.

Tauno Voipio tauno voipio (at) iki fi

Reply to
Tauno Voipio

They have a how_to_buy link on the site. They list 3 North American distributors: The email addresses are: snipped-for-privacy@iinchip.com snipped-for-privacy@ptsi.com snipped-for-privacy@remostech.com

There was a press release some time ago that Atmel has licensed the Wiznet technology. A ATmega128 with the W3100A functionality would be quite nice.

Regards Anton Erasmus

Reply to
Anton Erasmus

All you need in assembly language is a repeated 16-bit add-with-carry; even an 8-bit microcontroller can do this quite fast if you separate the upper & lower byte totals.

32-bit additions are only an advantage if you're doing the checksum in C. When using assembly language they'd actually be slower than 16-bit, since you have the additional step of adding on the accumulated high-end carries.

Jeremy Bentham Iosoft Ltd.

Reply to
Jeremy Bentham

Oops - I've rightly been taken to task for this sloppy statement; to clarify, 32-bit assembly-language additions give a significant advantage on systems with 32-bit-wide memory; the potential disadvantage occurs when using 32-bit additions on systems with only 8 or 16-bit-wide memory.

Jeremy Bentham Iosoft Ltd.

Reply to
Jeremy Bentham

The requirement is to have 32 bit arithmetic with a no-cost

16 bit operator load, like it is on most RISC processors.

It is less expensive in run time to make straight sums for all 16 bit halfwords in the packet and add the end-around carries afterward: the extra carry addition is saved inside the loop on the expense of doing a little more after the addition loop proper.

It is also to be noted that the endianess does not matter: due to the cyclic nature of the checksum, it can be calculated on a little-endian processor, although it is actually defined as a big-endian sum.

If you're interested, I can mail example code for both options in ARM assembly language (or GNU C with the assembly expansion).

Regards, Tauno Voipio tauno voipio (at) iki fi

Reply to
Tauno Voipio

getting back to the original post, the guy could perhaps use realtek's at RTL8019AS chips. there are boards out there with that chip plus the rs45 (or whatever) ethernet cable connection.

Reply to
zalzon

I would suggest you use the CS8900. It's an excellent 10Mbps all-in-one ethernet controller that work really well in 8-bit mode with just 14 I/Os needed to connect to your 8-bit micro. I used in in my project with an Atmel 8051 micro (AT89C51SND1C - embedded MP3 microcontroller) with great success. It's also very easy to get... you don't have to mess around with smaller distributors, cuz you can get it through newark.com (~10$US I think).

formatting link

Reply to
tjbuick

If your interest lies in the way of the realtek rtl8019as, futurlec sells them for $3.90 US

formatting link
This was designed to be accessed in either 8 or 16 bit mode.

--
Wing Wong.
Webpage: http://wing.ucc.asn.au
 Click to see the full signature
Reply to
Wing Fong Wong

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.