| ??? 05/23/08 00:49 Read: times |
#155046 - Protocol? "We don't need no %$#@! protocol!" Responding to: ???'s previous message |
Michael Karas said:
This problem is exactly analogous to the problem faced with when to safely turn the driver/receiver enables around for use in RS485 protocol. One must retard setting the change of the transmitter direction control until after the stop bit of the last bit is transferred.
One way to do this is to setup a simple timer delay interrupt. Each time you put a byte into the UART port output you reset the timer period to a maximal period of about two UART character shift times (taking your baud rate into account). Then if the timer interrupt ever occurs then you use that time to go out and toggle off the transmit enable. I don't have that much time. I have to switch the clock rate within ~20 ns so the purpose of the interrupt I mentioned, would be to kill time until the process requiring the faster clock had ended, and then either request a retransmission (if that's even possible) simply ignore the possibility of a lost character. That's why I'm looking to fiddle with the handshake. It's not likely there'll be a protocol in play, since I mainly use the serial port when a monitor is in use, so it's talking to a "dumb" terminal. I'm even considering sending a <CTL-S> from hardware ... You let the protocol design take care of the times when the receiver is in process. Your code always knows if it is the midst of receiving a packet. In that state you have logic to either decide to abort in-process receive commands/data or let them complete before clamping off the serial port. In cases where receive stuff is not yet in process you simply clamp off while not worrying about the possibility of something coming. It does however behoove you to make sure that the sending logic at the other end implements proper transmit timeout logic.
Michael Karas This is clearly not a common situation. I have another of those processes that takes place much faster than the MCU can process, and, therefore, I'm using programmable logic to assemble the data and stick it into a buffer memory. The fact that the clock needs to be switched can also tell the MCU to switch context, as it will then have to take the data from the buffer memory and shovel it out to another interface channel. There's no serial communication involved, aside from a little bit of async monitoring, so I'm thinking that I can diddle with the RTS/CTS or DSR/DTR pairs if I have to. Unfortunately, there's really never been a standard for handshaking on the RS232 signal set. RE |
| Topic | Author | Date |
| Asynchronous Serial Port handshake? | 01/01/70 00:00 | |
| Question isn\'t quite clear | 01/01/70 00:00 | |
| Thie problem is exactly analogous to,,, | 01/01/70 00:00 | |
| Protocol? "We don't need no %$#@! protocol!" | 01/01/70 00:00 | |
| Good Luck | 01/01/70 00:00 | |
| Sorry to step on your toes ... | 01/01/70 00:00 | |
| 'right now' | 01/01/70 00:00 | |
| sounds to be a case for an external UART... | 01/01/70 00:00 | |
| RE sounds to be a case for an external UART... | 01/01/70 00:00 | |
| double post, ignore | 01/01/70 00:00 | |
| It could be none at all ... | 01/01/70 00:00 | |
| Switch | 01/01/70 00:00 | |
The goal is to minimize the data loss | 01/01/70 00:00 |