| ??? 06/13/06 14:52 Read: times |
#118234 - Reason of 5 or more buffer Responding to: ???'s previous message |
Hi Erik,
the reason why to use more buffer is to keep as many packages as possible available. This buffer management functionality is implemented in the lower layers of the API software. The user SW can fetch the data through the API function from the buffers. There is also a processed bit in the flags byte. If this bit is not set than even if there was a timeout the package stays in the buffer, so the user application can fetch it any time. But now as I am looking at your example, maybe it would make sence after all the repeatedpackages has arrived to copy the package to another fifo buffer, where the user can access it. I just have to be sure wether 2 buffers are enough for more senders. Greetings Attila |
| Topic | Author | Date |
| Buffer management optimalization | 01/01/70 00:00 | |
| Simple things first ... | 01/01/70 00:00 | |
| You can use circular buffer | 01/01/70 00:00 | |
| Fragmentation problem... | 01/01/70 00:00 | |
| all methods have some problems | 01/01/70 00:00 | |
| Start of package or End of package | 01/01/70 00:00 | |
| Packages explanation | 01/01/70 00:00 | |
| Individual buffers | 01/01/70 00:00 | |
| Good Idea | 01/01/70 00:00 | |
| New packages | 01/01/70 00:00 | |
| hash table unefective | 01/01/70 00:00 | |
| why keep that many | 01/01/70 00:00 | |
| Reason of 5 or more buffer | 01/01/70 00:00 | |
| Protocol specifics | 01/01/70 00:00 | |
| One way protocol | 01/01/70 00:00 | |
| One way protocol | 01/01/70 00:00 | |
| never | 01/01/70 00:00 | |
| Definition of need | 01/01/70 00:00 | |
| Grant, I agree with what you post re thi | 01/01/70 00:00 | |
| Simply reason why one way transmission | 01/01/70 00:00 | |
then why not just do it the easy way | 01/01/70 00:00 |