On 29/07/2018 22:24, afachat@gmx.de wrote: > Usually you should set the handshake when you receive the byte and find too > little space left, i.e. in the IRQ/NMI. After all this is the place where it > fills up. Yes, the whole point of handshaking is to stop the sender when you're busy and haven't processed all of the data received so far. If you only tell them to stop sending when you're not actually busy then it's not going to work reliably. > To make it faster, you only need to _stop_ the PC sending in the NMI. Make the > PC start again you can do in the normal routine that reads from the buffer. > Reading from the buffer is the only place where you free some space in the > buffer, and can thus decide to let the PC send again. It's wasted effort to check for both conditions there. However as you only need to check at the point when you have actually received a character, at 2400 baud you're only able to receive a character 4 times per frame (2400baud/10 bits/60fps). The threshold checks should be done in the driver which is written in assembly & I would make it the drivers responsibility to do all the flow control, rather than using C callbacks into the application. The problem will actually get worse with swiftlink, because bytes can arrive even more quickly. It was probably done this way to be flexible and avoid duplication in the drivers, but it's flawed.Received on 2018-07-30 11:00:04
Archive generated by hypermail 2.2.0.