Serial LCD syntax help

[flotulopex]

Hello,

Can somebody give me the correct syntax I have to use to pilot my Serial LCD display please?

Here is (attachment) an extract of commands for this display.

For a test, I'm trying to switch the backlight ON and OFF, but it doesn't work this way:
serout2 data_out , 84, ["ESC L", 0]

[b1arrk5]

You might try sending the ascii codes, in decimal 27 is the ESC key, 76 is the letter L, so sending [27,76,0] might just do the trick. There is an ascii chart in the back of the PicBasic Pro manual, and there are a lot of them online that you could print out. I hope this helps.

Jerry.

[flotulopex]

Thanks, that was quick ;-)

I'm gone a try this now!

[flotulopex]

Well,

I've still some trouble. Characters appears but nothing consitant or logical.

I have attached both explanations I have about how to send commands to the display (in German "D" and English "E"). Don't be afraid, they're very short.

The display is directly connected through a 1k resistor to the PIC.

I've set the baudrate to 300 now; but still strange characters appear.

I have also tried out all the 300bds and 2400bds modes described in the Compiler's manual without any success.

Here's my code:
'-------------------------------------------------------------------------------
' Fuses
@ DEVICE PIC16F88,INTRC_OSC_NOCLKOUT
@ DEVICE PIC16F88,PROTECT_OFF
@ DEVICE PIC16F88,WDT_OFF
@ DEVICE PIC16F88,PWRT_ON
@ DEVICE PIC16F88,MCLR_ON
@ DEVICE PIC16F88,BOD_OFF
@ DEVICE PIC16F88,LVP_OFF
@ DEVICE PIC16F88,CPD_OFF
@ DEVICE PIC16F88,DEBUG_OFF
@ DEVICE PIC16F88,CCPMX_OFF

'-------------------------------------------------------------------------------
' Registers
PORTB = %00000000 'Drive all ports B low
TRISB = %00000000 'Segments - Set Inputs/Outputs on PORTBs (direction)
OSCCON = %01100000 'Internal RC set to 4MHz
ANSEL = %00000000 'Disable Analogue Inputs
ADCON0 = %00000000 'A/D converter is OFF

'-------------------------------------------------------------------------------
' Circuitery
'PORTB.0 = TX

'-------------------------------------------------------------------------------
' Init
DEFINE SER2_BITS 8 'Set number of data bits for Serin2 and Serout2
'DEFINE SER2_ODD 1 'Use odd parity instead of even parity
Data_Out VAR PORTB.0

'-------------------------------------------------------------------------------
' Program
pause 1000 'Stabilize the PIC (mybe not needed)
serout2 data_out , 36081, [27,76,$0]
end

Any idea what I'm doing wrong?

[BobK]

Hi Flotul,

What is the baud rate of the Serial Module on the LCD? Most of the ones I have seen are either 2400 or 9600. With the internal clock at 4mhz the best you can hope for is 2400 because of the not so stable clock freq. I use a Seetron Serial LCD @2400 and it works fine. I have some other Serial LCD's that I am trying that I got from Wulfden.org but he has a different command structure that uses ? in fron of the command letter. I get data displayed but it's all running together. Always the time factor.

Try putting a crystal or resonator on your PIC and see if theat doesn't help.

HTH,

BobK

[flotulopex]

I set the baudrate down to 300 (there's a jumper to do so).

Can I connect my display directly to the PIC or is this not possible?

[flotulopex]

It's working now.

So yes, the display can be directly connected to the PIC. I've inserted a 1k resistor to limit the current and it's fine.

It works at 300Bds without crystal.

At 1200Bd, it's getting fuzzy: sometimes I get correct characters on the screen, and sometimes the display is meesed-up.

At 2400Bd, it won't work anymore.

I can't understand why the same circuit will work perfectly at 9600Bd on the PC's terminal?

[keithdoxey]

It works at 300Bds without crystal.

At 1200Bd, it's getting fuzzy: sometimes I get correct characters on the screen, and sometimes the display is meesed-up.

At 2400Bd, it won't work anymore.

I can't understand why the same circuit will work perfectly at 9600Bd on the PC's terminal?

Have you tried using a Resonator or Crystal on the PIC to see if it works OK with that rather than the internal clock ?

[mister_e]

unless you calibrate the internal OSC, it will never be accurate. AND EVEN IF you calibrate it, you'll need to hire someone to fine tune it when temperature shift, wind is going on the other side, when you loose weight etc etc etc.

I already said few times before... for serious serial comm (critical timing), use a crystal. Ceramic resonator are still nice.

[Archangel]

It's working now.

So yes, the display can be directly connected to the PIC. I've inserted a 1k resistor to limit the current and it's fine.

It works at 300Bds without crystal.

At 1200Bd, it's getting fuzzy: sometimes I get correct characters on the screen, and sometimes the display is meesed-up.

At 2400Bd, it won't work anymore.

I can't understand why the same circuit will work perfectly at 9600Bd on the PC's terminal?

Hello,
It's all about timing, just like machines with gears and chains. If you engine's valves get out of time then they hit the pistons. If the old WW1 airplains machine guns get out of time then they shoot off the propeller. Same with Bits of information, if pic sends data at 2300 and the LCD is expecting 2400 then no sale! You get garbage. That is why the oscillator has to run at a <b>KNOWN and FIXED, value</b> so the pic can do it's job at the time expected of it.
Just like your homework, turned in late - no credit!
JS

[flotulopex]

It looks like SERIAL communication is not the best method to make different equipments communicate together. It's cheap, simple, uses only one data pin but is quite unreliable.

What is then better? I2C? Yes, but then you need at least 2 wires (Clock and Data).

Is there another "low PIN cost" communication system?

[mister_e]

Yes it is reliable BUT...at least you need a reliable hardware design to start, then everything will follow. The internal osc is never reliable for asynchronous serial communication anyways.

you could still share the OSC/Clockout of 1 PIC and connect all other pic to it... everybody will have the same the same reference so it could work. Never tried it, but in theory it have to work.

The Synchronous communication will work. You can use SHIFTOUT to send the data.. but you'll need to build your own routine to receive and decode it... or use the USART in synchronous mode.

[flotulopex]

Thanks Mister_E.

I think I'm going to do as you say: build my own decoding routine.

In fact, I'm trying to find the best ways to track Variables, Values and Status (bits) in my programs for debugging purpose.

I've found the trial version of PIC Simulator from http://www.oshonsoft.com/. But it seems it cannot show variables that haven been compiled with their program (?).

I don't know how you "professionals" do it.

Any good advise is welcome.

Please keep in mind that I'm a hobbyist and can't invest lots of $ (I don't make money with PICs - I just make my familly crazy...)

Last week, I have bought (my wife got mad once again...) the PICkit2 programmer - would this one be any help?

[mister_e]

:eek: Not another Sim issue? why i'm not surprised? :D

BTW, i usually use a Serial communication between my PIC and my PC, OR if there's a LCD attached to the project i could use it and drop some data on. I prefer the serial communication.

An ICD could be a nice option. PICKIT 2 have a debugger for a really few models listed bellow


PICkit 2 MPLAB 7.51 Support

Debugging & Programming

* PIC12F683
* PIC16F684, 685, 687, 688, 689, 690
* PIC16F883, 884, 886, 887
* PIC16F913, 914, 916, 917, 946

I never tried it, so can't comment how good it is.

Mecanique ICD (comming with the MicroCode Studio PLUS version) works pretty nice even if it's a little bit slow. Example and tutorial bellow
http://rentron.com/PicBasic/MCS_X3.htm

[mister_e]

O.K i did few test with the PICKIT 2 debugger in MPLAB... not bad but slow and there's no way to modify it's speed like the ICD-2.

To use the debugger, you need to load the PGD and PGC pins with 2 4.7K pull-down resistors... unless it works erratic or simply do nothing. I fitted 2 smd resistor in it. Fixed forever :D

OH and you must have MPLAB 7.52

[flotulopex]

Okay.

I'm going to try MPLABS again.

I already tried, but MPLABS is quite complicated to setup (in my opinion).

This is why I preferred anothe simulator....

BTW, can you see variables too in this debugger?

[skimask]

Okay.

I'm going to try MPLABS again.

I already tried, but MPLABS is quite complicated to setup (in my opinion).

This is why I preferred anothe simulator....

BTW, can you see variables too in this debugger?

Maybe not the variables created by PBP directly, but you can look at the .lst file, get the ram address from that, then pull up a 'watch' window and see them in action there, or since you've already got the ram address of your variable from the .lst file, you can pull up the 'file registers' window and watch everything going on in ram.

[mister_e]

Yes you can look Your variable and the hidden PBP one. You just need to select the right toolsuite and install the PBP plugin

[Archangel]

It looks like SERIAL communication is not the best method to make different equipments communicate together. It's cheap, simple, uses only one data pin but is quite unreliable.
What is then better? I2C? Yes, but then you need at least 2 wires (Clock and Data).
Is there another "low PIN cost" communication system?

You know what is not reliable are old prototype boards, that is why I prefer to use serial lcd to prove out code, as it uses 20 less connections. later it is simple to change over to lcdout routines, and if you use the lcd routine in My thread (mostly Darrel's code) then you can use standard lcdout type formatting so there is less to change.

http://www.picbasic.co.uk/forum/showthread.php?t=4972 post 16

[flotulopex]

Anyhow, if you want to make a (acceptable) serial communication, you'll need to clock your PIC with a crystal.

So, if you create an application where timing is not relevant, you may want to use all your available PIC's ports and use the internal oscillator

Monitoring your program with a serial communication will, at least, cost you 3 ports (2 for crystal + 1 for serial comm.).

This can be especially critical when you are using small PICs.

Thanks for pointing to your routine - can be really usefull.

[BobK]

Hi Joe,

I got a hold of several of the kits that have the phanderson chip in them and NOW I see what your were referring to. What a hassle it was figuring out their code versus the straight forward method that I was referring to.

Thank you for the education!!!!

BobK

[Archangel]

Anyhow, if you want to make a (acceptable) serial communication, you'll need to clock your PIC with a crystal.

So, if you create an application where timing is not relevant, you may want to use all your available PIC's ports and use the internal oscillator

Monitoring your program with a serial communication will, at least, cost you 3 ports (2 for crystal + 1 for serial comm.).

This can be especially critical when you are using small PICs.

Thanks for pointing to your routine - can be really usefull.

Hi flotulopex,
There is another way, andthat is to use an dedicated External Oscillator Chip.
As I understand it you lose 1 pin.
JS

[Archangel]

Hi Joe,

I got a hold of several of the kits that have the phanderson chip in them and NOW I see what your were referring to. What a hassle it was figuring out their code versus the straight forward method that I was referring to.

Thank you for the education!!!!

BobK
Hi Bob,
Yep I have one of those backpack units, it works pretty well. The issue I have is I do not want to be stuck with a single source for serial displays. His formatting codes are just that, His. And someone up the street is using their own too, so how do you code to make use of more than ! source? That is why the code in the thread listed uses the same format as LCDOUT. Nothing extra to learn and remember, and easy to port back and forth.
JS