| ??? 08/13/08 22:57 Modified: 08/13/08 23:01 Read: times |
#157480 - You missed a thing or two, Erik Responding to: ???'s previous message |
Erik Malund said: there's no doubt about that ... but what I said was
from the datasheet "In the DS89C430, the MOVX instruction takes as little as two machine cycles or two oscillator cycles" ... the data path is 16 bits wide, and because the code is simply a block of 256 MOVX A,@dptr MOVX @dptr,A instruction pairs ... MOVX A,@dptr MOVX @dptr,A instruction pairs, the whole thing takes 60 ns per byte nope, 2*2/33M = 121ns excluded as Richard did: djnz now comparing to a f120 with pagebound buffers movx A,@R0 3 cycles MOVX @dptr,A 3 cycles inc R0 1 cycle for a total of 70ns excluded as Richard did: djnz if you write the buffer backwards and use the same register for @R1 and djnz you can cut it to 60ns Erik Just a minute ... The arithmetic is right, but ... The MCU doesn't see the data, i.e. it's not connected to the MCU, and it's 16-bit-wide data. Data source and data sink are simply connected together. The MCU simply executes 256 instruction pairs, which generates 256 reads, and 256 writes, with 256 addresses, then moves on to the next thing, which, in this case, is 39 more of the same thing, each time first ordering the transfer with an quick command transfer. I'm thinking, actually, some simple logic can be used to generate the write strobe at the same time as the read strobe occurs. That would speed up the process by 2x, without affecting access time. No djnz is necessary, as the transfer module simple ends in RET. There's no loop. As I may have mentioned, the falling edge of A15 is used to increment a counter which provides the upper four address bits. The entire address generator is simply the DPTR and that programmable counter. As it happens, access time limitations prevent me from shortening the transfer to less than 120 ns per the applicable standard. It's easier than using a DMAC. As it happens, this is "multiword DMA" (doesn't require CRC) on an ATAPI channel to/from memory, which, BTW, is also used as a data source for yet another DMA-driven channel. If someone's interested in pursuing it, it's an easy way to create a datalogger, though this one has to be fast. RE |
