You may have noticed that I’ve been working on my ESP8266 home control software (see the updates elsewhere along with new diagram), specifically upgrading and adding to the number of OLED and LCD displays I can handle, either by I2c or SPI.
I’ve been doing a lot of optimising and simplifying – for example with SPI – assuming that there will only be the one SPI device at once on an ESP means you don’t need the CS line which can be grounded. But there’s more….
Also by connecting the reset lines where used to the processor reset line – and making the (generally correct) assumption that reading back from the display is not needed, you end up needing only three control lines (clock, data and D/C). So in software that does away with constantly flicking the CS line up and down.
Also, you can assume that generally after a command, the DC line will be set to data – hence the following data segments can do away with having to worry about that. Also I’ve made use of 16 and 32 bit SPI commands where possible to again speed things up – the result – pretty damned fast display graphics.
I’ve also standardised on GLCD format (slightly modified) for fonts and focussed on making that fast. The result is I can now handle several kinds of displays with more or less the same commands and I’ve reduced all of that to simple escape sequences (using the $ symbol for ease).
And so it was that I was studying speeding up the s6d02a1 chip (cheap QD-TECH boards offering colour LCD at 160×120 pixels) and getting myself annoyed that the hardware vertical scroll only works in portrait mode and therefore useless to me…. when in a moment of boredom I suddenly realised that the scrolling used in landscape could be used a pixel at a time to pull in graphing information from the right hand side (temperatures, voltages, logic information – you name it).
The hardware scrolling is simple enough the way I’ve used it – no static areas (a static area at the left would be easy – one at the top or bottom not so), I can simply scroll the screen left one pixel in an instant. Invoking hardware scroll is weird as you are rotating the entire screen. X=0, Y=0 remain in the same place in memory – they just display differently – so as you scroll you have to keep track of where to put stuff to have it appear in the same place. So in my simple little scope- I clear a column over on the left, rotate that around then allow a range of dots (lines actually) to be drawn at the extreme right (in different colours – I’ve arbitrarily allowed for 9 different coloured channels) – could have been more, could have been less. Before the next series I simply repeat the 1-pixel scroll. Works a treat.
Rather than having different commands I’ve put everything into a string – this applies also to all the OLED and LCD controls but for this specific use…
In common with my other commands – an MQTT or serial string can be sent to the board surrounded by {}
So {qd_string:”$S”}
That sets up and clears the screen. The command format for the Oscilloscope (I know, it’s not really that but I only had “O” available….) is as follows:
$Ochannel,value
where channel 0 starts the scroll and channel 10 returns the screen to normal use.
A set of 3 points then, of values 30,40 and 50 might be (and bearing in mind you can miss out values of zero:
{qd_string:”$0,$O1,30$O2,40%O3,50”}
Simple enough – that wipes the leftmost column, rotates it to the right, fills in those 3 values as dots or if more than 1 pixel different to previous values, lines.
Repeat until you’re done…
So for example you could use this on a wall mounted display to show temperature graphs at the touch of a button – oh, while I’m on – lit up touch button for the job… thanks to my pal Jonathan for that one. That’s a pack of 10 so maybe £1 or so each – logic output – 5v – I have great plans for these.
So as a scope this might be considered trivial – but it’s just one more thing my kitchen sink ESP8266 code can now do. I’ll do the same for the larger 240×320 display when I get a moment.
I’ll have to find a way to fit that little feature into the diagram..
Wot no video showing off the speed? :-p
It’s probably not THAT fast – but as the data will be sent by MQTT or serial – I think that will be the limiting factor. Real shame the hardware scroll area definitions are so simple – would be nice to put little rulers on the top and sides…. but maybe that’s overdoing it…