Forum Rule: Always post complete source code & details to reproduce any issue!
Page 10 of 17 FirstFirst ... 8 9 10 11 12 ... LastLast
Results 226 to 250 of 418

Thread: ILI9488_t3 - Support for the ILI9488 on T3.x and beyond...

  1. #226
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,477
    @KurtE, @....

    If you been following the other thread you all know about me playing with the HDMI shield (1280x720). Anyway, library needs some work and so do I in understanding whats going on but that is another story. Right now trying to figure out to get something like print and println to work with the library. If I just do a "Class ….. : public Print" it gets upset:
    Code:
    In file included from D:\Users\Merli\Documents\Arduino\T4\HDMI\HDMI.ino:1:0:
    
    D:\Users\Merli\Documents\Arduino\libraries\Ra8876_Lite\src/Ra8876_Lite.h:600:20: error: cannot declare variable 'ra8876lite' to be of abstract type 'Ra8876_Lite'
    
     extern Ra8876_Lite ra8876lite;
                        ^
    
    D:\Users\Merli\Documents\Arduino\libraries\Ra8876_Lite\src/Ra8876_Lite.h:143:7: note:   because the following virtual functions are pure within 'Ra8876_Lite':
     class Ra8876_Lite : Print
           ^
    
    In file included from F:\arduino-1.8.9\hardware\teensy\avr\cores\teensy4/Stream.h:24:0,
                     from F:\arduino-1.8.9\hardware\teensy\avr\cores\teensy4/HardwareSerial.h:106,
                     from F:\arduino-1.8.9\hardware\teensy\avr\cores\teensy4/WProgram.h:46,
                     from C:\Users\Merli\AppData\Local\Temp\arduino_build_572241\pch\Arduino.h:6:
    
    F:\arduino-1.8.9\hardware\teensy\avr\cores\teensy4/Print.h:58:17: note: 	virtual size_t Print::write(uint8_t)
    
      virtual size_t write(uint8_t b) = 0;
                     ^
    HDMI:40: error: cannot declare variable 'hdmi' to be of abstract type 'Ra8876_Lite'
     Ra8876_Lite hdmi(RA8876_XNSCS, RA8876_XNRESET, RA8876_MOSI, RA8876_MISO, RA8876_SCK);
    
                 ^
    Anyone have any ideas. Also how does that really work when I have execute another function to send it to the display?

  2. #227
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,876
    Hi Mike: Do you have public Print?

    The message is showing:

    Code:
    D:\Users\Merli\Documents\Arduino\libraries\Ra8876_Lite\src/Ra8876_Lite.h:143:7: note:   because the following virtual functions are pure within 'Ra8876_Lite':
     class Ra8876_Lite : Print
    Also do you have the function:
    Code:
    	virtual size_t write(uint8_t);
    Which is the actual function print uses to tell you the next byte to output.

  3. #228
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,477
    Hi Kurt

    Well in between taking care of my little one today - when she lets me I am working on this

    Anyway - had the public Print but didn't have the "virtual size_t write(uint8_t)" in the .h. Added that in and got this which is preventing compile:

    Code:
    C:\Users\Merli\AppData\Local\Temp\arduino_build_779226\libraries\Ra8876_Lite\Ra8876_Lite.cpp.o: In function `Ra8876_Lite::Ra8876_Lite(unsigned char, unsigned char, unsigned char, unsigned char, unsigned char)':
    
    D:\Users\Merli\Documents\Arduino\libraries\Ra8876_Lite\src/Ra8876_Lite.cpp:388: undefined reference to `vtable for Ra8876_Lite'
    
    collect2.exe: error: ld returned 1 exit status
    Know I came across vtable before but can't remember where.

    EDIT
    .cpp:
    Code:
    Ra8876_Lite::Ra8876_Lite(uint8_t xnscs, uint8_t xnreset, uint8_t mosi, uint8_t miso, uint8_t sck):
    _xnscs(xnscs), _xnreset(xnreset), _mosi(mosi), _miso(miso), _sck(sck){}
    .h
    Code:
      Ra8876_Lite(uint8_t xnscs, uint8_t xnreset, uint8_t mosi, uint8_t miso, uint8_t sck);
    Last edited by mjs513; 06-18-2019 at 05:29 PM.

  4. #229
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,477
    @KurtE
    Ok - figured it out. Now I have to write a function for write(size_t). Thanks for you help Kurt - pieces finally clicked in my dense head

  5. #230
    Member
    Join Date
    Jan 2015
    Location
    Toms River, NJ USA
    Posts
    33
    Gents, Forgive me for being a bit off topic here. Feel free to throw me out or point me elsewhere if appropriate. I'm lurking and trying to grok as much of this thread as I can. Most of it is way over my head, but I sincerely appreciate all the hard work I'm seeing here!!!!.

    I'm trying to piece together a Teensy (3.2?) & 9488 based o'scope with a generic Chinese board using the XPT2046 and would like to use some of the cool GUI stuff from LittlevGL (https://littlevgl.com/) but that might be overkill. Being a relative noob, I realize I've got a lot of work & learning to do.

    So after looking thru this thread, I couldn't see if anyone actually got the tri-state buffer board to work, as the LittlevGL library requires the FB. Is that mod possible without display board cut / strap mods?

    Is there a stable version / demo I can try with my T3.2? I also have a T3.6 if T3.2 isn't possible. Assume I'll need external FB RAM.

    Cheers

  6. #231
    Junior Member
    Join Date
    Dec 2016
    Posts
    13
    I have a working LittleVGL setup on Teensy 3.6 using a generic ILI9341 with an XPT2046 touch. Perhaps you could start a new thread and I can share my driver setup.

    Cheers

  7. #232
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,477
    Quote Originally Posted by prickle View Post
    I have a working LittleVGL setup on Teensy 3.6 using a generic ILI9341 with an XPT2046 touch. Perhaps you could start a new thread and I can share my driver setup.

    Cheers
    @prickle,
    You can actually start a new thread yourself to share your driver setup. Real easy to do. Go to the forum and click on the "Main Category" that you want to start the thread. In this case probably "General Discussion". Then once in that category, click on "+Post New Thread" and a new thread will be started once you put in a title and the text you want to add. Think it would be a good to let people on the forum what you did to get it working etc...

  8. #233
    Junior Member
    Join Date
    Sep 2014
    Posts
    15
    Quote Originally Posted by mjs513 View Post
    @prickle,
    You can actually start a new thread yourself to share your driver setup. Real easy to do. Go to the forum and click on the "Main Category" that you want to start the thread. In this case probably "General Discussion". Then once in that category, click on "+Post New Thread" and a new thread will be started once you put in a title and the text you want to add. Think it would be a good to let people on the forum what you did to get it working etc...
    @prickle,

    I would love to see what you did here.

  9. #234
    Member
    Join Date
    Jan 2015
    Location
    Toms River, NJ USA
    Posts
    33
    @prickle,
    Stop bloody teasing us! :-)

    Of course - We would love to see what you've done.

    As mjs513 suggested, you are probably the best one to start a new thread. However, I'd be happy to do so if you will add your insights!

  10. #235
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,477
    Quote Originally Posted by dslocum View Post
    @prickle,
    Stop bloody teasing us! :-)

    Of course - We would love to see what you've done.

    As mjs513 suggested, you are probably the best one to start a new thread. However, I'd be happy to do so if you will add your insights!
    He did. Here is the link: https://forum.pjrc.com/threads/56650...eVGL-on-Teensy

    As soon as get some time going to give a try

  11. #236
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,477
    @KurtE - @defragster

    Now that I figured out the right connections for touch I hooked up a tri-state buffer to the graphics line of the 9488 and ran the touchtest from the XPT2046 lib and the 9488-touchtest that was posted in this thread. The tristate buffer worked like a charm got graphics and touch working with the 9488 on the latest T$. Wasn't sure where to post here or on the other thread.

    Mike

  12. #237
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,876
    @mjs513 - glad it is working!

  13. #238
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,477
    Quote Originally Posted by KurtE View Post
    @mjs513 - glad it is working!
    Me too. Now I have to design some sort of adapter or shield. Can't keep using the mess of wires.

  14. #239
    Member
    Join Date
    Jan 2015
    Location
    Toms River, NJ USA
    Posts
    33
    @mjs513 - Could you summarize this for both my benefit and others that may follow please?

    What (if any) modifications to TFT boards might be required? What TFT board(s) have you tried? Do you have a "final" schematic for what you've done?

    Thanks

  15. #240
    Member
    Join Date
    Jan 2015
    Location
    Toms River, NJ USA
    Posts
    33
    I'd be happy to whip up something for the community and order PCBs if that would help.

  16. #241
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,477
    Hi @dslocum

    Sorry took so long to get back to you but anyway the tri-state buffer issue that we are talking about is related to the ILI9488 display that we got from Aliexpress and first identified in this thread: https://forum.pjrc.com/threads/54711...l=1#post199521.

    If you never came across this issue before suggest that you check this page out: https://www.pjrc.com/better-spi-bus-design-in-3-steps/. The basic design is based on the circuit described in this post: https://forum.pjrc.com/threads/55735...l=1#post203066. But used TFT_CS and TFT_MISO lines with the buffer.

  17. #242
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,876
    @defragster, @mjs513...

    Thought maybe should continue maybe here for the stuff from T4 thread:
    @KurtE and @defragster

    Actually its the exact same one . Think when I was researching earlier I saw that it was a ILI9486 but saw one post that said for an earlier model it was a ILI9341. Just came across this if you want to check this implementation out: https://github.com/lzto/RaspberryPi_KeDei_35_lcd_v62.

    You all might find these links interesting:
    https://www.raspberrypi.org/forums/v...?f=44&t=124961
    https://github.com/saper-2/rpi-spi-lcd35-kedei
    https://github.com/notro/fbtft

    EDIT: Found the link I was looking for. You might find this schematic interesting for the display: https://github.com/wdim0/esp8266_wit...ter/schema.jpg

    Basically the DC is on u1 (74HC595) - u1-02. Beginning to get the feeling that this display is rather unique in the way it does things.
    Yes looks pretty unique! It is running whatever the display is in 8 bit or 16 bit mode, but talking to through the other chips using a pseudo SPI...

    So it might sort of be a dead end... Unless someone really want it...

    Update on 3 wire SPI and the ILI9488... I was wrong on the speed part. That is every 9 bit byte has the upper bit as DC pin. So the 18 bit color is output still with three bytes where each byte is something like:
    <DC=1> <R5><R4><R3><R2><R1><R0>0 0 So extra clocks...

    But regardless of 3 wire or 4 wire SPI on T4 we are already doing the transfers of 24 bits per color using one FIFO queue entry (normal SPI), could do same with 27 bit if need be... Still want to figure out if we can setup better gaps between transfers.

  18. #243
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,876
    Update: However I see when we do Asynch updates (DMA) we are doing 8 bit transfers... Wondering if it might speed it up if I instead do my filling of the DMA buffer.

    If you remember I use a secondary buffer (probably two), where I convert the 565 format (16 bit) pixels into 3 bytes and do the DMA with 8 bit values. Wonder if it would make sense to try setting up these secondary buffers as 32 bit and pack the data into 24 bits and do the transfers that way? Maybe worth a try to get an idea if it works and if it speeds it up...

    EDIT: But obviously only on T4 as T3.x do not allow SPI transfers of 24 bits.

  19. #244
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,477
    Quote Originally Posted by KurtE View Post
    @defragster, @mjs513...

    Thought maybe should continue maybe here for the stuff from T4 thread:


    Yes looks pretty unique! It is running whatever the display is in 8 bit or 16 bit mode, but talking to through the other chips using a pseudo SPI...

    So it might sort of be a dead end... Unless someone really want it...

    Update on 3 wire SPI and the ILI9488... I was wrong on the speed part. That is every 9 bit byte has the upper bit as DC pin. So the 18 bit color is output still with three bytes where each byte is something like:
    <DC=1> <R5><R4><R3><R2><R1><R0>0 0 So extra clocks...

    But regardless of 3 wire or 4 wire SPI on T4 we are already doing the transfers of 24 bits per color using one FIFO queue entry (normal SPI), could do same with 27 bit if need be... Still want to figure out if we can setup better gaps between transfers.
    Well for a goof I decided to give it a try as is to see what would happen. Well, as expected it did not work using the ILI9488 lib and your colortest or the graphicstest sketch. With the colortest sketch the screen blinked when the LED lit up so it did something. With the graphicstest sketch got the following for diagnotics:
    Code:
    Display Power Mode: 0x87
    MADCTL Mode: 0x80
    Pixel Format: 0x87
    Image Format: 0x87
    Self Diagnostic: 0x87
    What can I tell you just couldn't resist trying to satisfy my curiosity. Am going to check one thing before I put it back in the box - what to check to see what its using for initialization and maybe put my makeshift logic analyzer on it once I solder it up.

    Oh, BTW, did run the touch test and that worked fine as I expected since it doesn't go through the latch

    UPDATE:
    Looks like its a 9486 not a 9488 based on the initialization commands. Ref:https://github.com/notro/fbtft/blob/master/fb_ili9486.c about line 33. So tempted to change it in the 9488 lib to see what happens . Maybe later today.
    Last edited by mjs513; 06-30-2019 at 02:25 PM.

  20. #245
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,876
    Quote Originally Posted by mjs513 View Post
    Well for a goof I decided to give it a try as is to see what would happen. Well, as expected it did not work using the ILI9488 lib and your colortest or the graphicstest sketch. With the colortest sketch the screen blinked when the LED lit up so it did something. With the graphicstest sketch got the following for diagnotics:
    Code:
    Display Power Mode: 0x87
    MADCTL Mode: 0x80
    Pixel Format: 0x87
    Image Format: 0x87
    Self Diagnostic: 0x87
    Question - The schematic does not show any MISO pin or logic? So not sure where these are coming from?

  21. #246
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,477
    @KurtE
    This link https://www.raspberrypi.org/forums/v...?f=44&t=124961 has the whole schematic. It shows MISO going to the touch but don't see where it goes to the controller.

  22. #247
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,876
    @mjs513

    Yep I only see MISO going to XPT... So wonder is CS of XPT high? Or wonder with some of those other signals like DC on other byte if maybe there are more additional chips taking Data the other direction...

    I have my current display setup I added some of the DMA testing to my clip/output test and have that working...

    Than it reminded me that our current version of code, is always using a Pallet to output colors, as non of the processors up to T4B2 had enough memory to allocate full buffer... Wonder if we should make version that allocates full memory?

  23. #248
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,477
    Quote Originally Posted by KurtE View Post
    @mjs513

    Yep I only see MISO going to XPT... So wonder is CS of XPT high? Or wonder with some of those other signals like DC on other byte if maybe there are more additional chips taking Data the other direction...

    I have my current display setup I added some of the DMA testing to my clip/output test and have that working...

    Than it reminded me that our current version of code, is always using a Pallet to output colors, as non of the processors up to T4B2 had enough memory to allocate full buffer... Wonder if we should make version that allocates full memory?
    Hmm. Didn't think of that for the XPT CS pin. Best I could do was get screen to go blank Will have to look at the code some more. Getting some 595 chips today so have to play around with them eventually.

    Would be interesting to see what the improvements are if you allocate full memory.

  24. #249
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,477
    @KurtE

    Found some code that should work with an ESP32 that might be modified for the T4 - this is an exercise in curiosity of course: https://www.raspberrypi.org/forums/v...19562#p1019562

  25. #250
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,477
    @KurtE - @defragster
    Think I converted the esp32 code correctly, still can only get the screen to dim and then brighten up, tried T4 and T3.6. Heres the code if you want to give it a try:
    Code:
    #include <SPI.h>
    SPISettings settingsA(4000000, MSBFIRST, SPI_MODE0);
    
    #define SPI_MOSI 11   //blue
    #define SPI_SCLK 13   //grey
    #define SPI_SS_L 10    //brown
    
    uint8_t lcd_rotations[4] = {
      0b11101010, //  0
      0b01001010, // 90
      0b00101010, //180
      0b10001010  //270
    };
    volatile uint8_t lcd_rotation;
    volatile uint16_t lcd_h;
    volatile uint16_t lcd_w;
    
    uint16_t colors[17] = {
      0b0000000000000000,        /* BLACK   000000 */
      0b0000000000010000,        /* NAVY    000080 */
      0b0000000000011111,        /* BLUE    0000ff */
      0b0000010011000000,        /* GREEN   009900 */
      0b0000010011010011,        /* TEAL    009999 */
      0b0000011111100000,        /* LIME    00ff00 */
      0b0000011111111111,        /* AQUA    00ffff */
      0b1000000000000000,        /* MAROON  800000 */
      0b1000000000010000,        /* PURPLE  800080 */
      0b1001110011000000,        /* OLIVE   999900 */
      0b1000010000010000,        /* GRAY    808080 */
      0b1100111001111001,        /* SILVER  cccccc */
      0b1111100000000000,        /* RED     ff0000 */
      0b1111100000011111,        /* FUCHSIA ff00ff */
      0b1111111111100000,        /* YELLOW  ffff00 */
      0b1111111111111111,        /* WHITE   ffffff */
      0b0000000000000000         /* BLACK   000000 */ //added to fix my poor coding (color+1)
    };
    
    uint8_t color;
    
    uint8_t buf[54];
    uint16_t p, c;
    uint32_t isize, ioffset, iwidth, iheight, ibpp, fpos, rowbytes;
    
    
    void lcd_rst(void) {
      SPI.beginTransaction(settingsA);
      digitalWrite(SPI_SS_L, LOW); SPI.transfer(0); digitalWrite(SPI_SS_L, HIGH); delay(25);
      SPI.endTransaction();
      SPI.beginTransaction(settingsA);
      digitalWrite(SPI_SS_L, LOW); SPI.transfer(1); digitalWrite(SPI_SS_L, HIGH); delay(25);
      SPI.endTransaction();
    }
    void lcd_cmd(uint8_t cmd) {
      SPI.beginTransaction(settingsA);
      digitalWrite(SPI_SS_L, LOW); SPI.transfer(cmd>>1); SPI.transfer(0x11+((cmd&1)<<5)); digitalWrite(SPI_SS_L, HIGH);
      SPI.endTransaction();
    
      SPI.beginTransaction(settingsA);
      digitalWrite(SPI_SS_L, LOW); SPI.transfer(cmd>>1); SPI.transfer(0x1B+((cmd&1)<<5)); digitalWrite(SPI_SS_L, HIGH);
      SPI.endTransaction();
    
    }
    void lcd_dat(uint8_t dat) {
      SPI.beginTransaction(settingsA);
      digitalWrite(SPI_SS_L, LOW); SPI.transfer(dat>>1); SPI.transfer(0x15+((dat&1)<<5)); digitalWrite(SPI_SS_L, HIGH);
      SPI.endTransaction();
      SPI.beginTransaction(settingsA);
      digitalWrite(SPI_SS_L, LOW); SPI.transfer(dat>>1); SPI.transfer(0x1F+((dat&1)<<5)); digitalWrite(SPI_SS_L, HIGH);
      SPI.endTransaction();
    }
    void lcd_color(uint16_t col) {
      SPI.beginTransaction(settingsA);
      digitalWrite(SPI_SS_L, LOW); SPI.transfer16(col); SPI.transfer(0x75); digitalWrite(SPI_SS_L, HIGH);
      SPI.endTransaction();
      SPI.beginTransaction(settingsA);
      digitalWrite(SPI_SS_L, LOW); SPI.transfer16(col); SPI.transfer(0x7F); digitalWrite(SPI_SS_L, HIGH);
      SPI.endTransaction();
    }
    void lcd_init(void) {
      //reset display
      lcd_rst();
      Serial.println("Reset");
      lcd_cmd(0x00);
      lcd_cmd(0x11);delay(1); //Sleep Out
      lcd_cmd(0xEE); lcd_dat(0x02); lcd_dat(0x01); lcd_dat(0x02); lcd_dat(0x01);
      lcd_cmd(0xED); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x9A); lcd_dat(0x9A); lcd_dat(0x9B); lcd_dat(0x9B); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0x00); lcd_dat(0xAE); lcd_dat(0xAE); lcd_dat(0x01); lcd_dat(0xA2); lcd_dat(0x00);
      lcd_cmd(0xB4); lcd_dat(0x00);
      lcd_cmd(0xC0); lcd_dat(0x10); lcd_dat(0x3B); lcd_dat(0x00); lcd_dat(0x02); lcd_dat(0x11);
      lcd_cmd(0xC1); lcd_dat(0x10);
      lcd_cmd(0xC8); lcd_dat(0x00); lcd_dat(0x46); lcd_dat(0x12); lcd_dat(0x20); lcd_dat(0x0C); lcd_dat(0x00); lcd_dat(0x56); lcd_dat(0x12); lcd_dat(0x67); lcd_dat(0x02); lcd_dat(0x00); lcd_dat(0x0C);
      lcd_cmd(0xD0); lcd_dat(0x44); lcd_dat(0x42); lcd_dat(0x06);
      lcd_cmd(0xD1); lcd_dat(0x43); lcd_dat(0x16);
      lcd_cmd(0xD2); lcd_dat(0x04); lcd_dat(0x22);
      lcd_cmd(0xD3); lcd_dat(0x04); lcd_dat(0x12);
      lcd_cmd(0xD4); lcd_dat(0x07); lcd_dat(0x12);
      lcd_cmd(0xE9); lcd_dat(0x00);
      lcd_cmd(0xC5); lcd_dat(0x08);
      
      lcd_setrotation(0);
      lcd_cmd(0x29);delay(2); // Display On
      lcd_cmd(0x00);   // NOP
      lcd_cmd(0x11);delay(1); // Sleep Out
    }
    
    //lcd_fillframe
    //fills an area of the screen with a single color.
    void lcd_fillframe(uint16_t x, uint16_t y, uint16_t w, uint16_t h, uint16_t col) {
      int span=h*w;
      lcd_setframe(x,y,w,h);
      for(int q=0;q<span;q++) { lcd_color(col); }
    }
    
    void lcd_setframe(uint16_t x, uint16_t y, uint16_t w, uint16_t h) {
      lcd_cmd(0x2A);
      lcd_dat(x>>8); lcd_dat(x&0xFF);
      lcd_dat(((w+x)-1)>>8); lcd_dat(((w+x)-1)&0xFF);
      lcd_cmd(0x2B);
      lcd_dat(y>>8); lcd_dat(y&0xFF);
      lcd_dat(((h+y)-1)>>8); lcd_dat(((h+y)-1)&0xFF);
      lcd_cmd(0x2C);
    }
    
    
    
    
    
    void lcd_setrotation(uint8_t m) {
      lcd_cmd(0x36); lcd_dat(lcd_rotations[m]);
      if (m&1) {
        lcd_h = 480;
        lcd_w = 320;
      } else {
        lcd_h = 320;
        lcd_w = 480;
      }
    }
    
    
    void setup() {
      //SPIFFS.begin();
      pinMode(SPI_SS_L,OUTPUT);
      //pinMode(SPI_SCLK,OUTPUT);
      //pinMode(SPI_MOSI,OUTPUT);
      digitalWrite(SPI_SS_L, HIGH);
      color=0;
      lcd_rotation=0;
      SPI.begin();
    
      Serial.begin(115200);
      delay(2000);
      Serial.println("Starting....");
      lcd_init();
      Serial.println("Initialized....");
    
      lcd_fillframe(0,0,480,320,0); //black out the screen.
      //lcd_img("/boot.bmp", 50, 5);
    }
    
    void loop() {
    
      //Update rotation
      lcd_setrotation(lcd_rotation);
      Serial.println("Rotated");
      //Fill entire screen with new color
      lcd_fillframe(0,0,lcd_w,lcd_h,colors[color]);
    
      //Make a color+1 box, 5 pixels from the top-left corner, 20 pixels high, 95 (100-5) pixels from right border.
      lcd_fillframe(5,5,lcd_w-100,20,colors[color+1]);
    
      //increment color
      color++;
      //if color is overflowed, reset to 0
      if (color==16) {color=0;}
    
      //increment rotation
      lcd_rotation++;
      //if rotation is overflowed, reset to 0
      if (lcd_rotation==4) lcd_rotation=0;
    
      delay(500);
    }

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •