How can a countdown be dispalyed on the OLED screen in large numbers (3 lines high) ?

Hi everyone,
I have an 8M2 that outputs a countdown (with other data) to an OLED screen.
This works but I want the countdown to be big, ie 3 lines high something like this:

XXXXX ---- ----- ----
XXXXX | . | | . | | . |
XXXXX ___ ___ ___
XXXXXXXXXXXXXXXX

Where "X" is some writing about what is being counted down and the 3 squares are the large countdown (like 3 x 7-segment displays)

I suspect I'll need to reprogram the OLED driver (18M2) and that's the bit I'd like some ideas on (The actual number of "X"s used on the display is not finalised yet)

Thank you,
Dave.

If it doesn't matter that the big digits are blocky and squarish, then there are plenty of examples on the forum of CGRAM characters being used for this purpose. There are only 8 CGRAM characters, so you are limited on the number of different blocks you can use to make up the digits.

If it does matter, then you'll have to use the display in graphic mode which means generating the character bitmaps for the small text yourself too.

Thanks for reply.
I've downloaded and read the "AXE134Y Firmware File" (axe134y.bas).
This is, I think, the program that is pre-loaded into the 18M2.
It looks like we are limited to using whatever is mapped into the OLED Character Tables (4 off)
I shall search for the "examples on the forum of CGRAM characters" you mention.

Whatever I do, I will need to rewrite the 18M2 code. I think I understand the basics of the pre-loaded program but we'll see what happens when I do!

Hi Dave

It should not be necessary to rewrite axe134y.bas 18M2 OLED driver.
It will pass on the commands to the display for CGRAM operations.

PE6 has a Wizard to create CGRAM once created and loaded into the OLED display
you call them when needed.

My approach to this has been to construct the entre image to be displayed (20x4 OLED
80 bytes) in RAM and then refresh the whole OLED screen in one action. I’ve not tried with
an 08M2+ but it should be possible.

Edit:

Here are two examples of my Large Digit Clock one with 20X2 and AXE033 in i2c mode the other with
08M2+ @16MHz with serout n2400_16 to 18M2 OLED driver firmware (AXE181 touch sensor demo board).
The AXE033 with i2c has a much better refresh rate than the 18M2 OLED driver with baud rate of n2400_16.

This is just a demo for anyone who is looking at this problem.
Video 1

[video]https://youtu.be/DYBjF4NLO2o[/video]
Video 2
[video]https://youtu.be/ImYYUxMmd_k[/video]

Video 2
[video]https://youtu.be/ImYYUxMmd_k[/video]

Thanks Dan, what you've got there is exactly what I was looking for!

As I understand it so far:
1: the OLED has 8 CGRAM characters
2: CGRAM characters are user defined
3: your project shows that CGRAM characters can be used to make 0 to 9 inclusive 3-lines high
4: This uses all 8 CGRAM characters

I can see that this may be possible to do using the 8M2, but I suspect it would be simpler to rewrite the 18M2.

I need to:
1: write the CGRAM characters (same as yours) into the 18M2 firmware
2: write a section to insert into the 18M2 firmware to output the right CGRAM characters to represent the countdown

eg, if the countdown = 156, then I have to output the 6 CGRAM characters that represent "1", then the 6 CGRAM characters that represent "5", then the 6 CGRAM characters that represent "6".

dave finney said:

Thanks Dan, what you've got there is exactly what I was looking for!

As I understand it so far:
1: the OLED has 8 CGRAM characters
2: CGRAM characters are user defined
3: your project shows that CGRAM characters can be used to make 0 to 9 inclusive 3-lines high
4: This uses all 8 CGRAM characters

I can see that this may be possible to do using the 8M2, but I suspect it would be simpler to rewrite the 18M2.

I need to:
1: write the CGRAM characters (same as yours) into the 18M2 firmware
2: write a section to insert into the 18M2 firmware to output the right CGRAM characters to represent the countdown

eg, if the countdown = 156, then I have to output the 6 CGRAM characters that represent "1", then the 6 CGRAM characters that represent "5", then the 6 CGRAM characters that represent "6".

Click to expand...

Hi Dave

Yes to the first three no to the fourth. My 0 thru 9 digits use only seven of the available eight CGRAM locations.
I did another test @ 32MHz with serout/serin @ n4800_32 and got better results, above this baud rate there are likely to be reliability problems. This also means changing the 18m2 firmware.

You can rewrite 18m2 firmware if you choose. After initialization of the OLED write the contents of the CGRAM to the OLED.

Two options for displaying large digits on screen.

1: Write subroutine in 18m2 firmware that produces the required 3 digit output when a prefixed (!) command is received followed by the number to be displayed.

2: Send the commands and data from the main controller byte by byte.

Thanks Dan,
My mistake. Having counted again you're right, only 7 of the 8 CGRAM characters are needed for the 3-lines high display. Only 6 of the 8 if you use the full height vertical on the RHS for the upper right of the "4".
I'm starting to think how to write the code to display the countdown and your option 1 appeals most.
I could use the start position command as the cue to display the countdown (gosub in 18M2 firmware when certain screen position is selected)

Is the code to write the 7 CGRAM characters for the 3 lines high numbers on this forum somewhere, or could you post it?

Hi Dave

I have not posted code for this project, have you tried the CGRAM Wizard?

If you are always going to display large digits at the same location then yes
you could command the OLED to display large digits from the start position.

Or use new command

else if b1 = 252 then

CGRAM wizard

I used the CGRAM wizard to come up with the 7 CGRAM characters.

The PE CGRAM wizard has AXE133Y, but the OLED is AXE134Y I think. Does AXE134Y use the same code as AXE133Y?

Having made the CGRAM characters, I need to sort into 0 to 9. "lookup" might be best for this.

=========================

' CGRAM characters (7 off) to make 0 to 9 in large numbers (3 lines high) on OLED display.

' From CGRAM wizard for "OLED" and "AXE133Y" and "Decimal".



symbol oled = C.0 ' oled display

serout oled, N2400, (1)
serout oled, N2400, (254,64,31,31,24,24,24,24,24,24) ' 0 top left

serout oled, N2400, (2)
serout oled, N2400, (254,80,31,31,3,3,3,3,3,3) ' 0 top right

serout oled, N2400, (3)
serout oled, N2400, (254,88,24,24,24,24,24,24,24,24) ' 0 middle left

serout oled, N2400, (4)
serout oled, N2400, (254,96,3,3,3,3,3,3,3,3) ' 0 middle right

serout oled, N2400, (5)
serout oled, N2400, (254,104,31,31,0,0,0,0,0,0) ' 0 lower left and right

serout oled, N2400, (6)
serout oled, N2400, (254,112,3,3,0,0,0,0,0,0) ' 1 top left and lower left

serout oled, N2400, (7)
serout oled, N2400, (254,120,0,0,3,3,3,3,3,3) ' 4 top right

dave finney said:

The PE CGRAM wizard has AXE133Y, but the OLED is AXE134Y I think. Does AXE134Y use the same code as AXE133Y?

Click to expand...

It does.

The generated PICAXE code can be slightly different for the AXE033 and AXE133 because of the way the firmware handles what's sent to them.

Your digits are narrow mine are three pixels thick.

dave finney said:

I need to sort into 0 to 9. "lookup" might be best for this.

Click to expand...

select case or on gosub

Thanks Hippy, it should work then!

And good suggestions Dan, thanks. I may have to rewrite the CGRAMs to be 3 wide, I'll check it out.

Even having written the CGRAM characters, this isn't as easy as it might appear. Suppose "countdown" = 256, then, in essence, the "2" could be stripped off and the 2 CGRAM values for the top row found and displayed.

Eg, in rough terms:

Let hundreds = countdown/100
lookup hundreds,(1,6,5,5,3,1,1,5,1,1),CGRAM
let pinsB = CGRAM
pulsout enable,1
lookup hundreds,(2,3,2,2,7,5,5,2,2,2),CGRAM
let pinsB = CGRAM
pulsout enable,1

Then do the same for the "5", and then the "6". Then repeat for middle row and repeat again for the lower row.

So the complete program would be the above times 9 plus other sections (change start position etc).

Is there a more elegant solution?

Just mentioning this :I might be wrong (and haven't searched the forum) but the underlying winstar datasheet (WS0010) mentions a one or two line display which I 'think' is giving the ability to display big characters automatically. I'm only starting to get into OLED and have had a quick glance. If this were the case though, it might be possible to change the AXE133 Serial LCD/OLED bas file.

Jeremy Leach said:

Just mentioning this :I might be wrong (and haven't searched the forum) but the underlying winstar datasheet (WS0010) mentions a one or two line display which I 'think' is giving the ability to display big characters automatically. I'm only starting to get into OLED and have had a quick glance. If this were the case though, it might be possible to change the AXE133 Serial LCD/OLED bas file.

Click to expand...

No, the WS0010 datasheet mentions one or two line display because that's what it supports logically. 1-line mode gives a duty cycle of 1/8 and 2-line mode gives a duty cycle of 1/16 (per row).

The 4-line display is logically arranged as a 40x2 display, with the third and fourth lines being continuations of the first and second. If the WS0010 is initialized for a 1-line display, only two of the four lines on the 20x4 display will work.

Oh I see Nick, thanks for that !

Thanks all for help.

I've now got the display I wanted, a countdown in big numbers (3-lines high).

In the end I only programmed the 8M2 (and didn't need to program the 18M2) although the program is close to the maximum possible. I actually had to cut out a section to fit it in!

The following could probably be condensed, but it does work:

display_all: ' this sub must be preceeded by: "let units = countdown // 10"

let hundreds = countdown / 100
let tens = countdown // 100
let tens = tens / 10
' display top line
' hundreds
lookup hundreds,(32,6,5,5,3,1,1,5,1,1),CGRAM1a ' 32 = " ", or space
lookup hundreds,(32,3,2,2,7,5,5,2,2,2),CGRAM1b
' tens
if hundreds > 0 then
lookup tens,(1,6,5,5,3,1,1,5,1,1),CGRAM2a
lookup tens,(2,3,2,2,7,5,5,2,2,2),CGRAM2b
else
lookup tens,(32,6,5,5,3,1,1,5,1,1),CGRAM2a
lookup tens,(32,3,2,2,7,5,5,2,2,2),CGRAM2b
endif
' units
lookup units,(1,6,5,5,3,1,1,5,1,1),CGRAM3a
lookup units,(2,3,2,2,7,5,5,2,2,2),CGRAM3b
serout oled, Baud, (254,140,CGRAM1a,CGRAM1b,32,CGRAM2a,CGRAM2b,32,CGRAM3a,CGRAM3b) ' move to first line, 13th position (127 + 13)
' display middle line
' hundreds
lookup hundreds,(32,32,1,6,5,5,1,32,1,5),CGRAM1a ' 32 = " ", or space
lookup hundreds,(32,3,5,2,2,2,2,4,2,2),CGRAM1b
' tens
if hundreds > 0 then
lookup tens,(3,32,1,6,5,5,1,32,1,5),CGRAM2a
lookup tens,(4,3,5,2,2,2,2,4,2,2),CGRAM2b
else
lookup tens,(32,32,1,6,5,5,1,32,1,5),CGRAM2a
lookup tens,(32,3,5,2,2,2,2,4,2,2),CGRAM2b
endif
' units
lookup units,(3,32,1,6,5,5,1,32,1,5),CGRAM3a
lookup units,(4,3,5,2,2,2,2,4,2,2),CGRAM3b
serout oled, Baud, (254,204,CGRAM1a,CGRAM1b,32,CGRAM2a,CGRAM2b,32,CGRAM3a,CGRAM3b) ' move to second line, 13th position (191 + 13)
' display lower line
' hundreds
lookup hundreds,(32,6,5,5,32,5,5,32,5,32),CGRAM1a
lookup hundreds,(32,5,5,5,6,5,5,6,5,6),CGRAM1b
' tens
if hundreds > 0 then
lookup tens,(5,6,5,5,32,5,5,32,5,32),CGRAM2a
lookup tens,(5,5,5,5,6,5,5,6,5,6),CGRAM2b
else
lookup tens,(32,6,5,5,32,5,5,32,5,32),CGRAM2a
lookup tens,(32,5,5,5,6,5,5,6,5,6),CGRAM2b
endif
' units
lookup units,(5,6,5,5,32,5,5,32,5,32),CGRAM3a
lookup units,(5,5,5,5,6,5,5,6,5,6),CGRAM3b
serout oled, Baud, (254,160,CGRAM1a,CGRAM1b,32,CGRAM2a,CGRAM2b,32,CGRAM3a,CGRAM3b) ' move to third line, 13th position (147 + 13)

return

This is quite frustrating. Having got the display right, I ran a countdown of 140 seconds and it took 147 seconds. I removed all "serout" commands from the main loop and the timing was then correct. It seems that "serout" commands slow down internal "time". I found this in the manual: "Please also see the interfacing circuits , affect of resonator clock speed, and explanation notes of the ‘serin’ command".

This means that time counters won't work properly when driving an OLED serially.

Is there a way to fix this?

To get around this, the best way might be to put the entire program into the 18M2. This will be awkward and may require removing the 18M2 pcb from the OLED.

dave finney said:

Is there a way to fix this?

To get around this, the best way might be to put the entire program into the 18M2. This will be awkward and may require removing the 18M2 pcb from the OLED.

Click to expand...

You could try using hserout on the 08M2, but otherwise the real solution is to use a single PICAXE using the parallel interface instead of a separate PICAXE and serial interface.

Hi Dave,

The "quick fix" might be to use a CALIBFREQ which increases the clock in approximately 0.1% - 0.2% increments. The maximum is +31 so try CALIBFREQ 31 to see if it's enough.

Another possibility might be to split the SEROUT commands into shorter blocks, so that the "time" interrupt "ticks" are disabled for less than 20 ms. I don't know if HSEROUT is itself interrupt-driven, which should allow "time" to update correctly.

There may be other possibilities, but do bear in mind that the PICaxe internal clock is basically only a simple R-C oscillator, not a more accurate crystal or ceramic resonator.

Cheers, Alan.

I have ended up using the "time" seconds to increment my own "minutes" and "hours" variables, incrementing my "minutes" when "time" reaches a multiple of (approximately) 40 seconds.

Coincedently yesterday, my two data loggers using this technique were as close as five minutes of the actual elapsed time after ten days. They were also within three minutes of each other. I was well'appy!

Thanks everyone,
Hi Alan, yes CALIBFREQ should get a count that's accurate enough provided SEROUT delay is consistent, which should be the case every 10 program loops.

I decided to load the program into the 18M2 as Nick suggests. It works and is much better (faster screen writes, fewer components etc)

BTW, Nick, your "guide to parallel" is excellent, thanks.

Had to compact the program to fit it all in but now just needs a few tweeks, calibration and testing. Thanks all, Dave.