sterretje:
The tendency here is that we like to see complete code so we don't have to copy from different parts from several posts and run the risk of making mistakes when we want to analyse / test.Glad you got it working.
Well, as it turns out it wasn't quite so simple.
I think the problem from the start was that I was expecting some sort of logic from a "logic" system...so get this...
The HT16K33 sends data in 16 bit bursts, preceded by a command nybble. The activation nybble is 0x00. 16 bits of memory that follow it are sequential...meaning you can't just "ignore" a bit...you have to make an acftive decision whether to write a 0 or a 1...
...or possibly other values, but that's a tale for later...
...because if you decide to do a "human" operation, and just say which bits are on in for example a "1" (00000110)...you can't.
(by the way, in terms of the segment numbners you have to read that binary number backkwards (or at least it feels backwards for me) so segment "a" is the rightmost bit, segment "h" (the full stop) the leftmost bit...)
The reason you can't is because the first bit the system expects you to write is the first OFF bit...if you try to tell it bit two is ON first...well you can't, it will just think you're talking about bit one.
And then it goes on to write bit two. Ha. You'd think so wouldn't you?
No. For some totally insane reason, the sequence is that even bits get assigned to the first byte, odd bits to the second...so I'm expecting to tell it the status of character one, bit two...but it's expecting me to tell it the status of character 9, bit one. So the "filling" order is like this
Byte one Byte two
First bit; x
Second bit; x x
Third bit; xx x
Fourth bit; xx xx
Fifth bit; xxx
etc.
Note; I've made no attempt to right or left justify the bits...by judicious use of the << or >> comands I now know I can fill the bytes from either end...though I'[m sure someone will tell me there's a convention as to how you should do it. (not that there should be...these bytes are not numbers. It took me a long time to get that into my head. Sure, you can represent them as numbers...but they are actually patterns...effectively a set of eight two-position switches.)
I'm sorry, but the way it fills just seems extremely awkward. Maybe it's to do with the order of displays with more segments...but for me, it's very (as in unecessarily) complex. It means for an automated system of filling the register, you HAVE to have the "Write" commands in pairs, and there has to be some logic involved when you start writing data to the 9th (or higher) character...because the HT16K33 demands that before you do, you have to RE-Write data to it's partner bit - effectively running the risk of overwriting the character 8 spaces before it.
So...yeah. My programmer friend used to code for professional organisations and hundreds of pounds per hour...he's good. Damn good. And he's been scratching his head about how the displays were behaving just as much as me...so I feel a little less dim than I did before.
It's not over yet.
The sketch attached below (which does have a lot of irrelevant guff in it that I haven't time to edit out) counts from 0 to 9 in each character position...and when it gets to position 9 rewrites a "zero" in position zero.
You have no idea how pleased that made me. By all means look at the code. I think I've come at this in a very "round the houses" way and it's extremely possible that logical functions like AND, OR and SHIFTs are only necessary in the write statements to correct for the way I've chosen to start the loop. If anyone can advise on ways to simplify, I'd be happy to hear them.
Next step is to address the display in it's entirety, so that I can write nine characters of individual data. I can do that in a fashion now...if I take out all the delays, the display will read 012345678...due to persistence orf vision...but with massive flickering.
The thing that attracted me to the demo code from partsnotincluded in the first place was the fact that it doesn't flicker at all. I'm hoping to replicate that, but with the data from my three potentiometers rather than simple sequential assignment of bits.
Watch this space (please!)
LCDsinglewrite.ino (3.31 KB)