CODE OPTIMISATION

[JANIS]

My project is a 12V car battery charger. I will use a graphic LCD for visualization. So far, I'm experimenting with visualization elements. I've started the code of the program, made a layout board with a graphical LCD to load the program code and check it in action, but something is not right. The program processing cycle time is very high. This is due to GLCD elements. I can't continue writing the program because this processing time is too large. Maybe someone can correct my code, the code is added. Thanks!

[Anobium]

Which piece of the code is slow? I think a video will help as we would have to build a project for this - a video will show us the issue.

[JANIS]

now_inc=!button_inc
if now_inc>prev_inc then
test=test+10
end if
prev_inc=now_inc
now_dec=!button_dec
if now_dec>prev_dec then
test=test-10
end if
prev_dec=now_dec

test_inverse=255-test
if test=255 then test=255

Buttons button_inc and button_dec works on the high front (rising edge). press the button to wait about 1 sec until test = test + 10 is executed

[Anobium]

Is the interrupt firing?

What is this doing? if test=255 then test=255

[JANIS]

Thanks Anobium. I think the video is not needed here. I hope you understand. converting the code as follows can hold the button, the variable amps_ref changes the value with an interval approx 1 sec.

if !button_inc then '' now_inc>prev_inc then
amps_ref++
end if
if !button_dec then ''now_dec>prev_dec then
amps_ref--
end if

[kent_twt4]

I think Anobium might be onto something there in that values are not attained as one might think. Or, values are only obtained when values loop back around after overflow.

Try some loops with static values just to make sure the work as you expect. So comment out the filled boxes Call then say use a Do Loop inside the Call to check the battery triangles like trimove:

For trimove = 0 to 4
  Select Case trimove
  ...
  ...
  wait 1 s
  End Select
 next

Same logic to check on the Call to fill the boxes.

It is a process till you find the culprit. When coding for a larger project, sometimes it is best to start at the beginning. Test the button press by themselves, then timeroverflow, glcd functions, even the a-d. Add them back together and fix the problems when they break.

Do you have external external pullup resistor and 0.1uf cap on the button? Or, use a software debounce routine.

[JANIS]

Thank you Kent , I use standard solution - pullup resistor. I can tell you that not always the capacitor should be used. I have had projects where it give an undesirable effect.
ohh. again a difficult and long process. Visualization takes 80% of the program you need.

[JANIS]

Kent, how were you thinking - software debounce routine? maybe it's an idea.

[kent_twt4]

This is the software debounce that I use. If the button is not noisy, then the wait time can be tightened up some. Might want to disable Timer interrupt (i.e. GIE= 0) in the sub, then enable on exit (GIE=1), when doing so?

Start:
  'read the button
  If button0 = 0 Then
    Call debounceButton
    If debounce = True Then
      led0 = NOT led0
    End If
  End If
goto Start

sub debounceButton
  debounce = False
  glitch = 0
Do
  If button = 0 Then
     debounce += 1
  else
     glitch += 1
  end if
  wait 10 ms
  If debounce > 2 Then
    debounce = true
    exit Do
  End If
  If glitch > 1 Then exit Do
Loop
end sub

[JANIS]

ANobium,
What is this doing? if test=255 then test=255 - part of its code has not been deleted from experiments.

It seems to me that most of the processing time is occupied by this part.

#include <glcd.h>

I delete all the box and triangle manipulations, but the code processing brake remains.

[JANIS]

Thank you, Kent! With the button filter everything is clear. But I am talking about program code processing time. In the program, the button is just the beginning, but there will be many more features that require faster processing time. include glcd.h establishes communication with a display on each cycle and takes time to process. Consequently, it breaking the processing of the rest of the program. I hope you understand what I mean.

[kent_twt4]

I may not fully understand what you are doing, but can continue with the conversation if you like.

Why would you need to display the glcd every cycle? This is a battery charge monitor after all. Refresh glcd every second, or split the tasks up?

If the charge current is critical, then use an ECCP module with an auto shutdown feature (e.g. 18f46k22).

Set up a State Machine. Start by defining how long it takes to update the glcd as a unit of time measured. Lets say for example you can update the screen in under 250 ms, then set that time as an on interrupt with the TimerX. Use a flag to keep track of the times it overflows and check that in main with a select case. You are using similar procedures in your program now, it just maybe could be organized a little differently.

So the State Machine structure might look like like:

overflows = 0
Main:
  If Timer250ms = True Then

    Select Case overflows
      Case 1
        'take a-d for volts and amps
        'refresh glcd volts and amps
        'check button presses
        'Timer250ms = False
      Case 2
        'read real time clock module
        'refresh glcd clock
        'check button presses
        'Timer250ms = False
      Case 3
        'update glcd volt figures
        'check button presses
        'Timer250ms = False
      Case 4
        'update glcd amps figures
        'could possibly do all glcd updates here
        'instead of splitting them up
        'check button presses
        'Timer250ms = False
    end select

  end if
goto Main

sub TimerX
   Timer250ms = True
  overflows = overflows++
  if overflows = 5 Then overflows = 1
end sub

[stan cartwright]

Instead of always updating the display, check if a value has changed and only update the display if it has changed.

[JANIS]

Thank you all for the suggestions I will try.

[JANIS]

I agree with stan cartwright. Maybe there are some suggestions for creating a code, how could a display update be simpler and more accurate?
I will take note of the suggestion of the kent_twt4 .

[stan cartwright]

If the display is slow , the glcds I use are fast...considering spi,i2c,
then just use a temp var
lastval =val
print val
do
if val <> lastval then print val : lastval=val
loop

You'd do this to stop flickering results...numbers, bar graphics

[Anobium]

I compiled the code. There is something fundementally wrong with the approach. Either a timer, or an errant code? I have tried to debug but it is a little hard to follow. I got the battery showing but I cannot really sort,

I am not sure what ADC values to set to make things work,

Simplify the code is my advice. The GLCD is not the issue.

[JANIS]

Anobium, the code will remain even more complicated. I'll try the stan cartwright idea in the new year.
Thank you friends!
Happy New Year!

[Anobium]

I tried at 64mhz. The code needs sorting, look at what Kent recommended.   I don't think another GLCD will help... but, I could be wrong.

[stan cartwright]

I only have a few different glcd that work with gcb. When I said "slow" displays, I was thinking of using the display in Picsimlab..which I thought was some real displays update speed.
little things like not testing the same value when you know the answer.

scale_volts_akku=volts_akku_AN1
if volts_akku_AN1>128 then scale_volts_akku=129  :percents_akku=100:goto done
if volts_akku_AN1<115 then scale_volts_akku=114  :percents_akku=0:goto done

if scale_volts_akku<115 then percents_akku=0:goto done
if scale_volts_akku=115  then percents_akku=10:goto done
if scale_volts_akku=116 or scale_volts_akku  =117 then percents_akku=20:goto done
if scale_volts_akku=118  then percents_akku=30:goto done
if scale_volts_akku=120  then percents_akku=40:goto done
if scale_volts_akku=121 or scale_volts_akku = 122 then percents_akku=50:goto done
if scale_volts_akku=123  then percents_akku=60:goto done
if scale_volts_akku=124 then percents_akku=70:goto done
if scale_volts_akku=125 or percents_akku=126  then percents_akku=80:goto done
if scale_volts_akku=127 or  percents_akku=128 then percents_akku=90:goto done
if scale_volts_akku>128 then percents_akku=100
:done

[William Roth]

GLCD displays that require each pixel to be bit-banged will be very slow. These cheapo GLCD displays have no builtd in fonts and no graphics processor.

I just tested the character speed of an ILI9486 based GLCD display operating on a Mega 328P @ 16 MHz. It took 284 ms to process & display 20 characters using "GLCDPrint". That is 14 ms to write only 1 character and a speed of only 71 characters per second. A cheap 4X20 LCD display can do thousands of characters per second, but has no graphics capabilies.

I could be wrong, but I doubt that the speed of these "dumb" GLCD dislpays can be much improved.

If the display speed needs to be lightning fast so as not to bog down the program, then I would suggest using a display with a built in graphics processor ( Nextion or4D). If your #1 specification is "cheap" then a character LCD may work OK if you can do without the graphics.

William

[Anobium]

The core issue is the coding style.

[kent_twt4]

The KS0108 type of glcd displays have 8 pages of data space with two controllers that divide the display in half. Think of that as 16 rectangular regions 8 bits high x 8 on the y axis and between 0-63bits and 64-127bits on the x axis. It should be fast enough as long as you are not trying to do a lot of pixel by pixel instructions, avoid if possible?

Using byte wide instructions that are aligned to the page boundaries coud really help if required. Do this by using constant tables and then preloading them into a buffer before executing the commands. A lot of the OP's demands on the glcd could be reduced to those constants, and maybe skip the outline box and who knows what else to make the code more efficient. Didn't want to get into that until further progress was made on the original code.

[Anobium]

We can easily use the double approach the we have for the others GLCDs. Would resolve this issue with the GLCD library.

But, I actually ran the user code - yes the GLCD, pots etc.. It is very recursive and the GLCD performance is not the core issue.

[JANIS]

Thank you all! I use the stan cartwright suggestion. I'm working on the program code and it is ok for the time . William Roth, I've decided to use KS0108, so I'm trying to do everything to build my own project. When the project will be ready (if I succeed at all and will be ready),
Then I will publish the code and the scheme, pcb.