So, I am curious about how much time there is between incoming bytes in the
use case of an M100 connected to the PC, using LaddieAlpha
Looking closely at the waveform being sent to the M100 during LaddieAlpha
transactions, it is clear that the PC can deliver back to back bytes with
almost no latency between bytes. So the M100 has to be quick.
What does this mean? It means for a bit banger interface (no UART) the
processor has to
1) recognize start bit
2) begin reading bits
3) read all 8 bits
and now in the time left, which is the stop bit, it has to write the byte
to RAM, and get ready for another interrupt and start all over again.
This is the scenario for the BCR TTL port.
In the normal RS-232 port, the UART takes care of the byte reception
allowing the CPU to do other things like service the UART and get data on
and off the circular buffer. Plus the UART has the potential for flow
control.
So the requirement for the BCR port receiver is to read and place the byte
into memory before the stop bit is completed. at 57600 baud that is about
17 microseconds. Typical processor instruction time is between 1.2 and 1.6
microseconds, so this is about 10-12 instructions max.
I think that is enough time to write to memory and increment a counter or a
parity, and a jump or 2.
57600 baud then looks feasible, even for large memory transfers so long as
the buffer can be continuously written to without interruption while the PC
is sending data. It also means that the RS-232 port could run flat-out at
5.7 kBytes/sec in the Rx direction.
In the Tx direction it similar, but it takes a small amount of time to
prepare the data before sending the start bit and following data bits. I
think it is probably better than 5.5 kbytes/sec.
On Mon, Apr 20, 2020 at 4:42 PM John R. Hogerhuis wrote:
>
>
> On Mon, Apr 20, 2020 at 1:24 PM Stephen Adolph
> wrote:
>
>> Interesting, but I think in my case I need to rely on small packets.
>> This is because there is no time to bit-bang an interface and ALSO manage
>> a circular buffer, and then move to memory.
>>
>
> For TPPD, the request/response nature is the main flow control. You don't
> request another packet until you're done handling the current one, so you
> can't get overrun.
>
> Doesn't seem like packet size should matter.
>
> You are bitbanging at a fast rate. Basically either you can keep up or you
> can't. SInce it's working, you're keeping up.
>
> How big the packets should be is more a function of how much space you
> want to reserve for a receive buffer.
>
>
>> I'm thinking to just read in data and directly place it into the Keyboard
>> buffer. Once the packet is read - pause and process the Rx data. Ready
>> to send another command then.
>>
>>
> You lost me on the keyboard stuff. I'm missing part of the picture. Is it
> necessary to be doing keyboard/video I/O during file transfer?
>
> It would be cool to do so of course.
>
> -- John.
>
