Re: Interface progress and issues

From: Jim Brain (
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
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 

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)


>	Marko
>       Message was sent through the cbm-hackers mailing list

Jim Brain, Brain Innovations                      
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.