Crystal CS8900a dropping packets

Either I don't understand your question too well (which might be) or then the answer seems to be pretty obvious. Once the recive buffer space of the CS8900a is used up you start to loose all subsequent packets unless you process those in the buffer thereby makeing room for new ones. Since you mention that you don't use interupts and 8 bit IO, you can't expect high performance or no lost packets. The latter can't be expected anyways due to factors along the comunication path. There's no way around you implementing your comunication protocol in a fashion where packet loss is no problem other than slowing down the transfer. This way it should not matter how many packets are actually buffered as long as the chip is able to buffer at least one of them. In other words, it's very likely that the CS8900a is faster in buffering packets than yuor controller is able to process them hence it's buffer space will be uesd up every now and then.

Markus

Thanks for your reply. I understand what you're saying, but if the chip has 4kb of buffer space, and I send in three 64byte packets, I should have only used up a fraction of that 4kb...leaving plenty of buffer space left.

By no means to I expect anything close to good performance with this implementation. We don't need it. We're in an environment where at very worst 1kb of traffic is sent to us every 15 minutes or so. If we were on a LAN, we'd be dead for sure.

Brian

Errrr, it's about two years ago that I implemented driver code for this chip, so I'm no longer familiar with the details - but have you examined the data sheet closely? If memory serves it was quite complete and should contain information about how the buffers are used.

Well, you CAN do nice things with an 8 bitter and this chip like embedded webserver to configure a device or show data etc, so it's not THAT bad if you implement say TCP/IP wisely. One of the best sources I saw for this kind of thing is a tech note from TI ( slaa137 ) which contains a very light weight TCP implementation. What I liked about it is that it's really only the absolut bare bones of it makeing it much easier to understand than a full blown stack supporting multiple connections and all later exensions to the protocol. I'm aware that you haven't mentioned TCP, but the tech note may show you how to drive the chip efficiently. They also don't use interupts.

Markus

Thanks for your help, Markus. The TI app note was useful for us. Now that you mention TCP, wouldn't that protocol in itself pretty much take care of the lost packets? I.e., once I know my buffer space is getting light, I advertise a smaller window, etc...

I'm an EE (so no TCP expert), but isn't the protocol designed that way? To ensure delivery, etc? Brian

If packet drops are due to IRQ latency of your system, you may try enabling early IRQ generation in CS8900A (Rx128 bit), that way you will be informed there will be something to read after 128 bits of a packets are received, thus by the time you get around to reading it, the whole thing may be in.

Maciek.

He said he did NOT use IRQ. Google for "CS8900A IRQ 8-bit". There is a bug in that specific combination. Bit me once.

Arie de Muynck

Yes of course. TCP is a reliable protocol which guarantees that segments arrive in order and none of them is missing etc.

If you can get away with ONE active session at a time, you can pretty much port the code available in that app note and you are done. Porting should be fairly straight foreward - especilly since you use the same network controller. Otherwise I'd recommend to check for the availablity of a comercial TCP stack (or use another open source one) over developping your own. It can be done - been there done that - but developping a TCP stack from scratch without know how in this field will use a lot of your time.

Markus

Forgot about that 8-bit bug ;-)

Maciek.

Thanks for your help.

Just for some closure; I finally got in touch with Cirrus and it turns out that there is a 4kb buffer but only 4 *pointers* therein. One of those is always dedicated to transmit buffering, so that leaves 3 for receiving, which means 3 packets is the most you can ever buffer, independent of size. >Sigh< Would it have *killed* them to put that in the data sheet???

I think with TCP, I should be good; glad I posted here :) Brian