PIC 18F46K22, MikroC: 'Multitasking' simple and time consuming task

Question

I'm receiving a UART message containing an array of raw sensor data. I'm reading the message within the main loop of the program. There are 2 things I need the PIC to do with the different values. Display it on a LCD (somewhat time consuming) and, atleast for one of the values, change a LED-bar connected to PORTD accordingly to the value (rather simple).

In the main loop this is my current way of working:

Request sensor data from external device on UART
Receive bytes array from external device
Do calculation to convert raw sensor data to actual values/units

Display RPM value on LCD-bar using this code:

 if (RPM < 99)
 {
   PORTD = 0;
 }

 if (RPM > 100)
 {
   PORTD = 0x01;
 }

 if (RPM > 2400)
 {
   PORTD = 0x03;
 }

 if (RPM > 3700)
 {
   PORTD = 0x07;
 }

 if (RPM > 4900)
 {
   PORTD = 0x0F;
 }

 if (RPM > 6200)
 {
   PORTD = 0x1F;
 }

 if (RPM > 7400)
 {
   PORTD = 0x3F;
 }

 if (RPM > 8700)
 {
   PORTD = 0x7F;
 }

 if (RPM > 10000)
 {
   PORTD = 0xFF;
 }

Finally displaying multiple values on a LCD. Thus removing old value, drawing the label, set new value, again draw the label.

That last task slows the whole loop down, which is making the LED-bar function to 'laggy'. I got the suggestion to check if the value(s) have changed before redrawing the labels, to avoid unnecessary drawing. But all the values are rather rapid changing values like RPM and such.

Any suggestion would be welcome!!

chux - Reinstate Monica · Accepted Answer · 2013-06-04T16:35:13.837

2

Data going to an display does not need to change faster than the viewer can sense. If your changes are greater than a threshold (40 to 100 Hz), then only use the last change that occurred in the previous period.

int UpdateValue;
int UpdateNeeded = 0;

void TimerServiceRountine() { // called at N (60) Hz.
  if (UpdateNeeded) {
    UpdateNeeded = 0;
    UpdateLCD(UpdateValue);
  }
  // ...
}

// Call this with each RPM
void UpdateDisplay(int Value) {
  UpdateValue = Value;
  UpdateNeeded = 1;
}

Further refinement: Only call UpdateLCD(x) if x is different from before.

edited Jun 04 '13 at 16:35

answered Jun 04 '13 at 16:27

chux - Reinstate Monica

143,097
13
135
256

Ok lets see if I understand correctly. I can call UpdateDisplay during the UART request/receive routine and thus when a new RPM value is available. Then check if the value is different from before. Only then call UpdateNeeded = 1. Do I need to use TimerServiceRoutine as interrupt (ISR) from e.g. TMR0? – Felix Jun 04 '13 at 16:45
Almost. Your check for "if the value is different" should be within `if (UpdateNeeded) {` as in `if (UpdateValue != OldUpdateValue) { UpdateLCD(UpdateValue); OldUpdateValue = UpdateValue; }` – chux - Reinstate Monica Jun 04 '13 at 16:51
Recommend TimerServiceRoutine() is called periodically, but not within an ISR. – chux - Reinstate Monica Jun 04 '13 at 16:53
Hmm but how to call at n (60) Hz? – Felix Jun 04 '13 at 18:57
Use timer with interrupt time set to 16ms? That'll give around 60 interrupts a minute. – Felix Jun 04 '13 at 19:17
Yes. Note, see Wikipedia Persistence of vision: LCD refresh rate. (~ 60 Hz) – chux - Reinstate Monica Jun 04 '13 at 19:23
let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/31207/discussion-between-felix-and-chux) – Felix Jun 04 '13 at 20:18

score 0 · Answer 2 · answered Aug 13 '13 at 16:15

Solution idea #1

My guess is that the slowness of the LCD part is due to that you need to wait for the LCD to process the commands sent to it (common with certain alphanumeric LCDs).

Your main loop otherwise could probably do several thousand cycles a second.

If this is the case, then you should implement a state machine for the LCD output in the main loop. This state machine would clock out the necessary commands to the LCD for updating the display, one by one, once in each run of the main loop, only if the LCD is ready to accept the new command.

This way your main loop can run free of waiting for the LCD, while the LCD also gets updated sufficiently fast (depending on whether the turnaround time of the main loop without the LCD task would be sufficiently low: optimally less than the typical "busy" time of the LCD).

Solution idea #2

This is more complicated and applies if the LCD process is rather calculation heavy for some reason (pixel by pixel work on a graphic LCD?).

Even this case a similar approach to Solution #1 may work well. If you can split up the LCD task to smaller chunks with roughly similar processing time requirements, you may speed up the main loop (by only processing one chunk of these at once).

If you rather would prefer a more accurate timing for the main task, then the main task needs to be put in an interrupt (Assuming that you request the data from your sensor, you need a timer IT to time these requests). The main loop then would only work with the LCD.

Common elements

In all cases you do more samplings while a single fragmented LCD display data construction processes. This needs some data management: You have to "sample" (mostly copy away, interrupts disabled in the case of the last solution) your data going onto the LCD before starting building the display.

All the solutions I presented are "ideal" in that sense they could "automatically" pull out the most (in the term of display update frequency) from your hardware using all cycles available. You only need to select the appropriate method for your situation.

PIC 18F46K22, MikroC: 'Multitasking' simple and time consuming task

2 Answers2