ST7735

[WingNut]

Starting to think this display needs comms at a very low rate. I see 9600 used a lot in C code routines

[mnfisher]

I think the 9600 will probably refer to a UART interface and refer to the BAUD rate. The display works well at SPI speeds - for example on the Arduino 4MHz (the 8MHz option having vanished?? in v9)
However - there is a fair amount of data to shift around - for example to clear the display - first the code must set the display area (128*160 - which involves sending RASET and CASET commands with x and y dimensions) and then shift 2 bytes per pixel to the display (so 128 * 1460 * 2 = 40kbytes.) - this is sent as multiple transaction writes. See my comments above - on write the 'write buffer' is cleared so must be refilled each time (I suppose this could be optimised for a slightly faster fill with black...) - so there is some 'overhead' too - but the speed of writing is the main factor...

Text etc is quick - for each 'pixel' (which can be bigger than 1 x 1) - the area required is first set and then data shifted in for each pixel..

From your comments above - it sounds as though the clock isn't being set correctly on your setup - changing the clock speed 'should' alter the code so that the delays are correct (setup of the display takes ~1s) - and the sign it is working correctly is a display of 'random' data. Once we have that it works smoothly - but if not then something in the setup is incorrect.
If changing the 'clock' in properties makes delays take the wrong amount of time then something in the configuration is wrong...

Please check that you can get a 1s 'flasher' (pin = 1, delay(1s) pin = 0, delay(1s)) program working to confirm the oscillator settings....

Martin

[WingNut]

Would you have a look?

[WingNut]

I ran through the various clock frequency options this morning. It def looks like a timing issue. The 1 MHz clock looks like 1 sec flasher but probably is a little longer. Change to 2MHz and the delay is significant longer on the flasher so as I'd said previously with the 40MHz option its prob so long that it looks like its on permanently

[mnfisher]

Yes, a problem with the configuration bits.. The delay will pause for a number of instructions calculated from the clock speed setting. Doubling, to 2MHz, will double the number needed to give the same delay - but if the actual speed stays at 1MHz then the delays will double in duration ...
I notice that when I program my board - the programmer gives the message 'no configuration found' - it is possible to write the data from a C block with 'Register = 0x1244' - so something not right with my PIC setup either...