From: Marko Mäkelä (msmakela_at_gmail.com)
Date: 2008-11-07 22:34:13
Jim,
On Fri, Nov 07, 2008 at 12:05:10PM -0600, Jim Brain wrote:
> I implemented the low level protocols in 2005, and found that RS232
> communication interfered with transfers resulting in corrupt data. I
> was not able to resolve the issue. I remember one example:
>
> 64 would open a file for reading.
> low level protocol would send 2 command bytes + filename.
> PC would open file and send ack back
> 64 would open channel for reading
> low level protocol would send 2 command bytes
> PC would respond with 254 of data
> 64 would issue GET#,A$
> low level protocol would send 1 byte of data back
> 64 would immediately bring ATN low
> low level protocol would then send ack to PC telling it that 1 byte had
> been sent
> 64 would send 2 more command bytes...
>
> Under load, the link would get saturated with chatter and the system
> would often corrupt data. Another example generated the same issue and
> corrupted file loads. While I am no IEC expert, I finally gave up.
My firmware shouldn't suffer from this problem. It polls for the
UART Data Register Empty before relaying bytes to the PC. The serial bus
protocol allows for arbitrary delays between bytes, as far as I remember.
The only timing-critical parts should be the ATN handshaking and
sending or receiving bytes once the between-bytes handshaking has been
completed.
I can imagine that there could be some problems with receiving data from
the PC. The receive buffer is only 124 bytes, and at least on Linux,
both the 16550 and the PL2303 driver seem to ignore flow control under
certain circumstances. For instance, I had to tweak c2nload on the
PAL C64 so that it would receive at 38,400 bps without requiring any
flow control. This problem should be fixable on the protocol level, though.
Just don't send more than 124 bytes at a time from the PC.
> To contrast, I implemented a high level protocol the other day that let
> the uC maintain buffer positions and only sends/receives data in blocks,
> and it works fine.
Buffering the blocks probably requires much more memory than the 128 bytes
that are available in the ATtiny2313.
> Thus, while I agree there might be some utility in a low level protocol,
> I'd rather concentrate my efforts on a high level protocol at this time.
It should be easier to do it on a big microcontroller (the Atmel ATmega
series) and on the high level. On a big uC, you can even program some
parts in C. My code is interrupt-driven and 100% machine language.
(The sending to the serial bus might use a polling instead of interrupts,
if I remember correctly.)
I checked, and the code is available here:
http://www.iki.fi/~msmakela/8bit/c2n232/firmware/c2n232i.s
http://www.iki.fi/~msmakela/8bit/c2n232/firmware/c2n232i.txt
I didn't port it to the ATtiny2313 yet (it was written for the AT90S2313
in the first series of the C2N232), but it shouldn't be difficult. In fact,
the ATtiny2313 might even make some things easier. For instance, if memory
serves, the ATtiny2313 features a Pin Change Interrupt.
Marko
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.