Displaying 4 different variables on an LCD - the best way?

[bigal_scorpio]

Hi to all,

I am making a project using a pic16F872 to measure 4 different ADC levels.

I have most of the code working now, I use PICBASIC PRO.

My question is when I send the data to the LCD what is the best way to do this? Is there a convention?

At present I am using $80 +8 for the start of the second lot of data and $C0 for the 3rd, $C0 +8 for the last.

This setup works and I just wondered if there was a better way or an optimum way to make the best use of the display concerning refresh rates and flicker etc.

How do you guys do it?

Thanks, Al

 

[Ian Rogers]

I always double buffer... I have a 17 character array that I use as a shadow writing pad.. That way I minimize the "spurious characters" that can appear.
It also eliminates any flicker..

 

[bigal_scorpio]

Hi Ian,

That sounds interesting mate, can you explain further or direct me to further info on it?

Al

 

[JimB]

Buffering the display.
An example using a project of mine, a DDS Signal Source, see the attachment.

I reserve 16 general purpose registers for the display, starting at a place I call DISPLAY_BASE.
During initialisation I clear these registers and the write a decimal point at position DISPLAY_BASE+4, and then "M" "h" "z" at positions DISPLAY_BASE +13, +14, and +15 respectively.

As the program runs, it writes either a "T" or an "S" at DISPLAY_BASE+0 and the frequency information in the appropriate places.

At the end of the program, before it goes to sleep waiting for something to change it writes out the contents of the registers DISPLAY_BASE+0:15
to the LCD.

One write to the LCD for all the info to be displayed, no flickering or funny characters, at least not after I had debugged the rest of the program.

I assume that Ian (Barney) Rogers has a similar approach, I am interested to find out.

JimB

 

[Ian Rogers]

As I program mainly in C, I use the sprintf(); function which makes life a whole lot better..

If I use basic I create a buffer array ( this could be 17 or 33 bytes long )... I usually store strings in EEPROM, so I write a function the fills the array with text values. I write a simple printf function that will convert up to a 32bit value with decimal places if required ( I use fixed point math )..

Lastly a single function that transfers all the array to the screen in one go...

It you look at this model.. this was written in Oshonsoft basic... the printf function right justify's the value as well.

 

[Mr RB]

I always double buffer... I have a 17 character array that I use as a shadow writing pad.. That way I minimize the "spurious characters" that can appear.
It also eliminates any flicker..

I average multiple readings at a specific frequency, then display at a multiple of that frequency.

For example to read the ADC at 10mS timing then average 25 readings which gives a lot higher ADC resolution and also updates the display every 250mS which is a nice update rate.

 

[Ian Rogers]

Mr RB! Same..... I do 24 readings ( oversampling ), with an update to the display 3-4 times a second.... works well....

 

[Mr RB]

No double buffering?

 

[Mike - K8LH]

No double buffering?

Who are you addressing, Roman? If it's me, I don't understand your question. Can you rephrase, please?

 

[Ian Rogers]

Who are you addressing, Roman? If it's me, I don't understand your question. Can you rephrase, please?

I thought he was addressing you Mike.... I always double buffer ( looks to me like you do too )..

 

[Mr RB]

Sorry Mike yes it was directed to you.

If you write a single digit to the display at a time you have the siutation where your display will be reading incorrectly, ie if it changes before the display sequence is completed. It's best to double buffer ie if the new data is ADC1 I would copy to a buffer ADC2 at a time when the display sequence was completed. More like;

seq++;
if(seq < 8) display_a_digit(ADC2,seq);
else
{
seq = 0;
ADC2 = ADC1;
}

So one step in the sequence of 9 does the double buffering, and the other 8 steps display the 8 digits.

 

[Mike - K8LH]

Hi RB,

I posted a simple method for updating an LCD display from a 32 character display buffer in the background via an ISR so I'm a bit confused by your comment. Is your comment and concern about how your main program would write an eight character ADC value into the display buffer? If so, wouldn't you just write the new eight digit ADC value, buffered or not, all at once into the display buffer three or four times per second? Your LCD writes to the display buffer in 'main' would be perceived as instantaneous since the ISR refreshes the entire LCD display from the buffer every 17 msecs (when using 500-usec interrupts).

 

[Mosaic]

I have an app that seems to require the buffering. Occasionally I'd get an odd character in the adc values readout. I have an adc sample in the 8 ms isr. But I don't think I need to buffer all the characters, just the ones that can be updated by ISR during the LCD write. Is this reasonable?

I do like Mike's approach to interleaving the LCD write though,kinda like multi threading. I had to do something similar a year back when sampling numerous adcs that had to complete inside of a time sensitive program loop. I would trigger the sample and then flag it with a sequential bit #, 1,2,4,8 etc. When the adc loop was called again (usually after the TAD time) the sample would be moved to a GPR (based on the flag bit) and the next channel selected & sample triggered.

 

[Ian Rogers]

I have an app that seems to require the buffering. Occasionally I'd get an odd character in the adc values readout. I have an adc sample in the 8 ms isr. But I don't think I need to buffer all the characters, just the ones that can be updated by ISR during the LCD write. Is this reasonable?

I found with these modules... If you have fixed text, ie... "VALUE = " after some time working... after a glitch or two it may read slightly different OR the whole thing shifts right or left. When double buffering, you refresh the screen every 250mS so the odd glitch is missed by the human eye... Our stuff is usually fitted to cranes and fork lift trucks... Imagine the amount of heavy duty solenoids clicking in and out.... Some controlled by me... You'll do anything to minimise little issues.

 

[ericgibbs]

hi,
New Thread here:

E.

 

[Mike - K8LH]

hi,
New Thread here:

E.

That's ok with me but shouldn't the new thread have started with post #8 where I introduced the method? As you have it now, the new thread is missing some important and vital context.

Regards, Mike

 

[Mosaic]

Can the average 16x2 LCD display :
https://www.newark.com/lumex/lcm-s0...lar Products&MER=PPSO_N_P_EverywhereElse_None

update with a single character write every 500uSec? Some how I thought it needed a bigger delay. Can anyone advise pls?

 

[Pommie]

Can the average 16x2 LCD display :
https://www.newark.com/lumex/lcm-s0...lar Products&MER=PPSO_N_P_EverywhereElse_None

update with a single character write every 500uSec? Some how I thought it needed a bigger delay. Can anyone advise pls?

In the datasheet I have, it states that a data write requires 46uS to complete so 500uS is plenty of time.

@Eric, Mike's original post isn't included and so I found the thread very confusing.
Edit, the new thread has Mike's post but this one doesn't which is even more confusing.

Mike.

 

[Mosaic]

46 uSec? ....when setting up to do a screen refresh based on a buffered display the Cursor must be located at the start which requires over 4 mSec, 160uSec for all other cmds, as per this doc.

https://www.electro-tech-online.com...478020Hitachi20chipset20compatible20LCD-1.pdf

I guess I have to manage the different timings to optimize the screen refresh. Or does the LCD automatically restart at col1, line1 when writing a character after the 1st 32?

 

[Mr RB]

No, to move the cursor to the desired location ready to write a character uses the instruction "set DDRAM address" and takes only 37uS.

Then each character you write shifts the cursor 1 space to the right, so you can write 16 characters on that line, after setting DDRAM address once at the start of the line.