Question: how to store a large list of instructions?

Morning all!

Question: how to store a large list of instructions?

There is a great library for TFT screens by Henning Karlsen, and there is a drawing demo.

I want to be able to save these drawings (to an SD card, perhaps). That means storing for every drawn dot its X and Y coordinates, colour and "brush" thickness.

One way can be to declare a large enough array... Wondering if there is a better way?

Thanks!

I don't have the TFT or the library. Care to post a sample of a few lines of said instructions?

liudr - thank you for your reply.

I meant to ask this as a more general question about saving data.
A temperature vs time datalogger can produce a lot of data if set to sample often. Or if to cut a part on CNC mill manually and then be able to reproduce that part will require the mill capturing and storing lots of x/y/z points.

As for the screen - there are two drawing sketches, a very basic one, and another with more functions. The code for the basic sketch is indeed very simple, just "get" x and y coordinates from touchscreen and light a pixel at those coordinates. With the second, more advanced sketch user can set colour and brush size.

Hence all the dots on the screen are described by x/y coordinates (from 0 to 320 for x and from 0 to 240 for y), 8 possible colours and one of four brush sizes.

99, 120, 1, 1 - 99/120 are the coordinates, first colour (white) and brush 1 (smallest).

And here is the code from Henning Karlsens example:

#include <UTFT.h>
#include <UTouch.h>

UTFT        myGLCD(ITDB32S, 38,39,40,41);
UTouch      myTouch(6,5,4,3,2);

void setup()
{
  myGLCD.InitLCD();
  myGLCD.clrScr();

  myTouch.InitTouch();
  myTouch.setPrecision(PREC_MEDIUM);
}

void loop()
{
  long x, y;
  
  while (myTouch.dataAvailable() == true)
  {
    myTouch.read();
    x = myTouch.getX();
    y = myTouch.getY();
    if ((x!=-1) and (y!=-1))
    {
      myGLCD.drawPixel (x, y);
    }
  }
}

You store the instructions that you send to the TFT driver. Normally this would involve a start and end coordinate. Then the reply code (what ever it is ) would emulate this.
Alternately when you have finished do a bulk save of all the individual pixels. This will normally take up more space but is simpler.

This has been done many times in the past. Each with their own solution. None of them trivial. Postscript would be one example, but even Gcode would have similarities. It depends on how sophisticated you want your file format to be. By studying the methods used by other standards, maybe you can come up with a solution that is more suited to your own application.

Sure, thats exactly what I have in mind - store coordinates for every point!
One way to approach it would be to inset them in to an array, and then, once "Save" button is pressed commit it to an SDcard.
What I'm wondering if there is a better way than declaring something like "my_array[1000]"?

Sure, thats exactly what I have in mind - store coordinates for every point!
One way to approach it would be to inset them in to an array

Where are these coordinates coming from? Why not store them after each set arrives?

PaulS:

Sure, thats exactly what I have in mind - store coordinates for every point!
One way to approach it would be to inset them in to an array

Where are these coordinates coming from? Why not store them after each set arrives?

Yah, one big serial string can arrive to storage as each part comes.

Yah, one big serial string can arrive to storage as each part comes.

But, a point is defined by 3 coordinates. Parse three values from the stream, and save a point. No need to keep all the ints or floats in arrays in memory.

PaulS:

Yah, one big serial string can arrive to storage as each part comes.

But, a point is defined by 3 coordinates. Parse three values from the stream, and save a point. No need to keep all the ints or floats in arrays in memory.

I'd make it look like NC/CNC G-code. I guess that's still used. It is/was leading zero based, no decimal points.
X0001234
Y0000123
G02
etc

If a coordinate doesn't change, there's no need to specify that one until it does.

Dear Paul, to be honest I do not know for sure where the coordinates are coming from... Resistive touchscreen interacts with the uC via an ADC.
There are five lines betveen ADC and uC: DataIn, DataOut, Clock, SlaveSelect and TP_IRQ (a mysterious touchscreen interrupt). Looks like serial, right?
On uC side pins that these line connect to have to be declared before the Setup part of the sketch. This, and what I was able to decipher from the library leads me to believe that Henning Karlsen bitbanging serial connection. So in short - I'm not sure, where the data comes from, or how it comes, for that matter.
I do know however that it ends up "inside" functions myTouch.getX(); and myTouch.getY(); in form of integers ranging from 0 to 800 for 5 and 7 inch screens. Henning Karlsen in his sketch declared x and y as longs, but int works fine as well. If to declare them as bytes only part of the screen responds.
As to why not save all the points right when the become available... Thats how everyone seem to be doing it. There is a "Save" button in MSWord, in Arduino IDE, even in this very forum (save draft or post) :slight_smile: Guess only reason to hold data in memory is make possible to discard the picture instead of saving it.

Dear GoForSmoke, Gcode really sounds like an overkill. An almost full-screen (for my little 3.2in screen) image fits in to an array of 57600 (tried displaying picture of my horse: const unsigned short Russel [0xE100]). So it does work, but one super-mega-huge array is kind of a brute force solution.

AlfaOmega:
There are five lines betveen ADC and uC: DataIn, DataOut, Clock, SlaveSelect and TP_IRQ (a mysterious touchscreen interrupt). Looks like serial, right?

It looks exactly like SPI bus.

Dear GoForSmoke, Gcode really sounds like an overkill. An almost full-screen (for my little 3.2in screen) image fits in to an array of 57600 (tried displaying picture of my horse: const unsigned short Russel [0xE100]). So it does work, but one super-mega-huge array is kind of a brute force solution

I don't suggest any such thing as a huge array.
I suggest get the coordinates and immediately write them to SD as one long string, same as printing to serial monitor. What you write can be read back and used directly without buffering. Been there, done it.

I suggest only writing what changes, hence X before X coordinate value, Y before Y coordinate value and perhaps C before color value. I suggest not using decimal points.
G-code at heart is dead simple and runs on machines from the 60's if not before. Using leading zeros to encode values from high to low order allows sequential read with a minimum of interpretation. I know this because I programmed such machines as well as newer back 30+ years ago.

It's real basic stuff that does not require anything like as powerful as the smallest AVR you can get. We had punch tape but really a serial file on SD is just an electronic version that allows the equivalent of miles of tape in a tiny space.

If you're looking to save only bits that have changed, this i sounding suspiciously like a video codec.

KenF:
If you're looking to save only bits that have changed, this i sounding suspiciously like a video codec.

Huh?
Video codecs operate over areas of image using motion estimation, along with JPEG-like frequency domain compression.

Yes, you can save inputs in a smaller file or list than it would take to fully describe them all and it doesn't have to take a big complex scheme to do that. Just some thought.

You can try some run time encoding. This is where an image is represented by a number indicating the number of constitutive pixels in a raster scan that are white, followed by a number of pixels that are black and so on for the whole image. This works best on images with large blocks but it normally is a reduction on the full array.
You can restrect these numbers to a single byte, and have zero for the other colour when you have a run greater than 255.