{"id":34,"date":"2014-01-24T14:57:00","date_gmt":"2014-01-24T14:57:00","guid":{"rendered":"https:\/\/blog.hslracing.com\/3dprinters\/2014\/01\/24\/repetier-and-i2c-lcd-panel\/"},"modified":"2021-06-08T18:46:37","modified_gmt":"2021-06-08T17:46:37","slug":"repetier-and-i2c-lcd-panel","status":"publish","type":"post","link":"https:\/\/blog.hslracing.com\/3dprinters\/2014\/01\/repetier-and-i2c-lcd-panel.html","title":{"rendered":"Repetier and I2C LCD panel"},"content":{"rendered":"

I was having yet another bash at persuading my breadboard based hardware to work with the I2C connected LCD display as mentioned in my Panelolu<\/a> post.<\/p>\n

I have been bashing my head against a wall with the Repetier<\/a> firmware for months. Every time I had it use the LCD and uploaded the firmware, the whole board would hang just as it reached the initialisation of the LCD display.<\/p>\n

I had tried with the built-in I2C library as well as several other Liquid Crystal libraries, none of which would work with\u00a0Repetier<\/a>\u00a0once the LCD part was enabled.<\/p>\n

I could manage to talk to the\u00a0PCF8574P\u00a0<\/a>\u00a0I2C chip and obtain the address with the Scanner<\/a> program, I could also write my own code to talk to the LCD all of which seemed to work fine, yet no matter what I did the LCD would just not play ball with\u00a0Repetier<\/a>.<\/p>\n

I decided to re-read a bunch of posts about the various Liquid Crystal I2C libraries along with checking the schematics used for each of them, re-check the pin configurations in\u00a0Repetier<\/a>\u00a0and also how it was wired up on the board.<\/p>\n

Eventually I discovered that I had the RS and RW pins backwards in uiconfig.h for\u00a0Repetier<\/a>\u00a0and after one last compile and upload we had success and the LCD sprang into life. (kind of begs the question how it was working with the other pieces of software though).<\/p>\n

<\/a><\/div>\n

This is my pin configuration for the LCD in uiconfig.h<\/p>\n

\/**<\/span>
\nWhat display type do you use?<\/span>
\n0 = No display<\/span>
\n1 = LCD Display with 4 bit data bus<\/span>
\n2 = LCD Display with 8 bit data bus (currently not implemented, fallback to 1)<\/span>
\n3 = LCD Display with I2C connection, 4 bit mode<\/span>
\n4 = Use the slower LiquiedCrystal library bundled with arduino.\u00a0<\/span>
\n\u00a0 \u00a0 IMPORTANT: You need to uncomment the LiquidCrystal include in Repetier.pde for it to work.<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0If you have Sanguino and want to use the library, you need to have Arduino 023 or older. (13.04.2012)<\/span>
\n*\/<\/span>
\n#define UI_DISPLAY_TYPE 3<\/span>
\n
\n<\/span>\/\/ This is line 2 of the status display at startup<\/span>
\n#define UI_VERSION_STRING2 “Orig. Mendel”<\/span>
\n
\n<\/span>\/** Number of columns per row<\/span>
\n
\n<\/span>Typical values are 16 and 20<\/span>
\n*\/<\/span>
\n#define UI_COLS 16<\/span>
\n\/**<\/span>
\nRows of your display. 2 or 4<\/span>
\n*\/<\/span>
\n#define UI_ROWS 2<\/span>
\n
\n<\/span>\/* What type of chip is used for I2C communication<\/span>
\n0 : PCF8574 or PCF8574A or compatible chips.<\/span>
\n1 : MCP23017<\/span>
\n*\/<\/span>
\n#define UI_DISPLAY_I2C_CHIPTYPE 0<\/span>
\n\/\/ 0x40 till 0x4e for PCF8574, 0x40 for the adafruid RGB shield, 0x40 – 0x4e for MCP23017<\/span>
\n#define UI_DISPLAY_I2C_ADDRESS 0x40<\/span>
\n\/\/ For MCP 23017 define which pins should be output<\/span>
\n#define UI_DISPLAY_I2C_OUTPUT_PINS 65504<\/span>
\n\/\/ Set the output mask that is or’d over the output data. This is needed to activate<\/span>
\n\/\/ a backlight switched over the I2C.\u00a0<\/span>
\n\/\/ The adafruit RGB shields enables a light if the bit is not set. Bits 6-8 are used for backlight.<\/span>
\n#define UI_DISPLAY_I2C_OUTPUT_START_MASK 0<\/span>
\n\/\/ For MCP which inputs are with pullup. 31 = pins 0-4 for adafruid rgb shield buttons<\/span>
\n#define UI_DISPLAY_I2C_PULLUP 31<\/span>
\n\/* How fast should the I2C clock go. The PCF8574 work only with the lowest setting 100000.<\/span>
\nA MCP23017 can run also with 400000 Hz *\/<\/span>
\n#define UI_I2C_CLOCKSPEED 100000L<\/span>
\n\/**<\/span>
\nDefine the pin<\/span>
\n*\/<\/span>
\n#if UI_DISPLAY_TYPE==3 \/\/ I2C Pin configuration<\/span>
\n#define UI_DISPLAY_RS_PIN _BV(4)<\/span>
\n#define UI_DISPLAY_RW_PIN _BV(5)<\/span>
\n#define UI_DISPLAY_ENABLE_PIN _BV(6)<\/span>
\n#define UI_DISPLAY_D0_PIN _BV(0)<\/span>
\n#define UI_DISPLAY_D1_PIN _BV(1)<\/span>
\n#define UI_DISPLAY_D2_PIN _BV(2)<\/span>
\n#define UI_DISPLAY_D3_PIN _BV(3)<\/span>
\n#define UI_DISPLAY_D4_PIN _BV(0)<\/span>
\n#define UI_DISPLAY_D5_PIN _BV(1)<\/span>
\n#define UI_DISPLAY_D6_PIN _BV(2)<\/span>
\n#define UI_DISPLAY_D7_PIN _BV(3)<\/span><\/p>\n

The _BV values are the P0-P7 pins from the\u00a0PCF8574P<\/a>\u00a0chip – I only needed P0-P6, D0-D4 are for the low nibble, D5-D8 for the high nibble, you can connect in 8-bit mode if you have enough pins (D0-D7), or you can connect in 4-bit mode (D5-D7), you just pretend that both sets are connected to the same pins and both the low and high nibble data is transferred over these 4 pins.<\/p>\n

As mentioned in my Firmware and Making Fumes<\/a> post, I have 10 pins to play with (13 if you include MOSI, MISO and SCK) on the\u00a0sanguinololu<\/a>.<\/p>\n

Now I have reduced my LCD pin requirement from 6 to 2, I have a few more to play with, which means I can use the buzzer again, and still have 3 pins spare.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Physical Pin #<\/th>\nPin Name<\/th>\nSanguinololu Pin<\/th>\nArduino Use<\/th>\nMy Use<\/th>\n<\/tr>\n
7<\/td>\nPB6<\/td>\nD7<\/td>\nMISO<\/td>\nSD card MISO<\/td>\n<\/tr>\n
6<\/td>\nPB5<\/td>\nD6<\/td>\nMOSI<\/td>\nSD card MOSI<\/td>\n<\/tr>\n
8<\/td>\nPB7<\/td>\nD5<\/td>\nSCK<\/td>\nSD card SCK<\/td>\n<\/tr>\n
40<\/td>\nPA0<\/td>\nA0\/D31<\/td>\nGP I\/O<\/td>\nSD card CS<\/td>\n<\/tr>\n
9<\/td>\nRST<\/td>\nRST<\/td>\nRST<\/td>\nReset Button<\/td>\n<\/tr>\n
38<\/td>\nPA2<\/td>\nA2\/D29<\/td>\nGP I\/O<\/td>\nEncoder 1<\/td>\n<\/tr>\n
39<\/td>\nPA1<\/td>\nA1\/D30<\/td>\nGP I\/O<\/td>\nEncoder 2<\/td>\n<\/tr>\n
16<\/td>\nPD2<\/td>\nD10<\/td>\nRX1<\/td>\nEncoder C<\/td>\n<\/tr>\n
37<\/td>\nPA3<\/td>\nA3\/D28<\/td>\nGP I\/O<\/td>\nBuzzer<\/td>\n<\/tr>\n
22<\/td>\nPC0<\/td>\nD16<\/td>\nSCL<\/td>\nI2C LCD SCL<\/td>\n<\/tr>\n
23<\/td>\nPC1<\/td>\nD17<\/td>\nSDA<\/td>\nI2C LCD SDA<\/td>\n<\/tr>\n
36<\/td>\nPA4<\/td>\nA4\/D27<\/td>\nGP I\/O<\/td>\nFree<\/td>\n<\/tr>\n
5<\/td>\nPB4<\/td>\nD4<\/td>\nPWM<\/td>\nFree<\/td>\n<\/tr>\n
17<\/td>\nPD3<\/td>\nD11<\/td>\nTX1<\/td>\nFree<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Whilst at a first glance, this might not seem the most logical layout, it makes more sense if you look at the way the pins are actually laid out on the\u00a0sanguinololu<\/a>.<\/p>\n
<\/a><\/div>\n
<\/div>\n<\/div>\n
I believe I have mentioned it already, but I am not interested in running any firmware that will not compile against a relatively current version of Arduino<\/a>, (trying to obtain any support for issues with older versions is quite simply a pain), as such I am only interested in firmware that will compile against\u00a0Arduino<\/a>\u00a01.0 or greater (I am currently using 1.0.5).<\/p>\n

I have not compiled in the extra code for the rotary encoder or the buzzer yet, but things are looking good for using an ATmega644P<\/a>\u00a0rather than needing the more expensive\u00a0ATmega1284P<\/a>, as the compiled code is only 47,928 bytes. Previously with the\u00a0Marlin<\/a>\u00a0firmware, after enabling the LCD code, I was beyond the 64Kb limit of the\u00a0ATmega644P<\/a>.<\/p>\n

Here is a possible interface board for the panelolu.<\/p>\n

<\/a><\/div>\n

And without the components covering the connections.<\/p>\n

<\/a><\/div>\n
The only real difference from the schematic is that the connections for pins 9 and 11 (P4 and P6) have been swapped in order to make wiring simpler.<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

I was having yet another bash at persuading my breadboard based hardware to work with the I2C connected LCD display as mentioned in my Panelolu post. I have been bashing my head against a wall with the Repetier firmware for months. Every time I had it use the LCD and uploaded the firmware, the whole…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[4],"class_list":["post-34","post","type-post","status-publish","format-standard","hentry","category-uncategorised","tag-prusa-i3"],"_links":{"self":[{"href":"https:\/\/blog.hslracing.com\/3dprinters\/wp-json\/wp\/v2\/posts\/34","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.hslracing.com\/3dprinters\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.hslracing.com\/3dprinters\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.hslracing.com\/3dprinters\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.hslracing.com\/3dprinters\/wp-json\/wp\/v2\/comments?post=34"}],"version-history":[{"count":1,"href":"https:\/\/blog.hslracing.com\/3dprinters\/wp-json\/wp\/v2\/posts\/34\/revisions"}],"predecessor-version":[{"id":224,"href":"https:\/\/blog.hslracing.com\/3dprinters\/wp-json\/wp\/v2\/posts\/34\/revisions\/224"}],"wp:attachment":[{"href":"https:\/\/blog.hslracing.com\/3dprinters\/wp-json\/wp\/v2\/media?parent=34"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.hslracing.com\/3dprinters\/wp-json\/wp\/v2\/categories?post=34"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.hslracing.com\/3dprinters\/wp-json\/wp\/v2\/tags?post=34"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}