| ??? 07/08/04 04:52 Read: times Msg Score: +1 +1 Good Answer/Helpful |
#73770 - RE: Hi speed serial commn revisited Responding to: ???'s previous message |
As you assumed, J Guy meant that the processing would be faster. As for estimating the size of the buffer required, that depends on a few things: 1/ the baud rate - at 10bits/char, characters/second = baud rate/10. 2/ the amount of data expected in a burst. If you're using a protocol where you're polled from a master (PC for instance) - normally the poll is a fixed size or there is a maximum size you would expect. This would set your buffer size. If the data is somehow greater - your code would reject the request. 3/ what else the processor has to do. This is where it gets a little tricky- you have to figure out what is time critical and what is not. Comms is normally time critical but there may be other tasks that are as critical or more so. Say for instance you code can process the incoming data every 100mS. Therefore at 115200 baud you have 11520 chars/second coming in so in 100ms that is 1152chars. Thus your buffer would need to be at least 1152 bytes. Where you response time may be variable due to other tasks running, you need to figure out the worst case response time and allocate you buffer to suit. Where you have little knowlege of the incoming data, say for a video display terminal, it may be impossible to have a buffer big enough to hold the worst case amount of incoming characters. Then you need handshaking - that is some method of telling the sending device to stop sending. On RS232 you have RTS/CTS and DSR/DTR to perform this function whereas on RS485 you don't. You can send a control character back to the sending device to tell it to stop sending and another to start sending. When your buffer get nearly full, you tell the sender to stop, when you buffer is nearly empty you tell the sender to start sending again. These are the basic techniques that have been used for years. As you've probably gathered, there's no one solution to your problem. It's a matter of evaluating your application and choosing the best technique. If you can tell us more about what you're trying to achieve, we can better suggest a technique that is suitable. |
| Topic | Author | Date |
| Hi speed serial commn revisited | 01/01/70 00:00 | |
| RE: Hi speed serial commn revisited | 01/01/70 00:00 | |
| RE: Hi speed serial commn revisited | 01/01/70 00:00 | |
| RE: Hi speed serial commn revisited | 01/01/70 00:00 | |
| RE: Hi speed serial commn revisited | 01/01/70 00:00 | |
| RE: Hi speed serial commn revisited | 01/01/70 00:00 | |
RE: Hi speed serial commn revisited | 01/01/70 00:00 |



