On Thu, Jun 24, 2004 at 02:58:17AM +0200, Kyrre Aalerud wrote:
> I am trying to figure out if there is any RS232 speed I can use to receive
> data slower than I can program it, but it seems that the programming may be
> too slow...
>
> The 4 word programming loop would need about 2.1 ms including some extra
> instructions.
> That's 476 writes pr second, 1904 bytes/sec needed to be received via
> serial.
> 9600 baud, 1 start and  1 stop bit should make transfer 960 byte/sec.
> Teoretically it can be programmed faster...

All true. But the points that you make below make more sense.

>
> Problem is that at 9600 baud, I would receive a new byte at a rate of half
> the time it takes to initiate a full 2x4 byte write, and the cpu wil halt
> for 2ms without the rx halting.  I only see a single byte receive-buffer so
> how can I continue to receive bytes at 1ms rate when I will be halted for 2
> ?

Short answer is that you can't. That's why almost every protocol out there
sends bigger blocks and has a ACK/NACK call response system.

>
> Seems to me I should use a protocol where I receive data in atleast a 2x4
> byte block, then ack it when it has been written.

Right.

> Next block would not be accepted before the previous one was acked.

Right again. Then you can take advantage of your high speed hardware USART
and receive the data at 38400, 57600, or even 115200 BPS. Then the speed of
the write is limited only by the speed of the programming.

> Since
> the bootloader only works alone, and a reset of the device should follow a
> reprogramming, I could use a lot more of the memory for the buffer,

And you should. You have all of the RAM of the part available. a 64 byte
buffer that transfers 32 words at a time would be rather trivial to do.

> trying
> to make the communication and programming more effichient while transferring
> at a higher speed.

Bingo. And if you check out others protocols, you'll find that most all of them
follow this model.

>
> Am I making sence ?

Of course. Also consider this: you'll have to have some type of communications
checksum. The smaller the packet, the more of the checksums you'll have to
compute. So bigger packet sizes are more efficient. Also it means that you can
verify that you have the proper packet to write before you start writing it.
With your previous scheme, you'd have already written the data before you
realize that it was a failed transmission.

BAJ

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu