When using the serial API in NET+OS 5.1 to read characters, sometimes characters get retained by the OS so that they do not become available for reading until more characters are received by the OS. The more characters that are input, the more characters are retained. The _CB_EMPTY macro in netos_serl.c reports that rx_buffer is empty even though there are more chars that have been input. The problem exists both when setting the RX trigger to the standard gap timer and when setting it to matching on all characters. The serial port is opened with non blocking reads and 9600 baud, 8-N-1. What is causing this behaviour? It seems to me that this is a bug in NET+OS 5.1. I cannot recall getting this problem with NET+OS 5.0 and the NET+40. I’ll give an example to clarify: Step 1. Input to OS: abc Read out with serial API (the ‘c’ is missing): ab Step 2. Input to OS (the ‘d’ is appened to the above input, the ‘abc’ is not input again): abcd Read out with serial API (the ‘c’ is appened to the above as a result of the input ‘d’, but the ‘d’ is missing): abc Step 3. Input to OS (appened to the above input): abcdefghijk Read out with serial API (appened to the above. Now two chars are missing): abcdefghi Best regards, Fredric
The problem you are describing sounds similar to a problem that we worked an fixed lately. The problems was that we realized that we were missing characters in the FIFO. The way we fixed this issue was that when we were receiving the data and as soon as this data filled up the receive buffer, we were initially disabling the interrupt. Well the side effect of this was that even there was data in the FIFO we wouldn’t look at it which will end up with data loss but now we removed that which is for HW flow control. The other fix was that once the driver does not determine that there is some bytes of data to be processed from the status register, the driver wouldn’t bear to read the FIFO and this was causing data but now this got addressed. Status Register was updated continuously based on the data received. In order to get these fixes please contcat Netsilicon Techical support for teh new serial driver.
To update: this problem was caused by using the MULTI 2000 I/O window to output stdio data. If you output the data to e.g. a serial channel the problem was not there.
Hello,I got the new serial driver from tech support but it did not resolve the problem. The problem reported in thread “NET+OS 5.1 serial RS485 problem” of Aug 6, 2003 could also be related to this. Could you please investigate further what is causing these problems? regards, Fredric