Marlin/ LCD-Keypad Code Mod

Hi, I am looking for a way of making this 6 button LCD shield works with Ramps 1.4 and Marlin. The keys all read from one analog pin as {30, 150, 360, 535, 760} . How should I proceed . Thank you.

[forums.reprap.org]

im looking at doing an almost identical thing, just not a sheild.

Same here, i checked marlin for the lcd purposes, but i find the lcd feature a little obscure and wrapped in all sorts of "panel products" for no reason that i can think of. Perhaps is not a knot impossible to untie, but it shouldnt be like that on principle. So i opened the issue here but i dont think anybody would consider putting things differently.

The way i see it, its down the path where the last FiveD died: many contributors with different points of view starting to mix things up without caring for clarity and purpose, and that its just a road to get things bloated, ending up with some code that was close to useless for everybody. Reasons why most went to sprinter and hence marlin. You can see issues like that in marlin too now, check config file like "ENDSTOPPULLUPS" section which is a simple direct thing of: "ifdef xxx then offer option set A, ifnotdef xxx then offer exact same option set A". Why should one believe the insides look any better than the front. This is most basic thingy, but just a sample, and probably more than that deep within. For example i would say having 2 config files doesnt make much sense unless you actually want to confuse things on purpose. If i think about its history, its a pitty considering to how clean and ordinated and well put first sprinter was in 1-2 pages, and down this path it will soon become another "Vista" rundown. Unless someone with a logic and cleanup sense takes things like that away instead of putting them under the carpet, but that is less likely since if someone was there like that, it wouldnt be here to start with. Or another 1-2 pages code with great clarity will appear like initial sprinter, and then story will repeat all over again. Perhaps its a circulary process. Or perhaps its just me that cant stand things that are not at their exact place. The way i see it the only firmwares that dont take BS and as a result have good cleaning and ordering of things that fit my taste and liking, are firmwares developed mostly by single persons or where there is one calling the shots with a ordinated sense. I can only think of teacup and repetier here, so too few of those around imho. May be others. Anyway, at a stretch i would say that a firmware that is "very open" to anybody who wants to patch it for whatever reason or purpose, in the sense that "takes it all in" with no rules and too little cleanup ... cant end up well, at least on the long run.

I totally agree, im a programmer by trade and marlin seems like a jumble even to me. Is there a simpler more customisable firmware that anyone can recommend?

stupid spam filter on this forum is kicking up a stink lol

NoobMan Wrote:
-------------------------------------------------------
> Or
> another 1-2 pages code with great clarity will
> appear like initial sprinter, and then story will
> repeat all over again. Perhaps its a circulary
> process.

Yes, I am pretty sure it is. And not just applied to software, I suspect it is a law of nature. Things start small and simple, end up unwieldy and complex and the only way forward is to start over.

In the particular case of software, for a particular set of requirements, one person can create a lean and efficient solution. As the requirements grow, they have to refactor the design to accomodate them. This can cause conflicts in the original design paradigm, and compromises are brought in (aka hacks). Also as more people get involved they have less idea of the original design and bring their own design ideas. A further constraint is maintaining compatibility with past implementations. While refactoring and redesign may be called for, no one will thank you for changing things that used to work fine.

I looked into how to create a standard way to accomodate different LCDs and keypads with some sort of generic but simple low-level "driver" API, and decided it was too impractical. The UI tends to be tightly bound to the application code, so there would also need to be an application level API. It becomes easier if you have a well defined device driver architecture and a process model so you can separate UI and application etc, but that all eats up resources which on small CPUs are not available.

It is frustrating because there are lots of great add ons out there. Supporting all of them in each firmware is an M x N problem. If there was a "standard" API then we could reduce it to nearer M, but people are not keen on standards. Unfortunately that leaves us needing to find a code sponsor to support each new panel.

Some few years ago, reprap had a config file where there were like 3 choices of hardware. Now we start to use 2 digit numbers. Its probably going to get worse with LCD's and panels in a few years. I dont think the permutations of boards with panels will get limited, so its probably going to be all over each other's interval. It looks like its going to be quite a mess, if i can say so.

How about defining LCD+menu, as one without the other doesnt make much sense, and separating the input method instead, as this is probably the part that might will vary more than the rest.

Hi, im new and I was plaing to connect a lcd keyboard too, were you able to get it working?

Quote
Mjuchiha
Hi, im new and I was plaing to connect a lcd keyboard too, were you able to get it working?

Repetier-Firmware

im current working on the same thing on the repetier firmware
got the lcd and menu showing on the keypad lcd sheald
alter the pin in uiconfing.h or ui.h

  Pins used by LCD & Keypad Shield:
  
    A0: Buttons, analog input from voltage ladder
    D4: LCD bit 4
    D5: LCD bit 5
    D6: LCD bit 6
    D7: LCD bit 7
    D8: LCD RS
    D9: LCD E
    D3: LCD Backlight (high = on, also has pullup high so default is on)

.
but..
still cant figure out how to code the init funtion to define all the key on the Analong (A0) pin.

// define some values used by the panel and buttons
int lcd_key     = 0;
int adc_key_in  = 0;
#define btnRIGHT  0
#define btnUP     1
#define btnDOWN   2
#define btnLEFT   3
#define btnSELECT 4
#define btnNONE   5

pls need some help here.

I see this and I like It....!!!
How connect in Prusa I3 mendel - RAMPS 1.4
sorry my bad english...

[www.thingiverse.com]