1.8" Adafruit Library query

Other Hardware Displays
1

Hi all,

I've successfully connected a 1.8" tft display, and have it displaying almost everything I want. In addition, I've connected a Chinese bought rotary encoder, which displays perfectly through the serial monitor. To really round out the experience, I can even get the display to emulate the serial monitor. Wow! What a great time I'm having.....

But, the serial monitor emulation only goes so far. My objective is to have a static display of the encoders activity at x,y co-ordinate on the tft display. What happens instead is that as I rotate the encoder, the serial monitor continues to scroll off the screen and print fresh numbers at the bottom of the window. No such luck with the display. The display fills until the bottom of it's screen, then although it's probably still outputting, it has nowhere to go, and the new co-ordinates aren't seen.

void loop() 

{
  boolean encoderA = digitalRead(encoderPinA);

  if ((encoderALast == HIGH) && (encoderA == LOW))
  {
    if (digitalRead(encoderPinB) == LOW)
    {
      encoderPos--;
    }
    else
    {
      encoderPos++;
    }
    angle=(encoderPos % encoderStepsPerRevolution)*360/encoderStepsPerRevolution;
    Serial.print (encoderPos);
    Serial.print (" ");
    Serial.println (angle);
  // tft.setCursor(10,10);
 // tft.setTextColor(ST7735_RED);
  tft.setTextSize(1);
     tft.print ("          ");
     tft.print (encoderPos);
    tft.print (" ");
    tft.println (angle);
    
   
    //tft.print (encoderPos);
    
  }

I've attempted to write a blank section i.e. tft.print(" ") but this doesn't seem to help. I can make it print in the same place each time, using tft.setCursor(x,y), which works except that it simply prints on top of the previous reading.

This can't be that complicated, but I'm starting to get frustrated, having made it this far.

I'd include links to the hardware, but since it's all working fine, I don't see any point.

Update: I've since also tried writing in the screen colour over the existing numbers, (as in a bouncing ball type program). The problem with doing this is that when the encoder stops moving, I'm left with black on black, which is difficult to read...

Any suggestions.....
Please......

2

Why did you comment out the setcursor command ?
You said you wanted a static position display so why
did you comment out the one part of the program
that could do that for you ? It's no different than
my DS18B20 temp display on my LCD. It doesn't
scroll.

3

I can make it print in the same place each time, using tft.setCursor(x,y), which works except that it simply prints on top of the previous reading.

Correct me if I'm wrong here but is the above not the definition of a static [position] display ?
If you are saying the new reading does not COMPLETELY overwrite the previous reading, ie; there is some part of old
reading still visible after new reading, then you need to add spaces in your lcd print statements or simply clear the
screen and initialize the cursor to the starting point before printing any coords.

4

The problem with the clear screen command is that it takes about 1.5 seconds to accomplish this. By this time, the encoder has moved on considerably.

I commented out the setCursor command as at least that way I was getting fast readings until the list hits the bottom of the screen. I've tried numerous permutations of setting screen position (works fine except that it overwrites on top of the previous reading), printing spaces, then printing the reading, (same as previous), and as you've observed, commenting out the setcursor command, but then it scrolls down to the bottom of the screen and does not continue to update as per the serial monitor.

What does seem to work, but with the wrong results is setting the text colour to the same as the screen, printing the previous reading, changing the text colour and printing the new reading. The snag with this is that no matter which way round I attempt this, I invariably end up with black on black when the encoder stops moving.

This isn't a particularly "mission critical" requirement. I'm very much at the start of a very long learning curve. As such, I'm attempting to "glue" various bits and pieces (either salvage, or cheap Chinese stuff) together, and make them work. I did try this routine with a 16x2 lcd display, and it worked perfectly, except that of course the display is much too slow if I spin the encoder. But at least I get a formatted reading in the same place, and if I were to use that in a working system, the Arduino would be monitoring the numbers, not me. I'd only be looking at it when it stopped or when it slowed as whatever was moving was instructed to do so.

I'm presently attempting to put some led displays together to accomplish the same objective. Unfortunately, they're 15 year old Korean job lots with no data sheet. (Can't even tell if they're Common Anode or Cathode). I have worked out the pin outs, and can get the segments to light individually without excessive brightness, but don't seem to be able to get a "Arduino Cookbook" sketch to work to light a number. I'll persevere.

Incidentally, you mention that you're using a SPI temp sensor. Two things occur to me on this topic. First is that unless you drop the sensor into a boiling kettle, the rate of change isn't going to be as fast as the encoder I'm using. But secondly, and of more curiosity to me; I know the purpose of SPI is that you can have numerous devices on the same bus. I've done a bit of reading on the subject, but haven't absorbed as much as I'd like to. How do you address the appropriate device? I wouldn't want to think I'm talking to a led driver chip, only to discover that I'm sending my stepper motor into reverse at high speed.

5

Change from

// tft.setCursor(10,10);
 // tft.setTextColor(ST7735_RED);

to

tft.setCursor(10,10);
tft.setTextColor(ST7735_RED, ST7735_BLACK); // first colour is font, second is background

its a nice feature of the adafruit libs that you can set foreground and background colour in one command. Of course this can fall foul if your variable length is not always the same, if so your options are:

  1. Store and reprint the old values in background font colour before you update the new values
  2. use the graphics library to print a rectangle over the display area
  3. Force your variable values to always be the same length (I use this one, but Im using a float variable to output decimals)

On the SPI front, each device being used has its own chip/slave select line. (You'll often see the terms used interchangeably, CS or SS).

PS. Im no expert, just a shaved monkey who has bashed his head against the desk a few times whilst sorting a display out

6

Be careful what you ask for.
Attached are two datasheets and two programs.
Check TABLE 4-1 on pg 29 for Memory Map showing the addresses.
Since on page 2 the device I am using (MCP4162-103-P) is listed as having a NV Wiper (Non-Volatile wiper),
that means the NV wiper commands will work and the NV addresses are valid. It doesn't mean it doesn't
have a VOLATILE memory, just that it ALSO has a NV memory.
When you look at TABLE 7-2 on pg 46 of Memory Map and supported commands, you will see there is no
nothing in the INCREMENT WIPER/DECREMENT WIPER, which is because in TABLE 7-1 on page 45 it
shows the commands and the Increment/Decrement commands don't require data because you are
telling it to add 1 or subtract 1 from the previously written value.
So to answer your question "How do you know what device you are talking to ?" In this case it is simply
address 0 for this device (or 02 for NV command)
The DS18B20 is a completely different story, since each device has a unique 64-bit serial code (see pg-1).
see pg-6 for following:

64-BIT LASERED ROM CODE
Each DS18B20 contains a unique 64–bit code (see Figure 6) stored in ROM. The least significant 8 bits of the ROM code contain the DS18B20’s 1-Wire family code: 28h. The next 48 bits contain a unique serial number. The most significant 8 bits contain a cyclic redundancy check (CRC) byte that is calculated from the first 56 bits of the ROM code. A detailed explanation of the CRC bits is provided in the CRC Generation section. The 64-bit ROM code and associated ROM function control logic allow the DS18B20 to operate as a 1-Wire device using the protocol detailed in the 1-Wire Bus System section.

Figure 6. 64-Bit Lasered ROM Code
8-BIT CRC | 48-BIT SERIAL NUMBER | 8-BIT FAMILY CODE (28h) |
MSB LSB | MSB LSB | MSB LSB |

I wouldn't want to think I'm talking to a led driver chip, only to discover that I'm sending my stepper motor into reverse at high speed.

See page 7 of 22 for the explanation of reading & writing to the device and Figure 7 for the DS18B20 Memory Map.
If you can figure out how to write to the device I would love to know but I have only been using C++ for 3 months
and am not that far along. The attached program I am using is one I found on the Net and uses the "RequestTemperature"
command, so I am not writing the Alarm Registers.

DS18B20.pdf (334 KB)

DS18B20_Serial_Temp_Multibple_ok.ino (3.05 KB)

MCP4162-103E-P.pdf (1.55 MB)

FIVE_MCP4162_P_Digital_Pots_dly_10_ino.ino (2.54 KB)

7

I had the same problem.
Thanks for the message with ("textcolor, background").

8

Be careful what you ask for indeed! Something tells me that my learning curve not only increased even further exponentially, but that now I'm supposed to grease the soles of my shoes whilst scaling it.

Grateful thanks to all who have responded. I'll persevere, and continue to pile cliche upon cliche as I attempt to convince myself that I do indeed learn more from my mistakes than my successes.