Hi Aaron
There is no simple answer becasue what happens depends on various factors. However the following can be said:
1) A queue overflow is not an overflow in the sense that something else gets overwritten. It means that not all of a message couple be put into the queue.
Queues have a finite size and all work with a standard queue driver - thsi queue driver will put as much of a message into the defined queue. If anthing doesn't fit it gets discarded. This means that it is possible that only a part of a message is committed to teh queue when there is not enough space for a complete message.
2) The messages that we are interested here are interrupt event messages. These are often sent from interrupt routines (as in your particular case) and have a fixed length of 5 bytes. If there is not enough queue space to put these 5 bytes into it may mean that 0 bytes or up to 4 bytes are copied.
3) No other tasks, areas or timers are directly effected by a lost or corrupted message.
4) How the receiver reacts to a partial message depends on how it is written. It will generally read the header length and then treat the 5 byte content. Usually it is assumed that 5 bytes have been read (when zero is not returned by the read()) and so it may be that it then interets random content if not all of the event were put into the queue.
5) The length of queue needed to ensure that the queue will never get full depends on the speed of the events being generated and the speed that the queue is being emptied. The size required to never get a problem in this case would probably be to have a queue size equal to >= (5 bytes * maximum Ethernet buffers) but of course having one twice the size should probably ensure some reserve too.
6) In case of the network indicator task, wich receives only interrupt events the following change could be useful:
while (fnRead(PortIDInternal, ucInputMessage, HEADER_LENGTH)) { // check input queue while ((fnRead(PortIDInternal, ucInputMessage, HEADER_LENGTH)) == HEADER_LENGTH) { // check input queueThis would cause incomplete events to be read but ignored (assuming it mucst be a partial message).
However also setting the queue size to a multiple of the
HEADER_LENGTH (5) would also ensure than no partical events can be enetered into the queue.
7) In cases where a message loss would cause a problem the technique discussed in the following thread can be used to avoid trying to put messages to queue when th emessages won't fit:
http://www.utasker.com/forum/index.php?topic=1203.08 ) In this particular case it is probably not a bit issue if the LED doesn't flash once when a message is lost so there would be no benefits in checking for space - a generous queue size (if resources allow it) is of course the simplest method of ensuring that it never occurs too.
9) I don't actually understand how the LED flashing could be stopped by a lost, or partial event, since it seems as though your linkup/down LED was still responding. This probably excludes that the queue became blocked by reading bad data (this would only happen when the queue reads became de-synchronised with the content - eg. it read 5 bytes and the first was never the start of a telegram but some part of it - which shouldn't be able to happen anyway with its loop alway clearing the queue before terminating (?)
Regards
Mark