??? 01/01/09 23:56 Modified: 01/01/09 23:57 Read: times |
#161248 - I play with that from time to time Responding to: ???'s previous message |
The DS89C4x0's are interesting to me because of their inherent speed, provided by their "features." Being one-clockers, they execute nearly any code that works with the "traditional" 11.05 MHz crystal at three times the "normal" speed, including three times the baud rate, when using a 33 MHz crystal. I use a 33 Mhz crystal oscillator with which to program my parts, and I've found that the ULTRAMON51 monitor works VERY well with them, though you have to provide 128 bytes of external memory for that memory to work properly. I've also found that you can expand the memory range by using an external counter clocked by the falling edge of A15, which has to be externally registered, during ALE. If all your code resides externally, you can use external data transfer (MOVX) sequences to move data from a memory-mapped I/O device to memory very quickly. As it happens, I do that with a 120 ns cycle with the external port address being an IDE channel operating in PIO mode 4. I use a 256 repetition macro of MOVX A, @DPTR with autoincrement of DPTR0 to transfer the data and that occurs at a 120 ns rate. My hardware writes the bytes to memory at twice the word rate allowed at the IDE channel in that PIO mode, and, as I mentioned, the 512-byte block is transferred in 256 word transfers accomplished by a 256-line code block consisting of 256 MOVX instructions.
One experiment you might try is to determine whether, when code is internal, the P0 and/or P2 SFR values can be latched at the rising edge of ALE. I've attempted this in the past, but have had "mixed" results. I wouldn't rely on that. This matters somewhat because P2 shouldn't be lost entirely just because, once in a long while, one uses an external 16-bit MOVX address cycle. Cycle timing is pretty "wishy-washy" in their data sheets and user guides. In some cases they've got sketched timing diagrams with obvious minor errors, and in others they simply have case omissions, notably the one to which I referred. They devote considerable print to external code fetch cycles yet show not one diagram of a repeated data fetch cycle. Another area of interest would be the Mode0 serial port I/O timing with respect to the oscillator, particularly when a clock multiplier configuration is used. That will be more challenging, I suppose, since there's absolutely no documentation about how the serial port interacts with the TI and RI flags, nor is there any indication of how the interrupt response is timed with respect to those flags. The classic documentation is of no help at all, since these are one-clockers, and the timer interaction with the serial port has to be quite different than on the "classic" parts. Good luck! RE |
Topic | Author | Date |
Happy new year and good resolutions. | 01/01/70 00:00 | |
I play with that from time to time![]() | 01/01/70 00:00 |