M52233DEMO  - High speed data streaming???

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

M52233DEMO  - High speed data streaming???

2,219件の閲覧回数
jockeyjim
Contributor I

Hi all

I'm a coldfire newbie and i am using a M52233DEMO board with the intention of using it for aquiring acceloration and sending it to a PC at high speed.

The demo webserver program is too slow for my application. Can anyone suggest an alternative method or a way of increasing the speed of the webserver?

Thanks

Alban: show PN in title

Message Edited by Alban on 2007-02-19 10:57 AM

ラベル(1)
0 件の賞賛
返信
3 返答(返信)

867件の閲覧回数
mccPaul
Contributor I
Hi,
 
You don't say if latency or bandwidth is the problem but I don't suppose bandwidth is the issue as I can't see how you would acquire that much acceleration data per second, so I assume your issue is latency. We have a product that requires minimum latency and maximum bandwidth so we construct our own Ethernet frames containing UDP packets and send them directly to the FEC. We co-operate with the Nichelite stack so that it can still work for user interface stuff.
 
First create a buffer to contain the frame you are going to transmit (16 byte aligned). Fill in the Ethernet header with the MAC address of your target (you may need to do an ARP first, but if you send to a multicast or broadcast address you don't even need this) and your own MAC address. Then construct the IP and UDP headers. The IP header can have its checksum calculated now and you can probably ignore checksums on the UDP payload (we do).
 
You now create an interrupt service routine that is either triggered by a timer interrupt or by a sample ready interrupt generated by the accelerometer chip (here I am guessing as I haven't looked at this on the 52235 demo board).
 
The ISR gets the current sample and inserts it in the UDP packet. It then calls the fec_tx_internal function in ifec.c in the Nichelite stack to put your packet onto the FEC's buffer descriptor ring. This function needs to be slightly modified to recognise your packet as being different to the stack's packets. You also need to modify the way the stack handles the packet_sent IRQ to make sure that your packet is not handed to the stack to be freed. There are a couple of user flags in the buffer descriptors that are handy for tagging your buffer with.
 
You may not want or be able to achieve this level of modification to the Nichelite stack, but with the changes we have made, we manage to get more than 90Mbit/s of data (payload - not including frame and protocol headers) onto the Ethernet. Latency is of the order of a few microseconds.
 
Good luck,
 
Paul.
 
Alban: show PN in subject line

Message Edited by Alban on 2007-02-19 10:57 AM

0 件の賞賛
返信

867件の閲覧回数
jockeyjim
Contributor I
Thanks for that Paul, i'll give it a go.
0 件の賞賛
返信

867件の閲覧回数
mjbcswitzerland
Specialist V
Hi

Simple web servers do not support TCP windowing and tranfers are not fast. They tend to be limited by the client which will perform delayed ACKing (this means that serving multiple pages has a delay of about 200ms between each frames).
UDP transmissions do not have this problem. Nor do HTTP implementation supporting windowing, or other TCP based protocols like it.

Regards

Mark Butcher
0 件の賞賛
返信