SPI Slave woes :-(

spinal · May 29, 2019, 10:59am

Yup, This is what I get -

/*
0xd5,0xf0,0x8d,0x14,0xa1,0xc8,0x81,0xcf,0xd9,0xf1,0xaf,

^#.#.#.#####
|.......#..#
|#.##...#..#
|..#..#.##.#
|##.#....##.
|.#..#....##
|##...#.###.
|###.#######
*/

And that’s not reliable either.
Then nothing. Worse still, is that my cheapo usb logic analyser is incapable at working at a speed capable of verifying any of the data.

[Edit] if the SS pin if not set high between bytes, would this cause issues? I think arduboy might leave it low constantly.

Pharap · May 29, 2019, 12:41pm

I have no clue what this means.

It does:

github.com

MLXXXp/Arduboy2/blob/096aaac8dd8c46eabbebbb9807b63142ac876e56/src/Arduboy2Core.cpp#L206


}


void Arduboy2Core::bootOLED()
{
// reset the display
delayShort(5); // reset pin should be low here. let it stay low a while
bitSet(RST_PORT, RST_BIT); // set high to come out of reset
delayShort(5); // wait a while


// select the display (permanently, since nothing else is using SPI)
bitClear(CS_PORT, CS_BIT);


// run our customized boot-up command sequence against the
// OLED to initialize it properly for Arduboy
LCDCommandMode();
for (uint8_t i = 0; i < sizeof(lcdBootProgram); i++) {
  SPItransfer(pgm_read_byte(lcdBootProgram + i));
}
LCDDataMode();
}

Though I have no clue if that would cause issues.

I think this might be wrong.
The Arduboy2 source indicates that SPI runs at 8MHz:

github.com

MLXXXp/Arduboy2/blob/096aaac8dd8c46eabbebbb9807b63142ac876e56/src/Arduboy2Core.cpp#L230


}


void Arduboy2Core::LCDCommandMode()
{
bitClear(DC_PORT, DC_BIT);
}


// Initialize the SPI interface for the display
void Arduboy2Core::bootSPI()
{
// master, mode 0, MSB first, CPU clock / 2 (8MHz)
SPCR = _BV(SPE) | _BV(MSTR);
SPSR = _BV(SPI2X);
}


// Write to the SPI bus (MOSI pin)
void Arduboy2Core::SPItransfer(uint8_t data)
{
SPDR = data;
/*
 * The following NOP introduces a small delay that can prevent the wait

Also the mention of ‘mode 0’ makes me think that maybe this is wrong too:

Perhaps it should be this?

spi.format(8, 0);
spi.frequency(8000000);

MLXXXp · May 29, 2019, 12:53pm

The frequency set for a slave shouldn’t matter since the master does the clocking.

spinal · May 29, 2019, 2:02pm

Not important, it’s the incoming data as dumped to the screen.

I wouldn’t have thought so at first as the pokitto sometimes receives the first few bytes. But who knows.

I only seem to get three bytes that way.

spinal · May 30, 2019, 11:11am

Ok, I’ve switched to using an interrupt on the clock pin and manually grabbing the incoming bits. It seems to be something but nothing usable just yet. With this method though I can also check the d/c pin at the same time, that’s a plus.

[edit]
Nope, that’s way too slow, I’m dropping most of the data.

spinal · May 31, 2019, 6:52am

I found this reply here back in 2011, doesn’t fill me with hope for this project…

Does anyone have any experience with running a pin interrupt at super speed? It seems that spi will not receive any bytes unless the CS is toggled after every byte and as that isn’t what the arduboy screen does, it seems a bit useless.

jonne · June 2, 2019, 9:13pm

RORIM register, UM10732 (LPC11U68 user manual) page 266 chapter 14

Interrupts are available for half full FIFO buffer and buffer overrun ( frame full) as well as frame timeout

I’ll try to find an application note/example

Edit: I suspect the CS ‘toggling’ is just a lazy way of reading in the buffers & clearing the SPI interrupt regs

spinal · June 13, 2019, 7:27am

I’ve been doing a bit of googling and it seems that reading an pin at high speeds might not even be possible. I think this idea might never work