Delay needed after RDFast?

Rayman · 2024-12-24 16:27

Noticing some randomish stuff occasionally coming out of the FIFO in this LCD driver being worked on...

It appears that since working repeated rdfast with 800 byte buffer, not divisible by 64, causes FIFO to choke?

Not seeing anything in documentation that suggests that a delay is needed.
But, searching the forum finds this one comment from @Wuerfel_21 that suggests it is:
https://forums.parallax.com/discussion/comment/1558402#Comment_1558402

Whether or not this problem shows up seems to depend on the alignment of the buffer in HUB, in some way that can't figure out...

Don't really know what's going on here, but one solution might be to make the buffer 800x2 bytes and use rdfast for every two lines, so is divisible by 64?

It's very strange. Wish there was P1 style documentation for every P2 assembly instruction...

Rayman · 2024-12-24 16:28

Here's that code with some nops after rdfast that seems to fix the problem above:

Note: Was thinking the $8000_0000 might remove the need for delay, but doesn't seem to...

DAT 'HVisible  - Visible data output
HVisible
            rdfast  ##$8000_0000,ptra
            nop
            nop
            nop
            nop
            nop
            nop
            drvh    #DePin
 'can have 9 instructions besides the drvh/l and have ~10 MHz dotclock with 250 MHz clock
            rep     @.end,##xpixels
            rfbyte  clr2         'Note:  24 bit bitmap is stored in order:  blue, green, red (but we need to reverse that)
            rfbyte  clr1
            wypin   #1, #LatchPin
            setbyte baseport,clr1,#basebyte
            wypin   #1, #PClkPin
            setbyte baseport,clr2,#basebyte
.end
            drvl    #DePin

Rayman · 2024-12-24 16:45

Could just be that the LCD driver hardware has some relationship to the software that is not being understood...

Seems can fix the issue by flipping the polarity of the pixel clock pulse:
pinstart(LatchPin, P_Pulse | P_OE |P_INVERT_OUTPUT , 2<<16+4, %01) ' pinstart(PClkPin, P_Pulse | P_OE , 2<<16+4, %01)
Seems to be working with no delay when the P_INVERT_OUTPUT is removed from PClkPIn Pulse starting.
Guess that means it's really a hardware issue...

Might have to break out the scope after all...

Rayman · 2024-12-24 17:33

Real problem might be that Pulse Smart Pins are running free and not synchronized well enough with the pixel output.

Guess might need to move the pinstart functionality into the assembly driver...

Still, maybe there is no way to get two Pulse mode smart pins exactly in sync?
Addpins might be solution there...

JonnyMac · 2024-12-24 17:37

Still, maybe there is no way to get two Pulse mode smart pins exactly in sync?
Addpins might be solution there...

Seems like that could work. You can even set them up in Spin, then disable them by floating the pins. In your assembly driver you can restart them by using drvl with a pin group.

Rayman · 2024-12-24 17:42

Thanks @JonnyMac That does sound like the easy way to go.

Rayman · 2024-12-24 17:52

I see in the spreadsheet that RDFAST takes as many clocks as it needs to prepare the FIFO.
So, don't think any extra delay is needed.

Just need to get my smart pins in order...

Rayman · 2024-12-24 18:02

Ok, think it is fixed like this in assembly now:

DAT 'HVisible  - Visible data output
HVisible
            rdfast  #0,ptra
            'Syncronize pulse smart pins
            flth    #LatchPin addpins 1
            drvl    #LatchPin addpins 1

Output seems stable. Hope all fixed now. Guess need more testing to say for sure...
Very lucky that Latch Pin and Pixel Clock Pin are next to each other...

TonyB_ · 2024-12-24 19:13

@Rayman said:
Here's that code with some nops after rdfast that seems to fix the problem above:

Note: Was thinking the $8000_0000 might remove the need for delay, but doesn't seem to...
DAT 'HVisible  - Visible data output
HVisible
            rdfast  ##$8000_0000,ptra
            nop
            nop
            nop
            nop
            nop
            nop
            drvh    #DePin
 'can have 9 instructions besides the drvh/l and have ~10 MHz dotclock with 250 MHz clock
            rep     @.end,##xpixels
            rfbyte  clr2         'Note:  24 bit bitmap is stored in order:  blue, green, red (but we need to reverse that)
            rfbyte  clr1
            wypin   #1, #LatchPin
            setbyte baseport,clr1,#basebyte
            wypin   #1, #PClkPin
            setbyte baseport,clr2,#basebyte
.end
            drvl    #DePin
@Rayman said:
I see in the spreadsheet that RDFAST takes as many clocks as it needs to prepare the FIFO.
So, don't think any extra delay is needed.

Just need to get my smart pins in order...

For a 'fast' RDFAST with D[31]=1 you must wait until the FIFO starts filling before doing a RFxxxx. A wait of 14 cycles between RDFAST and RFxxxx is enough or seven 2-cycle instructions (add one cycle if address is not long-aligned). For a 'slow' RDFAST with D[31]=0 no waiting is needed as the RDFAST doesn't end until FIFO starts filling.

I think your problem was related to the smart pins.

Rayman · 2024-12-24 20:43

Thanks @TonyB_ starting to remember how rdfast works now…

Wuerfel_21 · 2024-12-24 21:34

@TonyB_ said:
For a 'fast' RDFAST with D[31]=1 you must wait until the FIFO starts filling before doing a RFxxxx. A wait of 14 cycles between RDFAST and RFxxxx is enough or seven 2-cycle instructions (add one cycle if address is not long-aligned). For a 'slow' RDFAST with D[31]=0 no waiting is needed as the RDFAST doesn't end until FIFO starts filling.

IIRC alignment is irrelevant, 14 cycles is always safe.

evanh · 2024-12-24 23:15

Don't use ##$8000_0000 if you don't have something useful to fill in those instruction slots with.

TonyB_ · 2024-12-25 00:16

@Wuerfel_21 said:

@TonyB_ said:
For a 'fast' RDFAST with D[31]=1 you must wait until the FIFO starts filling before doing a RFxxxx. A wait of 14 cycles between RDFAST and RFxxxx is enough or seven 2-cycle instructions (add one cycle if address is not long-aligned). For a 'slow' RDFAST with D[31]=0 no waiting is needed as the RDFAST doesn't end until FIFO starts filling.

IIRC alignment is irrelevant, 14 cycles is always safe.

You're right. Not sure what I included the comment in brackets as I've done loads of testing with byte- or word-aligned addresses and 14 cycles always works, perhaps because spreadsheet says RDFAST takes 10-17 cycles. I've edited my original post.

evanh · 2024-12-25 04:19

@Rayman said:
Still, maybe there is no way to get two Pulse mode smart pins exactly in sync?
Addpins might be solution there...

The pulse/transition smartpin modes internally begin cycling on rising edge of DIR. The value in Y register has no bearing on their timing. It's painful for programs to manage and is the primary reason why my streamer+clock I/O code always looks similar to this:

' begin command phase
        xinit   r_leadin, #0    ' lead-in delay at sysclock/1
        setq    r_nco    ' data transfer rate, takes effect on XZERO below (buffered command)
        xzero   r_ca, pb    ' place first 32 bits in tx buffer, aligned with clock via lead-in delay
        dirh    r_clk    ' clock timing starts here, first clock pulse occurs in smartpin's second period
        wypin   #6*8+1, r_clk    ' SD clock pulses, 6 bytes + 1 pulse to kick off a response

Delay needed after RDFast?

Comments