Logic Level shifter for 12864 display on Duet 2 Wifi

antlob

@bearer Many thanks! I'll make the circuit on a breadboard just to see if I can turn on the display.

antlob

@dc42 Many thanks for replying. In my case would be to build just for the Duet Wifi and discard the Ethernet but my concern really is that in order for me to use LCD 12864 I would need to sacrifice the SD card support on the Duetpanel and maybe the SD on the LCD 12864 cannot be read by the DWC. If by any chance I could read the card on the LCD panel then I would go for it but as you say a separate build for the Wifi and Ethernet should be made and I don't know how to do it.

dc42

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

@dc42 Many thanks for replying. In my case would be to build just for the Duet Wifi and discard the Ethernet but my concern really is that in order for me to use LCD 12864 I would need to sacrifice the SD card support on the Duetpanel and maybe the SD on the LCD 12864 cannot be read by the DWC. If by any chance I could read the card on the LCD panel then I would go for it but as you say a separate build for the Wifi and Ethernet should be made and I don't know how to do it.

I've changed the compiler options in the Duet2Combined build of RRF 3.02 to optimise for space instead of speed, and saved some space in a few other places, and it now fits. Sometime soon I will change it to include the 12864 support as standard and automatically disable the extra 2 stepper drivers if the display is enabled using M918. I haven't yet assigned the extra pin needed by 12864 displays with ST7567 controllers, or the extra pin needed for backlight control on some displays, but I plan to take those from CONN_LCD too - which is why I will disable both stepper drivers on the connector.

antlob

@dc42 Great news, I'll wait and in the mean time I'll wire the hardware. Since I'm a rookie in this forum and the Duet, when you publish the change where do I find it? or how can I know that it has been published?

dc42

The work I have done so far is on the v3.02-dev branch of the Duet3D RepRapFirmware repository, and I will publish the further changes there too.

antlob

@dc42 Many thanks!

antlob

@dc42 Hello! My intention was to first upload the 3.02 to the printer and later do the hardware. I have downloaded RepRapFirmware-3.02-dev.zip and copied it to the /sys folder, rebooted the machine but nothing happens. My firmware version continues to be 2.05.1. Since it is version 3.02 I assumed it would be the same as v3.0. What am I doing wrong? Please advice.

dc42

That zip you downloaded is a source code zip, not a binary zip.

You will need to upgrade to firmware 3.0 first, then you can upgrade immediately to 3.1.1. Sort out the changes to your config,g file, and by the time you have done that I should have a 3.2 alpha firmware build available.

antlob

@dc42 Many thanks! Already with version 3.1.1, now updating my config.g file.

antlob

@dc42 All finished, a little bug on the BLtouch, on the reboot the probe pin remains down, have to put it back up manually by a macro. Everything else works perfect.

Schmart

Please also note the thread I started about my working solution here.

This is my own adaptation of RRF v3-dev code branch. It still needs a little work in terms of optimization and requires a NAND logic chip to invert the Chip Select (CS) signal if the default Maestro 12864 LCD pins are used. The extra A0/DC line that the ST7565/UC1701 requires is implemented with pin exp_0 on the Maestro.

dc42

I've put some RRF 3.1 alpha binaries at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. The 12864 display is not yet enabled in the Duet WiFi/Ethernet build because I still need to add the code to disable motors 10 and 11 when the 12864 display is configured.

Schmart

@dc42 Hi David, I tried the 3.1 alpha firmware on my Maestro, but my display is not working with this. Is this build (5/25/2020) based on the v3.02-dev branch? Because in that branch I'm missing some essential driver protocol not implemented for the ST7565/UC1701 (and the ST7567 seems to use the same protocol). Also, I'm pretty sure that using active low polarity for CS will not work because of the gated setup on the Maestro.

Is it an option that I share my preliminary (not entirely finished) code with you somehow?

And here is my firmware build for the Maestro, based on a recent v3-dev:
https://1drv.ms/u/s!Au1g8fW6BaQzioADewiHDAxzQ_Adlg?e=5sMNUT

Edit: Intended to test display support only, would not recommend to use this firmware for printing important stuff yet.

Schmart

@dc42 I created a draft pull request from my fork, so you can at least inspect my changes. I hope that's an acceptable process for you!

P.S. Relatively new to Git, though I read half the Pro Git book.

Schmart

@dc42 The optimized flush routine is implemented now, and I merged the v3.02-dev branch with my ST7565 branch as well, so the most recent beta changes are incorporated. The firmware binary is also updated, so the link provided earlier points to my newest build.

P.S. I also updated the draft pull request, but now against the v3.02-dev.

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.