Forum Rule: Always post complete source code & details to reproduce any issue!
Page 7 of 7 FirstFirst ... 5 6 7
Results 151 to 157 of 157

Thread: Playing around with yet another version of ILI9341_t3 library (ILI9341_t3n)

  1. #151
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,989
    The problem we run into with the fonts is, they #include header files.

    That is for example you use the fonts Ariel_bold, its header file starts off like:
    Code:
    #ifndef _ILI9341_t3_font_ArialBold_
    #define _ILI9341_t3_font_ArialBold_
    
    #include "ILI9341_t3.h"
    So it includes the ili9341_t3 library, and you end up with lots of duplicates...

    I could maybe should fix this case by including these font files as well, and Actually I do, but I renamed them, as having them in two different libraries with same name, sometimes it got the right one and other times not... But for other font's, like the ones you can get from Paul's github: https://github.com/PaulStoffregen/ILI9341_fonts

    They are problematic, They start off with the same hard coded include: #include "ILI9341_t3.h"

    At one point I suggested that maybe we could split off the font definition out of the main include file:
    Code:
    typedef struct {
    	const unsigned char *index;
    	const unsigned char *unicode;
    	const unsigned char *data;
    	unsigned char version;
    	unsigned char reserved;
    	unsigned char index1_first;
    	unsigned char index1_last;
    	unsigned char index2_first;
    	unsigned char index2_last;
    	unsigned char bits_index;
    	unsigned char bits_width;
    	unsigned char bits_height;
    	unsigned char bits_xoffset;
    	unsigned char bits_yoffset;
    	unsigned char bits_delta;
    	unsigned char line_space;
    	unsigned char cap_height;
    } ILI9341_t3_font_t;
    Into it's own header file, that maybe again each ili93... like display driver would include, and/or maybe the font files don't reference a structure, but simply a set of bytes, and the internals to the display drivers could then cast...

  2. #152
    Junior Member
    Join Date
    Sep 2014
    Posts
    14
    Hi KurtE,

    There are several SPI based LCDs that use almost identical setup and structure to the ILI9341; for example the ST7796S.

    What is the practicality of seperating out the graphical and HAL layers from the device drivers and making the library "multi-use"?

    Or is it more practical to fork the library and make the appropirate changes for a specific display?

  3. #153
    Hello Kurt,

    with new versions of SPIN and LI9341_t3n from GitHub I get following error message:

    In file included from display_test.ino:8:0:
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\ILI934 1_t3n-master/ILI9341_t3n.h: In member function 'uint32_t ILI9341_t3n::frameCount()':
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\ILI934 1_t3n-master/ILI9341_t3n.h:354:32: error: '_dma_frame_count' was not declared in this scope
    uint32_t frameCount() {return _dma_frame_count; }
    ^
    Fehler beim Kompilieren.


    This was the code to compile with Teensyduino 1.45 on Win10 for teensy 3.2, 24Mhz optimise speed
    Code:
    /***************************************************
      Display Test ILI9341 for teensy 3.2, 
     ***************************************************/
    
    #include <Wire.h>
    #include <SPI.h>
    #include <SPIN.h>
    #include <ILI9341_t3n.h>
    
    
    #define TFT_DC  9
    #define TFT_CS 10
    
    ILI9341_t3n tft = ILI9341_t3n(TFT_CS, TFT_DC);      // display object
    
    const byte HELLIGKEITOUT = 6;                       // PWM-PIN für Helligkeitssteuerung
    uint8_t rotation = 3;                               // Displayorientierung 1 ist normal, 3 ist 180 Grad gedreht, init
    
    void setup() {
      tft.begin();
      tft.fillScreen(ILI9341_BLACK);                    // Display löschen
      tft.setRotation(rotation);                        // Displayorientierung setzen (0 oder 180 Grad)
      pinMode(HELLIGKEITOUT, OUTPUT);                   // init PWM-Ausgang Helligkeitssteuerung
      analogWrite(HELLIGKEITOUT, 256);                  // PWM full
    }
    
    void loop(void) {
      tft.setTextSize(3);
      tft.setTextColor(ILI9341_WHITE);                    // Test columns
      tft.setCursor(0,50); tft.print("Test 1st column");
      tft.setCursor(5,90); tft.print("Test 6th column");
      tft.setTextSize(2);
      tft.setCursor(0,130); tft.print("Test from 1st column");
      tft.setCursor(5,150); tft.print("Test from 6th column");
      while(1);                                           // Lock out
    }


    Can you look please.
    Thank you
    Larry
    Last edited by larry_berlin; 01-20-2019 at 03:17 PM.

  4. #154
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,989
    Sorry,
    I have not built for 3.2 for awhile now.

    There were a few places where the #ifdef was not correct to exclude some frame buffer code from those boards like 3.2 which do not have enough memory for frame buffers...

    Try syncing back up to the ili9341_t3n project.

  5. #155
    Senior Member
    Join Date
    Nov 2012
    Location
    Salt Lake City, UT, USA
    Posts
    259

    one solution: library management with Git

    Quote Originally Posted by larry_berlin View Post
    with new versions of SPIN and LI9341_t3n from GitHub I get following error message:
    This is why we always fork libraries critical to our project and then 'git clone' those forks into local working repos which are used to build our project. Then we are not at the mercy of updates which could unexpectedly change operation in a way that breaks our application. It puts us in the update driver seat. This doesn't directly address your question but it would prevent errors like the ones you mention from popping up at inopportune times. I'm just wrapping up an almost two-year long project and in the process of final documentation and then a Git "release". Then I can go catch all our forked libraries up to current versions for the next project... which might take a bit of doing. This project uses Teensy 3.2.

    Also if you fork all libraries into your own Git account and clone from that, you can make library branches or roll back versions relatively easily if you find a new update has broken backwards compatibility. We've had to do that more than once on this project. But happily this approach has worked well.

    SPIN and ILI9341_t3n look interesting. On Teensy 3.2 there is only one SPI instance... so I wonder why you are using SPIN with it.

  6. #156
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,989
    Hi @bboyes - Sounds like you have been working on a pretty large project...

    Yes if I were doing anything commercial I too would fork projects and keep versions that I used on a project, so I could selectively update and/or be able to go back to the sources that I used to release a project... But I am retired so I only do this for my own fun.

    Why SPIN and ILI0341_t3n on T3.2 with only one SPI Instance? More back to history of this. These were originally done when I was doing testing for the Teensy 3.6 beta (and later 3.5 beta), which have more than one SPI instance, and I wanted to be able to test the other instances... I got tired of doing the approach of editing source code and change all instances of SPI to SPI1 or SPI2... So wanted a version of library that would work on all of them.

    But at the time SPI and SPI1 and SPI2 were not derived from some common base class so I could not pass in pointers to which SPI object to use. They were all something like: spi_class, spi1_class, ... So I did a quick and dirty wrapper class SPIN, which first pass was real stupid, where all of the methods were virtual, and a created sub classes for each of the SPI objects, which each of the sub-classes called the underlying SPI. or SPI1. or ... functions, which worked for this purpose.
    I also wanted to have some of the FIFO queue functions in here that Paul had put into the ili9341_t3 library as I was seeing versions of it popping up in several other libraries and wanted to not have to replicate them. Also again they may change depending on which object you are using, as SPI on 3.5/6 had different queue lengths depending on which SPI object you were using.

    But then Paul later updated the I2C objects (Wire) to have one base class and be data driven, which I liked, so I redid my SPIN objects to do that, which worked well. Once that was working, we then moved these data objects (hardware) and code to use back into SPI, which now has must of the SPIN functionality. Actually I think it has some of the additional information like queue size still in tables, but may not yet use it. As for T3.2? I simply wanted to make sure everything works and if there are other features of the ili9341_t3n that the hardware could handle on T3.2 that you wish to use, you could.

    So in a lot of ways, I would like to be able to remove SPIN and just use SPI, and may get there at some point, and maybe just have SPIN for FIFO handling..

    Some of the things in the ili9341_t3n library that I don't think are yet in ili9341_t3 library? Some of these have (or had) PR requests back into main library but...

    a) Can work using just one hardware CS pin (used on DC signal) - Needed on SPI1 on 3.6 as there was only 1 (unless you used SDCard adapter). Likewise you did not have to setup to use MISO pin (if you don't want to connect it up, some commands like readPixel and readRect won't work...

    b) Frame buffer (The main thing you can not use as part of T3.2 as it does not have enough memory), and likewise the Asynchronous screen updates using DMA can not work either...

    c) I integrated in some of the other Pull Requests that or issues I saw on the ili9341_t3 library that I don't believe ever made it into the mainline library. Things like:
    1) being able to setup an offset and a clipping rectangle and have all of the primitives use them.
    2) Opaque Text with fonts - Put support in to draw the characters with the background color set, which will set those bits not defined to background color in the same way the main font does... But I probably would not put this in to main one without clip rectangle as some of the font's define a large interline spacing which gets set to background color, which you may not want

    I think many of the others were migrated back into ili9341_t3 library like drawRect with different pixel counts and some gradient fills and ...

    Sorry for the long winded answer

  7. #157
    Thank you KurtE and bboyes for your efforts.
    I loaded the forked ILI9341_t3n from bboyes, that works for me.

    best regards

Posting Permissions

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