Logic Level shifter for 12864 display on Duet 2 Wifi

antlob

Thanks for the tip @bearer, found them finally, is huge but I'll definitely try it. Just one question, if I only connect ENC_SW, ENC_A, ENC_B, BEEP on the Duet 2 CON_LCD to the EXP 1 and EXP 2 on the LCD 12864. Will it work? The CON_SD is used right know to support the SD on the PanelDue.

A Former User

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

Will it work? The CON_SD is used right know to support the SD on the PanelDue.

CON_SD is also needed to drive the display, it uses the SPI bus for both, which is why I opted to change things around so I could connect only CON_SD and have a functional display sans the encoder.

antlob

OK! So for what you say it is impossible to connect this LCD only from CON_LCD. I do not have the required knowledge to swap the SPI pins to CON_LCD, or maybe it is not even possible. Thank you, you saved me a lot of time!

A Former User

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

me the modified libraries to make the build?

I didn't modify any libraries, and the patch against RRF is up there somewhere, and I believe we included it on the easyeda page for the board as well.

I don't have access to the computer I built the firmware atm, but i found these locally, if you're prepared to recover by usb/bossa you could give it a try.

https://www.dropbox.com/s/g42b7gye964sd5e/Duet2CombinedFirmware_2.0.51_LCD8.bin?dl=1
https://www.dropbox.com/s/f7fjuu7f0wcf7dc/Duet2CombinedFirmware-rrf3-lcd.bin?dl=1

dc42

The RRF v3.02-dev branch now includes the changes needed to support ST7920 and ST7567 displays in the source code. Unfortunately the generated binary is too large if you enable SUPPORT_12864_LCD in the standard Duet2CombinedFirmware build. So something else will need to be done, perhaps one of the following:

Strip out unused functionality
Use separate builds for Duet Wifi and Duet Ethernet, so that only one set of network code is needed
Remove the large font
Change the optimisation options to optimise for space instead of speed, and use function-specific attributes on those functions where optimisation for speed is desirable

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.