Logic Level shifter for 12864 display on Duet 2 Wifi

dc42

i see that you've made a lot of changes, in particular to the flush function for the ST7567. Is that all necessary? What is the "tile rotation" that you refer to in the comments?

dc42

btw I'm looking at assigning pins for a Mini 12864 connected to Duet WiFi. My aim is to have at least some of the connections straight through. This is my current plan:

CONN_LCD pin Function
1 No connection (+3.3V on Duet)
2 GND
3 Encoder A
4 Encoder B
5 Backlight control (Neopixel)
6 LCD reset (do we need it?)
7 LCD_A0
8 LCD_CS
9 Encoder button
10 Beep

Pins 2 and 5-10 are connected straight through.

antlob

@dc42 To have directly connected a Mini 12864 to the Duet without additional hardware could be a great thing for the Duet 2 Wifi/Ethernet. But my question right now is if a LCD 12864 can be connected with the RRF v3-dev and the schematic plublished by Markus Scheck (https://easyeda.com/markus.scheck1/duet-2-12864-display)? or Is it better to wait for the 3.2 alpha? Many thanks in advance for all the trouble you are taking to bring this new functionality.

Schmart

@dc42 Apologies for the many changes, I was really having fun (many late hours) and can explain the rationale behind every change, but I was also a little afraid of your reaction, because I knew I was touching a lot. My main goal was to make the ST7565 driver, with a modular driver system and to put the drawing logic on a higher level. That required some structural changes. But I also touched stuff which might not have been strictly necessary but helped me with the process of understanding the code.

Now for the tile rotation; when you write a word to the ST7920 display, this results in 16 horizontal pixels. And because the display buffer is organized with bytes in sequence representing horizontal pixels, writing data to the ST7920 is straightforward. You take the bytes from the display buffer and send them in pairs to the display.

The ST7565 does things differently and has 8 vertical pages and 128 columns. When you write a single byte to the ST7565 at page 0 and column 0, this results in eight vertical pixels in the top left corner. To prepare that single byte, you have to read bytes 0, 16 (=128/8), 32, 48, 64, 80, 96 and 112 from the display buffer, take the 7th bit from all of them, and OR these bits in the byte in order (LSB is top pixel). So to aid in that translation, which is essentially a rotation, I have the transformTile function. For efficiency, I'm re-using the eight bytes from the display buffer that I had already retrieved, and I'm refreshing per 8x8 tile to keep the logic straightforward.

It's possible to refresh the dirty rectangle from and to an exact column, so not 'quantised' per 8 pixels, but that would require some extra logic to handle cases where the left and right of the dirty rectangle are not exactly on 8 bit boundaries. So between that and some sleep, I chose the latter and did not see harm in flushing a few extra bytes to the display.

Schmart

@antlob These are the pinouts and mapping I used with the 12864 MiniPanel on my printer.

Note that sometimes the plastic connector housing is reversed on displays, and the tab goes to the other side.

Edit: diagram updated the 7400 NAND gate and wiring.

Schmart

@dc42 said in Logic Level shifter for 12864 display on Duet 2 Wifi:

That's the stepper channel 10 & 11 connector?

At least I'm not using reset, and apparently that display doesn't need it.

Maybe it makes sense to look at the pinout of the two connectors from the display you have and merge that into one connector, or at least have as many labels in the same place. But what I'm seeing is that there isn't much consistency between display manufacturers (looking at https://wiki.fysetc.com/Mini12864_Panel and the CR-20 display pinout).

dc42

@Schmart, thanks for the explanation. I hadn't got as far as reading the ST7567 datasheet enough to appreciate the differences other than the I/O interface differences.

We are short of flash memory space in the Duet WiFi/Ethernet firmware, so I am somewhat alarmed at how much extra code is needed to support both displays. I'm wondering whether it would be better to support only the ST7567 displays on these Duets, to keep the code size down and to minimise the extra hardware needed. In which case, the image bitmap could be organised as columns instead of as rows. This would probably be more efficient, because the character data in the fonts is organised as columns too.

antlob

@Schmart Thanks, maybe this is a stupid question but, since I have de LCD 12864 and not the Mini LCD 12864, Does the pinout of EXP1 and EXP2 is the same? Meaning that if I wire as you say (waiting for your final schematic) Will it work? Or just follow the original schematic at the top of this forum discussion. My problem is that I do not dare to compile the dev 3.02 since I know it will be a mess for me with a very low chace of success and I'm waiting for @dc42 to upload a 3.2 Alpha version. On the other hand I also have doubts about the correct schematic. If I run into trobule I do not have the skill nor the knowledge to solve it. I'm sorry that I cannot be of any help, believe that if I could I'll do it. Guess I have to wait.

Schmart

@antlob Certainly not a stupid question. If you have a regular RepRapDiscount graphics display, with a ST7920 on it (or a BigTreeTech TFT24 with ST7920 emulation) then the pinout I'm showing you is very likely completely different, so wiring like in my schematic will not work. I think the pinout should instead be similar or identical to the connectors of the Maestro (shameless grab from the schematic):

Maestro 12864 Pinout.png

Do you have some pictures of the front and back of your display?

Schmart

@dc42 I know the 12864 changes were a tight fit for the Duet Wifi/Ethernet already and that you were really looking to shave those last bytes off.

Is there a way I can determine which functions or constructs primarily contribute to the firmware size growth?

I haven't looked at optimizing my code (or any code actually) yet, but I also noticed that functions like DrawCircle() and ReadPixel() are not used at the moment. We can probably disable these with a #define. And I wanted to optimize the Flush() routine even more anyway because there are still enough similarities between the ST7920 and ST7565 with respect to flushing logic. I'm just not certain in how many bytes I can save there.

To your idea of making a ST7565 specific build; in the existing code, a fair number of functions use the display buffer directly, so using the buffer with a rotated orientation would require careful checking and possibly abstracting these functions from accessing the buffer directly. That's some work, but still feasible, and perhaps something to do anyway because I have a hunch this might even save some code.

Schmart

I updated the schematic of how I hooked up my MiniPanel display to the Maestro. See a couple of posts above.

dc42

@Schmart said in Logic Level shifter for 12864 display on Duet 2 Wifi:

but I also noticed that functions like DrawCircle() and ReadPixel() are not used at the moment

The linker eliminates any non-virtual functions that are not referenced, so no need to disable them using #define.

dc42

I've been working on the code in RRF 3.2 to vary the number of drivers depending on whether a display is configured or not. In the process, I finalised the pin assignments for Duet WiFi to the Fysetc mini 12864 display, as follows.

constexpr Pin EncoderPinB = PortCPin(7);		// connlcd.3	-> exp2.6
constexpr Pin EncoderPinA = PortAPin(8);		// connlcd.4	-> exp2.8
constexpr Pin LcdNeopixelPin = PortDPin(18);       	// connlcd.5	-> exp1.5
constexpr Pin LcdResetPin = PortCPin(28);		// connlcd.6	-> exp1.6
constexpr Pin LcdA0Pin = PortDPin(19);			// connlcd.7	-> exp1.7
constexpr Pin LcdCSPin = PortAPin(25);			// connlcd.8	-> exp1.8
constexpr Pin EncoderPinSw = PortDPin(20);		// connlcd.9	-> exp1.9
constexpr Pin LcdBeepPin = PortDPin(21);		// connlcd.10	-> exp1.10

// Additional spi wiring for FYSETC Mini 12864 display:
// connlcd.2 (gnd)	-> exp1.2
// connsd.1 (+5V)	-> exp1.1
// connsd.2 (gnd)	-> exp2.2
// connsd.3 (SD CS)	-> exp2.7
// connsd.4 (sck)	-> exp2.9
// connsd.5 (mosi)	-> exp2.5
// connsd.6 (miso)	-> exp2.10

jay_s_uk

Sounds promising. I have one of these displays gathering dust

Schmart

Hi @dc42

I've optimized and simplified the code further in my repo and managed to save a few hundred bytes.

Also, the ST7565 display now works without additional logic components, inverting the LCD_CS with a 74xx00 is not necessary anymore. I've used the exp_0 pin for DC and the exp_1 pin for CS now. My display accepts the logic levels perfectly.

I should be able to save another 60 bytes or so, but I have to first work out an issue that I uncovered when I start drawing columns pixel by pixel.

oliof

@Schmart where'd one find your patch, and what does the new wiring look like? Inquiring minds want to know ...

Schmart

@dc42: I created a pull request of my changes today, and I tested:

ST7920 display type 1
ST7565 display type 2 that uses EXP_1 for active low CD
ST7565 display type 3 which needs a NAND inverter IC to invert the LCD_CS towards the display

Also implemented a couple of optimizations, solved a few bugs and simplified the Flush routine.

I see some room for further size reduction of the firmware, but that would probably make some parts of the code a little slower. What's your stance on that?

Schmart

Hi @oliof, back from fishing?

The changes are in the following repo and branch.
https://github.com/SchmartMaker/RepRapFirmware/tree/ST7565

I have a binary firmware for the Maestro here:
https://1drv.ms/u/s!Au1g8fW6BaQzioADewiHDAxzQ_Adlg?e=KuNYOB

What's the board you're using? I'm asking, because the firmware build for the Duet Wifi and Duet Ethernet is still a little too large for the flash memory of these boards unfortunately.

Schmart

@oliof I'll see if I can hack the wiring picture so that it reflects the new option that doesn't require the 74xx00.

oliof

I have a Duet2Wifi, but I can easily remove stuff I don't need (I did remove Hangprinter when trying the level shifter approach).