TFT c++ framework

[Jim Lee]

I've been working on a project that is using the 2.8 TFT as a control panel. As development progressed, I started encapsulating the TFT stuff into a global "screen" class. This "lets make the screen easier to use" project morphed into "Hey, all these thing I've been doing are similar I can wrap everything together.." And now its grow almost into an Arduino OS that uses the TFT as the principal I/O device.

Its big, its a c++ framework that takes up about 20k of code space. But it has base classes for most everything I use. It runs the touchscreen code in the background. As well as base classes to run whatever else you want in the background. For example blinking LEDs & RC Servos. It has classes for objects to be draw on the screen, touchable controls, color management and low level tools like linked list base classes.

Anyway, its a work in progress, not all complete but the fundamental bits are running. I was just wondering if anyone would be interested in something like this. I find it extremely handy and wouldn't mind sharing.

I'm writing this tonight because I managed to break my TFT carrying it in my pocket from work to home so I'm waiting for my replacement to arrive, I'm bored..

-jim lee

[adafruit_support_bill]

Sounds like an interesting project. Post your results when you get it all running.

[Jim Lee]

Well here's an issue I've run into..

Code: Select all

//************* HARDWARE SPI ENABLE/DISABLE
// we want to reuse the pins for the SD card and the TFT - to save 2 pins. this means we have to
// enable the SPI hardware interface whenever accessing the SD card and then disable it when done
int8_t saved_spimode;

void disableSPI(void) {
  saved_spimode = SPCR;
  SPCR = 0;
}

void enableSPI(void) {
  SPCR = saved_spimode;
}

This is from the example bitmap read from the card thing. It looks to me that the first thing this does is slam an un-initialised value into the SPCR register. Are they backwards? Seems like if they were labeled the other way they would work better.

-jim lee

[pburgess]

SPCR is loaded (and SPI therefore enabled) in the SD card initialization function, which takes place fairly early in the program flow. Of the two functions shown, disableSPI() is always called first (based on the prior statement that SPI is already enabled), and enableSPI() afterward to put things back how they were when the SD library is in control. So no uninitialized slammage occurs.

[Jim Lee]

I don't see it. It looks like it saves the state of an already disabled SPI. Is it being enabled in some of the SD class files and that's where its getting its initial setup?

-jim lee

[adafruit_support_mike]

Yes.

The code snippet you posted only shows the function definitions. They aren't executed at that point in the code, any more than this:

Code: Select all

void printTwo (void) {
    printf "two.\n";
}

void printOne (void) {
    printf "one.\n";
}


would be expected to first print "two" then "one".

Functions only execute when invoked:

Code: Select all

void loop (void) {
    printOne();
    printTwo();
}


for instance.

For the SPI functions, enableSPI() gets called first, in the function that initializes the SD card. disableSPI() only gets called after that.

[Jim Lee]

No..

One more time. Here's the setup() method of the example sketch..

Code: Select all

void setup()
{

  Serial.begin(9600);
 
  tft.reset();
 
  // find the TFT display
  uint16_t identifier = tft.readRegister(0x0);
  if (identifier == 0x9325) {
    Serial.println("Found ILI9325");
  } else if (identifier == 0x9328) {
    Serial.println("Found ILI9328");
  } else {
    Serial.print("Unknown driver chip ");
    Serial.println(identifier, HEX);
    while (1);
  } 

  tft.begin();
  // the image is a landscape, so get into landscape mode
  tft.setRotation(1);

  Serial.print("Initializing SD card...");

  if (!SD.begin(SD_CS)) {
    Serial.println("failed!");
    return;
  }
  Serial.println("SD OK!");
 
  bmpFile = SD.open("tiger.bmp");

  if (! bmpFile) {
    Serial.println("didnt find image");
    while (1);
  }
 
  if (! bmpReadHeader(bmpFile)) {
     Serial.println("bad bmp");
     return;
  }
 
  Serial.print("image size ");
  Serial.print(bmpWidth, DEC);
  Serial.print(", ");
  Serial.println(bmpHeight, DEC);
  disableSPI();    // release SPI so we can use those pins to draw

  bmpdraw(bmpFile, 0, 0);
  // disable the SD card interface after we are done!
  disableSPI();
}

The first call is to disable the SPI, I'm asking, WERE is it originally being enabled? Because, from what I'm reading here, it has to be already enabled. Why is this you ask? Because this is the state we are saving and using to re-enable it.

-jim lee

[Jim Lee]

Forget it, I found it and see what your doing now.

-jim lee