SPI Slave woes :-(


#21

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.


#22

I have no clue what this means.

It does:

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:

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);

#23

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


#24

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.


#25

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.


#26

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.


#27

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


#28

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 :frowning: