Library for LCD19264 with UC1609C display (Oshosoft)

[DogFlu66]

UC1609C Driver​

• Developed using Pic18 Basic with the Oshonsoft v5.73 compiler.
• Implements communication with the UC1609C graphical display controller via SPI.
• Defines essential control pins (Reset, Chip Select, Command/Data, Clock, Data).
• Provides functions for initialization, command transmission, and data writing.
• Includes cursor control functions to set the display position.
• Supports text rendering through character and string printing functions.
• Implements pixel manipulation for basic graphics like lines and individual pixels.
• Optimized for monochrome 128x64 display operation.

Implemented Functions​

UC1609C_Locate​

• Positions the cursor to a specified row and column.
• Translates text coordinates into display pixel locations.

UC1609C_Send_XY​

• Sets the internal cursor position using x (column) and y (page) coordinates.
• Splits x into lower and upper nibbles and sends commands accordingly.

UC1609C_Print​

• Prints a string of characters on the display.
• Iterates through each character and calls UC1609C_PutC.

UC1609C_PutC​

• Displays a single character on the screen.
• Retrieves the font bitmap and sends data column by column.

UC1609C_PrintP​

• Prints a string of characters at a specific x, y position.
• Allows custom character width and height.

UC1609C_PutCP​

• Displays a single character at a given x, y position.
• Retrieves the font data and applies scaling for size adjustment.

UC1609C_Clear_Display​

• Clears the entire display by writing zeros to memory.
• Iterates through all pages and columns.

UC1609C_Init​

• Initializes the UC1609C display.
• Configures I/O pins, resets the display, and sends initialization commands.

UC1609C_Power_Down​

• Powers down the UC1609C display.
• Executes the reset sequence to enter low-power mode.

UC1609C_Pixel​

• Draws a single pixel at an (x, y) coordinate.
• Uses the vertical line function for precise control.

UC1609C_Line_H​

• Draws a horizontal line from (x, y) to (x2, y).
• Calls the vertical line function for each pixel.

UC1609C_Line_V​

• Draws a vertical line from (x, y) downward.
• Uses bitwise operations to set pixels within memory pages.

 

[ahsrabrifat]

Is this display compatible with Arduino?

 

[DogFlu66]

With the appropriate library for arduino.

 

[Nigel Goodwin]

I'd just like to say thanks to the OP for bringing this display to my attention, while I'm not using Oshonsoft (I'm using XC8), the display seems ideal for a forthcoming project - and also it will fit as a replacement for the normal LCD1602 we already use in a long term product we make.

The picture shows the UC1609 display on the new PCB, in the old case, the old display next to it, and the 3D printed spacers I used to mount the display - it's mounted using two 6x2mm self tapping screws on each end at the top, and a single one at each end in the middle of the bottom. If anyone wants the STL file?, feel free to ask, but it's really a very simple part to design, and the height can easily be adjusted as needed.

In this application the cases are machined for us by the manufacturer, so the 'window' for the display only covers part of the UC1609 screen, as does the window in the existing keypad, but it still gives us space for two decent sized lines of 16 characters (same as the LCD1602), and the choice of using graphics if need be. And while I've carefully positioned the centre of the display to match the window, the two lines can be aligned to single pixel accuracy in the software. The PIC used is a 16F18857, or can be swapped for a 18F27K42 - they are pin compatible.

All in all, a really nice little display.

 

[DogFlu66]

It looks great, with an impressive finish.
I program in C using the CCS compiler, and I discovered the LCD by chance. I thought it would be fun to write the library for Oshonsoft.
I've also been building a small automation system for almost 15 years. Although it uses a graphical display, it's become increasingly expensive, so I'm thinking of replacing it with this one.

 

[Nigel Goodwin]

Have you checked how fast it is?.

As I mentioned, I'm planning using this in a new product (while currently playing with it in an old product), and to update the screen takes about:

16F18857 - at 32MHz - SPI at 8MHz
100mS to update the screen

18F27K42 at 32MHz - SPI at 32MHz
25mS to update the screen

18F27K42 at 64MHz - SPI at 32MHz
12.5mS to update the screen

The 18F27K42 obviously has the big advantage, in that you can run the SPI four times as fast, and the processor twice as fast.

To measure it I simply stuck my scope on the CS like of the display, and ran the following continuous loop:

while(1)
    {
        LCDupdate();
        Delay_ms(1);
    }

My routines use a buffer, and the above routine copies the buffer to the screen - presumably, if you're writing direct to the screen, a similar speed routine would be your UC1609C_Clear_Display routine.

 

[DogFlu66]

I haven't checked the speed, but it won't be very fast anyway because I wrote it for microcontrollers that don't have the SPI module.

 

[Nigel Goodwin]

I haven't checked the speed, but it won't be very fast anyway because I wrote it for microcontrollers that don't have the SPI module.

Sorry, no point then - it will be very much slower - however, it would be very easy to add the option of using a hardware SPI module.

 

[Ian Rogers]

I don't have one so I'm not much help. However! I have one similar somewhere, just got to find it.

 

[DogFlu66]

In the automation systems I develop, screen refresh time is usually not a critical factor. I typically assign a timing base so the information updates every 100 ms. Lately, I've been experimenting for several weeks with low-cost RF modules, but I’ll try to make some space on my workbench to get the display running again and modify the library to work through the MSSP module in SPI mode. Let’s see how that goes.

 

[DogFlu66]

I've restarted the display and tested it with voltages lower than 5V, between 5V and 3V, and it works perfectly. Although its video RAM is a bit basic, the display is really interesting.

 

[Nigel Goodwin]

I've restarted the display and tested it with voltages lower than 5V, between 5V and 3V, and it works perfectly. Although its video RAM is a bit basic, the display is really interesting.

Is your display the one with the 3.3V regulator on it?, you can buy them as 5V or 3.3V, the only difference been the regulator fitted or not.

 

[DogFlu66]

I bought it as 5v, I put the link:

https://es.aliexpress.com/item/1005005235738386.html?spm=a2g0o.order_list.order_list_main.143.e45e194dXL7CTL&gatewayAdapt=glo2esp

 

[DogFlu66]

Whenever I can, I prefer to work at 5v and in this case I did the test at 3v.

 

[Nigel Goodwin]

I bought it as 5v, I put the link:

https://es.aliexpress.com/item/1005005235738386.html?spm=a2g0o.order_list.order_list_main.143.e45e194dXL7CTL&gatewayAdapt=glo2esp

OK, on the back there's a regulator U1, next to it is a jumper, J1 - for 5V you leave the jumper open, for 3.3V you solder across J1, shorting the voltage regulator out. I ordered 3.3V ones, if I'd thought about it I'd have ordered 5V ones, and shorted J1 out

 

[Nigel Goodwin]

Right, here's a quick video of my latest test board:

http://winpicprog.co.uk/temp/UC1609.mp4

The battery level is simulated, as I haven't got round to getting it working yet

 

[DogFlu66]

Have you checked how fast it is?.

As I mentioned, I'm planning using this in a new product (while currently playing with it in an old product), and to update the screen takes about:

16F18857 - at 32MHz - SPI at 8MHz
100mS to update the screen

18F27K42 at 32MHz - SPI at 32MHz
25mS to update the screen

18F27K42 at 64MHz - SPI at 32MHz
12.5mS to update the screen

The 18F27K42 obviously has the big advantage, in that you can run the SPI four times as fast, and the processor twice as fast.

To measure it I simply stuck my scope on the CS like of the display, and ran the following continuous loop:

while(1)
    {
        LCDupdate();
        Delay_ms(1);
    }

My routines use a buffer, and the above routine copies the buffer to the screen - presumably, if you're writing direct to the screen, a similar speed routine would be your UC1609C_Clear_Display routine.

With the following configuration (Pic18F46K22):

Call _SlewRate(_DISABLE) ' Enabled by default
Call _SPI1_Init(_SPI_MODE0, _SPI_MASTER_SPEED0 | _SPI_ENABLE) ' SPI clock at 16 MHz (Fosc = 64 MHz)

The UC1609C_Init() function, which includes a hardware-based clear, takes 11.40 µs.
In contrast, using the UC1609C_Clear_Display() function takes 3.54 ms.
When using software-based SPI functions, the same display-clear function takes 57.60 ms.

It’s important to note that these tests were performed without using a video RAM buffer.
I repeated the measurements several times, and the results remained consistent.

 

[DogFlu66]

Right, here's a quick video of my latest test board:

http://winpicprog.co.uk/temp/UC1609.mp4

The battery level is simulated, as I haven't got round to getting it working yet

The display looks great.

 

[Nigel Goodwin]

With the following configuration (Pic18F46K22):

Call _SlewRate(_DISABLE) ' Enabled by default
Call _SPI1_Init(_SPI_MODE0, _SPI_MASTER_SPEED0 | _SPI_ENABLE) ' SPI clock at 16 MHz (Fosc = 64 MHz)

Will your PIC do 32MHz SPI?, the 18F27K42 I'm using will, with 32MHz or 64MHz Fosc, while the 16F18857 will only do 8MHz, at 32MHz Fosc.

 

[Nigel Goodwin]

The display looks great.

Thanks, I've found my A2D issues - I've wired the opamp buffer wrong

I've connected the input to the inverting pin, and the feedback to the non-inverting pin - in my defence, the schematic symbol is confusing, as it has V+ right next to the inverting input, and V- right next to the non-inverting input. It explains why at one time the output was zero, and the next time it was 1023

I also had neglected to power the opamp from an I/O pin (so it can be powered down, so I've added that as well). Five new boards ordered from JLCPCB, with slow delivery - so it only costs £3 something for the boards delivered (otherwise it's about £25), I've also ordered some little key switch boards, for prototyping, until we get labels/keypads made.