Go Down

Topic: LiquidCrystal_SR3W Wiring E to the Strobe Pin (Read 7495 times) previous topic - next topic


Aug 02, 2013, 12:58 am Last Edit: Aug 02, 2013, 01:09 am by kowalski Reason: 1

You keep saying SDA, but do you mean the MOSI pin on the Arduino? Are you using SPI or just GPIO pins?
Also, that is a pretty good implementation, using SDA for RS. This keeps complexity of the circuit lower, but adds complexity to your code + requires more pins.

Actually it was your two SR solution that got me thinking about the possible pipelining as the 4-bit SR variant did not produce as good numbers as what you had shown. I had excepted better pipelining but there was a requirement of a 37 us delay also for the first nibble and not just for the last when the full byte has been transfered. After that I just did some "research", found the above solution for PIC and refactored it.

Had to breadboard the solution twice before I understood how to get the 8-bit LCD initialization working ;-)

SDA is just my pin naming convention (Serial DAta). Sorry about the bad naming. The version above, SR4W, is soft SPI, i.e. GPIO pins. Will be adding the SPI version soon. Not much to change and no big difference in speed. Just more delay ;-). For SPI SDA will translate to MOSI.

The added complexity is a single line "m_sda.write(m_rs)". And there are no extra pins required except for the back-light.

Actually (I believe) the SDA signal can be reused again for the BT after the EN pulse. This will give a possible flicker but some of that can be removed with a capacitor between the base and ground on the back-light power transistor. But then again the back-light is always on in many applications.

Off topic question, how do you make these ASCII schematics?

Hum, the ASCII schematics...., I just copied @bperrybap and changed a few lines. Might be a tool for that.

BW I implemented a LCD port adapter for the ERM1602-5 which is a 1602 with built-in SPI. It uses 3-wires (CS, MOSI, SCK) and an extra signal for back-light. No RS. Instead there is a special command for data transfer. To send a character (if previously in instruction mode) the driver must send a FUNCTION_SET command for extended mode switch, a SET_DATA_LENGTH command and then the data/character. Improving performance here is an interesting challenge ;-) even if SPI ;-)



Off topic question, how do you make these ASCII schematics?

Hum, the ASCII schematics...., I just copied @bperrybap and changed a few lines. Might be a tool for that.

Nope, no tool. Totally manual. It's not that bad
once you decide on a format and orientation, particularly since these
circuits are so simple.
Once you do a few, they go pretty quickly.

I got really frustrated seeing all the "fancy" graphic schematics out there that were sometimes wrong or out
of sync with the code.
I also wanted the schematics to be inside the code so they would stay in sync with the code and always
be available vs having to track down some drawing in some other location.
I'm also a big believer in tools like doxygen that allow the documentation to be inside the code.

I spent quite a while thinking about how to do the ASCII schematic to make it
the easiest to understand and to minimize wiring errors.
One of things I often find that can cause wiring issues is that the orientation/location of the pins
in the psuedo chip in the schematics drawings doesn't match the pin orientation/location
of the pins in the actual chip.
And in some cases different vendors call the same pins different names which can
add to the potential for making errors.

Plus I just got tired of having to constantly bring up a datasheet each and every time
I was wiring up one of these circuits.

So I decided to draw the schematic with a chip that looks like chip with all the pins
in the same orientation as the actual chip.
To me it seemed to really simplify how to wire up the chip by making it more obvious
and it can now be done with out having to look at a datasheet.

--- bill


i have this problem REDEFINITION of liquidcristal

Go Up