dsPic erasing array faster

[NorthGuy]

It does seem reliable if I use a function with no arguments or return value

Code: [Select]

void invertframe() {
asm volatile ("MOV #_framebuffer,W1");
asm volatile ("MOV #_imagebuffer,W0");
asm volatile ("MOV.B #255,W2");
asm volatile ("REPEAT #1023");
asm volatile ("XOR.B W2,[w0++],[w1++]");
}


If you align your buffers at word boundary then using words will be almost twice as fast:

Code: [Select]

asm volatile ("MOV #_framebuffer,W1");
asm volatile ("MOV #_imagebuffer,W0");
asm volatile ("MOV #0xffff,W2");
asm volatile ("REPEAT #511");
asm volatile ("XOR W2,[w0++],[w1++]");
There's a special command for inverting, although it doesn't make much difference:

Code: [Select]

asm volatile ("MOV #_framebuffer,W1");
asm volatile ("MOV #_imagebuffer,W0");
asm volatile ("REPEAT #511");
asm volatile ("COM [w0++],[w1++]");

[@rt]

I should have known that, it was comf.
Probably compliment file register.

[@rt]

My first DO loop worked, which is a software bit bang for SPI write. MSB goes out first.
The device select pin has already been pulled low before calling this to send a byte.

I remembered no way to copy a bit directly, so I don’t like that with the use of BTSS/BTSC,
the data pin would be set faster than it is cleared, so a serial waveform would look odd, despite working.
That is why the input byte is rotated where it is (for an extra instruction delay after the data pin possibly being sent low).

I’m wondering if I should AND the portb latch pin with the data bit for even timing?
So it would take the same time to set or clear the data pin before the latch pin is set?

Code: [Select]

void WriteSPIFast(unsigned char data_out) {
SPICLOCKLAT = 0; SPIOUTLAT = data_out >> 7; SPICLOCKLAT = 1;
SPICLOCKLAT = 0; SPIOUTLAT = data_out >> 6; SPICLOCKLAT = 1;
SPICLOCKLAT = 0; SPIOUTLAT = data_out >> 5; SPICLOCKLAT = 1;
SPICLOCKLAT = 0; SPIOUTLAT = data_out >> 4; SPICLOCKLAT = 1;
SPICLOCKLAT = 0; SPIOUTLAT = data_out >> 3; SPICLOCKLAT = 1;
SPICLOCKLAT = 0; SPIOUTLAT = data_out >> 2; SPICLOCKLAT = 1;
SPICLOCKLAT = 0; SPIOUTLAT = data_out >> 1; SPICLOCKLAT = 1;
SPICLOCKLAT = 0; SPIOUTLAT = data_out; SPICLOCKLAT = 1;
SPICLOCKLAT = 0; SPIOUTLAT = 0;
}

void WriteSPIFaster(unsigned char data_out) {
srbyte = data_out;
asm volatile ("BITBANG: DO #7, ENDBANG");
asm volatile ("BCLR LATB,#8");
asm volatile ("BTSC.b _srbyte,#7");
asm volatile ("BSET LATB,#7");
asm volatile ("BTSS.b _srbyte,#7");
asm volatile ("BCLR LATB,#7");
asm volatile ("RLNC.b _srbyte");
asm volatile ("ENDBANG: BSET LATB,#8");
asm volatile ("BCLR LATB,#8");
asm volatile ("BCLR LATB,#7");
}


[NorthGuy]

My first DO loop worked, which is a software bit bang for SPI write. MSB goes out first.
The device select pin has already been pulled low before calling this to send a byte.

I remembered no way to copy a bit directly, so I don’t like that with the use of BTSS/BTSC,
the data pin would be set faster than it is cleared, so a serial waveform would look odd, despite working.
That is why the input byte is rotated where it is (for an extra instruction delay after the data pin possibly being sent low).

I’m wondering if I should AND the portb latch pin with the data bit for even timing?
So it would take the same time to set or clear the data pin before the latch pin is set?

You can do even timing and a little bit faster:

Code: [Select]

// This assumes that LATB.7/8 are cleared at the entry
asm volatile ("LSR.B  _srbyte,WREG");
asm volatile ("XOR.B _srbyte,WREG"); // W0 holds differences between consecutive bits
asm volatile ("BITBANG: DO #7, ENDBANG");
asm volatile ("BTSC w0,#7");
asm volatile ("BTG LATB,#7");
asm volatile ("SL w0,w0");
asm volatile ("BSET LATB,#8");
asm volatile ("ENDBANG: BCLR LATB,#8");
asm volatile ("BCLR LATB,#7");

However, the best way is to use an SPI module.

[@rt]

Thanks
Some instructions there I’m unfamiliar with. It will give me something to chew on.
I am using the hardware SPI for an SD card, and a few different software routines to match variable clock speed of another device.

I didn’t think I’d be as interested, but every time something comes back to me, significant program memory is saved.