Re: serial link high level protocol thoughts?

From: Jim Brain (
Date: 2008-11-08 00:10:58

Marko Mäkelä wrote:
> 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 suspect your low level approach will work for standard IEC protocol, 
but not for speeder protocols.  Academically, then, the low level 
approach will work fine.  Pragmatically, the masses (if I can use that 
term in this community) expect speeder support.  My tests were run with 
JiffyDOS enabled.

As for my tests, I also tested UDRE and only sent when empty, so I don't 
think that was the issue.  Since it was very hard to diagnose corrupted 
data on the IEC bus when it only happened sproadically, I am not exactly 
sure what was going on.

Nonetheless, even if the low level protocol works fine, I don't see it 
as useful when fastloaders are in use.  Many of those simply can't 
handle transfers unless the entire block of data is in RAM.  And, once 
you move to support fastloaders, the uC firmware needs to be much more 
aware of the state of the IEC bus anyway.  Once that state has been 
established in the uC, supporting a high level protocol makes more sense.

> Just don't send more than 124 bytes at a time from the PC.
While that will indeed work for standard IEC, it will cause issues with 
many fastloaders and also requires more housekeeping (each block needs 
to be sent in three chunks)

> Buffering the blocks probably requires much more memory than the 128 bytes
> that are available in the ATtiny2313.
Yes, the ATMEGA1281 is my target platform.  While I think there is 
academic satisfaction in getting IEC routines to run in such a small uC, 
my time (fatherhood and all) suggests a more pragmatic approach to these 
projects.  The 1281 is not overly expensive, and users seem to prefer to 
spend more upfront and have lots of room to grow.
> 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.
sd2iec is in C (uIEC uses the same codebase, it is just compiled with 
ATA functions instead of SD functions), and used IRQ-based RS232 
routines.  I added support for a second UART (for the high speed IEC to 
PC protocol, to keep the primary UART for debugging information.

As to your inquiry about not being able to drive a 1541 from the AVR, I 
wonder if the AVR cannot sink enough current to overcome the 1KOhm 
pullups in the 1541.  It would not be my first thought, but aside from 
protocol concerns, one must consider the electrical portion of the bus.


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.