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 firstname.lastname@example.org 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.