> sansuikyo@gmail.com (Josh Fitzgerald) wrote in message news:<2daefa6b.0407271544.23f48678@posting.google.com>...
>> 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.
>
>
> 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).
>
> http://mp3oe.mine.nu
sansuikyo@gmail.com (Josh Fitzgerald) wrote in message news:<2daefa6b.0407271544.23f48678@posting.google.com>...
> 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.
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).
http://mp3oe.mine.nu
Reply by zalzon●July 31, 20042004-07-31
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 by Tauno Voipio●July 30, 20042004-07-30
"Jeremy Bentham" <jben@iosoft.nospam.uk> wrote in message
news:ucckg0hm5i3t0l42mb3a7dpb8r2p16j0nh@4ax.com...
> Jeremy Bentham <jben@iosoft.nospam.uk> wrote:
>
> >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.
>
> 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.
>
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 by Jeremy Bentham●July 30, 20042004-07-30
Jeremy Bentham <jben@iosoft.nospam.uk> wrote:
>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.
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.
>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.
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 by Anton Erasmus●July 29, 20042004-07-29
On Wed, 28 Jul 2004 10:34:31 -0700, Jim Stewart <jstewart@jkmicro.com>
wrote:
>Anton Erasmus wrote:
>> On 27 Jul 2004 16:44:17 -0700, sansuikyo@gmail.com (Josh Fitzgerald)
>> wrote:
>>
>>
>>>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.
>>
>>
>>
>> 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.
>
>Do you have a link to a US distributor and
>an approximate volume price? I dug around
>and could only find the .kr website.
>
They have a how_to_buy link on the site. They list 3 North American
distributors: The email addresses are:
helen@iinchip.com
sales@ptsi.com
info@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 by Tauno Voipio●July 29, 20042004-07-29
"Grant Edwards" <grante@visi.com> wrote in message
news:41091fb2$0$8085$a1866201@newsreader.visi.com...
> On 2004-07-29, Markus Zingg <m.zingg@nct.ch> wrote:
>
> >>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
>
> If you need a very high data rate, you offload IP and TCP
> header handling into hardware: $$.
>
> > 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.
>
> 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.
>
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 by Grant Edwards●July 29, 20042004-07-29
On 2004-07-29, Markus Zingg <m.zingg@nct.ch> wrote:
>>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
If you need a very high data rate, you offload IP and TCP
header handling into hardware: $$.
> 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.
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?
visi.com
Reply by Markus Zingg●July 29, 20042004-07-29
>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
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