SparkFun Forums 

Where electronics enthusiasts find answers.

All things pertaining to wireless and RF links
By NoWhereMan
#9738
Got finally SerLCD v2 and BlueSmirf. Works just ok, only one big drawback - cannot get backlight to work correctly at all!

Almost everytime when I put BL on (with help my Visual Basic program) SerLCD get hang totally. Only cold reset get LCD back to life. No help with giving more time in prog.

Backlight on or off works ok if there is nothing else happening in the program.

Is this a bug inf SerLCD or can anybody give me some hint what to do?

NoWhereMan
By Vraz
#9739
How are you powering the SerLCD? Remember that the backlight consumes a fair bit of current (60ma according to the SFE datasheet though I would never try to use one with less than 100ma available). If you turn it on with an insufficient supply it will likely cause the PIC to brownout and other bad things to happen.
By NoWhereMan
#9740
Vraz wrote:How are you powering the SerLCD?
Powering is not the reason. Thank you anyway.

More suggestions?
User avatar
By sparky
#9747
I've never heard of a SerLCD hanging. Let me ask one more time - how are you power the LCD? Vraz is very correct in asking.

-Nathan
By NoWhereMan
#9774
sparky wrote:I've never heard of a SerLCD hanging. Let me ask one more time - how are you power the LCD?
Sure thing. I have tried with two ways. 1) AC DC adaptor, regulated 5V 2) 4 pcs 1,5V 2100 mAh nickel-metal hybride batteries, which give 5,3V.

Always the same thing: Otherwise all is doing well but when I command backlight on, SerLCD hangs. _NOT_ every time, but mostly. Then only thing which helps is power off and then on again.

Hope this will help?
User avatar
By sparky
#9797
Couple words of caution - most wall warts output an unregulated voltage. It may be spec at 5V 300mA or something, but it will actually output much higher voltage with lighter loads. Just be sure your wallwart is outputting what you expect.

Also - NiMH, NiCads, and Alkalines all supposedly output 1.2V per cell. But when fully charged, NiMH will be 1.5V per cell, 6V on your pack. This can over voltage things unless you've got a 5V regulator in there somewhere. The pack will drop to a comfy 4.8V for the majority of the run time, but watch out for the peak at the beginning.

What code are you sending to the SerLCD to get the BL to turn on? If my memory serves me, the SerLCD ships with the BL fully activated.

-Nathan
By NoWhereMan
#9820
sparky wrote:Couple words of caution - most wall warts output an unregulated voltage.
What code are you sending to the SerLCD to get the BL to turn on? If my memory serves me, the SerLCD ships with the BL fully activated.
Thanks for warnings. I wrote regulated and I mean regulated voltage. No problem with that.

Codes are directly from SparkFun´s PDF-file. BackLight ON = chr$(124) & chr$(157).

BTW: There is a bug: You cannot turn BL totally off sending commands chr$(124) & chr$(128). Sending 129 works, but BL are still on, but it is very weak of course. If this is a bug, there might be other bugs too, like BL on or off?
By Vraz
#9828
Looks like there is a bug in the backlight PWM code with respect to 124/128. Because of the loop constuction, the "else (backlight_counter == brightness_setting)" nevers executes when brightness_setting is zero. The fix is to remove the "else" which allows the "if" to execute during all loop iterations. With the bug, I assume that 124/128 results in the backlight full-on (but not a lockup).
Code: Select all
    if(T0IF) //TMR0 Overflow Interrupt - Occurs every 1024us ~1ms
    {
        backlight_counter++;

        if(backlight_counter == 30)
        {
            backlight_counter = 0; //30ms pulse width period
            
            BL_Control = 1; //Kick on the back light
        }    

        //Turn off back light after its assigned duration
        else if(backlight_counter == brightness_setting) BL_Control = 0; 
        
        T0IF = 0; //Clear Interrupt Flag
    }
Specifically, what codes are you sending which cause the "lockup" you describe?[/code]
By NoWhereMan
#9829
Specifically, what codes are you sending which cause the "lockup" you describe?
I wrote a small prog with Visual Basic 6. This line force the BL go off:
Call cmdSendText(Chr$(124) & Chr$(129))

And this force it on:
Call cmdSendText(Chr$(124) & Chr$(157))

And this is the procedure which is needed:

Private Sub cmdSendText(OutText As String)

On Error GoTo ErrTrap

If comSerial.PortOpen = False Then
comSerial.PortOpen = True
End If

comSerial.Output = OutText

Exit Sub

ErrTrap:
MsgBox Err.Number & " " & Err.Description & vbCr & " Error Generated By " & Err.Source, vbCritical, _
"System Error Trap !"
End Sub
----------------------------------------

Adding delays etc after those calls have no influence. SerLCD freezes ie it do nothing until I put power off and on again.

First I was sure that there was some timing difficulties ie adding more time between commands would help, but it did not.

Faulty LCD?
User avatar
By sparky
#9834
I don't know. If you'd like to send it back to us for eval, I'd be willing to check it for you. If we find any problems, we'll of course replace the unit.

I am still suspicous of VB. It handles com ports very poorly - but it should work... Are you able to send normal string to the LCD without problems?

send me an email spark @ sparkfun.com

-Nathan
By NoWhereMan
#9837
sparky wrote: I am still suspicous of VB. It handles com ports very poorly - but it should work... Are you able to send normal string to the LCD without problems?
Yes. Any other string will do the job and without troubles. Only problems are BackLight -commands.
User avatar
By sparky
#9842
Wait wait. Is your VB script 'and'ing the two strings together? or concatinating them? I don't trust VB.

Try sending just basic commands like:

comSerial.output = chr$(124)

delay of some sort, 10ms is fine

comSerial.output = chr$(157)

delay of some sort.

-Nathan
By NoWhereMan
#9852
sparky wrote: comSerial.output = chr$(124)
delay of some sort, 10ms is fine
-Nathan
You know what? When you're right, you´re so right. :lol:

After makeing those two commands separated everything started to worked just fine! Funny that other commands work differently (you can send two strings together without problems), but now we know much more.

Thank you for taking care of my problem! :)