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.