From: Jim Brain (brain_at_jbrain.com)
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.
Jim
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.