Saving RAM with LCD and UART

[IstvanK]

Before I developed my own libraries (which provide a much smaller code), to spare RAM these simple functions was used:


Lcd_COut: positioned print, the string is placed in the code memory (a little tricky)

Code: Select all

void Lcd_COut(char row, char col, const char *cptr) {
  char chr = 0;             //first, it is used as empty string
  Lcd_Out(row, col, &chr);  //nothing to write but set position.
  for ( ; chr = *cptr ; ++cptr ) Lcd_Chr_CP(chr); //out in loop
}

//examples:
  Lcd_COut(1, 4, "A constant string");
     //or
  const char demo[] = "This is also constant";
  Lcd_COut(2, 2, demo);

UART1_Write_CText: send a string placed in code memory

Code: Select all

void UART1_Write_CText(const char *cptr) {
  char chr;
  for ( ; chr = *cptr ; ++cptr ) UART1_Write(chr);
}

//example:
  UART1_Write_CText("A constant string");
     //or
  const char demo[] = "This is also constant";
  UART1_Write_CText(demo);

No any copying, no IRP bit setting, still need a lot less RAM. Try it!

"Manual link for string literals" is also working using const pointers

Greets
IstvanK

[Mince-n-Tatties]

No any copying

this uses 1 RAM location (plus a couple for the function) but this still copies from ROM to RAM so it is still going to have the same speed impact on code execution time which is the big downer for any of these methods.

no IRP bit setting

none of the previous examples on this thread need irp_bit control

need a lot less RAM

this method is also friendly in that the text can be any length (within reason) without the coder needing to change anything, i like that part!

I think this is a good option when code speed is less important than running from RAM by manually manipulating irp_bit. when code speed is important (or if you just want to use as much of your CHIP as you have paid for)... http://www.mikroe.com/forum/viewtopic.php?f=88&t=54419

[IstvanK]

Hi Mince;
If you've been talking about it, sincerely yours, but I disagree:

this uses 1 RAM location (plus a couple for the function) but this still copies from ROM to RAM so it is still going to have the same speed impact on code execution time which is the big downer for any of these methods.

Yes, exactly as the pure RAM version (see the .LST, which shows the library functions too), but here RAM is copied to RAM (for each character, in a loop), and also the RAM array must be filled from ROM, if the program begins (startup init). So it gives much more code and eats much more RAM.

Mine is really a bit slower than the RAM versions (since the ROM access is a bit more complex: it uses the DoICP call to get every char, instead of the faster FSR - INDF method), but this slowdown is insignificant, compared to the delay of the LCD's or the UART's character-output, which is used in the RAM versions too, same way, in a loop. See the .LST output again ...

Based on measurements of the slowdown is less than 0.6 % when the length of the string is minimum 3 (at 4 MHz, in case of LCD; much less if Uart is used). With a higher PIC clock or larger string the situation is even better.

Otherwise this "1 RAM location" is a local (reusable, shared) variable, exactly as in the pure (official) RAM version.
"plus a couple for the function": these variables are also shared/reusable (managed by the compiler), so not increase the RAM usage. Tried!


This is just my humble opinion ...
Anyway, everyone uses it what you want (enough when the program works well )

Best regards
Istvan

[janni]

"Manual link for string literals" is also working using const pointers

Indeed, no trace of compiler's wastefulness .

No any copying, no IRP bit setting, still need a lot less RAM. Try it!

This is certainly a good solution . There's remote possibility that compiler will place chr in one of higher memory banks and the IRP bit problem will arise (for example, if a user carelessly fills lower banks), but then one could use Lcd_Chr instead of Lcd_Out, and the risk would be removed completely.

Though my estimates of overhead are a bit higher, I agree that it's small compared to delays the LCD lib uses, and your solution adds less overhead than the string-copying one.

[Mince-n-Tatties]

it seems my post is being confused. so let me be clear...

I LIKE YOUR METHOD AND THINK IT IS A GOOD, FRIENDLY & EASY TO USE OPTION.

i hope that is clear now.

[jesousamx]

Thank You !! , I needed that !!!

[xmaspako]

Code: Select all

void LCD_Out_const(char x, char y, const char *txt){
char loc_text[__MAX_STRING_LENGTH];
char * dst;

  dst = loc_text;
  while (*dst++ = *txt++)
    ;

  LCD_Out(x, y, loc_text);
}

This can be used as workaround to save RAM in these situations.

Best regards.

...this was very useful for me. Thanks a lot, janko.kaljevic!