Has anyone gotten an MINI12864 LCD to work with Ramps 1.4 on the new Marlin 1.1?
I have tried many different things and referenced https://github.com/makerbase-mks/Marlin but could not figure out how to properly configure dogm_lcd_implementation.h in the old or new versions of marlin.
Try enabling just REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER. It's based on the 12864.
@Bob-the-Kuhn tried enabling REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
After firmware uploaded the speaker would beep every half second with no backlight. I swapped EXP 1 & 2 which showed backlight but no display.
Is this your display?
The one I have is a little different.
Here is the one I have HERE
There's some decent interface instructions in that link. I take it that they don't work.
How are you connecting the display to your RAMPS board?
:smile: I tried the custom pin settings with the new version of marlin and no dice.
Maybe I need to try it with an older version?
I am connecting the EXP 1 & 2 Cables to a with one of these Adapter Cards
Are the connectors on your adapter card the same orientation as the picture? My card has the key on the other side of the connectors.
Do you at least have the backlight coming on?
I am able to get the back-light to come on but there is no text. I think you might be on to something here.
Tomorrow I'll cut the headers on the adapter so I can invert the cables. Will followup on the result. Thanks for the help!
Don't do that. If the headers were backwards then you wouldn't get a light.
Does the encoder, SD card and button(s) work? And the beeper?
I have this exact same display that just arrived today from the big rock candy mountain, which I felt forced to get in order to try out UBL on my Printrbot (although now I hear LCD is no longer an absolute requirement - * blech *).
I have a feeling getting it to work on your RAMPS will be much easier than on the rats nest of pin voodoo that is the Printrboard, but I'm curious how it goes for you :)
Try this file. I've made a couple of changes in it compared to the instructions in the link. On my RAMPS system DOGLCD_A0 should be connected to 16 and DOGLCD_CS should be connected to 17.
There one more pin I have a question on. I expect that it's a no connect for this LCD. I've sent a couple of emails trying to get the pinout of the connectors.
@fiveangle - Dave - if you find the connection diagram for a RepRap Discount Full Graphics controller then you're 90% of the way there. This says to use the MINIPANEL LCD controller option & modify some pin assignments.
@Bob-the-Kuhn
I tried the new pins.RAMPS.h file and had the same result. I tried defining the following LCDs;
REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
MINIPANEL
SAV_3DGLCD
All of those definitions have similar results.
When I connect the EXP 1 & 2 cables I get no back-light but I do get some buzzer noise randomly.
When I connect the EXP 1 & 2 cables inverted I get a back-light with no text and no buzzer noise.
Here are some photo's of my actual parts: Adapter | LCD
Also I did some digging and found the Manufactures website, which is zero help: https://www.makerbase.com.cn/home/index
When you had the cables inverted, were you able to see the SD card?
Was the screen blank or did it have garbage on it?
I received an email from MKS but it basically translated to the pinout in the link you provided earlier.
Try the mods in the link but this time use:
DOGLCD_CS 27
DOGLCD_A0 25
If that doesn't work then it's back to basics. Let's make sure of the pins on your adapter.
Here's the pinout I expect to see. This is what the Full Graphic interface is.
BEEPER D37 1 2 D35 BTN_ENC
LCDE D17 3 4 D16 LCDRS
LCD4 D23 5 6 D25 LCD5
LCD6 D27 7 8 D29 LCD7
GND 9 10 VCC
EXP2
MISO D50 1 2 D52 SCK
BTN_EN2 D31 3 4 D53 SD_CSEL
BTN_EN1 D33 5 6 D51 MOSI
SD_DET D49 7 8 D41 STOP/KILL BTN
GND 9 10 NC
To identify the logical pin that the each connector pin is attached to you'll need to attach an LED to the pin in question and run a utility that pulses every pin.
If you want to save some time then here's the full syntax for the M43 T command.
* M43 T - Toggle pin(s) and report which pin is being toggled
* S<pin> - Start Pin number. If not given, will default to 0
* L<pin> - End Pin number. If not given, will default to last pin defined for this board
* I<bool> - Flag to ignore Marlin's pin protection. Use with caution!!!!
* R - Repeat pulses on each pin this number of times before continueing to next pin
* W - Wait time (in miliseconds) between pulses. If not given will default to 500
I did run across a thread where they were able to get the MIN12864 to work. The nasty is they did hardware mods to the LCD. Sure hope it doesn't come to that.
I did run across a thread where they were able to get the MIN12864 to work. The nasty is they did hardware mods to the LCD. Sure hope it doesn't come to that.
My HW mod is just required for DUE, as the HWSPI in u8glib v1 for that display is not working at 32 bits:)
At rumba I managed to run this display with HWSPI, and I guess any 8bit will work, just you need correct pins..
I even found an old code I used for rumba (not in 3d printer firmware, just one of my projects needed a temporary display:) ), I used there simply:
#define UI_DISPLAY_DOGLCD_CS 38
#define UI_DISPLAY_DOGLCD_A0 41
U8GLIB_MINI12864 u8g(UI_DISPLAY_DOGLCD_CS, UI_DISPLAY_DOGLCD_A0,U8G_I2C_OPT_NONE);
And SD card:
#define SDSS 53
SD.begin(SDSS);
@GarrethX - many thanks 😊
Combined with your last post in the original thread I think I see a light at the end of the tunnel.
define MINIPANEL
But you must go through the firmware I posted, in file ultralcd_impl_DOGM.h I modified line 176:
elif ENABLED(MINIPANEL)
// The MINIPanel display
//U8GLIB_MINI12864 u8g(DOGLCD_CS, DOGLCD_A0); // 8 stripes
U8GLIB_MINI12864_2X u8g(53,51,DOGLCD_CS, DOGLCD_A0,U8G_PIN_NONE);
Someone has already made a similar mod to ultralcd_impl_DOGM.h. Not quite the same so if the current one doen't work then we'll try
U8GLIB_MINI12864_2X u8g(DOGLCD_CS, DOGLCD_A0,U8G_PIN_NONE);
@GarrethX
Where can I define?
I tried modifying
#define MINIPANEL
But you must go through the firmware I posted, in file ultralcd_impl_DOGM.h I modified line 176:
#elif ENABLED(MINIPANEL)
// The MINIPanel display
//U8GLIB_MINI12864 u8g(DOGLCD_CS, DOGLCD_A0); // 8 stripes
U8GLIB_MINI12864_2X u8g(53,51,DOGLCD_CS, DOGLCD_A0,U8G_PIN_NONE);
But was unable to get it working...
I came across the post where I think you got this from and the photo's on page 3 look like I may need to connect to more pins, but I'm not sure since this was for the rumba board?
@Bob-the-Kuhn
I also tried the
U8GLIB_MINI12864_2X u8g(DOGLCD_CS, DOGLCD_A0,U8G_PIN_NONE);
But was not able to get it working. This may be beyond my technical abilities.
Different thread, same white knight.
I can do the modifications.
But first ... is the SD card portion working?
Please identify the pins on your connector. I expect that we'll find some differences. Once we know for sure what we're working with then we can move forward to modifying pins_RAMPS.h and possibly ultralcd_impl_DOGM.h.
Well, we start to have a little confusion because of amount of threads :)
First, for 8 bit processors:
u8glib v1 works fine in hw spi together with the card reader. Pins for
rumba I posted above which I used for one project succesfully (lcd+card
reader). I guess they are the same on other boards like ramps?
For 32 bit processors:
u8glib v1 works only in SW SPI
u8glib v2 works in both SW and HW spi
Pin defines I copied from my project and their position was not relevant
there.
In firmware of the printer you want to put these defines in pin file for
your board.
I posted the drawing on the mentioned thread how the pins are located on
the exp1 and exp2 ports, but since different boards can have those ports
with different pinout, you have to check and compare pinout of your board
and adjust accordingly.
On May 25, 2017 21:33, "Bob-the-Kuhn" notifications@github.com wrote:
Different thread, same white knight.
I can do the modifications.
But first ... is the SD card portion working?
Please identify the pins on your connector. I expect that we'll find some
differences. Once we know for sure what we're working with then we can move
forward to modifying pins_RAMPS.h and possibly ultralcd_impl_DOGM.h.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/6847#issuecomment-304102372,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALEK7nIri-IrBdiQ3enlt99r30E2gHhQks5r9defgaJpZM4NltLY
.
@Bob-the-Kuhn
I'll grab an SD card tomorrow to test. But doing more research Leap 3D on their ebay listing is saying;
This LCD controller similar to Full Graphic LCD Smart Controller and most of information found in in RepRapDiscount Full Graphic Smart Controller WIKI will apply here as well. <
Still working to find the pinout for the actual board.
Looks like EXP2 is the same as the FULL Graphic & EXP1 is similar but needs different signals mapped to the pins.
I'm expecting (hoping) to see some pin mapping differences on your adapter from mine.
Oh - please use those jumpers that plug onto the connector pins when hooking up the LED. I just heard of one where he apparently shorted +12V to +5V and fried his controller.
I believe that we'll end up with the following pinout for the MKS MINI12865
FUNCTION PIN # FUNCTION
BEEPER 1 2 BTN_ENC
NC 3 4 NC
NC 5 6 DOGLCD_CS
DOGLCD_A0 7 8 NC
GND 9 10 VCC
EXP2
FUNCTION PIN # FUNCTION
MISO 1 2 SCK
BTN_EN2 3 4 SS
BTN_EN1 5 6 MOSI
SD_DET 7 8 KILL_PIN
GND 9 10 NC
EXP2 - same as RepRapDiscount FULL GRAPHIC Smart Controller
AT90USB controllers - use FASTIO logical pin numbers
Hardware implemented functions (software versions available)
logical pins
2560 2561 1284 AT90USB
SCK D52 D10 D7 D9
MOSI D51 D11 D5 D10
MISO D50 D12 D6 D11
SS D53 D16 D4 D8
@Bob-the-Kuhn what's this pinout mean in layman's terms?
Also what did you mean by jumping the connector pins when hooking up the LED?
and another question how can I tell if the SD Card is working with no screen text?
OK - need to do a real graphic on the pinout.
On the SD card - use the host interface (Repetier Host, Octoprint) to see if the SD card shows up.
On the LED - I have some single conductor female-female jumper cables that are meant to slip over the square posts on the controller board connectors/pins. I'm just saying it's safer to use those than to try to maneuver the LED pins directly.
These are the type of jumper wires @Bob-the-Kuhn is referring to, which make testing out different pin connections much easier:
Thanks @fiveangle I have these on hand. I was hoping for a digital pin change than a wire harness adapter. Maybe I'm better of getting another display ☺️? I'll try to follow @Bob-the-Kuhn instructions and get it working.
There's no CPLD on any 3D printer I've ever seen, so sometimes you need to just cozy up to the diagnostic basics ;)
I'll be working to get this LCD working on a Printrboard RevF sometime over the long weekend so I'll let you know if I find out anything interesting (which I doubt will help you, since it sounds like the real mystery for you is on the board-side. Good luck !
-=dave
@fiveangle - I just committed Teensyduino compatible M43 code on PR #6737. I expect it'll make finding the pin numbers easier.
Also, I noticed that the SD card reader software uses both FASTIO & Teensy pin number routines. You may not be able to get the card reader portion working.
Yeah, I wasn't expecting the SD card to work. I'll try it immediately and report back. Thx !
Looks like all the pins use FASTIO except for SDSS & LCD_SDSS. Those use the Teensy numbers
@fiveangle - how's it coming?
If you give me your connection list and a copy of your pins_xxx.h file I'll see if I can come up with some suggestions.
I believe that we'll end up with the following pinout for the MKS MINI12865
FUNCTION PIN # FUNCTION BEEPER 1 2 BTN_ENC NC 3 4 NC NC 5 6 DOGLCD_CS DOGLCD_A0 7 8 NC GND 9 10 VCC EXP2 FUNCTION PIN # FUNCTION MISO 1 2 SCK BTN_EN2 3 4 SS BTN_EN1 5 6 MOSI SD_DET 7 8 KILL_PIN GND 9 10 NC
It looks like the one I have (with side-access SD slot) has the keyways (and silkscreen key) the wrong way around, so technically pinout is this:
FUNCTION PIN # FUNCTION
VCC 1 2 GND
NC 3 4 DOGLCD_A0
DOGLCD_CS 5 6 NC
NC 7 8 NC
BTN_ENC 9 10 BEEPER
EXP2
FUNCTION PIN # FUNCTION
NC 1 2 GND
KILL_PIN 3 4 SD_DET
MOSI 5 6 BTN_EN1
SS 7 8 BTN_EN2
SCK 9 10 MISO
I'm making a custom cable for the Printrboard anyway, but it's probably best for others to just shave the keyway off and plug it in the other way around (with red tracer on ribbon closest to the "E" side of the port labels)
@fiveangle - how's it coming?
I'm starting to get the HW side sorted out. I'll probably take you up on the offer once I have the cable done and ready to start with pin debugging. Current output is:
Edit: I tried to use the "details" tag, but it doesn't support "code" formatting [le sigh]
Send: M43
Recv: The first number is the FAST_IO pin number. The one in parenthesis is the equivalent Teensy/Arduino pin number
Recv: PIN: 24 ( 0) Port: D0 <unused/unknown> Input = 1 TIMER0B PWM: 128 WGM: 3 COM0B: 0 CS: 3 TCCR0A: 3 TCCR0B: 3 TIMSK0: 5 compare interrupt enabled overflow interrupt enabled
Recv: PIN: 25 ( 1) Port: D1 <unused/unknown> Input = 1 TIMER2B PWM: 0 WGM: 1 COM2B: 0 CS: 2 TCCR2A: 1 TCCR2B: 2 TIMSK2: 0
Recv: PIN: 26 ( 2) Port: D2 <unused/unknown> Input = 1
Recv: PIN: 27 ( 3) Port: D3 <unused/unknown> Input = 1
Recv: PIN: 28 ( 4) Port: D4 <unused/unknown> Input = 0
Recv: PIN: 29 ( 5) Port: D5 <unused/unknown> Input = 1
Recv: PIN: 30 ( 6) Port: D6 <unused/unknown> Input = 1
Recv: PIN: 31 ( 7) Port: D7 <unused/unknown> Input = 1
Recv: PIN: 32 ( 8) Port: E0 <unused/unknown> Input = 1
Recv: PIN: 33 ( 9) Port: E1 <unused/unknown> Input = 1
Recv: PIN: 16 (10) Port: C0 <unused/unknown> Output = 0
Recv: PIN: 17 (11) Port: C1 <unused/unknown> Input = 1
Recv: PIN: 18 (12) Port: C2 <unused/unknown> Input = 1
Recv: PIN: 19 (13) Port: C3 E0_ENABLE_PIN Output = 1
Recv: PIN: 20 (14) Port: C4 HEATER_BED_PIN Output = 0 TIMER3C PWM: 0 WGM: 1 COM3C: 0 CS: 2 TCCR3A: 129 TCCR3B: 2 TIMSK3: 0
Recv: . SDSS Output = 0
Recv: PIN: 21 (15) Port: C5 HEATER_0_PIN Output = 0 TIMER3B PWM: 0 WGM: 1 COM3B: 0 CS: 2 TCCR3A: 129 TCCR3B: 2 TIMSK3: 0
Recv: PIN: 22 (16) Port: C6 <unused/unknown> PWM: 0 TIMER3A PWM: 0 WGM: 1 COM3A: 2 CS: 2 TCCR3A: 129 TCCR3B: 2 TIMSK3: 0
Recv: PIN: 23 (17) Port: C7 Z_ENABLE_PIN Output = 1
Recv: PIN: 38 (18) Port: E6 Y_ENABLE_PIN Output = 1
Recv: PIN: 39 (19) Port: E7 X_ENABLE_PIN pin_Teensy 19 protected
Recv: PIN: 8 (20) Port: B0 AVR_SS_PIN pin_Teensy 20 protected
Recv: . SS_PIN pin_Teensy 20 protected
Recv: PIN: 9 (21) Port: B1 AVR_SCK_PIN pin_Teensy 21 protected
Recv: . SCK_PIN pin_Teensy 21 protected
Recv: PIN: 10 (22) Port: B2 AVR_MOSI_PIN Output = 1
Recv: . FAN_PIN Output = 1
Recv: . MOSI_PIN Output = 1
Recv: PIN: 11 (23) Port: B3 AVR_MISO_PIN pin_Teensy 23 protected
Recv: . MISO_PIN pin_Teensy 23 protected
Recv: PIN: 12 (24) Port: B4 Y_MAX_PIN Input = 0 TIMER2A PWM: 0 WGM: 1 COM2A: 0 CS: 2 TCCR2A: 1 TCCR2B: 2 TIMSK2: 0
Recv: . Y_STOP_PIN Input = 0
Recv: PIN: 13 (25) Port: B5 <unused/unknown> Input = 1 TIMER1A PWM: 2000 WGM: 4 COM1A: 0 CS: 2 TCCR1A: 0 TCCR1B: 10 TIMSK1: 2 non-standard PWM mode compare interrupt enabled
Recv: PIN: 14 (26) Port: B6 <unused/unknown> Input = 1 TIMER1B PWM: 0 WGM: 4 COM1B: 0 CS: 2 TCCR1A: 0 TCCR1B: 10 TIMSK1: 2 non-standard PWM mode
Recv: PIN: 15 (27) Port: B7 <unused/unknown> Input = 1 TIMER1C PWM: 0 WGM: 4 COM1C: 0 CS: 2 TCCR1A: 0 TCCR1B: 10 TIMSK1: 2 non-standard PWM mode
Recv: . TIMER0A is also tied to this pin TIMER0A PWM: 130 WGM: 3 COM0A: 0 CS: 3 TCCR0A: 3 TCCR0B: 3 TIMSK0: 5 overflow interrupt enabled
Recv: PIN: 0 (28) Port: A0 X_STEP_PIN Output = 0
Recv: PIN: 1 (29) Port: A1 DAC_STEPPER_VREF Output = 0
Recv: . X_DIR_PIN Output = 0
Recv: PIN: 2 (30) Port: A2 Y_STEP_PIN Output = 0
Recv: PIN: 3 (31) Port: A3 Y_DIR_PIN Output = 0
Recv: PIN: 4 (32) Port: A4 Z_STEP_PIN Output = 0
Recv: PIN: 5 (33) Port: A5 Z_DIR_PIN Output = 0
Recv: PIN: 6 (34) Port: A6 E0_STEP_PIN Output = 0
Recv: PIN: 7 (35) Port: A7 E0_DIR_PIN pin_Teensy 35 protected
Recv: PIN: 36 (36) Port: E4 Z_MIN_PIN pin_Teensy 36 protected
Recv: . Z_STOP_PIN pin_Teensy 36 protected
Recv: PIN: 37 (37) Port: E5 <unused/unknown> Input = 1
Recv: PIN: 40 (38) Port: F0 (A 0) TEMP_BED_PIN pin_Teensy 38 protected
Recv: PIN: 41 (39) Port: F1 (A 1) TEMP_0_PIN pin_Teensy 39 protected
Recv: PIN: 42 (40) Port: F2 (A 2) FILWIDTH_PIN Analog in = 755
Recv: PIN: 43 (41) Port: F3 (A 3) <unused/unknown> Analog in = 628 Input = 0
Recv: PIN: 44 (42) Port: F4 (A 4) <unused/unknown> Analog in = 1023 Input = 0
Recv: PIN: 45 (43) Port: F5 (A 5) <unused/unknown> Analog in = 1023 Input = 0
Recv: PIN: 46 (44) Port: F6 (A 6) HEATER_1_PIN Output = 0
Recv: PIN: 47 (45) Port: F7 (A 7) HEATER_2_PIN Output = 0
Recv: PIN: 34 (--) Port: E2 <unused/unknown> Input = 1
Recv: PIN: 35 (--) Port: E3 X_MIN_PIN Input = 0
Recv: . X_STOP_PIN Input = 0
Recv: ok P15 B3
Below are the expansion port pinout according to RepRap adapter board (left), RevF schematics (middle), and your pins (right):

I tried the pins debugger and I'm not getting anything on it. When I use M43 E1, it shows my endstops, but shouldn't M43 W1 also show endstops triggering ? M43 seems to be flakey for me. First time I tried it, it showed this:
[...]
Send: M43 W1
Recv: Watching pins
Recv: PIN: 20 (14) Port: C4 HEATER_BED_PIN Input = 0 TIMER3C PWM: 0 WGM: 1 COM3C: 0 CS: 2 TCCR3A: 129 TCCR3B: 2 TIMSK3: 0
Recv: . SDSS Input = 0
Recv: PIN: 20 (14) Port: C4 HEATER_BED_PIN Input = 0 TIMER3C PWM: 0 WGM: 1 COM3C: 0 CS: 2 TCCR3A: 129 TCCR3B: 2 TIMSK3: 0
Recv: . SDSS Input = 0
Then next time, it didn't even show that:
Send: M43 E1
Recv: endstop monitor enabled
Recv: ok P15 B3
Recv: Z_MIN:1
Recv:
[...]
Recv: X_MIN:1
Recv:
Recv: X_MIN:0
Recv:
[...]
Send: M43 E0
Recv: endstop monitor disabled
Recv: ok P15 B3
[...]
Send: M43 W1
Recv: Watching pins
Recv: PIN: 17 (11) Port: C1 <unused/unknown> Input = 0
Recv: PIN: 17 (11) Port: C1 <unused/unknown> Input = 1
Recv: PIN: 16 (10) Port: C0 <unused/unknown> Input = 0
Recv: PIN: 17 (11) Port: C1 <unused/unknown> Input = 0
Recv: PIN: 16 (10) Port: C0 <unused/unknown> Input = 1
Recv: PIN: 17 (11) Port: C1 <unused/unknown> Input = 1
Recv: PIN: 17 (11) Port: C1 <unused/unknown> Input = 0
Recv: PIN: 17 (11) Port: C1 <unused/unknown> Input = 1
Above appears in response to rotating encoder. And we're on the board !
@Bob-the-Kuhn - let me know if you'd be up for a slack or hangouts session to help me with a few questions to get me started. Nothing is plugged in for Printrboards except the viki2 panel so I've got to put it all in and I just want some pointers on the "best" way to do it.
Found this from another vendor and matches closer to what I'm observing:
(From http://m.globalsources.com/gsol/I/3D-printer/p/sm/1148779928.htm)
It's a busy day so I don't know when I'll be available.
Looks like you've made good progress.
Try hooking up MOSI, SCK, and defining DOGLCD_CS & DOGLCD_A0. Maybe you'll get something on the display.
The only remaining signals to hook up are MISO & SS (also called SDSS & SDCS).
I'll have to do more research on what to do about SS. On Printrboard it only goes to the SD card. I've heard of software SPI being used on Marlin. It sounds like it's an option that's already there.
I'll mod the files & send them later.
I think I'm done. The Printrboard just wasn't meant to be run with an LCD ;)
I've wasted enough of my holiday on this failed project so someone else will have to pick up the torch.
I enabled MINIPANEL and set options in RevF pins file (attached) to patch to EXP1 header like so (which PB fork recently enabled VIKI for their new printers on same pins, so is probably correct):
#if ENABLED(MINIPANEL)
#define DOGLCD_A0 42 // Non-FastIO
#define DOGLCD_CS 43 // Non-FastIO
#define LCD_SCREEN_ROT_180
// (FastIO Pins)
#define BTN_EN1 26
#define BTN_EN2 27
#define BTN_ENC 47
#define BLEN_C 2
#define BLEN_B 1
#define BLEN_A 0
// encoder rotation values
#define encrot0 0
#define encrot1 2
#define encrot2 3
#define encrot3 1
#endif
It appears defining MINIPANEL defines ULTRAPANEL, which defines ULTRA_LCD, which already contained pin definitions in the RevF pins file, resulting in a bunch of redefines. Commenting those out, this was the closest it came to compiling:
"/Applications/Arduino 1.8.2-teensy.app/Contents/Java/hardware/teensy/../tools/avr/bin/avr-g++" -c -Os -g -Wall -ffunction-sections -fdata-sections -MMD -fno-exceptions -felide-constructors -std=c++0x -mmcu=at90usb1286 -DTEENSYDUINO=136 -DARDUINO_ARCH_AVR -DARDUINO=10802 -DF_CPU=16000000L -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-I/Applications/Arduino 1.8.2-teensy.app/Contents/Java/hardware/teensy/avr/cores/teensy" "-I/Users/speedster/Documents/Arduino/libraries/U8glib/src" "-I/Applications/Arduino 1.8.2-teensy.app/Contents/Java/hardware/teensy/avr/libraries/Wire" "/var/folders/q1/g9l9mqmn319fh27k43yqpy440000gr/T/arduino_build_243020/sketch/ultralcd.cpp" -o "/var/folders/q1/g9l9mqmn319fh27k43yqpy440000gr/T/arduino_build_243020/sketch/ultralcd.cpp.o"
ultralcd.cpp: In function 'void lcd_synchronize(const char*)':
ultralcd.cpp:493: error: invalid conversion from 'void (*)(const char*)' to 'screenFunc_t {aka void (*)()}' [-fpermissive]
lcd_goto_screen(lcd_synchronize);
^
/var/folders/q1/g9l9mqmn319fh27k43yqpy440000gr/T/arduino_build_243020/sketch/ultralcd.cpp:441:8: note: initializing argument 1 of 'void lcd_goto_screen(screenFunc_t, uint32_t)'
void lcd_goto_screen(screenFunc_t screen, const uint32_t encoder = 0) {
^
Using library U8glib at version 1.19.1 in folder: /Users/speedster/Documents/Arduino/libraries/U8glib
Using library Wire at version 1.0 in folder: /Applications/Arduino 1.8.2-teensy.app/Contents/Java/hardware/teensy/avr/libraries/Wire
invalid conversion from 'void (*)(const char*)' to 'screenFunc_t {aka void (*)()}' [-fpermissive]
When you begin just flailing, you know it's time to call off the dogs...
427e8f971464a14a9e178aded3ea554497687113.patch.txt
UPDATE: I beleive this is an error elsewhere, as just defining REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER (with default LCD pins defined in RevF pins file) results in the same error.
@fiveangle
Dave - take a look at PR #6896. Looks like I'm well on the way to having a system that uses "Teensy only" pins_XXX.h files.
As part of the testing I'm going to need to interface an LCD to my Teensy. 95% of that should translate directly to Printrboard. Don't throw the MKS MINI12864 away yet.
@fiveangle
Dave - we're getting close to releasing the Teensy only system. Could you do us a favor & see if it runs on your system?
Just drop these files into the latest bugfix-1.1.x and rename the Printrboard file. You shouldn't notice anything different except the pin numbers.
Also, I've fixed the M43 issues I created. It should be a useful tool again.
I've got my RepRap full graphic display sort of working with my Teensylu. The display seems to be missing some pixels and others are slightly shifted so I have a semi-readable display. Time to get the logic analyzer out & see what's going on.
The encoder is working.
The SD card isn't working. I think there's a software SPI I need to enable & configure.
My LCD is working!!!
I had to add the following lines to my Configuration.h file. Apparently on the AT90USB boards more delay is needed on the bit to clock setup & hold times. Haven't done any experimenting to see if shorter delays will work. DELAY_0_NOP is the shortest, 5 is the longest.
#define ST7920_DELAY_1 DELAY_5_NOP
#define ST7920_DELAY_2 DELAY_5_NOP
#define ST7920_DELAY_3 DELAY_5_NOP
Only three signals are needed to drive the LCD.
CLOCK LCD_PINS_D4
DATA LCD_PINS_ENABLE
SELECT LCD_PINS_RS
I've been doing some digging on the MINIPANEL setup in Marlin. The line of interest is:
U8GLIB_MINI12864_2X u8g(DOGLCD_CS, DOGLCD_A0);
In the U8GLIB documentation I found this:
class U8GLIB_MINI12864_2X : public U8GLIB
{
public:
U8GLIB_MINI12864_2X(uint8_t sck, uint8_t mosi, uint8_t cs, uint8_t a0, uint8_t reset = U8G_PIN_NONE)
: U8GLIB(&u8g_dev_uc1701_mini12864_2x_sw_spi, sck, mosi, cs, a0, reset)
{ }
U8GLIB_MINI12864_2X(uint8_t cs, uint8_t a0, uint8_t reset = U8G_PIN_NONE)
: U8GLIB(&u8g_dev_uc1701_mini12864_2x_hw_spi, cs, a0, reset)
{ }
};
It looks like there are four lines to control the LCD (sck, mosi, cs, a0) and that Marlin assumes the LCD is hooked up to a hardware SPI. I think you can get it to work with the following connections:
SCK - get it off the ISP connector
MOSI - get it off the ISP connector
DOGLCD_A0 - any convenient I/O pin
DOGLCD_CS - any convenient I/O pin
An alternative method is to use a software SPI. I think that is built into the U8GLIB. I think this will also work:
#define MINI_SCK // any convenient I/O pin
#define MINI_MOSI // any convenient I/O pin
#define DOGLCD_A0 // any convenient I/O pin
#define DOGLCD_CS // any convenient I/O pin
replace U8GLIB_MINI12864_2X u8g(DOGLCD_CS, DOGLCD_A0); with U8GLIB_MINI12864_2X u8g(MINI_SCK, MINI_MOSI, DOGLCD_CS, DOGLCD_A0);
If you use the hardware SPI signals I think you'll have access to the SD card.
If you use the software SPI signals then I doubt you'll have access to the SD card.
@Bob-the-Kuhn - compared to stock Printrbot Simple Metal config, with your changes fan doesn't appear to work but everything else present does (X, Y, Z, E, HE FET, HB FET, inductive probe, XYZE DAC_MOTOR_CURRENT adjust).
Previous code set FAN_PIN to 16 (theoretically fastio according to comments) in my config (neither FAST_SOFT_PWM nor FAST_PWM_FAN enabled) and resulted in fan working with noisy PWM:
// If soft or fast PWM is off then use Teensyduino pin numbering, Marlin
// fastio pin numbering otherwise
#if ENABLED(FAN_SOFT_PWM) || ENABLED(FAST_PWM_FAN)
#define FAN_PIN 22
#else
#define FAN_PIN 16
#endif
Your changes sets pin 10 and fan doesn't work at all:
#if ENABLED(FAST_PWM_FAN)
#define FAN_PIN 16 // C6 PWM3A
#else
#define FAN_PIN 10 // C0
#endif
According to Teensy2.0++ and Printrboard RevF schematics, PWM_FAN pin on PBRevF connects to Pin 41 on ATUSB90, which is C6 rather than C0:


Enabling FAST_PWM_FAN allows normal use of fan with quiet speed control. I know that defining neither before also set pin 16, which resulted in noisy HW PWM and worked, so is the correct action to make pins_PRINTRBOARD*.h remove the conditional entirely and just define the FAN_PIN always ?:
#define FAN_PIN 16 // C6 PWM3A
FYI: Current Teensyduino library of course supports compilation of images >64k so one does not require the Printrbot co HID library to build for Printrboard 128k targets:
* Printrboard - https://github.com/scwimbush/Printrboard-HID-Arduino-IDE-Support
* This is basically Teensyduino but with a bootloader that can handle image sizes
* larger than 64K.
The above seems like it may confuse new users into thinking they need to go through the pain of hand-installing the Printrbot stuff in order to fully utilize the Printrboard (which of course isn't true).
Thanks
My LCD is now fully functional. The SD card software also has a software SPI. The result is I'm using two software SPIs. That's OK for the RepRap full graphics because the LCD and the SD don't share any signals.
The MKS MINI12864 appears to use MOSI and SCK for both the display and the SD card which means there can be only one SPI. Right now I only know of the hardware SPI that can do this. There is a MSPIM hardware SPI on the chip but I have not been able to find the software to run it.
The EXP2 connector and the ISP connector have all the signals needed to run the MKS MINI.
I have a cable that should connect your MKS MINI to the Printrboard. If you give me your address I'll send it to you.
To use the cable you'll need the following defines:
#define DOGLCD_A0 4 // D4 EXP2-5
#define DOGLCD_CS 5 // D5 EXP2-6
#define BTN_ENC 6 // D6 EXP2-7
#define BEEPER_PIN 7 // D7 EXP2-8
#define KILL_PIN 8 // E0 EXP2-10
#define SD_DETECT_PIN 9 // E1 EXP2-11
#define BTN_EN1 10 // C0 EXP2-12
#define SDSS 11 // C1 EXP2-13
#define BTN_EN2 12 // C2 EXP2-14
Were you the one that asked for my email so long ago? It's
bob.[email protected]
@fiveangle - I just noticed your post. Sorry about the delay.
Thanks for testing. Make me a whole lot more comfortable with the change.
Nice to know that Teensduino can now handle 128k images. Now if I could only get it to install I'd be a happy camper.
Yes, removing the pointer to the Printrboard IDE extension makes sense given the 128k capability.
I know we've gone over this fan thing before. With the old system I'm sure that the physical output pin changed depending on the options that were enabled. I can't lay my hands on that discussion.
It makes sense to me to change it so the fan is always on the fan connector. I can't tell what the original developers meant to happen. Al I know for sure is the results didn't match the comments.
Again - thanks for the testing.
Nice work @Bob-the-Kuhn ! Reviewing your recent comments added in your pins*.h config files against my previous work, I had pretty much made it this far before but looks like I hit the HW SPI hurdle that I was unware of and beyond my capabilities to figure out at the time, which you've managed to overcome.
Printrboard has in-built SD on HW SPI plus you I can't enable SD + ABL + LCD anyway due to 128k prog mem limit, so ditching SD entirely makes sense for anyone with Octoprint (although with other optimizations like using only 3PL, no workspace offsets, etc, and every other trick in the book, it might be possible to just squeeze SD in along with graphics-based LCD but I doubt it).
I'll change my defines to match yours for simplicity. If you give me the complete pinout connections and other changes, I can makeshift the connections here now and confirm.
Using your defines, I have:
Configuration.h:
/**
* SD CARD: Multiple
*
* Set to use always use internal SD card slot instead of SD on your LCD panel if your board has one
*/
#define USE_INTERNAL_SD
//
// MKS MINI12864 panel with graphic
// controller and SD support - https://github.com/makerbase-mks/Marlin
//
#define MKSMINI12864
pins_PRINTRBOARD_REVF.h:
#if ENABLED(MKSMINI12864)
#define MINIPANEL
#if ENABLED(USE_INTERNAL_SD)
// PIN FASTIO PIN# ATUSB90 PIN# Teensy2.0++ PIN#
#define SDSS 20 // 10 B0
#define SD_DETECT_PIN -1 // no auto-detect SD insertion on built-in Printrboard SD reader
#else
// PIN FASTIO PIN# ATUSB90 PIN# Teensy2.0++ PIN# Printrboard RevF Conn. MKSLCD12864 PIN#
#define SDSS 11 // 36 C1 EXP2-13 EXP2-07
#define SD_DETECT_PIN 9 // 34 E1 EXP2-11 EXP2-04
#endif
// PIN FASTIO PIN# ATUSB90 PIN# Teensy2.0++ PIN# Printrboard RevF Conn. MKSLCD12864 PIN#
#define DOGLCD_A0 4 // 29 D4 EXP2-05 EXP1-04
#define DOGLCD_CS 5 // 30 D5 EXP2-06 EXP1-05
#define BTN_ENC 6 // 31 D6 EXP2-07 EXP1-09
#define BEEPER_PIN 7 // 32 D7 EXP2-08 EXP1-10
#define KILL_PIN 8 // 33 E0 EXP2-10 EXP2-03
#define BTN_EN1 10 // 35 C0 EXP2-12 EXP2-06
#define BTN_EN2 12 // 37 C2 EXP2-14 EXP2-08
// SCK 21 // 11 B1 ICSP-04 EXP2-09
// MOSI 22 // 12 B2 ICSP-03 EXP2-05
// MISO 23 // 13 B3 ICSP-06 EXP2-10
// VCC EXP2-02 EXP1-01
// GND EXP2-01 EXP1-02
// encoder connections present
#define BLEN_A 0
#define BLEN_B 1
#define BLEN_C 2
// encoder rotation values
#define encrot0 0
#define encrot1 2
#define encrot2 3
#define encrot3 1
// increase delays to max
#define ST7920_DELAY_1 DELAY_5_NOP
#define ST7920_DELAY_2 DELAY_5_NOP
#define ST7920_DELAY_3 DELAY_5_NOP
#endif
We'll see how it goes...
That'll do pig.
Here's the pinout for the EXP2 connector on the Printrboard.
PIN FUNCTION PORT
1 GND
2 5v
3 nc
4 nc
5 DOGLCD_A0 4 (D4)
6 DOGLCD_CS 5 (D5)
7 BTN_ENC 6 (D6)
8 BEEPER 7 (D7)
9 nc
10 KILL_PIN 8 (E0)
11 SD_DET 9 (E1)
12 BTN_EN1 10 (C0)
13 SDSS 11 (C1)
14 BTN_EN2 12 (C2)
I've got a flat ribbon cable that connects to EXP2 & ISP connectors on the Printrboard, does a few twists & turns and terminates in the MKS MINI connectors.
@Bob-the-Kuhn - yeah, that matches what I have above. When I send M300 S1 the beeper beeps alright, but the entire display goes blank. Could this be a power delivery issue with the 5v reg (hard to believe the buzzer takes that much) or could something else be wired wrong, you think ? Do you get the same on your RepRap graphic display ? I notice the screen flickers slightly every couple seconds also, which seems to correspond to screen refreshes of the FAN, Position coordinates (the ? 'swhen not homed). Is that typical behavior on graphic controllers or is this more indication of s potential power issue ?
UPDATE: found GND had wiggled loose from my janky spaghetti mess of wiring and it was pulling phantom ground through the other GPIOs, so was starved for power. Works fine now !
Okay, I guess we need to button this up now... I had originally thought the MKS12864 was different enough that we needed a new designation, but I'm not so sure now: there's the lack of backlight and contrast lines (which would be delt with in pins[BOARD].h) but the software serial does pose some quirks. What's your thoughts on that ? Adding it might be more useful if we can then bake-in a "SD_SOFTWARE_SPI" (which I assume would cover all the "unique" MKS displays like the MINI I have, but also the OLED ones.
I think adding a "USE_INTERNAL_SD" (or USE_EXTERNAL_SD if that fits the Marlin config model better) feature would be useful for boards like Prinintrboards and others with built-in SD card so we could push config logic into the respective pins files instead of users having to poke everytime they try to config one of these displays. My take is the board pin files shoudl have all the messy stuff for these weird HWs but hopefully users won't need to go into them for 80% of the configs. Do you think something like this is worthwhile enough to add to Configuration.h (as I show above) ?
The beeper works but the display goes blank ... very strange.
I'm drawing a blank.
Could be power. Could be hash caused by the beeper on power & ground getting the controller upset.
My RepRap doesn't have that issue.
Now that I have the delays set properly, the display is rock solid.
@Bob-the-Kuhn - how can i use MKS MINI 12864 with ramps 1.4, where do i change the pinout for the EXP2 ?
Thanks
I'm pretty sure you just shave the key off the ribbon plugs and plug them in 180-deg around. I appoligize for derailing the discussion here around Printrboard, but other than a few items not working (no contrast or backlight control implemented on MINIPANEL) it should plug into your RAMPS adapter after shaving off the keys on the IDC connectors.
@fiveangle
Thanks for the update and having the thread turn to the printboard was pretty interesting. I picked up a RepRapDiscount Smart Controller LCD and have been using that. Now that I know my Ramps and Firmware are working I will try to shave the IDC's and invert them when connecting. Let's see what happens...
The RAMPS to MKS MIN 12864 setup is documented in this WIKI page.
@Bob-the-Kuhn - page looks good. Only part that I think might be improved to help people is more specifically calling out that the cable keys are opposite of typical graphics controllers:
Note that the housings are rotated 180 degrees in this graphic.
Would it be better to be more direct like:
Note that the ribbon cable housings are rotated 180 degrees from most other graphic controllers. Some users have had success by removing the alignment key so the cable can be plugged in 180 degree so a custom cable is not required.
Or something between yours (terse) and mine (verbose) ?
You could also state that contrast and backlight control is not present, but that really should be self-evident by the pinout diagram (but you know how people are ;)
Thanks for help!
Just 5 cents. Instead of shaving key from the cable just remove the plastic part of the socket (leaving just the pins on the MKS board) and put it back rotated 180deg.
@dvseliteus - good to close ?
@fiveangle yup good to close. Great info on this thread. I hope it helped others like it helped me. Thanks all who commented!