LCD questions
verobel
Posts: 81
Fellow SXers;
I have used LED display with Basic Stamp and SX28 with and without multiplexing and now I would like to try using some LCDs such as a 3 digit 0.31" LCD from Lumex which costs about $2. I was wondering about the following things:
1. What is the suggested current flow for a typical lcd segment?
2. Can these Digits be multiplexed like in the SX/28 Clock/Timer example?
3. What LCD's would you recommend for low cost projects?
I have used the 2x16 serieal LCD from Parallax and this is great for many projects. I am simply looking for a lower cost display ($2-10) alternative that will not add ~$30 to the project cost.
As always, thanks for you advice. John
I have used LED display with Basic Stamp and SX28 with and without multiplexing and now I would like to try using some LCDs such as a 3 digit 0.31" LCD from Lumex which costs about $2. I was wondering about the following things:
1. What is the suggested current flow for a typical lcd segment?
2. Can these Digits be multiplexed like in the SX/28 Clock/Timer example?
3. What LCD's would you recommend for low cost projects?
I have used the 2x16 serieal LCD from Parallax and this is great for many projects. I am simply looking for a lower cost display ($2-10) alternative that will not add ~$30 to the project cost.
As always, thanks for you advice. John
Comments
If it is just the LCD glass without a controller, then you need to activate the segments with AC current. This means using two pins and making one high and the other low, then wait a short time, then make them switch states (low, high) then wait a short time again. And repeat that sequence for each segment that you want visable.
If you use DC you will ruin the display after a short time because the liquid will break down.
Usually the bare displays have a common (or a number of common) terminals, and then segment terminals. Very similar to a multiplexed LED display.
The current is very low. On the order of uAmps. I usually use 100K resistors from the SX pins to the LCD pins.
I have found it to be very hard to get a good display. Either you can see the segments that are NOT to be visable, or you get a dim display. You have to play around with the voltage levels and frequency and duty-cycle to find the best combination.
[noparse][[/noparse]edit]
Okay I did some searching and I assume you mean the LCD-S301C31TR, that only has 1 common. So you don't need to multiplex. The bad news is that you need 24 I/O pins to drive it.
So you'll have to use the SX48 to have enough I/O pins to drive it. I would suggest using ports C, D and E. Because port B has all the goodies (interrupts, ect).
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
Post Edited (Bean (Hitt Consulting)) : 11/9/2007 2:07:38 AM GMT
LCD should be excellent for portable stuff with practically no power drawn and is low cost, but will required lots of wires or traces but they can be microthin due to low current reqmts.
I don't have an SX48, but I do have and I2C expander: MCP23016
Thanks Bean
- Sparks
Then whatever state the com pin in, if the segment pins are in the same state, they are off. If they are in the opposite state they are on.
Then invert everything about 300 times a second (150 Hz).
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·
I am having a rough time getting SX/B to just show a single simple character on the LCD Terminal AppMod. I believe my problem is in setting up the bits on the data bus.
Did you program in SX/B?
If yes, could you post that code?
Much Thanks.
·
·· I love SX/B!· So , yes the bulk of my code was written in it.· I do not have access to the source code right now.· However, I can probably post the relevant sections in a day or two, possibly even tonight depending on which computer has it.
·
·· All of the information that you need is available within this forum.· That is where I found what I needed to get started.· Then I just modified what was already available to meet my needs.
·
·· Alternately, you might consider posting what you have coded and an explanation of how you have it wired.· I might be able to discern what is incorrect or missing.· I am sure others will be wiling to do the same.
·
·· In short, I will try to post the LCD code that I used.· I might need a day or two get to it.
·
· It really works well when it works!
·
·- Sparks
Here are some of the LCD subroutines that I use. I hope they are helpful.
I must confess that this collection is a bit of a hack job. Most of the information I obtained from previous posts. Unfortunately, I have since had trouble relocating most of those posts.
The bulk of the subroutines are from a posting from someone with the initials "JJC" from a few years ago. I used those as a base and simply modified them to work for my projects. I know from some of the original comments that his coding was heavily influenced by Jon Williams. I guess it all just goes to show how good ideas are shared and passed around in this community!
For these subroutines to work as written you will need to connect the four data lines of the LCD to the four most significant pins of the RB port. If you connect the data lines to the highest four pins of a different port just change the definition of LCDData to that port. LCDRS and LCDE can be assigned to pins of your choosing. Other variables will need to be defined as well. Hopefully you will be able to follow most of the logic and get your display working. Please post follow-up questions if you have any and let us know if you are able to get your display working.
I wish I had time to create a fully working demo. Now that the topic of using SX/B to communicate with an LCD has been raised it really deserves a tutorial! It is not hard; but it may not appear to be as obvious as it could be.
I hope this helps.
- Sparks
The display and interface are OK because they work with the BS2 example.·
Does the BS2 work by taking advantage of slower execution speed?·
SXB doesn't do HighNib/LowNib, so I'm masking and so on, too.·
I made a SUB to do a 2usec Pulse (because SXB PULSOUT is 10usec min.)·
Alas, to no avail.
Post Edit -- Deleted the SXB_program attachment.
Post Edited (PJ Allen) : 6/6/2008 7:32:18 PM GMT
I glanced at your code but did not check it thoroughly. You have this statement in a few places:
Multiplication by decimal ten will not produce the proper result. Multiplication by decimal sixteen will. Decimal sixteen is equivalent to hex $10. I assume that is what you meant to do so be sure to include the hex prefix. Otherwise the SX/B compiler will interpret "10" as a decimal value.
- Sparks
Thanks.
Post Edit -- I'm still stuck,·it's like·Initialisation doesn't complete or otherwise take.
Another Post Edit --
Whoop!·
I modified my E_pulse SUB, added a PAUSE 10 at the end and now it gets out of Init_LCD and Send_Inst is good, too.· Which seems to confirm my posit previous that with SXB/SX things come too quickly, it's overwhelmed by the flurry of spot-on.· Y'think?
It still doesn't knock out an "A", sitting there with an underscore cursor, the equivalent of a dumb if eager look on its face.· (Yeah, mine, too.· I'll remember that.)
Gosh, what progress.· No, really.· Isn't it?
A further Post Edit --
Reading up on another display module, I've found that there is a Busy Flag (BF) that has to clear out before further instructions or data transfer can take place.· I'm sure this point is valid regardless the unit used.· If your program executes at a slower speed then BF may not matter (it passes, no problem), but at faster execution speeds it holds up the show (i.e. "Not now! Can't you see·I'm Busy?")· The BF can be checked by Reading that register, a layer of complication I shall endeavor to avoid.
So, I probably need to place more strategic PAUSEs.· But, where?
Post Edit 3/02/07 -- Deleted program, to avoid confusion.· 4/08/09 The Working program follows in my succeeding post.
Post Edited (PJ Allen) : 4/10/2009 2:01:45 AM GMT
I do not think that differences in pulse timings between the BS2 and the SX are the cause of your LCD problem. Usually a longer pulse is acceptable (up to some point).
I think you should try moving your variable and subroutine definitions so they are located before your Starter: label but after the PROGRAM starter declaration. Like this:
DEVICE sx28, oschs3, TURBO, STACKX, OPTIONX 'IRC_CAL IRC_SLOW FREQ 28_000_000 PROGRAM starter char VAR Byte inst VAR Byte ' why char? "Induction to Send to LCD??? hi_nib VAR Byte lo_nib VAR Byte x_nib VAR Byte Init_LCD SUB 0 Send_Inst SUB 0 Send_Text SUB 0 Next_Line SUB 0 E_pulse SUB 0 ' BS2 uses PULSOUT E, 1, which is 2usec ' SX/B PULSOUT is 10usec Min. So, SUB E_pulse ' effects a approx 2usec High pulse starter: TRIS_B = $00 ' to LCD: .7 = DB7, .6 = DB6, .5 = DB5, .4 = DB4, .3 = RS, .2 = R/W, .1 = NC, .0 = E ' | DB7 | DB6 | DB5 | DB4 | RS | RW | ___ | E | RA = 0 RB = 0 Init_LCD char = $41 ' letter 'A' Send_Text ...etc...The label after the PROGRAM directive designates the location where program execution should begin. In your case you have called this label starter: which is fine. However, I suspect the location of starter: is not fine since you are trying to declare subroutines after the start of your program. I suspect that this causes the SX to actually attempt to run those subroutines in the order listed!
Init_LCD
Send_Inst
Send_Text
Next_Line
E_pulse
Init_LCD may work fine.
Send_Inst may work fine too... but what instruction did you just send it? You probably just sent it a command instruction of zero! I think that may explain the behavior you are seeing.
Try the rearrangement I have suggested and let us know if that helps.
- Sparks
I went a step further and took out the PAUSE that I'd placed at the end of my SUB E_pulse and it went flop-pot, doubleplusungood.· So, it needs that time to clear (wait out)·the Busy Flag/s.· It might stand to have a shorter period, but I'll leave that depth to others to plumb.
Attached are the "final" program and·The Picture. ·
So, Celebrations!· Happy Days!
I am very glad it worked for you. The hard part is now over. Let the fun begin!
Enjoy.
- Sparks
Note that the functinos of pins0 and 1 are reversed from the model you are using.
I'm getting the code cleaned up & will post.
Next task: accepting input from the buttons.
Now I want to use the AppMod’s buttons for input.
·
Full listing is attached;·the sub ButtonReact is casuing problems. Below is the section in PBASIC which checks if a bit within the buttons byte has been changed from zero to one.
·
··········· FOR idx = 0 TO 3 ····
······················· IF buttons.LOWBIT(idx) THEN······························
··································· Char = idx
······················· ENDIF
··········· NEXT
··········· … make decisions based on the value in char
·
Within an IF…THEN expression within a FOR…NEXT loop, how can I use the idx of the loop to refer to a single bit within a pin register?
THanks
You might be able to do something like this:
Mask = %0001_0000 ' Set the bit mask for the first button. FOR idx = 0 TO 3 ' display buttons TempValue = Mask AND Buttons ' Set TempValue to button position value or zero. IF TempValue = 0 THEN ' Test for zero result. ' IF TempValue > 0 THEN ' Test for non-zero result. char = "A" + idx ' button letter if pressed ' ELSE ' char = "-" ' otherwise dash ENDIF '' GOSUB LCD_Write_Char Mask = Mask SHL 1 ' Shift the bit mask left one position. NEXTI think this will accomplish what you are trying to do.
I introduced two new byte variables that you can replace or define as you like. You can also change the equal sign to a greater-than sign if I guessed the pressed/unpressed switch conditions improperly.
NOTE: The code you posted has many mismatch errors between subroutine name declarations and the names used to try to call then. Also the variable LcdLine2 has not been defined.
I hope this helps.
- Sparks
Thanks for re-writing it for me. I will test it shortly.
As I studied your code I realized I should understand masks, and that lead to WIkipedia. Several hyperlinks & a few hours later I've learned something new. So thanks for that as well.