ST7567 Support

[Schmart]

Hi @dc42, please consider this an informational update mostly. About seven days ago, I was finally able to make time to work on UC1701/ST7567 support for the 12864 Mini Panel in my CR-20 Pro.

I used the latest versions of Eclipse, plugins, tools and toolchain and (as instructed) the v3-dev branch of RRF. I set up the environment, accurately documented the whole process and started working on a DriverBase class that is both the base class for the ST7920 and UC1701 driver classes, so I can easily implement additional displays. I bricked the Maestro board the first time, but was able to figure out the problem and recovered quickly.

As of now, the firmware with the refactored ST7920 display code still shows two additional zeroes for the nozzle temperature (!), so that's something I have to figure out still, but I'm already excited that I got the concept working: long time ago, I was fluent in C++, but I'm a little rusty now, and I have only one machine to test firmwares on, which is not ideal.

I'm now at the point that can I implement the specifics for the UC1701/ST7567 controller. I expect to need one more day at most coding, and I've already mapped the vastly different display connector pinout that Creality is using. I'm using pin ext_0 (PA21) for the DC line, and I want to buffer the pin with an SN74HC08. I don't have a 74HCT08, so I'm hoping that will work out okay.

Three questions I'm hoping you'll answer:

• Today, I discovered in the v3.02dev branch that you also started on implementing ST7567 support. That's great! If I'm done, would you still like to review my approach and provide feedback?
• Is the SN74HC08 suitable to use for buffering?
• What is your process to test firmware? Are you using a development board or do you -like me- upload a firmware binary and look at the serial output for debug messages?

Edit: I was under the assumption that my display is based on a ST7565, not the ST7567, but these drivers are probably all close enough.

[A Former User]

@Schmart said in ST7567 Support:

Is the SN74HC08 suitable to use for buffering?

no, normal cmos chips will not trigger a high level at 3.3v, the T signifies ttl which trigger at 2-ish volts.

also the 7408 does perform a gating function in addition to the buffering, not sure if thats needed for the st7567

[dc42]

According to the data sheets and schematics, the ST7567 does not need the SCLK pin to be gated with CS. Also the ST7567 uses 3.3V signal levels, and displays using it normally have input level shifters to tolerate 5V signals. I believe these should work just fine with 3.3V signal levels. So it should not be necessary to use any buffers.

The ST7567 support code in the 3.02 branch is notionally complete, but untested and therefore almost certainly not working yet. The type of controller chip is selected in the M918 command.

[Schmart]

@dc42 I much prefer a wiring solution without additional components, as long as I don't risk blowing up the IO port or the MCU on the Maestro?

[Schmart]

@dc42 Just an update, I finally found and squashed a nasty bug I introduced as a result of refactoring for multiple display drivers, and will start testing the UC1701/ST7565 code with my MiniPanel display soon.

[dc42]

Thanks for the update.

I haven't tried my ST7567 changes yet either. Although I finished writing the code, the particular ST7567 display that I purchased has an RGB backlight, so it needs additional code to control that.

[jay_s_uk]

@dc42
Have you bought a mini12864 panel? The one by fysetc?

[dc42]

@jay_s_uk said in ST7567 Support:

@dc42
Have you bought a mini12864 panel? The one by fysetc?

Yes. I didn't realise it had an RGB backlight.

[Schmart]

@dc42 Since the ST7565/UC1701 uses a different GDRAM to COM/SEG mapping, I'm using some temporary code that flushes the entire display for testing purposes. It's my intention to later implement flushing the affected area only, either using the existing principle already in the firmware, or through keeping a bitmap of affected tiles (e.g. tile size 8x8 for the UC1701, 16x8 for the ST7920). That will be more efficient since smaller areas are refreshed and it's simpler to implement, but it will take some extra memory, about 64-128 bytes in RAM, so I wasn't sure if you would approve.

Also, I flashed the test firmware and turned on the printer... Nothing on the display at all.

So I hooked up a logic analyzer and then it hit me. The MiniPanel I'm using needs an active low, but SPI0_SCK_LCD is gated with LCD_CS. So configuring SPI active low does not put out a clock signal when needed. Apart from inverting the LCD_CS line between the Maestro and the display, do you have any creative thoughts? Maybe use the unbuffered SPI for the SD card (which I'm not using anyway)?

[Schmart]

@dc42 I think I'm making progress here...

I found an old 74LS00N NAND to invert the LCD_CS with, but it seems that when the display isn't configured properly, the Vcc drops to below 4v and the IC becomes a bit noisy which causes instability in the CS line. Now the display code is working, the Vcc is back to 4.8v and the noise seems gone though.

The 74LS00N is probably not the best choice, but I have nothing better at the moment. Any suggestions?

And using the SPI of the SD card reader raw, instead of the buffered 12864 pins of the Maestro, is that an option?

Next step: only draw affected pixels...

Update: Many additions and corrections. Too excited!