From: Jim Brain (brain_at_jbrain.com)
Date: 2004-06-16 04:13:07
Marko Mäkelä wrote:
>
>How does this differ from my implementation? In my implementation, the
>microcontroller will send a control code to the RS-232 line when it observes
>ATN=0 during a serial bus transfer. It'll also send the low-order bits of
>the byte counter, so that the computer connected to the RS-232 line knows
>how many bytes were successfully send. It then drops all received bytes
>until it sees a special command. That arrangement should avoid any race
>conditions.
>
>
Our approaches are similar. Your command set includes special commands
for TALK and LISTEN, I let the PC figure out if it a talk or a listen.
I also sent a TURN command, which is the trigger for the PC to send the
data.
I decided against just turning the PC loose, for various reasons. The
main one is that you have to buffer all the bytes you send to the
interface, as you may have already sent a number of bytes to the
interface before you receive a command stating that only 15 bytes were
sent. If you've sent more than 15 already, you have to reset your
pointer to resend bytes 16-. Although doing a fseek on a local file is
no big deal, for some of the stream types I plan to support (HTTP, FTP),
it seemed bad implementation practice to request a full HTTP request,
only to go back and re-request a RANGE transmission. The other
alternative is to buffer all incoming data until getting an ack for it
being sent, and I wanted to limit the size of my buffers , as this code
eventually would like to end up in an AVR MEGA 128 as a self sustaining
interface. So, I limited the buffer size to 256 bytes (seemed like a
good match given the hardware it emulates), and I send only that much
before waiting for an ACK. (Actually, I think it is 255 bytes, as my ack
command sends 1 byte of length). I drop the bytes until a command is
found, as you suggested.
>
>
>>This seemed a bit non-optimal (in tests using BASIC, a loop that does
>>GET#1,A$ will cause lots of data to be sent over the RS232 link (you
>>send 256 bytes, 1 gets transmitted, you send 255 bytes, 1 gets
>>transmitted, etc.).
>>
>>
>
>Have you experimented with a smaller transmission buffer? C-Kermit on
>GNU/Linux write()s as little as 1 byte at a time, and it achieves
>38,400 bps without problems, at least when using a 16550 with built-in
>16-byte FIFO buffer.
>
>
A bit. Performance is not bad with 255 bytes, and smaller is faster, at
the expense of more chattiness. I was thinking of 64 byte buffers, as
that seems a happy middle ground.
Sorry for the delay in responding. I moved my site in anticipation of
the mirror setup, and mail was down for a few days while the DNS entries
moved and I set up the new site.
(Oh, yes, and I had to help bring a new daughter into the world)
Jim
> Marko
>
> Message was sent through the cbm-hackers mailing list
>
>
--
Jim Brain, Brain Innovations
brain@jbrain.com http://www.jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.