I am looking at creating a moving graph on a graphic LCD of readings taken from an analogue input. The graph will be a line graph with area under the line filled in.
I will take the readings once a second and plot the reading (adjusted for the pixel height of display) with time on the x axis and reading magnitude on the y axis. As more readings are taken, the graph moves from left to right; moving the whole graph along one pixel at at time with the oldest value dropping off the right end and the new value showing at the left hand end.
The width of the graph, excluding legend and axes, would be around 200 pixels and therefore 200 readings. My first take on the logic was to update a circular list with each new value and then dump the 200 values to the LCD graph each reading (each second). However on second thoughts, this is rather inefficient in both 'CPU cycles' and RAM usage for the list.
Has anyone had any experience in this regard, who could shed some light on a more efficient method?
However on second thoughts, this is rather inefficient in both 'CPU cycles' and RAM usage for the list.
In what regards? Circular arrays are used a lot - that is how serial data is managed, for instance. Since the array size is constant, RAM usage is fixed. It does not change because there is more or less data in the array.
The array will use 400 bytes out of my 2000 bytes of RAM and cycling through updating 200 'columns' of the graph each second with each column being many (varying) pixels high (to fill in graph) seems like several thousand pixel updates per second. Will probably be laggy.
Just plot each point as it comes along after first clearing that pixel column...
This will not move the graph along from left to right. I would just have the first column updating and nothing else. I need to move 199 columns along one before updating the first column with the latest reading.
The rows will depict the magnitude of each reading and will vary from 0 to the number of pixels high of the LCD. I have not selected and LCD yet as I want to know if this is doable first. I would like to able to use a 5"-7" LCD so I should be allowing for maybe > 256 pixels.
I will check that datasheets to see if I can read existing contents of the LCD although if I had to read them and then update them all, this would seem to double the already busy workload of the Uno.
If your bars were 128 pixels high, you could pack the data.
If your values were limited in range (eg: X +/- 32 units), you could further pack the data.
If you can read the LCD, you only need to store the last value.
It's also possible your LCD can do pixel manipulation, like block move, etc. Your scrolling and memory requirements would mostly be handled.
lemming:
The rows will depict the magnitude of each reading and will vary from 0 to the number of pixels high of the LCD. I have not selected and LCD yet as I want to know if this is doable first. I would like to able to use a 5"-7" LCD so I should be allowing for maybe > 256 pixels.
I will check that datasheets to see if I can read existing contents of the LCD although if I had to read them and then update them all, this would seem to double the already busy workload of the Uno.
If you could read the columns you would only have to calculate the last column and do a straight forward series of copies (column 2->1, 3->2 etc). It all depends on the archtecture of the screen.