-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ADAFRUIT_ST7565 #2105
ADAFRUIT_ST7565 #2105
Conversation
Added support for new display type
@eboston
else this looks good. |
This is my first ever pull request/contribution to an open source so I'm still learning. I thought I had commented out the define but guess that didn't get saved. As for the tabs, I put in spaces but think the editor replaced them. Will fix it up. |
Fixes for some code formatting changes and commenting out the ADAFRUIT_ST7565 define that was left defined.
@eboston
|
It is a board that I am designing. It uses the Adafruit ST7565 display and a modified version of the RepRapDiscount Smart Graphics board. |
I have no problems with making those changes, but don't follow what it will really accomplish. It looks basically like renaming the ADAFRUIT_ST7565 to MYBOARD. Are you thinking the ADAFRUIT_ST7565 name is too close to the display used? I was planning on calling the board the Adafruit ST7565 Graphic Display. |
@eboston |
The display does come from Adafruit and that is the product name on the website (http://www.adafruit.com/products/250). I understand what you are saying so will change to a more generic name for the define. |
Rename of define to avoid confusion between the controller and the display which had similar names.
@eboston @thinkyhead |
I think I understand what you are saying. Let me repeat back what I think you want.
Does that sound about right? |
No. Please wait with a new commit for a comment of @thinkyhead . |
The other things are just really confusing me. So looking at the REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER define in Conditionals.h. It has a define for U8GLIB_ST7920. So under the ELB_FULL_GRAPHIC_CONTROLLER, would it make more sense to make a define like U8GLIB_LM6059 so it is using the same convention? The defines for SDSLOW and SDCARDDETECTINVERTED would make more sense under the ELB_FULL_GRAPHIC_CONTROLLER in Conditional.h?
becomes
and those two defines are removed from pins_RAMPS_13.h? This would essentially remove the define ADAFRUIT_ST7565 and add U8GLIB_LM6059. Am I getting close? |
Locking at the others - there is no real convention - but room for improvement. What ever you want, as long we can distinguish between board and display.
Yes.
Where you want to address the board use
Yes. |
#define Oops. Oh the joys of cut and paste. :) But in regards to the define U8GLIB_LM6059, I have to use a different name since it would conflict with the class definition. Would U8GLIB_LM6059_AF as a define be clear enough or do you have a better suggestion? |
Yes, we can discuss that. Such changes will bump the version up to 1.1, you know. 😁 If you look at the configurator, it breaks up options into sections, which could roughly correspond to configurations. So it's possible to end up with a bunch in the end. We should use shorter names and follow a new convention, so it can perhaps remain compatible with the old style.
|
I'll look it over shortly and get back to you… |
#ifdef ELB_FULL_GRAPHIC_CONTROLLER | ||
lcd_contrast += encoderPosition; | ||
lcd_contrast &= 0xFF; | ||
#else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor syntactical thing. Compiler directives should be part of the cascade too. This is so that naïve text editors can do code folding properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what is it you are suggesting that should be changed here?
It looks simple and stable to me. I'm actually surprised it doesn't require even more code. |
@thinkyhead When I was starting to add support, I realized it was very similar to the VIKI2 display so I just followed the settings for it. About the only difference was the pins used and the u8g class. |
@thinkyhead |
@AnHardt Oh good, that's a can of worms. |
Moved SDCARDDETECTINVERTED and SDSLOW to Conditionals.h. Added U8GLIB_LM6059_AF to define display specific actions. Added reminder to compile in u8glib
@eboston Good job! |
Fixed a couple defines that were not changed or commented out.
@@ -660,6 +660,12 @@ const bool Z_PROBE_ENDSTOP_INVERTING = false; // set to true to invert the logic | |||
//#define VIKI2 | |||
//#define miniVIKI | |||
|
|||
// This is a new controller currently under development. A link to more information will be provided as it | |||
// becomes available. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When will it be available?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about right now? I just updated Configuration.h with the link.
Added the link to the github information about the ELB_FULL_GRAPHIC_CONTROLLER
I'm happy with the link. |
Updated all the example Configuration.h files for the new display type.
lcd_contrast -= encoderPosition; | ||
lcd_contrast &= 0x3F; | ||
#ifdef U8GLIB_LM6059_AF | ||
lcd_contrast += encoderPosition; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is looking very complete. I have one question about the encoder direction. Does the contrast increase when the knob is turned clockwise? And, do the menus go in the down direction when you turn the knob clockwise? The reason I ask is that we want to add an option to reverse the direction that the knob moves through menus (for a knob to the right of the display). That change will only reverse menu movement. So I want to make sure that when we do that, reversing the knob direction, it works the same way, with clockwise moving in the up direction in the menus.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I turn the knob to the right (clockwise), the menu selection moves down and the contrast value moves up. When the contrast value goes up, the screen gets darker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, perfect!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may kick myself for asking this, but since you already merged in the change, too late! :) I got a RepRapDiscount Full Graphic Controller and noticed the default behaviour of the knob is opposite of what I have. Turn it counter-clockwise and the menu selection moves down. Is the standard going to be the way I have it on mine? Personally, turning it counter-clockwise seems backwards to me no matter where the knob is located.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it's one of the requests out there, at least to have an option to reverse just the menu direction. So, I just need to see if all knobs move the menu highlight in the same way, so that option will tend to behave the same on all printers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Roxy, I did not mean at all to sound mean or angry at any of you! I meant I
am so glad the environment is no longer toxic here! I appreciate all your
hard work and look forward to continue collaborating with the team!
On Wed, 1 Jun 2016 at 20:14, Roxy-3DPrintBoard [email protected]
wrote:
In Marlin/ultralcd.cpp
#2105 (comment):@@ -1110,13 +1110,24 @@ static void lcd_control_volumetric_menu() {
#ifdef HAS_LCD_CONTRAST
static void lcd_set_contrast() {
if (encoderPosition != 0) {
lcd_contrast -= encoderPosition;
lcd_contrast &= 0x3F;
#ifdef U8GLIB_LM6059_AF
lcd_contrast += encoderPosition;
@emartinez167 https://github.com/emartinez167 I fully understand your
statements. We would like you to give us a second chance. If you even think
you were treated less politely than you should have been, please send an @
message to ThinkyHead or me. My guess is we won't be getting any messages
from you going forward. We are very serious about keeping this a healthy
environment for both users and developers.—
You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/pull/2105/files/082ed3beedfaffaa7fb8b8e2ae4fa2f0f9f8aca4#r65348309,
or mute the thread
https://github.com/notifications/unsubscribe/AGcPb2IDnwCS4FHmvu3x1s4yCihqoqkvks5qHXejgaJpZM4Ed7jG
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@thinkyhead Reading through this, it seems most of the issues being discussed are addressed in that patch I submitted. In regards to action of turning the encoder in relationship to contrast, my thoughts are regardless of how it works with the menus, turning clockwise should increase contrast, counter clockwise decrease. That is how most controls like this work. Clockwise to turn up the volume. Increase the temperature on a stove. (at least in the US).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…issues being discussed are addressed in that patch…
@eboston Yes, your patch is a great improvement.
regardless of how it works with the menus
turning clockwise should increase contrast, counter clockwise decrease
The LCD contrast will change according to the same rotation direction as editing values. So clockwise increases contrast, counterclockwise decreases it. Users can reverse the direction of that using REVERSE_ENCODER_DIRECTION
, if they have some reason to do so.
(Menu navigation direction is reversed with REVERSE_MENU_DIRECTION
.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on a quick look, it looks good.
Add ELB_FULL_GRAPHIC_CONTROLLER with ADAFRUIT_ST7565 display.
@eboston When in edit mode, turning clockwise is ought to increase the numbers (test with a temperature). If not swap BTN_EN1 and BTN_EN2. The direction of movement in the menu may be configurable later. |
Since the RRD Full Graphic controller doesn't support menu based contrast, I don't have anything to compare against. But the code would make sense, using -= for contrast value, if turning the knob worked like it does on the RRD, turning counter-clockwise moves the menu selection down. So with the code the way it is, if someone changed the encoder pins to switch the menu movement, it would also switch how the contrast changes. Is this the reason for the request to add the option to switch the menu direction? If so, I might just look at that if no one else is. |
Some users would prefer counterclockwise ⟲ movement of a knob on the right side of the display to move the menu ⬇︎ instead of ⬆︎. But edited values, contrast, etc., should always increase clockwise ⟳ and decrease counterclockwise ⟲. |
Added support for new display type.