Data throughput of embedded ethernet

[snip]

As Willy Wonka once said: "strike that: reverse it." Or something like that. ;-)

--Mac

Reply to
Mac
Loading thread data ...

300KHz * 2 ADCs * 24-bit = 14.5Mbps, including IP overhead, assuming large packets.

Clearly 100Mb is needed; full-duplex always preferred. This is also about 10k packets/sec. I've pushed the ASIX over 20k/sec, so you're in the right range.

Your limiting factor will be the protocol used for the transfer. Behind that, the MCU and the rate it can get packets into the buffer.

UDP is highly recommended, especially if you can tolerate packet loss (which should be 0 anyway for local applications). TCP will cause you nothing but headaches unless you absolutely need to guarantee 100% data delivery. (It'll require a lot of buffer RAM for retransmissions, and a lot more overhead in the MCU, and it may take a chunk of tuning to get it up to the rates you need, even locally.) UDP can also run with payload checksums turned off, further reducing the MCU load.

Then, finding a creative way to load the data directly from the ADC into the Ethernet NIC will be key to how many cycles will be needed on the MCU. (E.g., setting the NIC in bulk write mode, toggling the ADC data onto the bus, and toggling the NIC to latch the bits; a la DMA controller style.)

If the MCU doesn't need to manipulate the data (e.g., even for checksums), you can avoid the overhead of copying it into the MCU and then right back out; this is the most frequent and biggest operation, so it's a big factor. Part of this will be driven by whether the ADC is being read serially or 8/16/24 bits wide, and the size of its buffer (if any). (I.e., if it can sustain pauses in the stream, and whether the MCU needs to handle all the data.)

There are 3 ISA-style 100Mb chips out there; the rest are integrated or PCI.

formatting link
formatting link
formatting link
formatting link
recommended for ASIX protos)

Cheers, Richard

Reply to
Richard H.

Has anyone made a card where the "ADC finished" signal feeds a counter and a DMA circuit on memory that is shared with the CPU?

Some Xilinx part could compute the CRC values in parallel so that no CPU overhead would be used for that. I suppose the same part would pre-fill the address, protocol, and other packet headers as well as putting the first user data address into the counter.

Reply to
Aubrey McIntosh, Ph.D.

2 channels at 300,000 24-bit samples per second is 1.2 megabytes per second. 16-bits is 1.8 megabytes per second. A good rule of thumb for real-world network performance is: 10baseT = 1 megabyte per second 100baseT = 10 megabytes per second 1000baseT = 30 megabytes per second

So it looks like a bog-standard 100baseT Ethernet link will handle your data stream. and it dooesn't much matter what card you use. Just make sure it is set up for full duplex and that nothing else is on that network.

You will, of course, need a processor that can handle the load, enough storage, etc.. but I don't see your network link as being a problem.

--
Guy Macon
Reply to
Guy Macon

Dear all There are a lot of embedded ethernet cards out there now. I was considering the use of one of these to stream data from a fast serial ADC to PC for analysis - digital radio app. What sort of data rate could be achieved for 2 16-24 bit I/Q words and what card would you use? The max baseband bandwidth of the ADC is up to about 300KHz (ie 2 X

600KSamples/sec What would be the limiting factor in this scenario?

Thanks Richard

Reply to
Richard Hosking

Actel has an ethernet core module.. add some extra logic to control the ADC, put the results directly into the ethernet controller's memory and send.. minimal cpu overhead..

Reply to
TheDoc

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.