Need advice about decoding ST7920 commands

Anything not related to STM32
Post Reply
Y@@J
Posts: 57
Joined: Mon Sep 28, 2020 8:51 pm

Need advice about decoding ST7920 commands

Post by Y@@J »

Hi,

I recently made a OLED emulator, want to make one for the ST7920 LCD (AKA RepRapDiscount Full Graphic Smart Controller), SPI mode. The OLED protocol was very simple (reason why I started with...), the ST7920 is much more complex !
The datasheet is really unclear to me. For now, much of my knowledge is based on this : https://controllerstech.com/glcd-128x64 ... ith-stm32/
It's been a great help.

Please remember it is NOT about displaying on the LCD. It's about sniffing the SPI master, turning the data into bitmaps with a STM32, and displaying them real time on a RasPi.

But for now I've to understand the commands format.
In order to understand, I modified some functions from https://controllerstech.com/glcd-128x64 ... ith-stm32/ so they output formated HEX to a console. Every command begins with a sync byte (0xF8), and is followed by two bytes (the command). See the fist paragraph : "Sending Command"

But it is NOT what I see with the logic analyser ! For example, in the initialization sequence I'm sniffing from Marlin + u8glib, I see 0xF8 followed by 5 pairs of bytes. So, There's no need for a 0xF8 for every command ?

This initialisation sequence makes sense... Decoding it on the paper with the datasheet, I read :

cmd 0x38 (= 8bit, basic set of instructions) / cmd 0x0C (= display ON) / cmd 0x06 (= Entry mode with I/D and no S) / cmd 0x02 (home) / cmd 0x01 (clear)

(command bits are shifted as explained in the datasheet - I don't konw why, maybe because it's easier for the ST7920 and its shift registers...)
init.JPG
init.JPG (35.84 KiB) Viewed 3645 times
Does this make sense for you : one F8 byte only + a series of commands. I've a hard time because the datasheet is unclear to me : it mixes parallel and series protocols, and is not really untertaining ! And obviously, nowhere functions are listed as numbers : they are defined by name, with the bits to be set. I've to do the exact opposite.
User avatar
Bakisha
Posts: 139
Joined: Fri Dec 20, 2019 6:50 pm
Answers: 5
Contact:

Re: Need advice about decoding ST7920 commands

Post by Bakisha »

As i see it, you pretty much figure out most of the stuff. I am only confused why there is no 72uS delay (execution time) after every two bytes. Maybe not all commands need large execution time?
When first byte received is F8, rest of pair of bytes are commands, until CS goes low? (RS=0, RW=0)
When first byte received is F9, pair of bytes are data, until CS goes low? (RS=1,RW=0)

IMHO:
- set DMA to receive SPI bytes, in circular mode. Set size of a buffer at maximum of what you think you can process/expect. No need for half/full transfer interrupt.
- attach interrupt at falling edge of CS (end of transmission). Once triggered, read how much bytes you received, set flags for main program or process those bytes inside interrupt. Disable/enable DMA (so it can start from 0). Or keep track of the head and tail of your buffer.

My advice, get ST7920 LCD. It is much easier to emulate something if you have actual hardware to test stuff that you are trying to emulate.
Y@@J
Posts: 57
Joined: Mon Sep 28, 2020 8:51 pm

Re: Need advice about decoding ST7920 commands

Post by Y@@J »

Hello !
Some necro posting here...

For some reasons the project has been in standby for 1+ year. A couple months ago, I went back on it, and it's now half completed :

https://github.com/yet-another-average- ... C_8487.JPG

- a BluePill based hat for the RasPi, that for now emulates a OLED only (simpler to implement), with KiCad files and Roger's Core based firmware :
https://github.com/yet-another-average- ... linOctoHat
- a OctoPrint plugin that displays the emulated OLED as a fully customizable overlay window, mostly written with C++, using dispmanx, usable for anything else than OctoPrint (first iterations were implemented as a Linux systemd service) :
https://github.com/yet-another-average- ... OSD_Plugin
display : https://github.com/yet-another-average- ... data/c_src

Now, time for the second half of the job : ST7920 emulator.
I Googled again about ST7920 emulation, and found :

- this thread (sorry, completely forgot about it ; at this time I forgot to enable notifications !)
- and, most of all, meanwhile, someone did the job ! It is written with Cube, and the HAL

https://github.com/teeminus/ST7920Emulator
https://github.com/teeminus/NoTouchScreenFirmware

My PCB was designed with a few jumpers that allow for two emulators ! (SSD1306 OLED, and ST7902 LCD, both hardware and software).

I don't know if the Roger's core SPI library is suitable for a HAL -> Roger's Core port (never used anything else than the Roger's core). I imagine all the soft has to do is stopping DMA transfer when CS ("LCD_RS") changes it's state... I'm confused because I understand SPI as a fixed length protocol. Here, there's another control signal and a variable length payload...

In your opinion, is this doable with the Roger's, or should I have to bite the bullet and learn Cube/HAL ?

[EDIT]

After playing with the logic analyzer, and a known image, there's no need to use someone else's code. Encoding is simple (simpler than SSD1306) : frames are made of two pages (top and bottom), themselves made of lines, with some command/control bytes that just have to be removed.
The datasheet is a useless crap, making simple things overcomplicated.

Frames are fixed size, except at initialization time.

Frame = two pages ; begins with one byte
Page = 32 lines
Line : prefix = 7 bytes, then the pixels (32 bytes), postfix = 1 (ot 2?) byte -> 40 bytyes
2 bytes when one would be enough.
Should be easier to decode (SSD1306 needed "sub-matrices" transpositions)

download/file.php?mode=view&id=761
Attachments
Capture.PNG
Capture.PNG (90.75 KiB) Viewed 2400 times
ademenev
Posts: 1
Joined: Fri Jul 22, 2022 5:11 am

Re: Need advice about decoding ST7920 commands

Post by ademenev »

Y@@J wrote: Wed May 11, 2022 4:08 pm Some necro posting here...
Let me add some more. You do not need to send 0xF8/0xFA before each byte transfer (well, actually, two bytes :D ). You only need that when switching between commands and data. If you look at the serial bus timing diagram, you can notice that the sync byte always contains 5 consequent ones, and the payload can contain at most 4. Relying on that fact, the hardware changes the data/command bit only when seeing the sync sequence, but not during normal data transfer
Post Reply

Return to “Off topic”