pilot.csum 0x4a != csum 0x00 on second try about openrabbit HOT 5 CLOSED

Current trunk now check the status line before and after sending the initial loader.
Turn out that something goes wrong when sending the initial loader: The status line is fine before sending it, but it doesn't go high after sending the loader (but if I omit the actual sending of the loader, the byte sequence sent after, that is supposed to set the line high, works fine).

P.S.:: The status line issue is observable even if sending just the first triplet of the initial loader. But if no such triplet is sent, setting the line works.

P.P.S.: This is odd, since AFAIK the very first triplet sent just switches the peripheral clock from osc/8 to osc by writing 0x08 to GCSR.

P.P.P.S.: I was able to deal with this problem: Apparently PCs are too fast to send triplets. When I wait for 15 ms after sending each triplet from the initial loader, I do not encounter the problem.

from openrabbit.

Hmm. 2400bps is 240 bytes/second or 80 triplets/second, which is 12.5ms. So your delay aligns well with that.

I haven't looked at the code, but what happens if you place your entire delay after sending the complete loader? Just dump the triplets and then wait 3.5 seconds (or whatever the byte count * 5ms comes to) before timing out on your status line check?

My guess is that the send happens instantaneously and the OS buffers the bytes. You may need to check the serial port's transmit buffer and wait for it to drain before expecting the status line to change.

from openrabbit.

True. It also works if I just wait the whole time period in the end.
I don't know of a way to flush the buffer (and with an USB converter involved, there might not be even a way to flush the whole buffer); so for now I'll try to make stuff work with the delays.

from openrabbit.

And once I fixed all the details, it now works reliably using the loader binaries from Dynamic C 8.61!
Waiting isn't elegant, but we can keep it that way until we find a better solution.

from openrabbit.

You could update the code to watch for the STATUS pin to change, and base the timeout on the number of bytes sent.

This Stack Overflow answer has a possible method to determining how many bytes are still in the output buffer. But as you said it might not be accurate due to buffering in the FTDI chip.

Also, tcdrain() will block until all data has been sent.

from openrabbit.